[Openicc] colord Printing Plans

Gerhard Fuernkranz nospam456 at gmx.de
Thu Feb 24 15:14:44 PST 2011


Am 24.02.2011 23:09, schrieb Chris Murphy:
> And in the case of RGB content being printed to a PostScript device, the content is color managed before it gets turned into PostScript.

When printing from dumb applications which are not color management
aware, this is unfortunately not the case. IMO most applications still
produce DeviceRGB Postscript files (actually "untagged" RGB, but as
there is no "UntaggedRGB" defined in Postscript, they use DeviceRGB
instead). A simple pass-through would either treat the DeviceRGB as
printer RGB (in case of a printer driver with RGB ProcessColorModel), or
result in an UCR-based DeviceRGB -> DeviceCMYK transformation in the
RIP, as defined by the PLRM, which is certainly not what we want either.
Somewhere these DeviceRGB colors still need to be remapped (e.g. to
sRGB) and transformed to the ICC-based printer color space.

So I'm wondering, what are arguments against generally supplying the
desired DefaultRGB/Gray/CMYK profiles, and the printer profile as output
profile to ghostscript, and then feeding gs either with the PS or with
the PDF document to be printed, in order to produce the raster file,
implicitly getting more or less full PS and PDF color management (except
for potential bugs/limitations still present in the current
implementation)? [still all options are open; DefaultCMYK can be of
course also set to /DeviceCMYK if printer CMYK passthrough is desired,
or one could set DefaultCMYK to say ISOcoated, for re-targeting PS and
PDF files intended for a press to the printer]

Regards,
Gerhard



More information about the openicc mailing list