[Openicc] Introduction / Gutenprint

Graeme Gill graeme at argyllcms.com
Tue Apr 12 15:14:13 EST 2005


Gerhard Fuernkranz wrote:

 > PostScript level 2 and 3 define color management functionality, and any PostScript document may
 > legally use it, for instance CIE-based color spaces, which are of course expected to be rendered
 > correctly by a "PostScript level 3 printer" (i.e. ghostscript + driver + printer in our case). IMO
 > particularly color managed applications which produce PostScript or PDF output may likely use
 > these particular PostScript or PDF features.

There are three ways of dealing with this:

1) Have a mechanism that translates ICC profiles into Postscript color
    dictionaries, and let the RIP do the work. You can't do device links
    though, nor a separate separation transform. Calibration can
    be implemented in Postscript, but some drivers can interfere with it.
    Named colors are hard to support except as direct named to device translations.

2) Substitute ICC type machinery for the Postscript color back end (that's
    what we did with Cyclone). This allows support for device links and
    anything else. Basically Postscipt does the device to PCS, and the
    ICC based machinery does PCS to device and device to device.
    Generic (ie. PCS based) named color translation can be implemented too.

3) Put the RIP and ICC based machinery in series. I.e. RIP to a standardized
     RGB or CMYK, and then do a device to device + separation + calibration
     after the RIP. Device links can't work, and accuracy, gamut size and speed
     are compromised.

Graeme Gill.





More information about the openicc mailing list