[Openicc] Google Summer of Code 2011: The Common Printing Dialog and Color Management
lists at colorremedies.com
Sun May 15 22:28:47 PDT 2011
On May 15, 2011, at 11:09 PM, Graeme Gill wrote:
> Hal V. Engel wrote:
>> B. There is significant disagreement over how to handle target printing that
>> appears to break down into two approaches.
>> Use a specialized app. A slight variation on this would be to approach one of
>> 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.
> You are missing the third alternative, which is to tag
> the test files.
This is interesting. But it could still be assumed to be sRGB (or something else) and converted to Display RGB (or something else) prior to being submitted to the print pipeline. I don't know of an example application that behaves this way, but that it probably doesn't exist doesn't mean it's not out there, or won't be. If I enable full color management in Firefox, I don't know for sure that it does NOT behave this way when printing. It very likely doesn't, but to know this, it'd have to be tested.
What I like about this is some way to bomb proof the target itself. Maybe if it does get converted, this affects a checksum somehow, and causes a different layer to be printed by Ghostscript rather than the target data - a layer that when printed informs the user that the target is unreliable.
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.
More information about the openicc