References: http://openoffice.org/bugzilla/show_bug.cgi?id=116135 http://www.oooforum.org/forum/viewtopic.phtml?t=112264&highlight=zorder In large documents, the z-order of objects within a graphics frame can be corrupted when the document is saved and then reopened, as noted in the OpenOffice bug report above, which includes test cases. I had come to suspect that the corruption takes place when saving the document, as the test case files above always seemed to render identically on different machines for me, although this may be coincidence. Happy to supply additional info/test cases as required. Below are my notes from the OpenOffice bug report: ------------------------------------------------------ It appears that the Z-order of objects within a frame can be scrambled when saving an odt file in Writer. Example file: http://dl.dropbox.com/u/1735103/Figure%20z%20order%20problems%204.odt In the example file linked above, the arrows were all placed above the JPEG images when the file was created, however, when it is opened, figures 9 onwards have been corrupted, and the arrows are now below the JPEG images. This file seems to render identically on different computers running the same version of OOo (3.2.0) on Windows XP. Second example file: http://dl.dropbox.com/u/1735103/Figure%20z%20order%20problems%205.odt The same file, again with all of the arrows positioned above the JPEG images, was saved to odt format using a different (slower) computer running the same version of OOo. This file again appears to render identically on different computers, but the corruption of the images is different to that in the previous file. This implies to me that the corruption is taking place when the file is saved, rather than when it is opened, although I may be wrong. This erroneous behaviour seems to be highly variable. It only seems to affect files with many images - the attached files exhibited no problems until around 12 complex images with Z ordered features were added. I see a few other OpenOffice bug reports relating to Z order, but in slightly different ways: #62094 #77355 (#103338) Best regards, Richard Walker.
Dear all. I've now had a look at the content.xml portion of the example (Figure z order problems 4.odt) it looks like the issue occurs when loading or rendering the file, not when saving it, as the draw:z-index properties of the various components are numbered in the correct order. I used an xml editor to remove all but one of the frames from the document, keeping figure 12 unchanged, and saved this as a new document. It displays correctly, so there presumably isn't anything wrong with the xml for this frame. However, if I use an xml editor to move figure 12 to the start of the document and then open it, figure 12 displays incorrectly (all the arrows under the images) while the others are unchanged. Therefore, the behaviour doesn't seem to be order dependent. I wonder if it is some interaction with another component of the document which causes the problem? This could possibly be related to the way the z-orders have been numbered when saving the file. It looks like the top level objects (frames) are numbered first, sequentially from 0, followed by the images, and finally the arrows. In one test I removed all images except for 11 and 12, and found that one of the arrows in figure 11 appears under the image. The z-order of the figure 11 frame was 160, with the images being 161 and 162, while those of figure 12 were 159, 163 and 164 respectively. I think the problem might be related to the image z-orders of figure 11 being between the frame and image z-orders of figure 12. When I changed the figure 11 frame to 100, and it's images to 101 and 102, the document rendered correctly. Perhaps as a complex document evolves, these get mixed up at some point, and while the z-orders sound ok, writer is getting confused. I hope this is helpful. Kind regards, Richard.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
reproduced in LibO 3.6.0 master on Fedora 64 bit use file Figure z order problems 4.odt from first link and see on Figure 11 inside one arrow beneath of photo and if bring it one step to front and save and do File-> Reload, arrow again appears beneath of photo
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: *Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later) https://www.libreoffice.org/download/ *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT *Update the version field *Reply via email (please reply directly on the bug tracker) *Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-04-18
http://dl.dropbox.com/u/1735103/Figure%20z%20order%20problems%204.odt Only 1 arrow in Figure 11 is below an image. Bring to front, reload causes a different arrow to pop under an image in Figure 11. Similar issue: bug 84127 Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: 80ec99db4325a439a8a3f1d420d0a80f8bf9c439 TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-06-16_00:00:20 Locale: fi-FI (fi_FI)
Hi, Similar issue on LibreOffice 5.1.2 (Ubuntu 16.04). The problem disappear with more memory in LibreOffice configuration. I have now in Tools/Option/LibreOffice/Memory: - Memory used for LO : 256 Mb - Memory per object : 20 Mb - Number of object : 40 Regards,
Julien, You bug is not the same. Followed steps in Comment 5 with Version: 5.3.0.0.alpha1+ Build ID: bbd44f8f89839b5abb4ec6c7ea195431de5b2f48 with - Memory used for LO : 256 Mb - Memory per object : 20 Mb - Number of object : 40 Z Order changed after save and reload. Please file a new bug report including a test case.
Hi Luke, I mean that with a similar problem (z order lost after reload) on one of my own file I resolved it after setting more memory in LibreOffice configuration. But it's not a definitive solution. With my configuration I can't get the correct z-orders with Buovjaga's file. Regards.
The dropbox files are gone, but the fix for bug 107392 fixed a lot of different cases like this, so it is very likely this is fixed. Closing as insufficientdata for now.