[CREATE] OpenRaster specification update

[Johann ELSASS]

Hello folks,

As I am developing a software that uses OpenRaster, I looked at all programs and how they handled stacks. From there I came to the conclusion that the definition of isolate needs to be altered to make sense and actually to make it consistent with Krita. Also the specifications are not draft anymore as they have been implemented, so certain things are now established. Others, like text element, needs to be removed from baseline because they are not implemented as far as I know. Here is the pull request for all this and some other details:
https://invent.kde.org/documentation/openraster-org/-/merge_requests/2

About SVG embedding in OpenRaster, I found programs that can read SVG layers. Those are DrawPile, Chasys Draw IES, MyPaint and also my software LazPaint (as of version 7.1.6). This is done by specifying an SVG file instead of PNG as layer source, which is in fact ok with the original specifications that actually suggested that this could be done. In all those software, the DPI used for computing SVG units is 90 (maybe because it's the DPI used by Inkscape). Note that this doesn't match CSS specifications of units which states that the DPI is 96.

Using 90 may sound as a contradiction with the default DPI of 72 suggested in the OpenRaster draft, but the DPI in SVG is something fixed ; it cannot be set for individual files. In other words, SVG "pixels" are always 90 or 96 DPI, whatever the real DPI is. As far as OpenRaster is concerned, we can just use pixel units, and thus avoid the question of the DPI. Technically, that means that values either are just numbers without units or with the "px" suffix (the result is the same).

To sum up I suggest to add in OpenRaster specifications that SVG can be used as a layer source, that their size must be set in pixels, but if when reading a file, one encounters non-pixel units, they should be computed with 90 or 96 DPI. We would need to choose if we would like to push the CSS value 96 or keep compatibility with existing 90.  

About the Porter/Duff compositing, I looked at actual software implementation, what I found is the ability to exclude the alpha channel (which amounts to the "atop" mode) and the ability to use a mask (which amounts to the "dest-in" mode). This is possible for example in Krita and Photoshop. In fact it possible to exclude any other channel as well (red/green/blue). Thinking about it, most other Porter/Duff are not necessary, here is how to achieve them using the layer structure, exclude channel and mask:
- "source": hide layers underneath
- "atop": exclude alpha channel
- "over": nothing special to do
- "in": use the layer underneath (its alpha channel) as mask
- "dest": make the layer on top invisible
- "dest-over": switch layer positions
- "dest-atop": switch layer positions and exclude alpha channel
- "dest-in": use the layer on top (its alpha channel) as a mask
- "clear" make all layers invisible
The modes "out", "dest-out" are similar to "in" and "dest-in" but with mask inversion. The "xor" mode is the only one that is not possible to do.

>From that, I conclude that it would be easier to implement channel exclusion (alpha and maybe R/G/B) and masking (using alpha or using lightness, with or without inversion). That would make it easy for existing software to read/write as OpenRaster. Otherwise, there would need to modify the layer structure in the OpenRaster to get the same result, using the equivalences I mentioned.

Hope to hear from you soon,

Regards,

-- 
  Johann ELSASS
  circular at operamail.com