Bug 137850 - Fileopen DOCX: text box shapes in wrong zOrder position compared to Word 2013 and higher - FIXED (misc problems still noted in comment 12).
Summary: Fileopen DOCX: text box shapes in wrong zOrder position compared to Word 2013...
Status: RESOLVED DUPLICATE of bug 138782
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Attila Bakos (NISZ)
Whiteboard: compatibilityMode15 target:7.1.0
Keywords: bibisected, bisected, filter:docx
Depends on:
Blocks: DOCX-compatibilityMode-15
  Show dependency treegraph
Reported: 2020-10-29 09:33 UTC by Timur
Modified: 2024-01-12 17:53 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

FAHR CASE_word2003.pdf: How it looks in Word 2010 and 2003 (243.36 KB, application/pdf)
2020-10-30 08:16 UTC, Justin L
Comparison LibreOffice 7.1 master and MSO 2010 (171.78 KB, image/png)
2020-10-30 09:54 UTC, Xisco Faulí
FAHR_compat11.docx: compatibilityMode 11 instead of 15. (402.87 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-10-30 10:51 UTC, Justin L
FAHR CASE-reduced-c15.docx: bare minimum example. (25.74 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-11-09 10:59 UTC, Justin L
wrapModes_withBehindDoc.zip: hand-edited to show how various wrapping is affected by behindDoc. (95.09 KB, application/zip)
2020-11-09 12:20 UTC, Justin L
How the original file looks now in Word 2013 and Writer (178.44 KB, image/png)
2020-12-08 13:51 UTC, NISZ LibreOffice Team

Note You need to log in before you can comment on or make changes to this bug.
Description Timur 2020-10-29 09:33:54 UTC
Fileopen of attachment 134969 [details] MSO docx regression issue that text box shapes (2015 and months) are in wrong position. Seen as 1. from screenshot attachment 166835 [details].

commit c25dae6618bdf573228be38837dfa02a0cc0f884
Date:   Sat Jul 15 15:19:28 2017 +0200
    source cc438f60d6ad0855f754dd32da9c9a80c7cabf92
    prev source 403ddd6cb1c0d6a0e0db105e68f58fe40057cb42

author	Justin Luth <justin_luth@sil.org>	2017-07-06 14:54:27 -0400
committer	Justin Luth <justin_luth@sil.org>	2017-07-15 03:39:26 +0200
commit cc438f60d6ad0855f754dd32da9c9a80c7cabf92 (patch)
tree 13c44745982a0d262096000a09e889d4c3c39c8b
parent 403ddd6cb1c0d6a0e0db105e68f58fe40057cb42 (diff)
tdf#103978 textboxhelper: syncProperty OPAQUE (wrap in background)

Commit also in bug 111899 marked as duplicate of bug 104602.

Justin, please see this.
Comment 1 Justin L 2020-10-30 08:16:29 UTC
Created attachment 166866 [details]
FAHR CASE_word2003.pdf: How it looks in Word 2010 and 2003

It is hard to say whose bug this is. In Word 2003 and 2010, the arrow shape is not in the background, so it covers text and the other shapes - just like LO now does. I'm not considering this a regression.
Comment 2 Xisco Faulí 2020-10-30 09:54:53 UTC
Created attachment 166868 [details]
Comparison LibreOffice 7.1 master and  MSO 2010
Comment 3 Justin L 2020-10-30 10:51:03 UTC
Created attachment 166871 [details]
FAHR_compat11.docx: compatibilityMode 11 instead of 15.

Please note that this bug report refers to notation #1 in attachment 166835 [details] which is referring to whether "2015" and "May" textboxes are visible.  The bibisect correctly identifies the zOrder related commit that puts them in the "hell" layer. The large arrow shape itself is (and is supposed to be) in the "heaven" layer.

So comment 2's comparison re-confirms what I said earlier.

This is affected by compatibilityMode. When I change the value of compatibilityMode from 15 to 11, then even Word 2016 displays like Word 2010. So this is all related to new rules that MS has introduced that only work in Word 2013 or newer, and LO has never learned what those new rules are.
Comment 4 Timur 2020-10-30 15:22:44 UTC
Nice explanation. I don't test for compatibility. I'm focused on testing both DOC and DOCX from MSO. I use MSO 2016.I suppose LO should conform to newer versions. I set to New.
Comment 5 Justin L 2020-10-30 16:13:00 UTC
(In reply to Timur from comment #4)
>  I use MSO 2016.I suppose LO should conform to newer versions.
Well, really it needs to handle both versions properly. But the new version is more important as of LO 7.0, since now LO exports as compatibiltyMode 15, and so generates documents that potentially will look differently in Word now than it did before if the look is controlled only by the compat setting.
Comment 6 Justin L 2020-11-09 10:59:39 UTC
Created attachment 167122 [details]
FAHR CASE-reduced-c15.docx: bare minimum example.

To quote from MS documentation on relativeHeight:
> This attribute shall only indicate the Z-order with respect to other objects
> in the document which have an identical behindDoc attribute value.
> _All_ objects with a behindDoc value of false shall be displayed
> above elements with a value of true.

The textbox containing 2015 is behindDoc (and a higher relativeHieght), but the arrow is not. So according to the documentation, the textbox should be behind the arrow. So what circumstance is causing it to display above the arrow?
Comment 7 Justin L 2020-11-09 12:20:54 UTC
Created attachment 167130 [details]
wrapModes_withBehindDoc.zip: hand-edited to show how various wrapping is affected by behindDoc.

In this suite of tests, I started with the wrapSquare example from FAHR Case-reduced-c15.docx, and simply changed the "2015" textbox's wrap type to the other options. In all cases except for wrapNone, the textbox stayed on top in Word 2016. (In the case of wrapNone, the textbox comes to the top when behindDoc is changed to false.)

Wrap options are wrapNone, wrapSquare, wrapThrough, wrapTight, wrapTopAndBottom.

So obviously, behindDoc must be ignored when the text is set to wrap. The only time the textbox disappears behind the arrow is when <wp:wrapNone/>. (True for Word 2016, but not for Word 2010 as mentioned earlier.)

The only time behindDoc is mentioned in the documentation is in regards to wrapNone. So that is probably how they can get away with this.

The TopAndBottom case is going to give us trouble, because we treat that as wrapNone.
Comment 8 Justin L 2020-11-09 16:05:24 UTC
Proposed fix at http://gerrit.libreoffice.org/c/core/+/105486
Comment 9 Justin L 2020-11-09 16:29:43 UTC
It is worth noting I guess that my patch can "cause regressions" because what you see in an ODT file is no longer necessarily going to be what you see in the resulting .docx. But at least it conforms to what MSOffice would see it as.

The only thing I can think of would be save any document that has a wrapped object in the background as compatibilityMode 14. But that is hardly a solution because other situations in the same document might call for different compatibility modes. So best to just ignore it and have the user fix up any differences when changing formats.
Comment 10 Justin L 2020-11-10 07:14:40 UTC
(In reply to Justin L from comment #7)
> So that is probably how they can get away with this.

I think I know why they did it. In their UI, the only choice for behind text and in front of text is a conflicting choice with the rest of their wrapping methods. (Of course, in the Bring to Front/Back you have a chance to send to heaven/hell layers still - so not entirely impossible to do from UI.)
Comment 11 Commit Notification 2020-11-12 09:57:25 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":


tdf#137850 writerfilter compatibilityMode15: ignore behindDoc if wrapped

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 12 NISZ LibreOffice Team 2020-12-08 13:51:56 UTC
Created attachment 167974 [details]
How the original file looks now in Word 2013 and Writer

A lot better now (regarding Z-order at least) in:

Version: (x64)
Build ID: 796c7f612603490dda9277ced0f6ab3cce3bc116
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win
Locale: en-US (hu_HU); UI: en-US
Calc: CL

Still some problems:
- The bottom most "July" textbox of the arrow is hidden. This is because it has a huge vertical 17,06 cm position "Below paragraph" and it's anchored to a paragraph ("Opportunistic infections out ruled.") that is about vertically at the center of the page, so there is about 13 cm below it until the footer. 
Word does not put it into / above the footer, but Writer does.
- Several arrow objects are a lot more to the right side of the page. This is because they are originally horizontally positioned relative "to column", and that is imported as to "Paragraph area".

I believe this is incorrect. Paragraph area in Writer can start right of a shape that is wrapped around by the paragraph. 

This results in the "to column" positioned shapes position increasing by the horizontal size of the shape, as can be seen with the first green rectangle and the green arrow next to it. Simply deleting the green shape however positions correctly the green arrow, so that its head is next to the grey arrow like in Word.

However simply changing the horizontal position of such shapes to "Page text area" in Writer seemingly fixes the horizontal positioning.
Comment 13 Attila Bakos (NISZ) 2021-05-05 06:28:38 UTC

*** This bug has been marked as a duplicate of bug 138782 ***