Created attachment 191903 [details] sw/qa/extras/ooxmlexport/data/n747461.docx While working on bug 159157, I noticed that ooxmlexport8's n747461.docx (which was added for zOrder fixing sadly) does not put the objects in the correct zOrder. Specifically, the black should be on the top, but currently it is at the bottom. It becomes clearer when Word 2019 round-trips the file (attachment 191899 [details]) and didn't use relativeHeight of 0, but instead gave a large number. Steps to reproduce 1.) open n747461_2019.docx. (In MS Word 2010: black box is fully seen, then green, then red.) For a PDF of what it should look like, see attachment 191902 [details] (n747461_2019.pdf). Prior to 3.5 the shapes overlapped each other completely in no apparent rational zorder (last to load is the highest?). In 3.5 they separated a bit, but still in unknown zOrder, and in 3.5.5rc3 it looks like it does today, with black at the back. Potential clue from the author of n747461.docx for a starting point: commit e05e77f4b7373b686f02cc51c7003e72efb07053 Author: Luboš Luňák <l.lunak@suse.cz> on Tue Apr 17 13:36:24 2012 +0200 fix UNO ZOrder reading http://lists.freedesktop.org/archives/libreoffice/2012-April/030206.html
Created attachment 191915 [details] gradient-fill-preservation-yellowBehindBlue10.docx: Yellow=1, Blue=0, but blue wins?!? The plot thickens. Both 0 and 1 are relatively high, and changed into arbitrary numbers when round-tripped by MSO, while values of 2+ are preserved. ooxmlexport6's gradient-fill-preservation.docx triggered a unit test failure on my exploratory patch at https://gerrit.libreoffice.org/c/core/+/161989. It has been useful in trying to tease out the specifics of what is happening here. Current theory - both 0 and 1 have a equivalent relativeHeight value of 0x0EFFFFFF. Last one wins in this case (which is the opposite to what our zOrder handler is very deliberately doing).
Created attachment 191916 [details] gradient-fill-preservation-yellowBehindBlue01.docx: Yellow=0, Blue=1, and blue wins
Created attachment 191917 [details] gradient-fill-preservation-yellowBehindBlue22.docx: yellow=2, blue=2 Our zOrder generally says "first come, highest zOrder". Sanity check: if I made Yellow=3, Blue=2, then yellow is in front? Yes. We do have a flag for "oldStyle" and this is compatibilityMode=12 (2007). However, changing to 15 doesn't make any difference. So, I have to assume that we have a conflict between z-Index doing first-wins and relativeHeight where last-wins. It is worth noting that MS Word 2019 replaced these conflicting 2's with new, randomized positions. (Sanity check - verify that non-conflicting 3,2 was not change? Correct - no change.) Conclusion? I guess that when we hit NS_ooxml::LN_CT_Anchor_relativeHeight, we need to check if that zOrder is already registered. If so, bump up by 1.
Created attachment 191919 [details] gradient-fill-preservation-yellowBehindBlueH0.docx: Yellow=0x0F00 0000 Blue=1 So, we already have determined that 0 and 1 are the same zOrder value. I calculated that value to be 251658240. In this example, Blue=0, but since it is defined last, it wins and is in front.
Created attachment 191921 [details] gradient-fill-preservation-yellowBehindBlue0H.docx: yellow=0, blue=0F00 0000 and of course, since they are the same value, switching them around makes no difference since the last always wins. It proves they are the same value, if not then the yellow would have come to the top.
Created attachment 191922 [details] gradient-fill-preservation-blueBehindYellow0G.docx: Yellow=0 Blue=0EFF FFFF This one wasn't really necessary, but I included it for completeness. It shows that 0 is greater than 251658239
Created attachment 191923 [details] gradient-fill-preservation-yellowBehindBlueI1.docx: Yellow = 0F00 0001 Blue = 1 Another surprise! Since yellow is a higher number than the value of 0/1, I expected blue to be behind. But it is in front - as it is for all larger numbers. So 0 and 1 really are the maximum after all...
OOPS: I got carried away in the Hex stuff. It is 32bit, so only 0F00 0000.
Created attachment 191962 [details] gradient-fill-preservation-blueBehindYellowbehindZIndexIH0.docx: yellow=max, blue=wayBeyondMax, textbox=0 Something else very interesting - a z-index ALWAYS is in front of a relativeHeight when in the same heaven/hell layer. As noted in comment 3, a z-index needs to interoperate with relativeHeight. This hand-crafted document has both types of references. It is only when the z-index textbox is in the hell-layer (a negative z-order) that the heaven-layer star shapes can appear on top of it. That suggests that to implement this, we can ALWAYS treat relativeHeights as a negative index, and subtract the maximum z-index value as well. So then the question becomes, "what is the maximum z-index value?".
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a9c3955c13531045646df7c29a782980121e6960 tdf#159158 writerfilter: duplicate relativeHeights? last one wins It will be available in 24.8.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d26fe92554273f7d8299f799681075d8a44a917a tdf#159158 writerfilter: duplicate relativeHeights? last one wins #2 It will be available in 24.8.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/db819557a351a5626a9ac50cd339dceb81749f58 tdf#159158 writerfilter: relativeHeights of 0/1 are highest zOrder It will be available in 24.8.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3f50503a69bc92e3a0c6c36686d8ff37d77188bf tdf#159158 DOCX import: relativeHeights of 0/1 are highest zOrder #2 It will be available in 24.8.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/bd9178ad31051de316092ec062b9f378c8a19852 tdf#159158 writerfilter: relativeHeight max allowed value It will be available in 24.8.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/12ea98fe637eda5f038b6447a5f0c5ea7104f448 tdf#159158 tdf#120760 DOCX shape import: fix Z-order with behindDoc #2 It will be available in 24.8.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0b03dff37f4cad722819f36d5cf3bd39fb46d8ed tdf#159158 writerfilter: relativeHeight always under z-index It will be available in 24.8.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5120cc702741ee3bdded80336f33362e42bf4276 tdf#159158 DOCX import: shape's last duplicate z-index wins It will be available in 24.8.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ca29c240dbfe6396115c961d27b1bf13a65793c2 tdf#159158 writerfilter: improve m_bBehindDoc/m_bOpaque documentation It will be available in 24.8.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/027632ec97ad556606997254244c76c7474d9122 NFC prepwork for tdf#159158: flatten writerfilter applyZOrder It will be available in 24.8.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9aa7dc185af99a540926cc699193449177050386 tdf#159158 writerfilter: headers always under other z-orders It will be available in 24.8.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c4c5937a98572630915de497b3138164b12079e3 tdf#159158 writerfilter: headers always behind text (!opaque) It will be available in 24.8.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.