[Openicc] Printing Plans GhostScript

Chris Murphy lists at colorremedies.com
Wed Mar 2 15:06:32 PST 2011



On Mar 2, 2011, at 2:31 PM, Kai-Uwe Behrmann wrote:

> Am 02.03.11, 13:25 -0700 schrieb Chris Murphy:
>> 
>> Yes but once it's at pstopdf it's already separated from the application and the CPD, there's no way to know/communicate what the user intention is: /Device = sRGB, or /Device = /Device.
> 
> Ah, I see. But if I read Till correctly the prefered Linux printing format is PDF. So PostScript might not play that important role any more and we do not need to suggest it to calibration software and early colour binding print file creators. If you had a actual example I might get a better idea what makes your concern around PostScript. Are you afraid that existing workflows and devices will somehow break?

I'm just trying to understand the general propositions. But I agree with Gerhard that leaving PostScript behind is a potential issue because there will be legacy applications that continue to churn out PostScript for years, even after pstopdf CUPS prefilter is applied to the chain. Even once you do that, you don't automatically inherent OutputIntent. You'd need a CPD that captures the PostScript and immediately turns it into a PDF at that stage, before it even gets to CUPS.

I think the print pipeline can and should handle all PDF. Otherwise you need a gatekeeper application to print something as basic as PDF/A correctly. And in that case, there are a lot of PDFs in the world, and will continue to be created, that are /DeviceRGB or /DeviceCMYK and will look like crap if they are printed to most any output device known to mankind if no substitution of the device space occurs.

Chris


More information about the openicc mailing list