Bug 41006 - Z-order lost for objects within a frame
Summary: Z-order lost for objects within a frame
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
3.4.3 RC1
Hardware: All All
: medium normal
Assignee: Not Assigned
URL: https://issues.apache.org/ooo/show_bu...
Depends on:
Blocks: Image-Caching
  Show dependency treegraph
Reported: 2011-09-19 05:51 UTC by Richard Walker
Modified: 2017-05-28 15:55 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Richard Walker 2011-09-19 05:51:10 UTC

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:

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:

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

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
#77355 (#103338)

Best regards,
Richard Walker.
Comment 1 Richard Walker 2011-09-19 14:30:01 UTC
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,
Comment 2 Björn Michaelsen 2011-12-23 12:36:00 UTC Comment hidden (obsolete)
Comment 3 sasha.libreoffice 2012-02-03 03:55:49 UTC
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
Comment 4 QA Administrators 2015-04-19 03:21:28 UTC Comment hidden (obsolete)
Comment 5 Buovjaga 2015-06-16 10:14:26 UTC

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:
Build ID: 80ec99db4325a439a8a3f1d420d0a80f8bf9c439
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-06-16_00:00:20
Locale: fi-FI (fi_FI)
Comment 6 Julien 2016-10-31 14:40:06 UTC

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

Comment 7 Luke 2016-11-01 01:24:49 UTC
You bug is not the same. 

Followed steps in Comment 5 with Version: 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.
Comment 8 Julien 2016-11-01 08:45:49 UTC
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.

Comment 9 Buovjaga 2017-05-28 15:55:25 UTC
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.