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

Good morning,

Quite a puzzle, this topic. Had to rewrite my reply as I caught on to the 
thoughts you already put into it.

On Monday 01 August 2016 09:14:40 Yousuf 'Jay' Philips wrote:
> On 07/31/2016 11:11 PM, Jos van den Oever wrote:
> > On Sunday 31 July 2016 18:47:22 Yousuf 'Jay' Philips wrote:
> > > On 07/31/2016 03:23 PM, Jos van den Oever wrote:
> > > > Hello Yousuf,
> > >
> > > Hi Jos,
> > >
> > > > I read your document. You say
> > > >
> > > >  "ODF ...handles layers differently from other tools."
> > > >
> > > > and give Inkscape as an example. Inkscape does not have layers, just
> > > > <svg:g>.
> > >
> > > ODF defines the word layer to mean one thing, while other apps define it
> > > to mean something different. That is what is intended to get across. For
> > > example, GIMP has layers for text and bitmap, while ODF would calls
> > > these objects and not layers.
> >
> > The distinction between layer and group is something a user has to learn.
> > It helps if the application behaviour is close the file format. That
> > saves on translation between internal model and file format.
>
> 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.

>  > If all ODF supporting
> > applications do this, it also makes behavior more similar.
>
> 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.

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

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.

CSS and SVG are conceptually nice and simple. In ODF, a separate z-index based 
array is necessary to do efficient drawing.

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.

> > > > You discuss Krita. For vector graphics, you can also look at Karbon
> > > > which
> > > > can open and save odg files. Unfortunately, I just saw a bug there:
> > > > Karbon does not respect the z-index when objects are in layers.
> > > > https://bugs.kde.org/show_bug.cgi?id=366297
> > >
> > > Krita wasnt discussed, just screenshots were taken from it. Yes heiko
> > > and i tried out calligra karbon today and i tried out calligra flow
> > > yesterday. Both apps do the same with objects being limited to a maximum
> > > z-index defined by the layering of the layers.
> >
> > I'd say that that is a bug and I've reported it as such. Currently when
> > loading/saving an LO file with Karbon would lose information.
>
> 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?

> > BTW similarly a file with layers in created in Karbon is not read properly
> > by LO Draw: the layers are discarded.
>
> 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.

> > > > Karbon has a convenient layer view where you can toggle visibility and
> > > > editability of layers.
> > >
> > > We will be implementing the visibility and editability toggles as well
> > > with our redesign.
> >
> > Cool. That will fix most UI issues I'm sure.
> >
> > > > Layers do not influence the z-index. This gives flexibility. A UI might
> > > > still offer to increase or decrease the z-index for all objects in a
> > > > layer.
> > >
> > > There isnt a convenient means that i can think of that can show a
> > > stackable tree view if object z-orders can cross layer boundaries. This
> > > is something we've been wrangling with for a few weeks when discussing
> > > the proposal and likely why karbon and flow have decided to limit users
> > > ability to have objects cross z-orders of other layer objects.
> >
> > 3D view would help but it's quite some work to implement. Mozilla has a 3d
> > view for web pages.
> > What might help is the give objects that belong to a layer a shine when
> > you
> > hover the layer in the layer list.
>
> 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.

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

> > The idea you have to let go is to enable z-index buttons for the layers.
> > That does not fit with the file format.
>
> That is true, which is why our proposal is to hide layers in easy mode
> so regular users dont get confused by the concept.
>
> > You can have the hierarcy of Page/Slide > Layer > Group* > Object in the
> > navigator.
>
> 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.

> > > > Why do you want to hide individual groups or shapes?
> > >
> > > Because its a feature that individuals will use, i know i would, as i
> > > use it all the time in gimp, photoshop and inkscape. Karbon and flow
> > > have the same feature and all apps that show a stackable tree view do as
> > > well.
> > >
> > > > Should that information be saved?
> > >
> > > Karbon saves visibility with draw:layer="Invisible" and locking with
> > > draw:layer="Locked", though it doesnt import the locked set attribute.
> >
> > No, Karbon uses draw:display="none" and draw:protected="true".
>
> 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.

> > > > The ODF specification does not allow setting the visibility of draw
> > > > items.
> > >
> > > Yes it presently doesnt have the feature available, but i'm assuming
> > > that it can be proposed as an amendment to ODF, or are you confirming
> > > that it would never be accepted.
> >
> > No, I'm not saying that. But a change in the spec takes a long time to get
> > into the spec and to get into implementations. A bit of effort to work
> > with the current version of the file format is much easier than pushing
> > for a spec change.
>
> Yes ideally we'd like to stick to the spec as much as possible, but when
> it doesnt work, there isnt much else to be done.
>
> > That being said, adding 'draw:display' to all drawing objects is a fairly
> > simple change and I think it makes sense. So you can propose it, but do
> > let
> > your other work depend on it.
>
> 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.

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

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