The OpenIcc/Cairo page is dedicated to collect colour management requirements for Cairo.
Preface: Flatcolor documents vs. mixed color document
If icc profile support should be implemented into cairo, it makes sense to do it in two steps. Firstly concentrating on ICC profile support for documents where every object of the document must be in the same colorspace. This would allow e.g. to implement CMYK colors in Cairo. The first step would be the possibility to associate a profile for all objects of a cairo document. If the document will be rasterized to a bitmap no colormanagement will be applied but the profile valid for the document must now be associated with the rasterized bitmap. For output on a monitor or a printer the rasteized bitmp has to be color converted from the document colorspace to the output device. This could be easily implemented with littleCMS or may be also calculated in the graphics card.
For PDF-export the document colorspace of a cairo CMYK-document should be embedded as PDF/X output intent.
As colormanagement in Cairo has also to deal with the communication to X in monitor and to the printer infrastructure like e.g. CUPS and Gutentprint, it would be much easier to implement colormangement for flatcolor documents and learn here to communicate with X and e.g. Gutenprint.
After this things have been solved, we can discuss, how to implement colormanagement on object level.
Requirements for color management on object level
- input colour space tagging
- assume a reasonable input colour space
- tag the colour space per object for images, actual drawing colour, gradients (?)
- output should be device dependent
- ICC_PROFILE_ in X for monitors
- ICC based colour spaces for printing, including Cmyk
- individual overriding
- blend in a consistent editing (often called working) colour space
- OS neutral API
- good defaults, which match system preferences
- this targets to default profiles (editing/blending space, output devices like monitor)
- settings like rendering intent or proofing
- overriding should be possible to allow individual settings
- honour automatic conversions requests (PDF-X xxx?)
- n-channel input for n-channel output (spot colours, Cmyk++ ?)
- preserving separations (cmyk_K_)?
- higher bit depths
- allow for Lab/XYZ blending?
- high quality photo printing
- cinema
- only one colour space (scRGB) in Cairo?
- simple for displaying
- still useful for high quality previews?
- no cmy_K_ preserving
- still good photo output, no print output
References
Creating CMYK and spot colors OpenICC email list thread
Spot colors (and CMYK) dec.2009 jan2010 Cairo email list thread
Questions
Add external dependency?
- implement only hooks in Cairo to plug-in whatever colour library?
- makes CM optional and may possibly confuse Cairo users wether Cairo is CM aware or not
- provide a Oyranos function oyCairoInit( cairo_t ) to plug-in Oyranos?
- use the Oyranos APIs:
- hard coded dependency?
- as compile option?
- consistent through OS's
Slides
Cairo with external colour management: 
Colours need to be prematched. Blending and so on happens in this colour space. For output on different devices the whole image must be rendered each time with the appropriate input.
Cairo with basic internal colour management: 
The above scheme allows for assigning of profiles to input and passing through of profiles to output. This is a intermediate step, to tell backends what to render to and what to embedd into output or even do the conversion. Such a implementation is not very foolproof for users but allowes for important features in advanced colour managed applciations.
Cairo with automated colour management support: 
In the above scheme Cairo converts all input to its internal editing space, which is eighter set explicitely or by a CMS like Oyranos. The output is converted sensible. Whether to keep a copy of input colours to pass through to complex vector documents is a question for later on. Such feature would allow for preserving Cmyk and similiar content for PDF's.