[Openicc] Google Summer of Code 2011: The Common Printing Dialog and Color Management
graeme at argyllcms.com
Mon May 16 00:51:52 PDT 2011
Chris Murphy wrote:
> 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.
So what ? There are lots of ways an application may stuff the color up.
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. 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
> 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.
More information about the openicc