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 _______________________________________________ CREATE mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/create
