Mike, <div><br></div><div> Ok, this is a precise, documented workaround. I will go out and check whether it works when printing to a remote CUPS queue that is a Gutenprint instance. </div><div><br></div><div> What I found out with a lot of pain was that this workaround wasn't working *for me* with CS5 when it came out; what took me very longer to figure out and confirm was that it wasn't working because of a bug *specific to Photoshop CS5* that meant that the *first print of a session* made with Photoshop CS5 was often bad, and the first print of a profiling session *in my workflow* was usually the target :( . Even worse, any prints made from then on would be correct, so that comparison test prints made from then on in that session would be consistent with previous tests. </div> <div><br></div><div> Reminds me of a guy getting repeat poisoned by his first drink of water in the morning from a lead tainted water-tap which would be completely inoffensive in regular use!</div><div> </div><div>Edmund </div> <div><br></div><div><br><br><div class="gmail_quote">On Fri, May 13, 2011 at 5:42 AM, Michael Sweet <span dir="ltr"><<a href="mailto:msweet@apple.com">msweet@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div style="word-wrap:break-word"><br><div><div class="im"><div>On May 12, 2011, at 5:21 PM, edmund ronald wrote:</div><br></div><div class="im"><blockquote type="cite">Chris, <div><br></div><div> I say applications should have all options open at the behest of the user, including printing targets. </div> <div><br></div><div> You and Mike both say that "special" apps only should be able to print targets. </div> <div><br></div><div> Mike has made a very nice printing system that can just about print anything except a target.</div></blockquote><div><br></div></div>Um, that isn't CUPS' fault - CUPS doesn't do any color management on its own (at least not yet). The issue is how we expose the "identity" color path from the Mac OS X print APIs - it *is* possible, but incredibly obtuse, and none of the standard Apple apps expose the ability to print a target.</div> <div><br></div><div>The "cheating" method is to tag a target image as sRGB (without changing the color values) and then print from Preview, selecting sRGB in the ColorSync pane of the print dialog - this effectively disables ColorSync and should work with all recent vendor drivers you get from Software Update...</div> <div><div></div><div class="h5"><div><br><blockquote type="cite"><div>I say that if you really want to print targets you are welcome to write an app to print targets, as it's pretty clear that otherwise you won't get one :)</div> <div><br></div><div>Edmund</div><div><br></div><div><br><div class="gmail_quote">On Thu, May 12, 2011 at 10:44 PM, Chris Murphy <span dir="ltr"><<a href="mailto:lists@colorremedies.com" target="_blank">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><br> On May 12, 2011, at 10:34 AM, Michael Sweet wrote:<br> <br> > On May 12, 2011, at 3:21 AM, edmund ronald wrote:<br> >> 1. I do agree with Chris that not being able to "disable" color<br> >> management (eg. for targets) on OS Xhas really created considerable<br> >> user pain and this needs fixingI think every app, including Preview<br> >> should be able to print targets.<br> ><br> > There seems little point when you need an app to generate the target image and interpret it anyways.<br> <br> </div>That's not how profiling applications have worked, historically. They came with pre-built targets, and the apps have functioned on a legacy of opt-in color management so an app to print the target wasn't needed.<br> <br> With the advent of opt out color management, Apple very ridiculously failed to provide either an application for printing these targets reliably, and also to provide key developers with a reliable, documented, or publicly available means of opting out for the purpose of printing targets and printing prematched images. Both of these were necessary from the beginning once an opt-out system was implemented.<br> <br> My primary suggestion is that we don't need more UI in print dialogs, things should just work. The use case isn't there so long as there is a utility and API that are reliable and freely available. But Apple has provided neither. Instead there is a private SPI that has largely been denied to exist until very recently, still is private, undocumented, and not locatable on the dev web site, and one which doesn't actually ensure ColorSync's transforms are disabled. And on top of it, Apple deferred to Adobe to create the utility for printing profile targets. I find that quite inappropriate to kick the can of responsibility down the road to some 3rd party who has no control over the SPI on which the utility depends.<br> <br> So regardless of verbal intentions, the actions to me demonstrate something between disinterest and hostility toward ICC based workflows that require custom profile generation and usage without ColorSync.<br> <br> Although things should "just work" and we shouldn't need more UI in every print dialog, given that the Mac OS X print dialog already has a pop-up menu to manually choose an ICC profile, including a "ColorSync Disabled" option in that pop-up menu to choose instead of Automatic or another ICC profile, doesn't seem out of scope or particularly controversial. And the same applies to Linux, if an opt-out color management system is going to be developed.<br> <font color="#888888"><br> <br> Chris Murphy<br> </font><div><div></div><div>_______________________________________________<br> openicc mailing list<br> <a href="mailto:openicc@lists.freedesktop.org" target="_blank">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> _______________________________________________<br>openicc mailing list<br><a href="mailto:openicc@lists.freedesktop.org" target="_blank">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></blockquote> </div><br></div></div><div class="im"><div> <span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><div> ________________________________________________________________________<br>Michael Sweet, Senior Printing System Engineer, PWG Chair<br></div></span> </div> <br></div></div> <br>_______________________________________________<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></blockquote></div><br></div>