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

[edmund ronald]

On Mon, May 16, 2011 at 7:28 AM, Chris Murphy <lists at colorremedies.com>wrote:

>
>
> 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.
>
>
> Chris Murphy
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
>

Here I must say I really like the way Chris is thinking. Bugs often nest in
color managed apps because only people with good eyes and strictly
controlled workflows can dislodge them. If we provide probe profiles and
targets that go with them as part of the test suite in the package, many of
the bugs can be destroyed as part of a default test action. I know this is
ridiculous but I consider the "Test Print" button in CUPS to be one of the
most valuable features of the software, since it provides precise input, and
the diagnostic logs can be usefully sent to the developers if one does NOT
get the test print.

Edmund

Edmund
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110516/d3662928/attachment.htm>