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: 4.2.0.0.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 4.3.2.2 and 4.4.0.0.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) [NinjaEdit]
Reproducible with: Version: 5.4.0.0.alpha0+ 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! Warm Regards, QA Team MassPing-UntouchedBug
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: 6.1.0.2 (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%"
Created attachment 163965 [details] Draft unit test document with test cases
Created attachment 164678 [details] 2-page test document to avoid regression
Daniel Arato (NISZ) committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d336e6c26012255015d3fc0caf8e7fafe14bd8f2 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: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Version: 7.1.0.0.alpha0+ (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
(In reply to NISZ LibreOffice Team from comment #19) > Version: ... ... a description of what with that version is right/wrong missing?
Created attachment 165480 [details] DOCX compared after the fix It's marked Verified so it means OK with 7.1+.
the commit already includes a unittest
*** Bug 89699 has been marked as a duplicate of this bug. ***