[cairo] [RFC] Color space API (partial proposal)

[Andrea Canciani]

The attached changes to cairo.h are the base of what will probably be
my API change proposal for color space handling.
Basically all surfaces and patterns will have a color space in which
all the "math" related to them happens (compositing/blending for
surfaces, interpolation for patterns) and their colors are
interpreted. I think that after the creation the color space should
not be changed so I didn't write functions to permit it as this
operation seems to have no meaning in terms of colors. If it is deemed
useful, I will consider adding it, but I'd really like to know what it
would be for.
Following this design, to change the blending space of a surface, the
"right" thing to do is pushing a group with the desired color space,
then use it as appropriate. Please notice that just blending in a
colorspace then converting to another is rarely needed (as conversion
should be handled automatically by cairo whenever it is actually
required). Why would someone want to do the last conversion? It is
only needed when outputting to a format that doesn't support color
profiles (in which case cairo should handle the conversion) and
proofing (but you will obviously have to ask for this one explicitly).
Are there use cases where the proposed API is inadequate?
I think that rendering intent should be an element of the current
graphic state as it's not something related to a "static" surface, but
its interest is basically limited to color change
(blending/compositing). I'm not sure about how to best handle
out-of-gamut color in patterns. They could be disallowed (invalidating
the pattern when such a stop is added), handled as said by the cairo_t
rendering intent or patterns (gradient patterns, actually) might have
a rendering intent.
I didn't attach backend API changes, they will require some more time,
but AFAICT ps/pdf, svg, quartz and win32 should have (some) color
space support. Image (and all other backends, expecially xcb and xlib)
will probably get it through pixman and/or fallback to image.
This is essentially a RFC, so I'm expecting some complaints (I'd like
to be able to do this and that...), but I'm also interested in
high-level comments (I don't think every surface/pattern/color should
have a color space, the rendering intent is in the wrong place...)
Thank you in advance
Andrea Canciani
PS: I was almost forgetting... I think I won't be able to avoid the
availability of the uncalibrated rgb color space
(cairo_color_space_create_device_rgb) to retain compatibility. I'll
evaluate the possibility to make it the same as sRGB or some other
well-defined RGB colorspace at least in some backends (I'm afraid it
probably won't be possible in ps/pdf and xcb/xlib).
PPS: Oops! At 2:30 am my memory is failing me... Going to bed soon,
but I should thank Adrian Johnson as these changes are heavily based
on his colorspace branch, on some conversations I had with him,
Benjamin Otte and Joonas Pihlaja on irc and on the quartz API, which
seems to do an awesome job about color management.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cairo.h.diff
Type: application/octet-stream
Size: 9978 bytes
Desc: not available
URL: <http://lists.cairographics.org/archives/cairo/attachments/20100222/106db8ea/attachment.obj>