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

[Ross McFarland]

On Fri, 2004-10-29 at 17:08, Carl Worth wrote:
> On Sun, 20 Jun 2004 20:51:16 -0400, Ross McFarland wrote:
> > attached is a patch that changes the color path in cairo allowing
> > arbitrary data to be passed through.
> 
> Hi Ross,
> 
> I'm sorry for the very late reply, but I'm trying to push through my
> backlog. Hopefully I won't have to get so far behind in the future. And
> I do want people to know that patches they have submitted have not been
> forgotten.
> 
> > my thoughts are that cairo doesn't know or care anything about color, it
> > just passes it through, so why not have a generic path so that any type
> > of color could be passed through. (leave it up to the app and the
> > backend to determine how the data is interpreted.) 
> 
> In the recent teleconference we discussed the issue of color spaces. I
> agree that we need a system by which any color can be expressed. Keith
> recommends that the cairo RGB API be specified to be sRGB but that it
> allows negative values. I'm assured that this approach will allow all
> colors to be expressed. It also has the benefit of doing the right thing
> when users naïvely pass in RGB values.

sRGB with negative values and positive values above 255 would allow you
to specific all possible colors. but still would not be sufficient for
many situations, namely for multi-ink printers/presses. you could
conceivably represent all of the possible colors they could print, but
you wouldn't be able to preserve the usage of specific inks.

the simplest case where this comes into play is with a CMYK device. if
text is specified as 50% K. and this is translated into rgb as (128,
128, 128) which is fine and would still result in the same ideal color.
but if you try to go back to cmyk (inks now) how would that come out?
you need to keep things that were specified as pure C,M,Y,K (or even
specific combinations of them) as requested or you end up with
undesirable print. at first glance the solutions seem simple, but i
assure you they aren't. (there is much ongoing research about how to do
this in a full-proof way and no answers)

> But I'm not interested in an API addition that provides backend-specific
> colors to be passed in. One of the goals of cairo is to enable you to
> switch backends and get matching results without changing the
> application code. If I understood the intent of your patch, it would
> violate that property.

i don't have a good answer for that except to say that i wouldn't
envision any app or 'normal' backend using the ability. i would see it
being useful in special case applications (print pre-press) or device
RIPs.

> What do you think of this approach?

basically if you don't support an arbitrary number of color planes cairo
couldn't be used as a RIP engine for a printer or printing press. (and i
would imagine there are other similar situations with which i am not
familiar) i realize that's not exactly your goal and there aren't
exactly a plethora of RIP's out there, but when it is pretty well suited
for such purposes otherwise and i think it's a shame to rule it out
completely.

-- 
-rm
http://www.neces.com/