Created attachment 86261 [details]
DOCX containing image and text
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
LO renders the image too far from the text
LO should render the image and text like MS Word
Operating System: All
Version: 18.104.22.168.alpha0+ Master
Created attachment 86262 [details]
Comarison screenshot between LibreOffice and MS Word
Created attachment 86265 [details]
Comarison screenshot between LibreOffice and MS Word
Was fine in 3.3.4, and not OK in 3.4.0
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 )
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.
Created attachment 86600 [details]
ODT file with the same issue
bug still present in LibO 22.214.171.124 and 126.96.36.199.alpha0+
Build ID: 3e2bd1e4022e25b77bcc8eba5e02c1adc57008a1
TinderBox: Win-x86@42, Branch:master, Time: 2014-10-16_01:04:13
tested under Win7x64
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.
Another issue, but interesting title: Bug 78756 - FILEOPEN: DOC importer ignores table's "Wrap Around" property.
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.
Migrating Whiteboard tags to Keywords: (preBibisect)
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
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
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: 188.8.131.52 (x64)
Build ID: b3972dcf1284967612d5ee04fea9d15bcf0cc106
CPU threads: 8; OS: Windows 10.0; UI render: default;
Locale: de-DE (en_US); Calc: CL
Created attachment 143729 [details]
An example with line spacing "double" and "300%"