[cairo] Spot colors (and CMYK)

[Andrea Canciani]

On Thu, Feb 18, 2010 at 8:47 PM, Bill Spitzak <spitzak at gmail.com> wrote:
> Andrea Canciani wrote:
>
>> Actually all of the quartz surface/image creation functions have a
>> colorspace parameter.
>
> There is however a default value for this for screen windows and I have no
> idea what a non-default value produces. I can't even figure out whether this
> defines the space to convert *to* or *from*. Certainly from experiments it
> is obvious that it has no effect on what is stored in the buffers, even if
> it inverted perfectly the quantization of integer image buffers would mean
> images read back would differ.
There is no default, as you always have to explicilty ask for a color
space (which can be the one of the device, yes, but also anything
else, for example sRGB, just like you would like).
>
>> They are quite similar to what Adrian Johnson came up with when trying
>> to add colorspace support to cairo (and tightly related to PDF
>> design). This seems the right way to follow and is what I'll probably
>> implement. I'll post the proposed extension to current API as soon as
>> possible
>
> Yes if the backend is designed to produce multiple color spaces, it can have
> a device-specific api to set this output color space. People also want to
> stick titles and html references in pdfs and Cairo has pdf-specific apis to
> do this.
This is quite non-pdf specific, as it is basically color-related. In
fact all the vector backends (svg, ps, pdf) and at least quartz would
be able to correctly support color management without fallbacks. Image
would have to be extended and xlib (or xcb, and any other backend
without native colorspace support) would have to fallback (which is
something that already happens for many unsupported operations).
>
> What I do not want is some idea that the color space of the display screen
> can be changed.
Actually I'd like to be able to completely ignore the colorspace of
the display screen. cairo should just produce images in the colorspace
that the user wants.
>
>> Andrea Canciani
>> PS: I tried to get a few snapshot of my desktop with different color
>> profile settings. I found amazing how well color management is handled
>> by "Preview" (I used it to both grab and view the images). The images
>> were automatically created with the ICC profile currently set on the
>> screen (and it was attached to the image, too) and used as such (i.e.
>> displayed correctly, not ignoring it). I realize that most of this is
>> not done by Preview itself, but by Quartz and I think that the same
>> should happen in cairo.
>
> As far as I can tell messing with the color management on OSX changes all
> the displayed images the same. It does not attempt to correct a screen shot
> made with one setting to look that color when you change the settings.
Actually all the images that I produced as snapshots display as
expected here (Leopard, aka MacOS X 10.5)
>
> I think instead the images are being tagged with a fixed color space that
> says "the default color space". This agrees with what I want, with the
> further attempt to nail this fixed color space down to sRGB.
No, they're definitely tagged with different color profiles.