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

[Ross McFarland]

On Mon, 2004-11-01 at 15:54, Carl Worth wrote:
> 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.

no disagreement.

> > 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.

it wouldn't imedeiately be useful to 99% of the use-cases, but it would
allow for the other 1% to exist. that's why i purpose doing it in a way
that explicitly says that apps should not use the extended color api nor
will the backends support it.

a side benefit of using an internal structure capable of supporting an
arbitrary number of planes is support for high-end stuff like control of
specific toner amounts could eventually be built in without changing the
existing backends if they're using the mechinism that allows any number
of planes but in a way that always uses three. 

later additions to cairo could add a mechinism by which apps could query
the color abilities of a back end and proceed accordingly. i don't know
that this could be designed without a specific case needing it, but i
think the internals should be structured to allow it.

> > 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.

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.

> 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.

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.

> >              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.

perhaps, but i don't like the idea of the normal use involving color
going through cairo, but other uses bypassing cairo for color. that
seems to violate something. especially when you consider that the cairo
object will have a current color that will differ from the one the
backend is using. 

> 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.

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. 

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