[Printing-architecture] Common Printing Dialog and color management

Chris Murphy lists at colorremedies.com
Thu Feb 24 11:31:24 PST 2011



On Feb 24, 2011, at 12:13 PM, Kai-Uwe Behrmann wrote:
> 
> 
>> * Every single PPD file on the planet would need to be modified to
>> support the CPD.
> 
> You can not be serious about this.

Well in a set of slides I found from the Open Printing Summit 2009, the CPD is expected to use the Extended Format proposed for PPD. So if that's still proposed and not done...

If I read these slides right, there is built in graceful degradation of the CPD in terms of options, depending on platform: no GUI, mobile GUI, reduced GUI (netbook, regular user default on desktop perhaps), and expanded. In order for the CPD to be drawn correctly and degrade options properly for each of these levels, its seems to me that the PPDs would need to be modified.


> 
>> So basically, I'm not sure what the CPD buys us. Looking at
>> http://wiki.openusability.org/wiki/printing/index.php/Photo_printers_parameter_specifications#Color_Management_and_the_CPD
>> I'm not convinced mixing the color management settings in with the
>> printing options makes a lot of sense either.
> 
> CPD runs as a user process. Thus the user relation is first class. While xxxtoraster is a server side process running as user lp. How might lp know, which ICC profile is the actual one and from which user? On which mechanism does the scheme rely on? It was brought up several times. I never read a convincing answere for that question.

The profiles to use get rolled into the PDF print spool file at the time it's created (or modified using a pdftopdf filter). If the user has specified one, it would definitely need to be in the PDF print spool file, or we're going to need a sidecar for metadata...eek. I see no reason why it can't go in the PDF using CUPS PDF which supports such job ticket info.

Chris


More information about the Printing-architecture mailing list