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

[ecir hana]

On Mon, Feb 22, 2010 at 6:31 PM, Andrea Canciani <ranma42 at gmail.com> wrote:
>
> Well, the current proposal doesn't even allow creating DeviceGray
> and DeviceCMYK spaces (but I will probably add those later).

For me, that would be great, thanks!

> If I understood the PDF spec correctly, to be able to use DeviceN
> you would have to specify how to convert your n components to
> a known color space anyway... why not take one step further and build
> a real color profile? (i.e. use a PCS as your alternateSpace)

Couple of points:

- if you know the alternative CMYK of a full solid (100%) spot color,
it is rather easy to compute the tintTransform mapping - see the
attachment here:
http://lists.cairographics.org/archives/cairo/2010-January/018997.html

- so yes, if you are able to pre-calculate the tintTransform it should
be possible to create a profile, which would map my spot colors to
CMYK values. The problem is, I don't know how to create such profile.

- that was for CMYK alternative, it is also possible to define the
alternative in LAB, where I totally don't know how to calculate the
alternatives for tint values. Not to mention the blending of several
spots.

> I know that adding color space constructor taking a color space and a tint
> transform we would remove the profile creation burden from the user...

That is true, otherwise everyone who would like to use such colors had
to implement basically the same thing and to create such a profile
from tintTransfom all over again.

That's said, so far we are only talking about the definition of a
substitute in alternative space. But much more important is the main
purpose of spot colors (and DeviceN) - that is to *name* a color, to
attach "const char *" to a color. I think, this is much more crucial
for the "Color space API", something which is currently missing in
your proposal.