Re: [libreoffice-design] Re: ODF spec for hiding a shape or group

*See comments inline.*

On Mon, Aug 1, 2016 at 12:48 PM, Yousuf 'Jay' Philips <ypharis@gmail.com>
wrote:

> On 08/01/2016 01:41 PM, Jos van den Oever wrote:
>
> > Good morning,
> >
> > Quite a puzzle, this topic. Had to rewrite my reply as I caught on to the
> > thoughts you already put into it.
>
> Yes this is definitely a very confusing topic. :D
>
> On Monday 01 August 2016 09:14:40 Yousuf 'Jay' Philips wrote:
> > > On 07/31/2016 11:11 PM, Jos van den Oever wrote:
> > >
> > > The concept of what ODF defines as a layer or group isnt something most
> > > users will comprehend as its a foreign concept that no other app
> > > implements and a concept not possible to conveniently show in a layering
> > > tree.
> >
> > I get that now. You could perhaps show the layer name in a (optional)
> > column.
>
> With the limited space in the tree list, dedicating a column to show the
> layer name wouldnt be a wise use of space, especially when layer and shape
> names can be long.
>
> If ODF supporting apps have to support both what ODF defines as a layer
> > > and group and what other formats define them as, unfortunately these
> > > apps will likely stick with what the other formats define, which is what
> > > karbon and flow have done. I would assume the best way to deal with this
> > > complication is for ODF supporting software to have two layering modes
> > > that handle specific formats, as the standard layering concept can be
> > > saved to ODF, but ODF layering cant be saved back.
> >
> > Indeed, looking at rendering order, an draw:layer is a group and a a
> > draw:group is a layer.
> > I think layers is a useful concept, but it does require a separate list
> > from
> > the navigator. I kind of like the current tabs in LO that show the layers.
> > Toggle buttons for protection and visibility could go on the tabs.
>
> ODF layers and groups are interesting as a concept but seem to make things
> more complicated than they should be. I can see the point of layers being
> presented in horizontal tabs, as that best symbolizes that they dont affect
> z-order, though i'm not so sure that toggle buttons on tabs would work.
>
> Regarding z-index, what does it mean to change the z-index on a group if
> > the
> > objects in the group also have a z-index? This is not defined in ODF.
> > Presumably, objects inherit z-index from a group but can override it.
> >
> > ODF says: "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."
>
> With my limited knowledge of ODF, groups dont have z-index only shapes do,
> so though you can pretend to move a group's z-index, you are actually
> moving the z-index of the shapes.


*In ODF (LO 5.1), groups do have a z-index. When a group is created, it is
created as a new shape and assigned a z index. The sub shapes are assigned
new z indices starting from the lowest z index, in order of the shapes
contained within the group, but referenced to the group shape. Think of a
sub array within an array.*
*The ODF Specification also defines a group element <draw:g> which has the
attribute <draw:z-index>. Here is the reference: *
*http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#element-draw_g
<http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#element-draw_g>
*

*All shapes with z indices greater than the lowest z index to be included
in the group, but less than the highest z index of the shapes to be
included in the group are reassigned indices, in the order they were before
the grouping, beginning at the index of the lowest shape to be included in
the group. The group is then assigned the next z index to follow. All
remaining shapes with z indices higher than the index of the last shape to
be included are then reassigned in order beginning with the first index
following the group.*

*For example take the following array of shapes: [a, b, c, d, e, f, g, h].*
*Here is the result after grouping shapes b, d, and f: [a,c,e, [b, d, f],
g, h].*
*The group now has the index of 3, and the index for h changed from 7 to 5.
The rendering order is now a, c, e, b, d, f, g, h.*


