z-index absolute or relative to containing group?

[Thorsten Zachmann]

Hello,

On Friday, March 16, 2012 23:19:53 Friedrich W. H. Kossebau wrote:
> Hi,
> 
> see $subject, is the z-index of items absolute or relative to the
> containing group?
> 
> I could not find anything relevant on the webs. Has this been discussed
> before? If not, were could this be discussed?
> 
> All I found in the OpenDocument 1.2 spec is this, but it does not talk
> about this problem:
> --- 8< ---
> 19.231 draw:z-index
> 
> The draw:z-index attribute defines a rendering order for shapes in a
> document instance. Shapes are rendered in the order in which they appear
> in the document in the absence of this attribute.
> --- 8< ---
> 
> Calligra seems to do the z-index hierarchically, i.e. each group does the
> z- index internally, then places the whole group into the global order by
> the z- index of the group, recursively. LibreOffice Draw seems to do the
> same.
> 
> So is this behaviour as implemented actually complementing the spec and
> defining what is correct?
> 
> Reason is that xfig only uses the z-index (depth in xfig terms) for real
> objects, but not for compound objects. So single objects in different
> compounds can be intertwined in the z-order.
> 
> And the more I think about it having this option to intertwin elements of
> different compounds in the z-order makes more sense than to automatically
> group them also in the z-order, which limits what is possible.
> After all that is what layers are for, or can be used for, to subgroup
> objects in the z-order, no?
> 
> Usecase I think of are e.g. predefined composed elements from a gallery
> which get set together: like placing a tool under the arm of a person,
> between body and arm, where the tool and the person vector images are from
> a gallery. Would be nice to keep both compositions, but being able to
> layer the tool image intertwined with the person compound.
> 
> And 10.3.15 does not mention this property of draw:g as well. Hm, too bad,
> just see that draw:g has also a property draw:z-index, which only makes
> sense if groups are kind of a sublayer :( Bah.

What we do currently is to have a hierarchy of shapes. And the shapes are 
painted by the hierarchy. This was different before but lead to all kind of 
problems. E.g. out painting code needs a well defined order which was not true 
before as shapes could turn out th get the same z-index which resulted in 
random paint order and flickering. 
At that point we decided that using a hierarchy makes much more sense. To not 
break documents that have shapes  not following the hierachy when loading we 
change change their parent layer on loading so that the correct order is kept. 
The current approach makes quite a lot of things more easy/faster to do, e.g. 
keeping the zindex per layer unique.

This is also what other graphic apps do, e.g. inkscape.

I looked a bit and I found some of the old dicsussion here:

http://osdir.com/ml/koffice-devel/2009-09/msg00297.html

Your above example can be reached by having both objects in the same parent 
and move the stuff down. 
One other solution to your problem would be to have some kind of logical 
grouping per RDF. One could assign a tag to a shape saying what object it is 
e.g. Person, Tool. That could be an additional to what we have at the moment 
and allow you to remove different stuff like known from a cad program.

Thorsten