Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org

[Taylor Jenkins]

As a user of libreoffice interested in searching for an available
extension, the logical place to look is libreoffice.org. While
ask.libreoffice.org may be easy for contributors to upload and discuss
extensions,  it is a nightmare to navigate for someone simply trying to
find available extensions, and I seriously doubt it can be configured in
such a way as to make the search pleasant.

The only way, architecturally, that I see ask.libreoffice.org being able to
play a role in an extension repository, is if the uploaded extensions were
stored to a remotely queriable database for access by a separate front end
at libreoffice.org. In fact, it would be really great if the
ask.libreoffice.org message board could also be embedded in this front end,
to make for a seamless UX.

On Fri, Oct 12, 2018, 10:02 AM MiguelAngel  wrote:

> Hi Bjoern,
>
> I have been at ask since the beginning, so let me think that I can talk
> with some knowledge.
>
> Is it successful? Apparently maybe, many users is the only place they
> know. But many people remains in the AOo forums specially volunteers
> because don't like Ask.
>
> For me Its usability is far from optimal.Basics like messages from
> threads, badly works.
>
> IMHO, unless Ask has some hidden capabilities for that purpose, I cannot
> see how it can serve to improve the current situation for extensions and
> templates. Sure I need to review the graduation of my contact lenses.:)
>
> Anyway, if it's so good or the better solution in this situation, I
> think you don't need of anyone for that, so please just do it. We can
> live with two places at once.
>
> Miguel Ángel
>
> El 12/10/18 a las 1:12, Bjoern Michaelsen escribió:
> > Hi Miguel,
> >
> > (you do not seem to be subscribed to the design@ list, so others will
> not see
> > your mail. I will reply anyway, but please consider subscribing to the
> mailing
> > list when discussing there.)
> >
> > On Thu, Oct 11, 2018 at 10:56:43PM +0200, Miguel Ángel Ríos Vázquez
> wrote:
> >> Can we really think about using Ask for that?
> > yes. The problems are well-known, have repeatedly communicated in the
> project
> > since at least 2013. There really isnt any news here. Unfortunately,
> there has
> > been little movement, the community around the old extension webpage did
> not
> > grow despite efforts to do so and even external commercial support wasnt
> > unlocking the situation.
> >
> > OTOH, my mail clearly stated that I would like to invite the design team
> to
> > consider thinking outside of the box and ALSO think about
> ask.libreoffice.org
> > as a platform. This e.g. doesnt mean that the old Plone site _needs_ to
> die --
> > but it should not be the only platform considered to provide the much
> needed
> > content hosting.
> >
> > If this results in three to four people volunteering to push the old page
> > forward in a coordinated effort, I am a happy bunny. BUT: Given this has
> been
> > tried since 2013 at least and given the feedback I heard from even
> commercial
> > suppliers about the state of things, I am not too optimistic.
> >
> >> My impression is that it is not even very well accepted as a forum. Not
> an
> >> example of success.
> > Impressions are odd in that. ask.libreoffice.org is certainly the most
> > successful forum LibreOffice currently hosts.
> >
> > https://ask.libreoffice.org/en/users/  shows currently 1547 pages of 30
> users
> > each, so >45.000 registered accounts on ask.libreoffice.org. For
> comparison:
> > wiki.documentfoundation.org has ~17.000 accounts. I'd assume all other
> TDF
> > infra has less accounts.
> >
> > https://ask.libreoffice.org/en/questions/  has >29.000 _english_
> questions
> > alone. For comparision: wiki.documentfoundation.org has ~22.000 pages
> in all
> > languages.
> >
> > While there is always room for improvement, ask.libreoffice.org is our
> most
> > successful platform -- by far.
> >
> >> And on the other hand we could be more thankful with the volunteer work
> of
> >> the people in the project, whether we like it or not.
> > That is also true for those content creators trying to use the extension
> > website to publish content. I posted some random tweets that show their
> > experience. Unfortunately, that feedback isnt too hard to find and has
> been
> > around for years. People uploading their first extension or template are
> > newcomers to the community -- and as active contributors we should make
> sure
> > their experience is not too aweful. The tweets -- together with the fact
> that
> > so many extensions and templates are hosted elsewhere (e.g. on github)
> shows
> > that we are loosing contributors and miss the opportunity to integrate
> them
> > with the wider community. We let those future contributors down.
> >
> >
> > So: tl;dr: I encouraged the design team to look ALSO look at
> ask.libreoffice.org
> > for allowing content publication, esp. since we had good past experience
> with
> > getting commercial support for it for well-defined feature 

