OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [Fwd: Re: [Fwd: [office] Proposal: layer-set per page]]

please find below Thorsten Zachmann's comments regarding layer-sets per page.



I'm Thorsten Zachmann and I'm working on KPresenter the presentation 
application of koffice. Sorry that it took so long to reply to your email.
I also talked to one of our artists and the developer of Karbon our vector 
drawing application. I initiated the original proposal of the page layers 
David sent out.

On Monday 13 August 2007, Christian Lippka wrote:
> having individual layers for pages in a drawing document makes perfectly
> sense as a feature.
> If I read your proposal correct you want to keep the document wide
> layers and add
> optional layers per page. I think this only complicates things. Take
> your example that
> when you delete a layer only the shapes that are on that layer on the
> current slides
> are deleted. This will only happen if the deleted layer is in fact a
> layer that is local
> to the current slide. Deleting a document wide layer will still cause
> all shapes to be
> deleted. I think this is a source of major confusion for the users.
> Also I'm not a fan of user interface dialogs like "do you want to add
> that layer
> to the current page only or to the document Yes/No/What?"
> So my opinion to this proposal is to either define that the page layer
> completely override the document wide layer or better to define
> that a document can have either only document wide layer or
> page layer.
> Having only page layer and maybe deprecating document wide layer would
> allow us to add two other nice enhancements.

Yes you are right, having only page layers simplifies the implementation for 
us developers. However I think we should come up with a unified way to 
convert document layers to page layers. This would ease the life of the 
users. It also would enable us to have a silent conversation form document 
layers to page layers. 
However as the features do not fit, as page layers also "influence" the paint 
order, I think we should at least keep the paint order of the shapes as they 
are defined in the document and adjust the layer with a best effort strategy. 

> 1) Layer in other drawing applications always also influence the paint
> order of the shapes.
> Therefore if you move one layer behind another layer, you also move the
> shapes
> from that layer behind the shapes of the other layer. If we deprecate
> the old
> document wide layer we could define this behavior for the page layer and
> avoid
> compatibility issues with old documents.

The talk with the artist revealed that this is the behaviour he prefers.

> By adding this paint order feature to the layers, one must thing how to
> handle
> group shapes. Does it make sense that shapes inside group shapes can
> have individual layers? Or should only the group shapes on page level have
> layers and all shapes inside would be forced to the layer of the top
> group shape?
> Personally I think only the later makes sense and could be implemented
> without
> making this feature to complicated for the end user.

It also applies to how to handle raise/lower bring to front/send to back. I 
thing the applications can decide how to handle this cases. Sure when shapes 
of different layers are grouped together only the shapes can only be part of 
one layer.

I think we should keep the behaviour described in ODF 1.1, 9.2.15:

Drawing shapes are rendered in a specific order. In general, the shapes are 
rendered in the order in which they appear in the XML document. To change the 
order, use the svg:z-index attribute.

With this also applications which do not support layers still display the 
shapes in the right order.

> 2) Layer settings are currently application view settings
> In OpenOffice.org a layer can be visible or hidden, printable or non
> printable and
> locked or non locked. These are implemented as view settings and therefore
> stored like the other settings as generic and undocumented data.
> OOo supports these settings individual for each open view. This may make
> sense
> for the visibility flag, so you want a layer visible in one view and not
> visible in
> the next. But that does not make much sense for printing and lock. Those
> attributes are definitely document settings.
> And even for the visibility the current feature is flawed as OOo only
> saves one
> view, so the per view information is lost.
> Therefore I would suggest to also add these three layer properties directly
> to the page layer in the document and making them therefore document
> settings.

We fully agree in this point that these setting should be document settings.

Have a nice week.

Thorsten Zachmann

David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]