[Openicc] Google Summer of Code 2011: The Common Printing Dialog and Color Management

[Alastair M. Robinson]

Hi,

On 15/05/11 23:43, Hal V. Engel wrote:

> B. The only open source apps that I am aware off that can produce well
> formed PDF files with full CM support are specialized publishing apps
> like Scribus.

Are there any at all, besides Scribus?

> A. We now have many of the underlaying building blocks for CUPS to
> handle CM correctly. In particular we now have two working (but largely
> untested) *toraster filters based on GhostScript and Poppler that
> support CM at least to some extent.

Last time I tested the Poppler-based filter it failed miserably on the 
Altona and Ghent test suites, but in the simplest case (sRGB input, 
printer profile output) it worked.

> A. Tool kits need to implement at least basic support for producing well
> formed PDF spool files. This means at a minimum that they must not use
> DeviceXXX object tagging unless it is specifically requested by the app.
> Most tool kits appear to use DeviceRGB by default and have no way for
> apps override this. Clearly a major design flaw that is very wide
> spread. This also a major issue for the GSoC project.

It shouldn't be difficult to modify the toolkits such that as a starting 
point they use sRGB ICCBased instead of DeviceRGB (should it?). 
Assuming the toolkit maintainers can be persuaded of the importance of 
such a change, that is!

>     * Another option is to approach one of our existing apps to ask them
>       to add specialized target printing functionality. This would
>       likely add only a few lines of code to the existing app. We
>       currently have members here from at least two apps that might be
>       good candidates. These are Scribus and PhotoPrint. PhotoPrint
>       might actually be the simplest to use for this but either should
>       work. For Scribus this might be implemented as a plug-in.

PhotoPrint is a special case because it bypasses the normal print 
pipeline.  This is a double-edged sword.  On the positive side, it means 
PhotoPrint (when printing to Gutenprint-supported printers) is 
guaranteed to be immune to unwanted colour-mangling downstream in the 
pipeline.  On the negative side, it's a different enough workflow that 
it's harder to be confident that settings are perfectly in sync between 
Photoprint and a regular print dialog.  This problem would be mitigated 
significantly by having print settings embedded in profiles, mind you.
The only other issue with PhotoPrint is that I have next to no time 
available for programming at the moment, and that's not likely to change 
in the forseeable future.

> C. The other option is to put controls in the print UI for target
> printing. This might be OK as a stop gap pending creating a specialized app.

I imagine such an option probably wouldn't be something specifically 
implemented in the print UI, but something in the PPD that becomes 
presented by the UI like any other PPD option would be.

>  Perhaps producing one or more example PPDs that do this correctly
> is a good idea for the prototype.

Definitely.

All the best
--
Alastair M. Robinson