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

[Chris Murphy]

On May 16, 2011, at 1:51 AM, Graeme Gill wrote:
> I'm certainly not addressing this aspect with this suggestion. In fact this
> approach does absolutely nothing unless various applications and printing
> systems honour the tag. But it would provide a mechanism that any
> half sane "submit to the printer" application can pass through, and makes
> sense as a mechanism for a printer driver to implement setup/calibration/profiling
> support.

I read "does nothing unless tag is honored" and then "provides mechanism that any half san app can pass through."

These things appear to me to be in conflict because 98% of all applications ignore tags that have existed for 15 years. So how are we going to get more sane apps that honor new tags?

I'm still reading a specialized application. I'm not going to trust a randomly chosen app for this task, even with special files, until it's tested. And every time that random app is updated, I'd have to test it yet again to confirm nothing has changed.

I think it's better to have this emphasis on a handful of apps rather than any random application - with a print UI that implies it can affect any application and give us the results we want.



> Of course if a printing system has no direct submission interface
> (i.e. client system driver/spooler etc. always re-interprets the input
> into the spool format), then it needs to pass the tag through.
> 
> If it were a standard, then there would be a simple bug report for
> applications that don't do the right thing: "Please implement the
> SCPS Tag".

Haven't we been doing this for a very long time with respect to ICC profiles and it basically has failed? This is an area where Apple has done more work than any company I'm aware of, in that they integrated ColorSync into various image related APIs such that you get some degree of automatic handling of embedded profiles in open and save dialogs - or at least it's easier for developers. It took a really long time to get to this point. On Windows, this is totally MIA.


> 
>> I still prefer a dedicated app, honestly. It's not enough that the target is printed
>> correctly for profiling - we need assurance that it has been. Printing a target is a
>> bit of a leap of faith with each new application I print from, each new OS/manufacturer
>> print driver I use.
> 
> To be useful the printer should give some feedback that it's noticed the tag
> and is honouring it. But then it should also reject the job if any color
> specification doesn't match the expected device colorspace.

I very much like the idea of some nugget in the print pipeline itself having awareness of target printing, to qualify visually (or with a print queue related error) the resulting output of the target. Something that could be printed from any application, but if it is altered, the print system would know that it's a profile target, know that it's been altered and either fail to print it (with suitable error) or print it with some mask that indicates to the user the target is invalid (has been modified).

I think this has the potential to get us what we want. It doesn't require adding UI. And it does something that even present workflows do not have.


Chris Murphy