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

[Jon Cruz]

On Feb 23, 2010, at 12:12 PM, Bill Spitzak wrote:

>>> 
>>> 6. A correct Cairo backend can be implemented that will IMMEDIATELY (ie before the call to set the color or image returns) convert the color or image to destination space and throw away irretrievably the "source" space.
>> Yes, e.g. the Xlib backend.
> 
> I certainly agree that this is how it MUST be done, but I have to point out that this directly conflicts with most/all of the claims of color management making it possible to replicate a given printer's output. Even if you assume mixing the numbers in the printer's space is the same as printing those quantities of ink (which is demonstratively false), it is certainly not true in a different color space such as the display device.

That's generally not how a CMS API is used.

A target profile will help with mixing the device numbers/colors, but then a *display* profile is used to preview that printing result on screen.

For example, LittleCMS has a cmsCreateTransform() call for normal work, chaining, but then for the display preview there is an explicit cmsCreateProofingTransform() call. So given RGB input of a known colorspace, a transform is built that ends with the target profile of the CMYK printer. *Then* a proofing transform is used to preview that output in display.