[CREATE] OpenRaster, some open points

[Cyrille Berger]

Hello,

A little update and call for comments about OpenRaster specifications:

- layer stack, it's the specification the closest to be finished (see 
http://create.freedesktop.org/wiki/index.php/OpenRaster/Layers_Stack_Specification), 
but there are still a few points that need to be addressed:
 . mask handling, currently, while it's not clearly stated in the draft, masks 
are stored as children nodes of the layer on which they are applied. But a 
second proposition has been made: masks could be handled as a filter layer, 
in fact a mask is a filter that works on the transparency of a layer. So mask 
storage could be done this way:
<filter name="filter1" type="masking">
<params>
 <param name="mask"><layer src="mask1.png" /></param>
</params>
</filter>

Instead of:

<layer name="layer1" src="image1.png" >
  <layer src="mask1.png" /> <!-- note that this layer element should be at 
least renamed to "mask" -->
</layer>

The main drawback is that the XML looks heavier this way, but the 
implementation should be easier, as you won't need to add a special way to 
handle masks as they would be correctly handle by the allready existing 
filter mechanism.

 . it needs to be bullet proof, I would like to know if there is any points 
that need clarification ?

- supported color spaces in baseline, RGBA (integer and float for HDR) 
8/16bits, GRAYA (integer) 8/16bits, CMYKA (integer) 8/16bits are must have. 
But Krita and gegl supports (or will supports) a much broader variety of 
color spaces (LABA, XYZA, YCbCrA...), the question is : is there an interest 
to consider some of those as important for interoperability, and therefor, 
needed to be included in baseline ?
- data storage specification
 . png for RGBA integer 8/16bits and GRAYA integer 8/16bits
 . exr for RGBA float 16/32bits

Some have expressed concern that having a specific data storage specification 
will make it complicated for a great variety of projects to write a complete 
implementation. On the other hand, at least CMYK 8/16bit is a must have, and 
none of the above fileformat supports it. And I also thinks that the above 
formats (or any other) are not unnecessarily the most efficient file formats 
for daily usuage in either the Gimp or Krita, and having either of them use a 
(even slightly) different fileformat will defeat one of the strongest 
interest of OpenRaster.


As we are definitively not going to reinvent the wheel for the few following 
items, we are going to take inspiration from existing file format

- filter / composite operations, the SVG specification define some filters and 
some composite operations (see http://www.w3.org/TR/SVG/filters.html), while 
SVG defines both of them as "filter", in OpenRaster they will have to be 
divided in to two sections : composite operations (takes two layers as input 
and return only one) and filters (transform one layer into an other).

- vector layer, tinySVG (see http://www.w3.org/TR/SVGMobile12/) seems to be 
enough for the need of OpenRaster

- text layer, before considering a solution, we need to think about the use of 
text layer and then the list of "features" we want text layer to have. Beside 
some basic formating like, alignment, fonts and styles (by style I mean 
italic, bold, underline...).


Remember, that we don't necessarily aim at being exhaustive for the first 
version of the specifications, but it is important that no unneeded features 
is included as they would be harder to remove in later revisions.

-- 
Cyrille Berger