> In CSS, each element has it's own stacking order. So, no interleaving is
> > possible unless the elements are interleaved. SVG has no z-index at all,
> > only
> > document order. So it's normal that Inkscape is simpler/less powerful in
> > this
> > regard.
>
> Not sure why CSS would be an example of a drawing format, so maybe you can
> clarify that. With SVG defining that document order is equivalent to
> z-index, it doesnt have to define an actual z-index value. This is no
> different than pages in a book or slides in a presentation.
>
> CSS and SVG are conceptually nice and simple. In ODF, a separate z-index
> > based
> > array is necessary to do efficient drawing.
>
> I believe efficient drawing can be done with a document order type
> z-index, as i would assume photoshop's psd format and illustrator's ai
> format follow this simple ordering. Even ODF states "Shapes are rendered in
> the order in which they appear in the document in the absence of this
> attribute."
>
> I'm not sure how many documents we'd break if we'd go for a the simple CSS
> > z-
> > index model. If it's not too many, we could make the specification
> > language
> > more precise and the same as CSS.
> >
> > Yes i guessed that any app using the standard layering would have the
> > > same problem of loading ODF layering, but there is a workaround that
> > > could be done to still maintain the correct layering to some degree,
> > > though it wouldnt work for groups across layers.
> >
> > What is that workaround?
>
> So lets say we have 2 layers called Mobile and Tablet and we have 3
> objects on these two layers called iPhone, Nexus and iPad, with the below
> ODF structure.
>
> [Layer] Mobile
>    [Object] iPhone (z-index: 1)
>    [Object] Nexus (z-index: 3)
> [Layer] Tablet
>    [Object] iPad (z-index: 2)
>
> This could be processed into the standard layering system like so.
>
> [Layer] Mobile1
>    [Object] iPhone (z-index: 1)
> [Layer] Tablet
>    [Object] iPad (z-index: 2)
> [Layer] Mobile2
>    [Object] Nexus (z-index: 3)
>
> So basically it breaks up layers when objects of a z-index reside within
> the objects on the layer.


*While this is a good workaround, I don't know that it is entirely
necessary. I think both layering schemes could easily be incorporated with
a change in UI terminology and an LO specific layer feature that also
manages z-index. Since the existing layers are essentially nothing more
than visibility layers, I suggest renaming them as such in the UI, or
perhaps V-Layers for short. The LO specific layers could be called
Z-Layers. Unlike a V-Layer which only has attributes: draw:display,
draw:name, and draw:protected, and does not change draw:z-index, a Z-Layer
could have V-Layers as child elements, and also manage the draw:z-index of
its child elements, simply by assigning the values of both attributes:
draw:layer, and draw:z-index for each drawing object that is a child
element. *

*Each drawing object has the attributes <draw:layer> and <draw:z-index>. *


*http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#element-draw_layer-set
<http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#element-draw_layer-set>*

*http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#attribute-draw_z-index
<http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#attribute-draw_z-index>*

* Using your workaround example, I could import the first ODF structure
like so:*

*[Z-Layer] Default*





*  [V-Layer] Mobile     [Object] iPhone (z-index: 1)     [Object] Nexus
(z-index: 3)  [V-Layer] Tablet     [Object] iPad (z-index: 2)*

*I could then add objects and layers, while maintaining and ODF readable
document like so:*









*[Z-Layer] Default  [V-Layer] Mobile     [Object] iPhone (z-index: 1)
 [Object] Nexus (z-index: 3)  [V-Layer] Tablet     [Object] iPad (z-index:
2)     [Object] Galaxy Tab(z-index: 4)  [V-Layer] PC     [Object] Laptop
(z-index: 5)[Z-Layer] New  [V-Layer] Data      [Object] Specs (z-index: 6)*

*Since Z-Layers are LO specific, they are ignored by ODF, but since we
structured it like this the resulting ODF document opened in another
application would maintain the same structure and appearance, as shown
below:*










*  [V-Layer] Mobile     [Object] iPhone (z-index: 1)     [Object] Nexus
(z-index: 3)  [V-Layer] Tablet     [Object] iPad (z-index: 2)     [Object]
Galaxy Tab(z-index: 4)  [V-Layer] PC     [Object] Laptop (z-index: 5)
[V-Layer] Data     [Object] Specs (z-index: 6)*


Yes i've reported the issue as i noticed the same and it comes down to
> > LO not supporting <draw:layer-set> as a child element of <draw:page>.
> >
> > https://bugs.documentfoundation.org/show_bug.cgi?id=101218
>
> Awesome to see the report and the discussion on it already.

Does your test suite have test documents for layers, groups, and stuff and
it would be good to test to find out what else LO doesnt support correctly.

Dont think that would help much, especially when you have a long layer
> > list. We've gone with the idea to include the layer name after the shape
> > name and/or in a tooltip.
>
> Right layers are orthogonal to grouping with draw:g. So still a separate
> list
> of layers.
> Showing which elements belong to a layer by hightlighting when hovering the
> layer tab could help for users to see the relation between the layer and
> the
> object
> I guess such highlighting would be also useful in the navigator.
> In browsers, with 'inspect element' this is a very nice feature that helps
> a
> lot to understand where all the parts of the document are.

