[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