[Openicc] colord Printing Plans

[Chris Murphy]

On Feb 24, 2011, at 5:52 PM, Graeme Gill wrote:
> 
> 	I think you are being far too pessimistic. It is possible to color manage
> PostScript quite well, but you're right that the lack of explicit ICC profiles
> makes it a lot less flexible than PDF. I've done it in two ways :- intercept
> the internal color machinery and substitute specific device link transforms
> (or Source/Destination device profile pairs) for the DeviceXXX to output space
> transform + handle the CSA by running it through the device profile, or
> the second way was to convert DeviceXXX input profiles into CSA's, and the
> device output profile into a CRD. I would be surprised if the new GS doesn't
> have an equally good approach to handling color,

Color managing PostScript, yeah, if you have knowledge and control about how the device behaves. I assume you've talked to manufacturers about how their own printers function and what crap responses you get from them, like they really have no idea how the interpreter is working in the printer.

The problem with RGB PostScript is that the printer itself is going to make an assumption for the incoming RGB and convert to CMYK. I have had printers ignore embedded CSAs in incoming PostScript and only use internal CSAs. I've had them ignore only CRDs in the PostScript, but honor CSAs. I've had them ignore both. I've had them honor both. The only way you know WTF the printer does is to test it because the documentation for the printers sucks. And the manufacturer's tech support sucks even worse. 

I have profiled a lot of such printers and it is a frigging nightmare. I invariably have to profile them as both RGB and CMYK, in multiple driver modes, to find out which method sucks the least.

If Ghostcript can waive a magic want over such printers and figure out how they need to be coddled to get them to spit out decent color, fine. Otherwise, I say the PPD tells all. Honor it. I don't know how you'd unwind it without lots of iteration anyway.


Chris Murphy