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

[Ross McFarland]

On Wed, 2004-11-03 at 11:46, Carl Worth wrote:
> On Mon, 01 Nov 2004 18:23:32 -0500, Ross McFarland wrote:
> > no disagreement.
> 
> Phew.
> 
> > public api in a separate header not normally included by apps, that
> > explicitly says do not use this unless you are creating an app that
> > speaks to a specific backend developed in conjunction with that app.
> > while it's not ideal, i think that's a reasonable route.
> 
> Sure, I could imagine adding something like:
> 
> 	cairo_pdf_this_is_the_pantone_color_I_actually_want_here
> 
> We can add backend-specific functions as necessary, (after ruling out a
> generic solution). Or backends can provide hooks through a separate
> library interface as does glitz). But I don't want to add a generic
> function like cairo_set_n_color that just so happens to fail on some
> subset of the backends.

i suppose this would be a workable route. it would still require being
able to store arbitrary data in the color portion of the cairo context.
after thinking about it for a bit, truly arbitrary, since there's no way
to envision what types of data an app and external backend might want to
pass though. this would probably require turning the color structures
into full blown objects with destroy methods etc. 

> > i think down that road lies madness. a sufficent api for things like
> > that could be unwieldy. i don't think cairo should know anything about
> > color but i think it best to take it a step further and allow that color
> > it doesn't know about to be anything to allow for possible future cases.
> 
> OK, I disagree here. I think cairo should provide a precise means for
> the user to describe the desired appearance of the objects, including
> their color.

if that's the case then something much more grandious is probably going
to be required. vector graphic page layout programs will require the
ability to work in CMYK so for exacting control of printed output.
likely leaving cairo deal with converting to RGB for the screen display.
a real postscript/pdf backend would easily take CMYK color, but it
wouldn't make sense to force all of the other backends to as well, so
perhaps cairo should be able to do cmyk -> rgb. this would be where
things would get pretty hairy.

> > i would settle for changing the internal structure to something that
> > could hold an arbitrary number of color planes. then changing the
> > existing backends to require that it be 3 plane and read it out of that
> > structure accordingly, assuming it's (s)RGB. thus leaving the public api
> > untouched (still having set_rgb, etc.) until the time came when the
> > ability was going to be specifically used and could be designed
> > accordingly. 
> 
> That would be a much less contentious patch for me to accept. But I also
> wouldn't find it compelling at all. I don't have a lot of stake in
> anything about the current implementation. At any point I'd be glad to
> rip out and rewrite large parts of it. So, I'd prefer to wait until
> there was some use before redoing the internals.
> 
> It's getting the API right that I really care about right now.

understandable. i guess it might be best to wait for an application to
need advanced color, but i suspect it may end up being a chicken and egg
problem.

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