-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: ODF 1.3
-
Component/s: Graphics, Part 3 (Schema) [1.2: 1]
-
Labels:None
-
Proposal:Hide
19.231 draw:z-index, add this:
The draw:z-index values increase from back to front.
For a shape on which the attribute style:run-through (20.343) with value foreground is in effect, producers should not generate a draw:z-index value that is smaller than the value of any draw:z-index on a shape on which the attribute style:run-through with value background is in effect.
Producers SHALL NOT generate a draw:z-index for shapes that are children of a <draw:g> element (10.3.15) or a <dr3d:scene> element (10.5.2).
20.343 style:run-through, add this:
The default value for this attribute is foreground.
Show19.231 draw:z-index, add this: The draw:z-index values increase from back to front. For a shape on which the attribute style:run-through (20.343) with value foreground is in effect, producers should not generate a draw:z-index value that is smaller than the value of any draw:z-index on a shape on which the attribute style:run-through with value background is in effect. Producers SHALL NOT generate a draw:z-index for shapes that are children of a <draw:g> element (10.3.15) or a <dr3d:scene> element (10.5.2). 20.343 style:run-through, add this: The default value for this attribute is foreground .
After the first sentence "The draw:z-index attribute ... instance." add the sentence "The z-index values increase from back to front."
=======================================
The current description does not say, what to do, if elements with z-index attributes and elements without z-index attributes are mixed.
In LibreOffice I get this order for example:
Elements as they appear in the document: [blue z=2] [red no z] [yellow z=0] [green no z]
Rendering order from back to front: yellow red blue green
Elements as they appear in the document: [blue z=4] [red no z] [yellow z=3] [green no z]
Rendering order from back to front: red green yellow blue
Elements as they appear in the document: [blue z=1] [red no z] [yellow z=0] [green no z]
Rendering order from back to front: yellow blue red green
Proposal:
Instead of the current sentence "Shapes are rendered in the order in which they appear in the document in the absence of this attribute." use this:
Elements without draw:z-index attribute are ordered as if they have got draw:z-index values of consecutive integers, increasing in the order the elements appear in the document, skipping those values, which are used by explicit draw:z-index attributes, starting with the smallest not used non-negative integer.
=========================================
It makes no sense to define a z-order for elements of a 3D-scene. The rendering of the elements in the scene is produced by the projection and depends on the kind of projection and its direction. It is even possible, that elements penetrate each other.
Proposal:
Remove the tag
<ref name="common-draw-z-index-attlist"/>
in
<element name="dr3d:cube">
<element name="dr3d:sphere">
<element name="dr3d:extrude">
<element name="dr3d:rotate">
in the schema.
Reasoning: These elements occur only as child of a <dr3d:scene> element.
And add in the description:
For a <dr3d:scene> element the z-index attribute is only interpreted in case it is the outer most <dr3d:scene> element of a scene, and in that case it is applied to the two-dimensional projection result of the scene, including its shadow if any. A z-index attribute of an inner <dr3d:scene> element is treated as not existent and its value as not used.
Or in case it is possible to forbid an attribute in the description, although it is possible by the schema:
For a <dr3d:scene> element the z-index attribute is only allowed in case it is the outer most <dr3d:scene> element of a scene.
====================================
For the <draw:g> element I have a different solution:
For <draw:g> elements and their child elements the following rules apply:
(1) The rendering order among a <draw:g> element and its siblings is determined without considering the child elements of the <draw:g> element.
(2) The rendering order among the child elements is determined recursively by the same rules, but without considering the elements from the rendering order of rule (1).
(3) When a <draw:g> element is to be rendered in the rendering order of rule (1), then all its child elements are rendered in the order of rule (2) before the next element in the order of rule (1) is rendered.
1. sentence added to proposal
2. "The current description does not say, what to do, if elements with z-index attributes and elements without z-index attributes are mixed."
i don't like to specify this corner case. counter-proposal:
Producers should either put a z-index on every top-level shape, or not use z-index at all.
3. good point about <dr3d:scene> - i didn't know about this.
we should definitely discourage the use of z-index on inner nodes here, not sure if removing the attribute altogether is warranted.
(then again, i've heard people say the whole <dr3d:scene> thing is some obsolete 90s relic that should be removed)
4. i just wrote that horrendous last draw:g sentence as a straw-man, i don't actually like it
i think there is no reason at all to use z-index inside a draw:g; my understanding is that z-index exists because the top-level shapes are distributed across the document and don't share a common parent element, so z-index is required in case they overlap, but the elements inside draw:g do share the draw:g as common parent, so the z-index can just be implicit in the ordering of the elements within the parent.
so i far prefer to just omit specifying what z-index inside draw:g means, and discourage its use. (similar argument applies to dr3d:scene)
resolved as proposed, 2017-09-18
https://lists.oasis-open.org/archives/office/201709/msg00029.html
Applied in OpenDocument-v1.3-wd08-part3-documents.odt (also removed a redundant sentence from draw:z-index.
added a proposal based on the points discussed in this week's call