Re: [libreoffice-design] Re: [libreoffice-projects] Re: LibreOffice Mascot

[Taylor Jenkins]

How about a tardigrade for a mascot?
What is a tardigrade you ask? Also known as water bears, they are adorable,
and also perhaps the most indestructable creatures known to man.
https://youtu.be/6H0E77TdYnY
https://www.tumblr.com/search/tardigrade%20gif



On Apr 26, 2017 3:26 AM, "Stefan Weiberg" 
wrote:

> To put my two cents in.
>
> The dragonfly is already used by DragonFly BSD and Opera Dragonfly.
>
> On 26/04/17 10:57, Heiko Tietze wrote:
> > Since today is world penguin day [1] some journals reported about Tux,
> > which is a good reminder to keep our discussion boiling with the
> > reference how Linux found its mascot [2]. To summarize the discussion
> > I created a pad [3]. Anything to add?
> >
> > [1] https://www.awarenessdays.co.uk/awareness-days-calendar/
> world-penguin-day-2017/
> > [2] http://www.gregroelofs.com/greg_lnxpeng.html
> > [3] https://pad.documentfoundation.org/p/UX-mascot
> >
> > 2017-03-31 9:51 GMT+02:00 Heiko Tietze :
> >> Hello all,
> >>
> >> additional to the unique branding of LibreOffice today, we want to
> introduce an alternative to TDF's trademarked logo/icon elements that can
> be used by the community with minimal restrictions: a mascot.
> >>
> >> The idea is similar to "Duke" from Java (https://kenai.com/projects/
> duke/pages/Home), SuSE's chameleon "Geeko", Mozilla has a
> lizard/godzilla/tyrannosaurus, Linux' "Tux" is famous, KDE is going with
> the dragon "Konqi" (https://en.wikipedia.org/wiki/Konqi) and Krita has
> "Kiki" (https://krita.org/en/kiki/).
> >>
> >> The first step would be to find some metaphors that enables designs to
> be creative. Something like Freedom, Documents, Openness etc. Ideas for the
> realization are of course also welcome. The mascot could be an animal like
> a (grumpy old) cat to refer to the seven lives of LibreOffice or something
> more symbolic.
> >>
> >> Based on your input we would later start the actual design task, and
> ideally have a few options where the community can choose the best.
> >>
> >> Cheers,
> >> Heiko
> >> --
> >> Dr. Heiko Tietze
> >> UX Designer
> >> Tel. +49 (0)179/1268509
> >>
> >>
> >>
> >
>
> --
> Primary PGP Key (4096 RSA):
> Key ID: 9F73 1A0A
> Fingerprint: 0C67 F721 D7FF 0D9C 13FA 10FD 8141 BA2B 9F73 1A0A
>
> Public Key can be exported from pgp.mit.edu, keyserver.ubuntu.com and
> sks-keyservers.net.
>
>
> --
> To unsubscribe e-mail to: design+unsubscr...@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+unsubscr...@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

Re: [libreoffice-design] Fwd: About UI/UX & LibreOffice

[Taylor Jenkins]

I like this a lot!

On Mon, Jan 9, 2017 at 1:56 PM, Italo Vignoli  wrote:

> Heiko, you are the specialist here, but I personally like the design.
>
> On 08/01/2017 22:09, Heiko Tietze wrote:
> > Hi all,
> >
> > someone send me a proposal how the sidebar could be improved. I tried to
> convince him from our awesome mailing list *g*, but he didn't want to join
> for now. So here is the link to the mockup: http://budislavtvp.deviantart.
> com/art/LibreOffice-SINGLE-WINDOW-Sidepanel-Concept-
> 656226009?ga_submit_new=10%253A1483903742
> >
> > What's your impression?
>
> --
> Italo Vignoli - LibreOffice Marketing & PR
> mobile/signal +39.348.5653829 - email it...@libreoffice.org
> hangout/jabber italo.vign...@gmail.com - skype italovignoli
> GPG Key ID - 0xAAB8D5C0
> DB75 1534 3FD0 EA5F 56B5 FDA6 DE82 934C AAB8 D5C0
>
> --
> To unsubscribe e-mail to: design+unsubscr...@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+unsubscr...@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

Re: Fwd: [libreoffice-design] Share 3D models in the new web site for templates and extensions

[Taylor Jenkins]

I like the idea of being able to download 3D objects for use in documents,
but they should be uploaded and downloaded as 3D object files, not
extensions, unless you are installing a 3D object library, only then does
an extension make sense. My reasoning is based on a few technical and UX
reasons.

   1. UX consistency: I work with 3D models of many formats regularly,
   using a variety of software. Never have I downloaded or utilized a 3D model
   as an extension, only as a file, or zip file of multiple models. Using
   extensions would break consistency of user expectations. Think of inserting
   a 3D object as inserting a png. Would you use and extension to do so?
   2. Efficiency and Minimalism: Installing an extension requires extra
   steps and overhead, when a simple "Insert > Object > 3D Model" would
   suffice. Even better would be to offer the ability to insert directly from
   the website, in addition to inserting from a file. Using extensions
   requires you to find and install the extension, then find and insert the
   object. Using extensions to insert objects into a library might be a wash
   here, except that you would then be using the extension manager to manage
   you object library, instead of managing your objects directly in the
   library. I know LO doesn't have a good custom library implementation, but
   it should, especially in Draw.
   3. Affordance and Discovery: Users expect to find their artwork,
   symbols, 3D objects, etc. in a gallery or library. They expect to insert
   any object the same way they would an image, not by way of the extension
   manager. If they want to manage their libraries/galleries, they expect to
   do it by interacting with the galleries/libraries, not by interacting with
   the extension manager.
   4. Technical: By wrapping the 3D model in an extension you unnecessarily
   increase the size of the file, requiring greater storage resources.
   5. Technical: Further development of LO is needed to better handle reuse
   of artwork and objects in custom libraries/galleries, especially in Draw,
   which would be much better than requiring users to package that capability
   in their extensions.

In answer to Bastian, 3D models are neither templates nor extensions. They
are 3D models, graphics, and artwork. I think the new section should be
labeled, "3D Models" or "3D Art".

I would also like to see a section to upload and download shapes or symbols
and symbol libraries for Draw.

Regards,
Taylor

On Sat, Dec 17, 2016 at 3:17 AM, Heiko Tietze 
wrote:

> Impress can handle
>
> JSON - GL Transmission Format
> DAE - COLLADA
> KMZ - Keyhole Markup language zipped
>
> http://zolnaitamas.blogspot.de/2014/08/3d-models-in-
> impress-libreoffice-43.html
>
> And I would recommend to have 3D models as extensions.
>
> PS: Surprisingly I cannot insert 3D objects in Draw; will file a bug
> report -> tdf#104730.
>
> On 12/16/2016 06:58 PM, Andreas Mantke wrote:
> > Hi,
> >
> > Am 16.12.2016 um 08:08 schrieb Heiko Tietze:
> >> Hi all,
> >>
> >> this email was waiting for a long time in my inbox. But since we have a
> new extensions site now I'd ask you, Andreas, to make this possible.
> >>
> >> Cheers,
> >> Heiko
> >>
> >>  Forwarded Message 
> >> Subject: [libreoffice-design] Share 3D models in the new web site for
> templates and extensions
> >> Date: Mon, 05 Oct 2015 14:00:26 -0300
> >> From: Bastián Díaz 
> >> To: design@global.libreoffice.org
> >>
> >> Hello, I have understood that the design team has been working on a
> >> redesign for the website of extensions and templates for LibreOffice.
> >>
> >> I wonder if it is possible to add a section to share 3D models for use
> >> in Impress. This feature has been added since LO 4.3, and from my point
> >> of view has great potential in education.
> >>
> >> Unfortunately, it is not easy to get 3D models and not all have the
> >> ability to create our own. With a section so the community could
> >> exchange and improve available 3D models.
> >>
> >> Cheers
> >>
> > I wonder, whether this 3D models are templates or extensions. And if
> > they are some sort of them (which one?), do they have a special file
> > format and a file extension?
> >
> > Kind regards,
> > Andreas
> >
>
> --
> Dr. Heiko Tietze
> UX Designer
> Tel. +49 (0)179/1268509
>
>
> --
> To unsubscribe e-mail to: design+unsubscr...@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+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette

Re: Aw: [libreoffice-design] Fwd: Re: Re: Re: LibreColor-HLC palette

[Taylor Jenkins]

I downloaded the palettes availabe from
http://www.dtpstudio.de/palettes.html and looked at the CIE HLC palettes
for several of the software packages I am familiar with. None of the
palette files I looked at had any copyright notice of any kind, so I'm
wondering why it's necessary for the LibreColor-HLC.soc to contain a
copyright notice?

I understand the importance of protecting the integrity of the color
standard. I believe this could be done exactly the way LibreOffice protects
the integrity of it's product through the use of trademarks rather than
copyrights. Is it acceptable to include code in LO under a 3rd party
Trademark?

I think this approach of attaching a trademark, if acceptable to freieFarbe
e.V. and LO, would allow for more elegant integration into the source code,
and provide a greater user experience, with the assurance that users are
using an official palette. Users would then be able adjust the palette for
their own needs if desired, or make derivatives, such as creating a smaller
version for their own corporate branding colors. These derivatives would
simply no longer carry the trademark.

I think it makes a lot of sense for LO to be able to work with standards
organizations in ways that enhance user experience while preserving both
freedom and standards. Let's make the discussion about how to make it
happen, by offering solutions, and alternatives, rather than just pointing
out problems.

Taylor Jenkins




On Dec 12, 2016 12:31 AM, Christoph Schäfer <christoph-schae...@gmx.de>
wrote:

Thank you, Heiko.

Some details may have been lost in translation, so I take the liberty to
clarify my position and situation.

1) I've been using this office suite since it was called StarOffice,
beginning with v. 3.0 Business Pack (or whatever it was called back then).
I tried others but always returned to StarOffice, OpenOffice.org, now
LibreOffice.

2) I still think LibreOffice and *especially* LibreOffice with its many
improvements and enhancements is the best Office Suite out there, at least
for my needs. Its style management is second to none, and the list of
import filters is breathtaking.

