Bug 69647 - FILEOPEN: wrong spacing/disctance of text and picture (shape?) in docx (wrap involved?)
Summary: FILEOPEN: wrong spacing/disctance of text and picture (shape?) in docx (wrap ...
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
3.4.0 release
Hardware: Other All
: medium normal
Assignee: Dániel Arató (NISZ)
Whiteboard: BSA target:7.1.0
Keywords: filter:docx, preBibisect, regression
Depends on:
Blocks: DOCX-Images DOCX-Anchor-and-Text-Wrap
  Show dependency treegraph
Reported: 2013-09-21 15:56 UTC by Adam CloudOn
Modified: 2020-10-02 10:02 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:

DOCX containing image and text (189.60 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2013-09-21 15:56 UTC, Adam CloudOn
Comarison screenshot between LibreOffice and MS Word (844.99 KB, image/png)
2013-09-21 15:57 UTC, Adam CloudOn
Comarison screenshot between LibreOffice and MS Word (705.28 KB, image/png)
2013-09-21 16:10 UTC, Adam CloudOn
ODT file with the same issue (28.73 KB, application/vnd.oasis.opendocument.text)
2013-09-25 20:38 UTC, Ahmad Harthi
An example with line spacing "double" and "300%" (29.54 KB, application/vnd.oasis.opendocument.text)
2018-07-24 15:22 UTC, Regina Henschel
Draft unit test document with test cases (13.15 KB, application/vnd.oasis.opendocument.text)
2020-08-05 12:44 UTC, László Németh
2-page test document to avoid regression (5.23 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-08-25 17:08 UTC, László Németh
DOCX compared after the fix (500.87 KB, image/png)
2020-09-14 09:48 UTC, Timur

Note You need to log in before you can comment on or make changes to this bug.
Description Adam CloudOn 2013-09-21 15:56:41 UTC
Created attachment 86261 [details]
DOCX containing image and text

Problem description: 
When LO loads a DOCX that has text and an image, LO shows the image too far from the text (not like in Word).

Steps to reproduce:
1. Load the attached DOCX in LO
2. The image is too far from the text

Current behavior:
LO renders the image too far from the text

Expected behavior:
LO should render the image and text like MS Word
Operating System: All
Version: Master
Comment 1 Adam CloudOn 2013-09-21 15:57:25 UTC
Created attachment 86262 [details]
Comarison screenshot between LibreOffice and MS Word
Comment 2 Adam CloudOn 2013-09-21 16:10:36 UTC
Created attachment 86265 [details]
Comarison screenshot between LibreOffice and MS Word
Comment 3 Cor Nouws 2013-09-25 18:12:54 UTC Comment hidden (obsolete)
Comment 4 Cor Nouws 2013-09-25 18:25:00 UTC
Difference visible in the UI, dialog Picture, tab Wrap:

3.3.4 (fine):    Wrap None
3.4.0 (broken):  Wrap Optimal

(these can not be set for the picture
 all I get in the context menu is Wrap > Edit contour )
Comment 5 Ahmad Harthi 2013-09-25 20:29:41 UTC
Hi, this is a layout issue not an import/export bug.

You can check by doing the following:

1. write some text
2. insert an picture and change anchor to "as a character"
3. make the picture on the line with previous text
4. add more text until the picture comes to next line
5. make the paragraph spacing "Proportional: 115%"

You'll find that the picture jumps down by "a lot" much more than 115%, this doesn't happen to text only pictures and maybe objects.
Comment 6 Ahmad Harthi 2013-09-25 20:38:54 UTC
Created attachment 86600 [details]
ODT file with the same issue
Comment 7 tommy27 2014-10-19 19:06:43 UTC
bug still present in LibO and
Build ID: 3e2bd1e4022e25b77bcc8eba5e02c1adc57008a1
TinderBox: Win-x86@42, Branch:master, Time: 2014-10-16_01:04:13

tested under Win7x64
Comment 8 Timur 2014-11-03 15:41:51 UTC
Why do shapes that have wrap option loose it on import?
I'd say that's the same problem here and with https://bugs.freedesktop.org/attachment.cgi?id=60704 from Bug 49229.
That case is so common, I think it's for MAB.
Comment 9 Timur 2014-11-03 16:09:19 UTC
Another issue, but interesting title: Bug 78756 - FILEOPEN: DOC importer ignores table's "Wrap Around" property.
Comment 10 Mike Kaganski 2015-12-10 08:49:55 UTC
Here, at the first glance, the problem is not with wrap, but with the line spacing calculations. It seems that current LO (since 3.4) calculates 115% from the actual line height, not from font metric, as do MS Office and previous LO versions. Since the picture is anchored as character, it makes the line height much greater, and 15% of it is a considerable amount, visible in this case.
Comment 11 Robinson Tryon (qubit) 2015-12-14 05:41:05 UTC Comment hidden (obsolete)
Comment 12 Telesto 2016-12-07 08:32:05 UTC
Reproducible with:
Build ID: 2bad9f1cd8da0cd3d8ff33e875eaf10c1fd9d0bf
CPU Threads: 4; OS Version: Mac OS X 10.12.1; UI Render: default; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2016-11-29_01:04:44
Locale: nl-NL (nl_NL.UTF-8); Calc: group
Comment 13 QA Administrators 2017-12-08 08:06:37 UTC Comment hidden (obsolete)
Comment 14 Regina Henschel 2018-07-24 15:16:36 UTC
LibreOffice does a wrong calculation of the height of the "line box". The value "Line Spacing" in the UI belongs to the attribute fo:line-height (http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#property-fo_line-height). That refers to section §7.15.4 in XSL 2001. (https://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#line-height) And that refers to https://www.w3.org/TR/CSS2/visudet.html#propdef-line-height

There it is defined, that the percent value refers to the font size of the element. In the attached document the line-height value is 115% and the font-size is 12pt. So that gives a computed height of 13.8pt. That is obviously not tall enough for the image. Therefore the height is extended, so that the image fits into it.
(Some rules are in https://www.w3.org/TR/2011/REC-CSS2-20110607/visuren.html#inline-formatting)

As  Mike Kaganski already mentioned, LibreOffice seems to calculate it different: It does not base the line-height on the font size, but uses the vertical extend of the text including the image and then it multiplies it with the percent value. So for the height above the baseline the resulting value is 11.2cm (= 9.74cm from the image multiplied with 1.15). That results in ca 1.46cm (=11.2cm-9.74cm) additional space above the image.

The error becomes more obvious, if you set "Line spacing" to "double" or to e.g. 250%.

I do not have a version, that makes it correct. I see the error already in OOo2.4, so it is inherited from OpenOffice.

The error is not a problem of the import filter for docx, but it can be seen in own ODF files as well.

I see this error still in Version: (x64)
Build ID: b3972dcf1284967612d5ee04fea9d15bcf0cc106
CPU threads: 8; OS: Windows 10.0; UI render: default; 
Locale: de-DE (en_US); Calc: CL
Comment 15 Regina Henschel 2018-07-24 15:22:44 UTC
Created attachment 143729 [details]
An example with line spacing "double" and "300%"
Comment 16 László Németh 2020-08-05 12:44:09 UTC
Created attachment 163965 [details]
Draft unit test document with test cases
Comment 17 László Németh 2020-08-25 17:08:49 UTC
Created attachment 164678 [details]
2-page test document to avoid regression
Comment 18 Commit Notification 2020-08-28 11:14:41 UTC
Daniel Arato (NISZ) committed a patch related to this issue.
It has been pushed to "master":


tdf#69647 sw layout: fix line spacing with inline pictures

It will be available in 7.1.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:

Affected users are encouraged to test the fix and report feedback.
Comment 19 NISZ LibreOffice Team 2020-09-14 07:17:45 UTC
Version: (x64)
Build ID: 34a09c9c61bff30e8c4d16132bb47b2b1b16e422
CPU threads: 4; OS: Windows 10.0 Build 17134; UI render: Skia/Raster; VCL: win
Locale: hu-HU (hu_HU); UI: hu-HU
Calc: threaded
Comment 20 Mike Kaganski 2020-09-14 09:20:00 UTC
(In reply to NISZ LibreOffice Team from comment #19)
> Version: ...

... a description of what with that version is right/wrong missing?
Comment 21 Timur 2020-09-14 09:48:40 UTC
Created attachment 165480 [details]
DOCX compared after the fix

It's marked Verified so it means OK with 7.1+.
Comment 22 Xisco Faulí 2020-09-15 13:44:01 UTC
the commit already includes a unittest