[cairo] Spot colors (and CMYK)
cloos at jhcloos.com
Thu Jan 14 11:53:56 PST 2010
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
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.
James Cloos <cloos at jhcloos.com> OpenPGP: 1024D/ED7DAEA6
More information about the cairo