3) I've tested a lot of closed and open source Office Suites for use in
cross-media workflows, and there's only a single one I can recommend,
namely LO.

4) freieFarbe e.V. is a non-profit organisation, dedicated to liberate
colour from its proprietary chains (Pantone, RAL etc.) and to establish
truly free colour systems based on open standards like CIE L*a*b*.

5) We hoped to create a win-win situation by offering LibreOffice the
integration of the HLC palette. Since there is a very good physical colour
fan available at a low price, which has been thoroughly tested in all kinds
of workflows, it would help promoting LibreOffice as the office suite of
choice in many creative departments or for self-employed creatives. The
advantage for freieFarbe was supposed to be the promotion of its
vendor-independent colour standard with a tried-and-tested HLC colour
palette.

6) I'm not opposed to an extension, but I haven't created one before, and I
simply do not have the time to get acquainted with all of the necessary
details before your 5.3 release. If someone could step up and create the
OXT file, I'd be grateful for the assistance.

7) If you can find a way to make the HLC colours a part of 5.3, all the
better, but the colour values need to be protected against inadvertent or
intentional modification in the default installation. It's OK if users
store a local copy and modify it, but the original needs to be the same
across all platforms, because otherwise it would become useless.

freieFarbe e.V. wants LibreOffice to succeed in the creative space, which
also needs an office suite. We even promoted it successfully in Switzerland
as the better alternative to MS Office. So please let us find a way to make
LibreOffice the office tool of choice for publishing workflows.

Thanks,
Christoph

> Gesendet: Sonntag, 11. Dezember 2016 um 10:14 Uhr
> Von: "Heiko Tietze" <tietze.he...@googlemail.com>
> An: "design@global.libreoffice.org" <design@global.libreoffice.org>
> Betreff: [libreoffice-design] Fwd: Aw: Re: Re: Re: LibreColor-HLC palette
>
> Hi all,
>
> I had a conversation with Christoph Schaefer about the palette thing in
the last days. He is not happy with what happened and in particular how the
communication was going. I'm translating his last email excluding the
exaggerated parts just for information and not to start a lengthy
discussion. While in my opinion we improved the color palette handling, the
discussion was indeed not really welcoming. That's my responsibility as the
initial discussion could have been done out of the bug tracker, for
instance. But after all I believe that transparency is paramount for open
source. Nevertheless we all should remind to find positive wording when
talking to contributors.
>
> Christoph: "If I get you rig

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

[Taylor Jenkins]

On Aug 4, 2016 1:43 AM, "Jos van den Oever"  wrote:
>
> Hi Regina,
>
> Thanks for the elegant ODG test file.
>
> On Wednesday 03 August 2016 16:31:18 you wrote:
> > Jos, Thorsten, should we adapt the specification to the way LibreOffice
> > and Calligra do it? It would implicate, that the z-index need not be
> > unique over the whole document, but only locally on the level.
>
> Yes we should propose it. This is how it works in CSS and XSL-FO and ODF
> should be the same and at least LO and Calligra implementations work like
how
> CSS and XSL-FO describe it.
>
> Many complicated cases of CSS do not apply to ODF, because in ODF
drawings,
> everything is positioned. One thing we need to specify is what
constitutes a
> stacking context in ODF. Is it just draw:g?
>
> ODF specification currently does not mention what the default z-index is.
I
> assume it is 0. In ODF, index is a non-negative integer. In CSS, it's an
> integer.
>
> I am wondering about the usefulness of z-index in ODF though. If z-index
is
> only local, one might just as well change the order of the elements in
their
> parent.
>
> In CSS, z-index is useful, because CSS is meant to style documents that
are
> independent of the CSS. CSS does not change the document it styles, but
it can
> modify the stacking order for styling purposes. In ODF, the z-index is
> directly on the elements and not on the style. So the question is: is
there
> meaning in the element order besides the stacking order?
>
Yes there is meaning in element order. According to the ODF specificatin,
elements without a z-index will render in the order they appear in the
document. What I'm not sure about, is that if there is an element without a
z-index in the middle of several elements with z-inices, will the element
render first,  last, or in the middle?
>
> Cheers,
> Jos
>
>

-- 
To unsubscribe e-mail to: design+unsubscr...@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

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

[Taylor Jenkins]

*See comments inline.*

On Mon, Aug 1, 2016 at 12:48 PM, Yousuf 'Jay' Philips 
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  which has the
attribute . Here is the reference: *
*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