[cairo] Subtractive API, part 1

Francois Robert frobert at atex.com
Mon Feb 1 01:40:08 PST 2010


ecir hana wtote: 

> void cairo_set_source_spot(cairo_t *cr, const char *name);
> what do you think it is missing?

Dunno if that may help but here is the sort of API found in Postscript :

[ /Separation  % colorspace type
  /MySpotName  % == *name
  /DeviceCMYK  % alternate colorspace (if colorant not available)
  { ...        % tint proc to convert single component to 4 (C,M,Y and K)
  } bind
] setcolorspace
1 setcolor  % maximum ink coverage requested

Many posters have hightlighted the pro and cons of CMYK so I will not elaborate. Suffice to say that the tint proc can be an arbitrarily complex procedure to convert the spot component to the alternate colorspace.
Note that you can also speocify /DeviceRGB or /DeviceGray as the alternate colorspace, with the tint proc returning 3 (resp. 1) value.

Now, things become interesting for a 3-component CIE alternate colorspaces :

[ /Separation         % colorspace type
  /MySpotName         % == *name
  [ /CIEBasedABC      % use 3 component colorspace
    <<
    /RangeABC  [...] % array of 3 min/max value clamping 
                     % each component of ABC input triple
    /DecodeABC [...] % array of 3 function to convert 
                     % each input to a "linear" value
    /MatrixABC [...] % array of 9 values to convert "linear"
                     % ABC triple to intermediate L'M'N' triple
    /DecodeLMN [...] % array of 3 procedures to make each LMN
                     % component "linear" in respect with 
                     % CIE 1931 XYZ
    /RangeLMN  [...] % array of 3 min/max value for each
                     % of LMN component
    /MatrixLMN [...] % matrix (9 values) to linearily convert a
                     % LMN triple to a CIE 1931 XYZ triple
    /WhitePoint[...] % array of 3 values defining diffuse
                     % white point in CIE 1931 XYZ
    /BlackPoint[...] % array of 3 values defining diffuse
                     % black point in CIE 1931 XYZ
    >> 
  ]
  {...               % tint proc converting single spot tint 
                     % to an ABC triple
  } 
] setcolorspace

The point I am trying to make here is that Postscript *forces* you to specify the details of the conversion. The idea in Postscript is that generic mathematical transformations can describe the usual 3-components colorspaces in terms of XYZ. This allows a single mechanism for using the ABC triple to represent any of the following :
- CIE 1931 XYZ (easy one : identity transformation)
- sRGB or some calibrated RGB
- CIE 1976 L*a*b*
- YUV (used in PAL TV)
- YIQ (used in NTSC TV)

A similarly defined /CIEBasedDEF colorspace (PS level 3) adds look-up tables to the mix, so that CIE L*u*v* becomes doable.
1-component (/CIEBasedA) and 4-components with LUT (/CIEBasedDEFG) are also available.

As a side note, the underlying "connection space" (an ICC term not a PS term) is CIE 1931 XYZ, not Lab or L*a*b*.

In PDF, things are somewhat different because only special cases of /CIEBasedABC are considered:  /CalRGB and  /Lab (actually CIE 1976 L*a*b*) plus /CalGray (a special case of /CIEBasedA). In those PDF colorspaces, the some or all of transforms, matrices etc... are hardwired and you can only specify /WhitePoint, /BlackPoint. In /Lab case /Range can be specified. In /CalRGB the 3 /Decode procedures are exponential functions and you can specify the 3 (gamma) exponents. You can also specify the /Matrix.
Finally, PDF knows an entirely different beast : /ICCBased, where all conversion details are left to the CMS and the the matrices, arrays, gamma are replaced by a byte streams containing an (opaque) ICC profile.

François


More information about the cairo mailing list