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.
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.
Created attachment 166868 [details] Comparison LibreOffice 7.1 master and MSO 2010
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.
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.
(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.
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?
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.
Proposed fix at http://gerrit.libreoffice.org/c/core/+/105486
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.
(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.)
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/aaf931335b39cc788a544994fb0712286c4d998e 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: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
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: 7.2.0.0.alpha0+ (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.
*** This bug has been marked as a duplicate of bug 138782 ***