[cairo] Spot colors (and CMYK)

[James Cloos]

To really get colour to work well for both on-screen and print uses,
cairo really needs to embrace colour spaces.

Every object should have a cairo_color_space_t member, which the default
value meaning inherit the parent's cairo_color_space_t, and the default
for cairo_t meaning one of DeviceRGB, sRGB or scRGB -- which one whould
need to decided and documented.

There should be several well known values for cairo_color_space_t, such
as sRGB, scRGB, CIELab, CIELuv, logLuv, DeviceRGB, DeviceGray, DeviceN,
DeviceCMYK, CIEXYZ, CIEYxy, ICC, CIEBasedA, CIEBasedABC, CIEBasedDEF,
CIEBasedDEFG and the typical set of Yuv-style spaces.

For ICC there would be a pointer to an ICC profile.

The CIEBased spaces require a function specifying their conversion to
some other space such as XYZ.  Cairo should support specifying that
function either as a C function pointer or as a string of something
such as cairoscript code.

The well known spaces other than the Device and CIEBased spaces have
documented conversion functions; cairo should implement those in C.

The Device spaces should pass colour values through as far as possible.
In those cases where a conversion must occur, DeviceRGB should be
treated as either sRGB or scRGB; DeviceCMYK as something aproximating
the uncalibrated output of a "typical" office colour laser printer.
XPDF (and therefore poppler), following Acrobat's lead, demonstrate
how that can work.

DeviceN users need to specify their fallbacks.  That may require another
struct.

The default cairo_color_space_t could either be NULL or a global struct
in rodata which would have (int)0 and a few NULL pointers as members.

The struct(s) would, of course, be opaque.

Once everything has a specified colour space and conversions between
spaces are available, the rest mostly should fall into place.

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6