[cairo] RFC the idea of n-plane color support

[Carl Worth]

On Sat, 30 Oct 2004 18:53:42 -0400, Ross McFarland wrote:
> On Sat, 2004-10-30 at 17:54, Carl Worth wrote:
> > On Sat, 30 Oct 2004 16:43:09 -0400, Ross McFarland wrote:
> > > it doesn't need to understand the color, as it doesn't now.
> > 
> > But it does now. The color values provided by the user are sRGB. That's
> 
> cairo itself doesn't know anything about sRGB.

If I were to take a cue from my 4-year-old at this point, I would just
say, "It does too!", well prepared to continue the debate ad nauseam.

Let me instead say that I think we are in violent agreement here. The
"core" cairo code does pass color values from the user to the backend
largely uninterpreted.

>                           it's only RGB in api name and backend
> interpretation.

Yes, and that is everything. The utility of "core" cairo is largely in
the contract it provides to the user for expressing intent and the
contract with the backends in terms of rendering to match that intent.

> what i'm proposing would cause no visible changes to apps. and only
> (possibly) slight changes to backends (array indexes rather than struct
> members. changes it took me a couple of mins to make in my local copy of
> the backends.)

The amount of work needed in the internals is almost irrelevant. That
kind of work is always a lot easier than getting the API right, (which
is the part I really care about).

So, you are correct that it would be easy to add an API for specifying
color as N nameless channels while not otherwise changing the code. But
would this be useful? It wouldn't magically let the user start passing
CMYK colors to cairo as the current backends would interpret the colors
as RGB. That would be broken.

> nothing would be broken b/c the standard backends wouldn't support
> anything but using sRGB (programming assertions.)

Ugh. I definitely don't want to add public API so that certain
combinations would be documented to lead to failure due to programming
assertions. That would also be broken.

An alternate approach to this issue would be to implement an API along
the lines of what PostScript provides. That is, there would be a single
cairo_set_color API with generic channels and a set of calls that
designate the colorspace under which the color should be interpreted
(cairo_set_colorspace_srgb, cairo_set_colorspace_cmyk,
etc.). Implementing this would require putting the color management
problem inside of cairo.

I know very little about color management, so I've been trusting the
advice of those with more expertise than me. The advice I've received so
far has convinced me that the right architecture will leave color
management outside of cairo itself.

>              so that if special tied apps and backends (printer/press
> RIP's) could be developed with cairo.

If the application is going to be tied so tightly with one particular
backend, then it sounds like this data channel should go from the
application directly to the backend.

For example, we've already got that kind of communication between
applications and glitz. And this is the kind of thing that led to the
following diagram of the cairo architecture:

	http://freedesktop.org/~cworth/xdevconf/slide_05.png

As I said, I'm no expert here, so I'm prepared to be convinced to change
the current approach to color in cairo. But I'm definitely uninterested
in new top-level API that only works for some subset of the backends.

-Carl