I had played around with Draw last year as a new user and never noticed the
tabs, but during that time i never felt that i was missing out of features
that would have caused me to search around for them, as it treated the
functionality just like any other app i was used to which dealt with
stackable objects. But if i did notice the layers and clicked on them to
try them out and draw some shapes on them, i doubt i would notice anything
special, as layers didnt limit the movement of the object's z-index.

But you can have a tree from the layer into the objects and allow changing
> > > the z-index for the groups and the objects in the groups.
> >
> > Likely this view is fine for advanced users who specifically want to use
> > ODF's layering concept, but not something that the average user will.
>
> As you pointed out, layers and groups are independent concepts and do not
> fit
> in one hierarchy, so keeping the tabs for the layers might be simplest.

Yes layers are being kept in their own hierarchy separate from objects in
expert mode. The choice to not include groups in the hierarchy is where it
really gets tricking.

Unfortunately you cant as group isnt limited to a layer, so its possible
> > to have a group with two objects from two different layers. It would be
> > great if there was some text or mockup from ODF of a hierarchical view
> > to demonstrate how it could look.
>
> At this point I had to redo rewrite my reply mail. I totally missed that in
> earlier mails. Knowing this, I agree that the layer cannot go in the same
> hierarchy.

How we intend to separate layers -
https://design.blog.documentfoundation.org/wp-content/uploads/sites/2/2016/07/20160730_ExpertMode.png

That was for shapes and not layers, but its strange that i cant
> > reproduce it now.
>
> If you name a layer 'Locked' then an object may have draw:layer="Locked"
> as an
> attribute. Same goes for 'Invisible'. Perhaps you used those names when
> creating an example file.
>
> I do not think that Karbon has hardcoded layer names.

Yep that might have been it and i got confused. :D

This is what i would like to propose:
> > 1) draw:display - used in <draw:layer> to be ported to groups and objects.
> >
> > 2) draw:opacity - used in <style:graphic-properties> to be ported to
> > layers and groups to alter the opacity of all underlying shapes.
>
> This is already in the spec, because of style inheritance. If opacity is
> not
> defined on object (via the style) directly, it will look at the parent
> styles.
> If the parent styles do not set it, than opacity should be inherited from
> the
> parent group. This is similar to how e.g. font size is inherited.

From what i understood with draw:opacity is that it isnt an attribute of
layers or groups.

"The <draw:opacity> element specifies an opacity gradient for a graphic
object."

http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1416472_253892949



*<draw:opacity> isn't an attribute of layers or groups, but it appears that
it can be used to modify the opacity of a layer or group, since layers and
groups are graphical objects.
Ref: 
http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1415788_253892949
<http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1415788_253892949>Even
if by chance layers and groups can't be directly modified by
<draw:opacity>, then it can be used to modify the list of elements
contained therein.*


> 3) tree:collapse - a boolean value for saving the state of whether a
> > > layer or group was open or closed.
> >
> > That's a UI dependent thing. It should not go into the content.xml or
> > styles.xml but into settings.xml where application specific UI settings
> > are
> > stored.
>
> The intend would be for other apps to support this as well and it not be
> just an application specific feature. Everytime i opened up a document in
> Karbon the layers werent collapsed, so i had to repeatedly expand them to
> get to the shapes i wanted to work on. Any app that would display a
> hierarchy in this manner would benefit from this feature.

*I don't see why any application specific feature couldn't be structured
such that they will still display properly in other applications, since the
application specific features could still be using the ODF specified
features to accomplish their task.*


> Cheers,
> > Jos
>
> On my quest to find some other app that has a similar type of layering
> system, i found it in visio (just another reason why i correctly compare
> draw with visio and not inkscape ;D). Their expert focused "Drawing
> Explorer" shows the structure and leaves out the manipulation of z-index,
> which allows the successful hierarchy of shapes and groups. Definitely
> something to consider for expert mode.
>
> http://i.stack.imgur.com/l9Qts.png
>
> https://youtu.be/fCBcpBfxrgI?t=4m36s
>
> Yousuf
>
>
> --
> To unsubscribe e-mail to: design+unsubscribe@global.libreoffice.org
> Problems?
> http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.libreoffice.org/global/design/
> All messages sent to this list will be publicly archived and cannot be
> deleted

-- 
To unsubscribe e-mail to: design+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted