Date: prev next · Thread: first prev next last
2016 Archives by date, by thread · List index


On Wednesday 03 August 2016 12:01:04 Yousuf 'Jay' Philips wrote:
On 08/03/2016 09:36 AM, Taylor Jenkins wrote:
*See comments inline.*

*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 <draw:g> which has
the attribute <draw:z-index>. 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.*
Thanks for the clarification as this simplifies everything.

*While this is a good workaround, I don't know that it is entirely
necessary. I think both layering schemes could easily be incorporated
with a change in UI terminology and an LO specific layer feature that
also manages z-index. Since the existing layers are essentially nothing
more than visibility layers, I suggest renaming them as such in the UI,
or perhaps V-Layers for short. The LO specific layers could be called
Z-Layers. Unlike a V-Layer which only has attributes: draw:display,
draw:name, and draw:protected, and does not change draw:z-index, a
Z-Layer could have V-Layers as child elements, and also manage the
draw:z-index of its child elements, simply by assigning the values of
both attributes: draw:layer, and draw:z-index for each drawing object
that is a child element. *
*
*
*Each drawing object has the attributes <draw:layer> and <draw:z-index>. *
*
*
*http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html
#element-draw_layer-set *
*http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html
#attribute-draw_z-index *
*
*
* Using your workaround example, I could import the first ODF structure
like so:*
*
*
*[Z-Layer] Default*
*  [V-Layer] Mobile

     [Object] iPhone (z-index: 1)
     [Object] Nexus (z-index: 3)
  
  [V-Layer] Tablet
  
     [Object] iPad (z-index: 2)

*
*
*
*I could then add objects and layers, while maintaining and ODF readable
document like so:*
*
*
*
[Z-Layer] Default

  [V-Layer] Mobile
  
     [Object] iPhone (z-index: 1)
     [Object] Nexus (z-index: 3)
  
  [V-Layer] Tablet
  
     [Object] iPad (z-index: 2)
     [Object] Galaxy Tab(z-index: 4)
  
  [V-Layer] PC
  
     [Object] Laptop (z-index: 5)

[Z-Layer] New

  [V-Layer] Data
  
     [Object] Specs (z-index: 6)*

*
*
*Since Z-Layers are LO specific, they are ignored by ODF, but since we
structured it like this the resulting ODF document opened in another
application would maintain the same structure and appearance, as shown
below:*
*
*
*

  [V-Layer] Mobile
  
     [Object] iPhone (z-index: 1)
     [Object] Nexus (z-index: 3)
  
  [V-Layer] Tablet
  
     [Object] iPad (z-index: 2)
     [Object] Galaxy Tab(z-index: 4)
  
  [V-Layer] PC
  
     [Object] Laptop (z-index: 5)
  
  [V-Layer] Data
  
     [Object] Specs (z-index: 6)

*
Now with the clarity that groups have z-index, the Z-Layer concept isnt
needed as groups can easily take its place, and V-Layer is actually an
attribute of objects so shouldnt be placed above objects in a hierarchy.
Yes.

[Group] Default (z-index: 8)
   [Object] iPhone (z-index: 7, layer: Mobile)
   [Object] iPad (z-index: 6, layer: Tablet)
   [Object] Nexus (z-index: 5, layer: Mobile)
   [Object] Galaxy Tab (z-index: 4, layer: Tablet)
   [Object] Laptop (z-index: 3, layer: PC)
[Group] New (z-index: 2)
   [Object] Specs (z-index: 1, layer: Data)

Note: i could be mistaken with the z-index numbering and the numbers go
in the opposite direction. :D
Depends what top and bottom of the list mean here :-)
'iPhone' is rendered at top. 'Specs' is rendered lowest and might be occluded.
Having z-index: 3 on the first group would suffice since (in the current 
implementations) it's only evaluated relative to z-index: 2 of group 'New'.

*<draw:opacity> isn't an attribute of layers or groups, but it appears
that it can be used to modify the opacity of a layer or group, since
layers and groups are graphical objects. Ref:
http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#
__RefHeading__1415788_253892949 Even if by chance layers and groups 
can't
be directly modified by
<draw:opacity>, then it can be used to modify the list of elements
contained therein.*
Seems i incorrectly gave the <draw:opacity> tag when i meant to give the
draw:opacity attribute, which states "The draw:opacity attribute
specifies the opacity for an image or graphic object. The defined value
range for the draw:opacity attribute is 0% to 100%, where 0% is fully
transparent and 100% is fully opaque." Its currently available in
<style:graphic-properties>, <style:background-image> and
<style:drawing-page-properties>.

http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__
RefHeading__1417180_253892949

So if draw:opacity is available in layer and groups, thats great.

*I don't see why any application specific feature couldn't be structured
such that they will still display properly in other applications, since
the application specific features could still be using the ODF specified
features to accomplish their task.*
Okay, as i was under the impression that application specific features
wouldnt be part of the ODF spec.
They are not of course. You can use a custom namespace though. LO does this 
for quite some things already. Making an application specific feature is 
usually the first step to getting something in the 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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.