[CREATE] W3C Compositing and Blending 1.0 draft is up: implications for OpenRaster?

Andrew Chadwick a.t.chadwick at gmail.com
Fri Nov 9 09:39:49 PST 2012


The W3C's new Compositing and Blending working draft[1] was published
back in August[2], and is being actively maintained. I like it a lot.
It's very clear about the model SVG and Canvas should use, and
describes very neatly all the algorithms. In my opinion as a humble
developer it's much easier to work from than the older SVG Compositing
Specification[3]. The new spec

 1. Distinguishes firmly between blending and compositing. The older
draft did not.
 2. Formally adds four non-separable blend modes: hue, saturation,
color, luminosity.
 3. Allows any blend mode to be used with any Porter-Duff compositing operation.
 4. Describes how isolated groups combine internally and externally.

Does this change anything for OpenRaster, given that we have always
defined our composite-op values in terms of the W3C specs?

I think we should at least A) update our wording in
http://www.freedesktop.org/wiki/Specifications/OpenRaster/Draft/LayersStack
and make it refer to Compositing and Blending 1.0 because the newer
spec is simply more comprehensible and more tightly focused. There are
some naming issues to deal with, coming from the explicit split
between blending and compositing. A table of equivalences in the ORA
spec would be needed. Where there is overlap, the new spec's blend
modes are the same as those in the older spec.

Alternatively, we could B) split blending and compositing ourselves,
use the new SVG attribute and value names, and permit any blending
mode to be used with any Porter-Duff compositing operator. We'd need
to make the table from A) mapping old ORA comp-op values to split
blend-mode and alpha-compositing values explicit and part of the spec
to support legacy ORA files.

We can use A) as a stepping-stone to a later B) state of course. Is B)
interesting enough to artists and graphics app developers, and close
enough to the way Photoshop does things (...sigh...) to be useful for
interchange? It's certainly more _flexible_; and with layer groups we
could do nice mask tricks with groups that composite internally as
source-in and externally as source-over.

[1] http://www.w3.org/TR/compositing/
[2] https://twitter.com/w3c/status/236106796656361472
[3] http://www.w3.org/TR/SVGCompositing/

-- 
Andrew Chadwick


More information about the CREATE mailing list