Bug 77794 - FILEOPEN: DOCX - incorrect placement of image inside a cell when position option "Layout in table cell" is set
Summary: FILEOPEN: DOCX - incorrect placement of image inside a cell when position opt...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.2.3.3 release
Hardware: Other All
: medium normal
Assignee: Justin L
URL:
Whiteboard: target:7.1.0
Keywords: filter:docx
Depends on:
Blocks: DOCX-Limitations DOCX-Images OOXML-Transitional-2010vs2013 DOCX-compatibilityMode-15
  Show dependency treegraph
 
Reported: 2014-04-23 06:46 UTC by Yousuf Philips (jay) (retired)
Modified: 2020-10-20 10:52 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
microsoft logo placement in LibO 4.2 (40.66 KB, image/jpeg)
2014-04-23 06:46 UTC, Yousuf Philips (jay) (retired)
Details
microsoft logo in word 2010 (40.57 KB, image/jpeg)
2014-04-23 06:47 UTC, Yousuf Philips (jay) (retired)
Details
microsoft logo in word 2013 (40.24 KB, image/jpeg)
2014-04-23 06:48 UTC, Yousuf Philips (jay) (retired)
Details
Side by side LibO 4.3 and MS Office 2010 (98.30 KB, image/png)
2014-04-25 06:32 UTC, Florian Reisinger
Details
Compare MS 2010 and LO 4.3.3 - just a column size.jpg (124.75 KB, image/jpeg)
2014-11-03 15:23 UTC, Timur
Details
logo position - Image Layout Options for LO 4.4.0 MSO 2010 MSO 2013.pdf (132.05 KB, application/pdf)
2015-01-30 12:23 UTC, Timur
Details
trimmed samples from word 2010, 2013 and strict xml (115.89 KB, application/zip)
2017-09-27 03:22 UTC, Yousuf Philips (jay) (retired)
Details
Screenshot of the 2010-saved document in Word and Writer (71.48 KB, image/png)
2020-05-22 13:16 UTC, NISZ LibreOffice Team
Details
How_to_license_the_operating_system_Windows_8_COMPAT12.docx: in 2010 compat mode (113.30 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-05-27 13:22 UTC, Justin L
Details
debug_patch77794.diff: a patch that works for How_to_license_the_operating_system_Windows_8_new.docx (2.50 KB, patch)
2020-05-30 09:12 UTC, Justin L
Details
missing-path.docx_COMPAT15.docx: from ooxmlexport10 - but changed compat to 15 (13.79 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-05-30 10:51 UTC, Justin L
Details
screenshot in LO 7.1+ in Linux (271.85 KB, image/png)
2020-09-11 18:56 UTC, BogdanB
Details
Logo compared MSO LO in Windows (233.03 KB, image/png)
2020-10-20 10:48 UTC, Timur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) (retired) 2014-04-23 06:46:34 UTC
Created attachment 97802 [details]
microsoft logo placement in LibO 4.2

I download the .docx file found at < http://download.microsoft.com/documents/rus/microsoft4you/How_to_license_the_operating_system_Windows_8_new.docx > and when i open it in 3.6 - 4.2 the purple microsoft background image is not place correctly in relationship to the output of word 2013 (most likely the version of word used to create the file), but is placed correctly according to word 2010.
Comment 1 Yousuf Philips (jay) (retired) 2014-04-23 06:47:30 UTC
Created attachment 97803 [details]
microsoft logo in word 2010
Comment 2 Yousuf Philips (jay) (retired) 2014-04-23 06:48:00 UTC
Created attachment 97804 [details]
microsoft logo in word 2013
Comment 3 Florian Reisinger 2014-04-25 06:32:37 UTC
Created attachment 97937 [details]
Side by side LibO 4.3 and MS Office 2010

Hi Jay, can confirm this with Version: 4.3.0.0.alpha1+
Build ID: 4916dd570fb7bb5447f1d63fba46ac0b3a10dd14
TinderBox: Win-x86@47-TDF, Branch:MASTER, Time: 2014-04-20_03:53:39

The text you see in the image is vanished and there is a table instead....
Comment 4 Yousuf Philips (jay) (retired) 2014-04-25 09:14:32 UTC
The behaviour of 4.3 is a regression, but relates to bug 77848 which is the transparency of loaded tables being white rather than transparent.
Comment 5 Florian Reisinger 2014-04-25 13:25:53 UTC Comment hidden (obsolete)
Comment 6 Andras Timar 2014-04-29 13:10:38 UTC
So, it's not a regression.
Comment 7 Yousuf Philips (jay) (retired) 2014-04-29 13:17:19 UTC
I'm assuming the issue here is that its a update in the docx specification that office 2013 understands, but office 2010 does, and as a result it looks the same in LibO as office 2010, but not as in office 2013, which the file was created in.
Comment 8 Florian Reisinger 2014-05-18 06:20:18 UTC Comment hidden (obsolete)
Comment 9 Timur 2014-11-03 15:23:02 UTC Comment hidden (obsolete)
Comment 10 Yousuf Philips (jay) (retired) 2014-11-03 16:59:09 UTC
Hi Timur,

This bug is about the location image on the page, which libreoffice isnt understanding likley understandy in the docx format.
Comment 11 Timur 2015-01-30 12:23:56 UTC
Created attachment 112950 [details]
logo position - Image Layout Options for LO 4.4.0 MSO 2010 MSO 2013.pdf

OK, I see the problem.
Difference between MSO 2010 and 2013 is in Image Layout Position option "Layout in table cell" that exists in either, but this file has it turned on in MSO 2013.
If we open the file in MSO 2010 and turn that on manually, image is in the same position as MSO 2013.

I notice there might be another bug here: although columns are of the same width, text layout is not the same. The reason may be that in LO there is paragraph indent after text of 0,03 cm. If that's set to 0, text layout is the same. I don't know how to check it in MSO.
Comment 12 Robinson Tryon (qubit) 2015-12-09 18:44:58 UTC Comment hidden (obsolete)
Comment 13 Yousuf Philips (jay) (retired) 2017-09-27 03:21:13 UTC
As Timur mentioned in comment 11, the issue boils down to the "Layout in table cell" position option being set in the docx and LO not being able to handle it.

Here is the relevant xml - <wp:anchor ... layoutInCell="1" ...>

@Regina: is there an equivalent odf attribute that the position of an object takes the table cell top left corner as the basis of its positioning rather than the page's top left corner?

@Justin, @Mike: would it be simple enough to take the cell's top corner value and add it to the image's top corner value to give it its correct top corner value based on the page's top corner?
Comment 14 Yousuf Philips (jay) (retired) 2017-09-27 03:22:18 UTC
Created attachment 136558 [details]
trimmed samples from word 2010, 2013 and strict xml
Comment 15 NISZ LibreOffice Team 2020-05-22 13:16:38 UTC
Created attachment 161142 [details]
Screenshot of the 2010-saved document in Word and Writer

The version saved by Word 2010 looks good since:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=e042a83843ed2573dbce9338058b3dc545dd6898

author	Miklos Vajna <vmiklos@collabora.com>	2019-10-15 21:44:42 +0200
committer	Miklos Vajna <vmiklos@collabora.com>	2019-10-16 08:20:37 +0200

writerfilter: sync layout-in-cell vs wrap-though behavior with ww8 import

However the 2013 and strict versions are still aligned to the very left of the page.
Comment 16 Justin L 2020-05-27 13:22:02 UTC
Created attachment 161333 [details]
How_to_license_the_operating_system_Windows_8_COMPAT12.docx: in 2010 compat mode

The is related to compatbilityMode=15 (2013).  I'm submitting here a copy of the document from comment 0, but with that settings.xml value changed to =12 (2007). Word 2013 displays this version of it just like LO/2010 does.
Comment 17 Justin L 2020-05-30 09:12:38 UTC
Created attachment 161421 [details]
debug_patch77794.diff: a patch that works for How_to_license_the_operating_system_Windows_8_new.docx

The UI in Word suggests that "Layout in Cell" is enforced now, and thus basically the option is ignored (since in this case LayoutInCell=0).

<wp:anchor distT="0" distB="0" distL="114300" distR="114300" simplePos="0" relativeHeight="251685888" behindDoc="1" locked="1" layoutInCell="0" allowOverlap="1" wp14:anchorId="06CE213F" wp14:editId="2CDE1DEB">

If that is true. then my patch might be OK. But right now I am in regression shock from the OIT testing, so I am very reluctant to implement any theories about things I really know nothing about.
Comment 18 Justin L 2020-05-30 10:51:58 UTC
Created attachment 161425 [details]
missing-path.docx_COMPAT15.docx: from ooxmlexport10 - but changed compat to 15

There are two existing unit tests that have some object in a table with LayoutInCell=false, so they can be tested to see what impact changing the compatibilityMode has. Unfortunately they do not clearly prove or disprove my theory.

In this first test, based on the original attachment 161424 [details] from ooxmlexport10, the arrow no longer points directly to the number when in 2013 mode. (However, currently LO positions it incorrectly for both cases - see bug 133522 for that.)


The other unit test is tdf129888dml.docx from ooxmlexport14 - where the page number should disappear in 2013 mode.
Comment 19 Justin L 2020-08-13 10:21:18 UTC
proposed patch at http://gerrit.libreoffice.org/c/core/+/100651
Comment 20 Justin L 2020-08-13 13:17:26 UTC
Going through the linked bugs:
-bug 112684's document is irrelevant.
-bug 105971 duplicate of bug 115896 are about .doc's LayoutInCell.  Irrelevant.
-bug 115883 just uses this bug's document as an example.
-bug 114034 doesn't seem to have a table - irrelevant.
-bug 116256 has an ugly textbox in frame in table in frame example - useless.
-bug 135595's document was used as the unit test for my proposed patch.

everything in trimmed samples.zip from comment 14 looks fine.
Comment 21 Justin L 2020-08-14 10:29:46 UTC
(In reply to Justin L from comment #17)
> I am very reluctant to implement any theories
> about things I really know nothing about.
bug 116256 comment 11 and other examples have convinced me that this is really needed - especially since we now save as compatibiltyMode = 15. Thus we will start generating a lot more of these kinds of documents, and had better import them the same way that MS Word does.

The one problem is that LO doesn't default to "Keep inside text boundaries" for flies - and so it is only set after round-tripping to DOC/X - and thus will look different from the way the user initially laid it out.
Comment 22 Commit Notification 2020-08-15 06:28:52 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/7cc353df4f0993228984fcda3efb2c9181dddafb

tdf#77794 writerfilter: compat15 - always bLayoutInCell

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.
Comment 23 BogdanB 2020-09-11 18:56:31 UTC
Created attachment 165405 [details]
screenshot in LO 7.1+ in Linux

This is how it looks on my
Version: 7.1.0.0.alpha0+
Build ID: 3a22f5a589e822e7ca8bbb00e38a3aff93ed7ba5
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-US (ro_RO.UTF-8); UI: en-US
Calc: threaded

The background is ok now, but the text is not 100% ok.
See the screenshot.
Comment 24 Timur 2020-10-20 10:48:09 UTC
Created attachment 166538 [details]
Logo compared MSO LO in Windows

Logo is fine, meaning bug is fixed - thanks Justin.

Text in logo in Linux is another issue, replacement font for Segoe UI Light.
It's OK in my Windows, where I have MSO installed.