[cairo] Spot colors (and CMYK)

ecir hana ecir.hana at gmail.com
Wed Feb 17 10:56:10 PST 2010

On Wed, Feb 17, 2010 at 6:44 PM, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
>> Again, the real question is, how do you supply CMYK image to Cairo and
> The API is not (yet) existent. Perhaps:
> typedef enum {
>  CAIRO_COLOR,                        /* no alpha is present */
> } cairo_channel_layout_e;
> /* create a ICC profile container */
> cairo_profile_t * profile = cairo_profile_create(
>            cairo_profile_e         CAIRO_ICC_PROFILE,
>            void                  * blob,
>            size_t                  blob_size );
> /* Specify arbitrary, well defined colour data to cairo.
>  * Care is to be taken for the alpha channel.
>  * Alpha is specified after color.
>  */
> cairo_color_t * color = cairo_color_create(
>            cairo_profile_t       * cmyk_profile,
>            float                 * native_channels,
>            cairo_channel_layout_e  CAIRO_COLOR_ALPHA_NON_PREMULTIPLIED );
> cairo_set_blending_color_space(
>            cairo_t               * cr,
>            cairo_profile_t       * well_behaved );
> /* replace the cairo_set_source_rgb toy API
>  * cairo_set_source_rgb() can be handled as it would be sRGB with
>  * implicite colour space assigment.
>  */
> cairo_set_source_color(
>            cairo_t               * cr,
>            cairo_color_t         * color );
> All _rgb and _rgba functions need complementing cairo_color_t versions.
> As well the image input has to accept a assigned cairo_profile_t container
> and cairo_channel_layout_e enum.
> The profile and color references can be reused and afterward freed.
> The above example requires changes to cairo's core:
> * CMS hooks or linked in CMS
> * cmyk is only possible with four or multi channel support
> Adrian had suggested per colour space constructors for rgb, rgba and later
> for cmyk and cmyka. I would be afraid that the channels count requirements
> would grow in some years beyond the cmyka contructor and the API would need
> to grow further.
> If checking the colour creation can be a runtime thing as in my above
> example, Cmyk and more channels can be added later on need.
>> first, show it on the screen and second, export it to PDF with the
> a) cairo knows how to use a hooked in CMS or uses a internal one - real
>   color API:
>   it will convert cairo_color_t to whatever is required or configured for
>   intermediate blending and after drawing to the required or
>   configured output backends colour space
> b) only cairos PDF backend knows - circumvent cairo toy color API:
>   glueless
> c) only cairos Xlib backend knows - circumvent cairo toy color API:
>   convert in advance to some RGB and configure the backend to know about
>   your delivered colour space
>> same set of graphic operators?
> a) - yes, straight forward
> b) and c) - not really
> To honour the threads name, spot colour could be made a property of
> cairo_color_t with according setters and getters? But I do not have much
> knowledge about that part.


- Do you think it is necessary to allocate each new color? Some
surfaces are able to contain more than one color space (e.g. PDF) so
there's need of attaching a profile to "native_channels". If there was
"cairo_set_working_profile(cairo_profile_t *profile)" instead of
"cairo_set_blending_color_space()" you could do without allocating
each new color - all subsequent operations will assume that space.
There problem is, what about spaces you don't have profile for, such
as Pantone duotones.

- There's also "d)" - just attach the profile as metadata blob without
understanding it and supply a callback function which will do the
conversion from space A to space B. Think of it as how lcms 2.0 works
- read and understand ICC elsewhere, query a surface for ICC blob,
create a function with two arguments (source buffer, output buffer).
Cairo wont care how you created a transformation, just supply one. And
always embed ICC to PDF. But I don't really like the idea of calling
some random callback, just a food for thought...

- And then, there is always this big "if" and "how" I asked several
times already - who will do the conversion? Cairo? lcms? OS? I asked
this several times but saw no conclusive answer. Besides, I still
believe "display and export CMYK in one go" can be done without CMS in

- Lastly, it might be easier to come up with API for just one spot
color first, rather than the whole CMYK, this is why I started
"Subtractive API, part 1".

More information about the cairo mailing list