Details

    • 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.

      Show
      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 .

      Attachments

        Activity

        Hide
        mstahl Michael Stahl (Inactive) added a comment -

        added a proposal based on the points discussed in this week's call

        Show
        mstahl Michael Stahl (Inactive) added a comment - added a proposal based on the points discussed in this week's call
        Hide
        regina.henschel Regina Henschel added a comment -

        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.

        Show
        regina.henschel Regina Henschel added a comment - 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.
        Hide
        mstahl Michael Stahl (Inactive) added a comment -

        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)

        Show
        mstahl Michael Stahl (Inactive) added a comment - 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)
        Hide
        mstahl Michael Stahl (Inactive) added a comment -
        Show
        mstahl Michael Stahl (Inactive) added a comment - resolved as proposed, 2017-09-18 https://lists.oasis-open.org/archives/office/201709/msg00029.html
        Hide
        patrick Patrick Durusau added a comment -

        Applied in OpenDocument-v1.3-wd08-part3-documents.odt (also removed a redundant sentence from draw:z-index.

        Show
        patrick Patrick Durusau added a comment - Applied in OpenDocument-v1.3-wd08-part3-documents.odt (also removed a redundant sentence from draw:z-index.

          People

          • Assignee:
            dmahugh Doug Mahugh (Inactive)
            Reporter:
            rcweir Robert Weir (Inactive)
          • Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: