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

On Monday 01 August 2016 22:48:32 Yousuf 'Jay' Philips wrote:
> 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.

The current dialog for changing protection or visibility of a layer is 
cumbersome (4 clicks). Moving those toggles to a tab (1 click) or  tab context 
menu (2 clicks) would help. I can see that the tab needs the room when there's 
many of them. The context menu has plenty of room. There's only 5 entries at 
the moment.

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

As Taylor already pointed out, z-index on draw:group matters.

> > 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 is for styling and can change the order of the elements in a document.
You can use it for drawing though ...
http://littlebox.cabmaddux.com/
http://www.cssplay.co.uk/menu/
ODF inherits most of its styling from XSL-FO which again inherits it from 
CSS2.
The ODF spec for z-index currently does not reference CSS2 or XSL-FO, but it 
is probably meant to behave the same and should refer to those specifications, 
like it does for all other CSS/XSL properties that it inherits.

https://www.w3.org/TR/xsl11/#z-index

z-index in CSS is quite complicated. Here is a nice explanation:
  https://philipwalton.com/articles/what-no-one-told-you-about-z-index/
For example, "z-index only works on positioned elements". Luckily all draw:* 
elements have explicit position and hence are 'positioned'.

CSS works with stacking contexts. The ODF spec does not mention these at all. 
Without stacking contexts, the root of the document is the only stacking 
context and all z-index are in the same stacking context.
LO and Calligra Karbon implement z-index as if each draw:group is a stacking 
context.

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

You might show it like that in the UI, but keep in mind that layers are 
independent of document hierarchy.

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

Not yet. Neither in Calligra nor in ODF AutoTests.

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

Yes, layers are just for creating named groups of objects on which protection 
and visibility can be toggled.

> > > > 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/0
> 7/20160730_ExpertMode.png

Excellent.

You might even show a filtered hierarchy beneath each collection. 'Just' take 
the whole hierarchy and leave out every object that is not in that collection.

> http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__
> RefHeading__1416472_253892949
> > > 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 see the use, but I do not think this is a high priority feature. If LO 
implements it in custom namespace, it might at some point be picked by other 
implementations and go into the ODF spec.

Cheers,
Jos


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