<br><br><div class="gmail_quote">On Mon, May 16, 2011 at 7:28 AM, Chris Murphy <span dir="ltr"><<a href="mailto:lists@colorremedies.com">lists@colorremedies.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im"><br> <br> On May 15, 2011, at 11:09 PM, Graeme Gill wrote:<br> <br> > Hal V. Engel wrote:<br> ><br> >> B. There is significant disagreement over how to handle target printing that<br> >> appears to break down into two approaches.<br> >><br> >> Use a specialized app. A slight variation on this would be to approach one of<br> ><br> >> C. The other option is to put controls in the print UI for target printing.<br> >> This might be OK as a stop gap pending creating a specialized app.<br> ><br> > You are missing the third alternative, which is to tag<br> > the test files.<br> <br> </div>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.<br> <br> 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.<br> <br> 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.<br> <font color="#888888"><br> <br> Chris Murphy<br> </font><div><div></div><div class="h5">_______________________________________________<br> openicc mailing list<br> <a href="mailto:openicc@lists.freedesktop.org">openicc@lists.freedesktop.org</a><br> <a href="http://lists.freedesktop.org/mailman/listinfo/openicc" target="_blank">http://lists.freedesktop.org/mailman/listinfo/openicc</a><br> </div></div></blockquote></div><br><div>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. </div> <div><br></div><div>Edmund</div><div><br></div><div>Edmund</div>