[Openicc] colord Printing Plans

[Chris Murphy]

On Feb 24, 2011, at 4:14 PM, Gerhard Fuernkranz wrote:

> 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).

I admit this is unique on Linux. On Mac OS and Windows, the legacy RGB path is not PostScript but QuickDraw and GDI, and for Mac OS today now that QuickDraw is deprecated it is Quartz which can do either RGB or CMYK.

> 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.

Fair enough. I do not know the consequences of implementing this with PostScript + ICC externally at raster time, since PostScript doesn't support it directly; versus normalizing to PDF and using an implementation of a color managed PDF pipeline which is certainly going to happen anyway. Conversion with pdftops to the actual printer is also possible and due to normalization through PDF, you clean up crusty PostScript from these applications are writing out with an increase in reliability for printing, and they are more compact both for new and old PostScript interpreters.

> 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;

Well, the main argument against it is building something that hasn't found a need for it in the first place. If the application is seriously producing untagged data across the board including saving out its own document format, then neither that developer nor its users really care one bit about color. I am not opposed to the idea of building this capability but it already does not look correct on the display, I don't really see the point it making it look "correct" in print. In fact it will just look different in print in any event.


> 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]

CMYK to RGB yes. CMYK to CMYK should very arguably be passthrough. I don't think we gain anything by 2nd guessing a device dependent color space using a device dependent printer language, and it can actually result in problems due to ink limits and GCR and channel purity, etc.


Chris Murphy