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

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.

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

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

> 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

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

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

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

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

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

3) tree:collapse - a boolean value for saving the state of whether a 
layer or group was open or closed.

> > > You
> > > can set the visibility at the layer level with the 'draw:display'
> > > attribute.
> > Yes we noticed that with <draw:layer ... draw:display="none"/>.
> >
> > > The properties of graphic objects can be set via style:graphic-properties.
> > > http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#
> > > element-style_graphic-properties
> > >
> > > In style:graphic-properies you can set the opacity with draw:opacity.
> > > http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#
> > > property-draw_opacity This is for the object and group level. A layer does
> > > not have opacity, only visible or not visible.
> >
> > The intent of the visibility attribute for objects and groups, just like
> > with layers, is not to modify the underlying object's fill opacity
> > (draw:opacity) or the border opacity (svg:stroke-opacity) from what the
> > user has already set them to be, but simply to toggle its visibility.
>
> Yes, draw: opacity is not a replacement for a visibility toggle.

Glad you agree.

> Cheers,
> Jos

Thanks again.

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