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.
Created attachment 97803 [details]
microsoft logo in word 2010
Created attachment 97804 [details]
microsoft logo in word 2013
Created attachment 97937 [details]
Side by side LibO 4.3 and MS Office 2010
Hi Jay, can confirm this with Version: 188.8.131.52.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....
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.
So, it's not a regression.
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.
Why was I assigned? Sorry for spam...
Created attachment 108845 [details]
Compare MS 2010 and LO 4.3.3 - just a column size.jpg
If we compare MS 2010 and LO 4.3.3, it's just a column size that differs.
This bug is about the location image on the page, which libreoffice isnt understanding likley understandy in the docx format.
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.
Migrating Whiteboard tags to Keywords: (filter:docx)
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?
Created attachment 136558 [details]
trimmed samples from word 2010, 2013 and strict xml
Created attachment 161142 [details]
Screenshot of the 2010-saved document in Word and Writer
The version saved by Word 2010 looks good since:
author Miklos Vajna <firstname.lastname@example.org> 2019-10-15 21:44:42 +0200
committer Miklos Vajna <email@example.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.
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.
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.
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.
proposed patch at http://gerrit.libreoffice.org/c/core/+/100651
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.
(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.
Justin Luth committed a patch related to this issue.
It has been pushed to "master":
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:
Affected users are encouraged to test the fix and report feedback.
Created attachment 165405 [details]
screenshot in LO 7.1+ in Linux
This is how it looks on my
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
The background is ok now, but the text is not 100% ok.
See the screenshot.
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.