https://bugs.documentfoundation.org/show_bug.cgi?id=159158
Bug ID: 159158
Summary: FILEOPEN DOCX: relativeHeight zOrder of 0 apparently
is the highest, while 1 is the lowest, then 2...
Product: LibreOffice
Version: Inherited From OOo
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: filter:docx, notBibisectable
Severity: normal
Priority: medium
Component: Writer
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Blocks: 159143
Created attachment 191903
--> https://bugs.documentfoundation.org/attachment.cgi?id=191903&action=edit
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) 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
(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 <[email protected]> on Tue Apr 17 13:36:24 2012 +0200
fix UNO ZOrder reading
http://lists.freedesktop.org/archives/libreoffice/2012-April/030206.html
Referenced Bugs:
https://bugs.documentfoundation.org/show_bug.cgi?id=159143
[Bug 159143] [META] Z-order / arrangement of objects
--
You are receiving this mail because:
You are the assignee for the bug.
