<div dir="ltr">Chris, <div><br></div><div> At this point I think it will be necessary to have a debate. </div><div><br></div><div> But I would like to stress that we DO NOT require a GUI switch, as we want to be able to switch a whole queue into the CMS OFF mode ... and watch ink running off the paper if we exceed the ink limits if we foobar the data ... because that's what we do. We deal with the physical device, not its logical rendering. You off all people know the drill: Ink limitation, ink curves channel by channel, linearisation channel by channel, profiling, each requires its set of targets. You of all people know how many sheets of paper end up going through a device, in its raw mode before the device is profiled and locked. </div>
<div><br></div><div> Re. the ppd etc, two remarks.</div><div> 1. We expect that some mechanism for editing ie.. loading part of the ppd governing its inking behavior be editable BY US on the fly, because when tuning the media settings that is what we do.</div>
<div> 2. Who do you think is responsible for the contents of the PPD as it stands? My impression, last time I looked is that the ppd contains in large part a printer description, which comes from ... the people who have created the printing backend.</div>
<div> </div><div>I'm drunk. I'm tired. Clearly these points need to be debated by smarter and cooler heads than mine. </div><div><br></div><div>Edmund</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Tue, May 21, 2013 at 9:43 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 class="im"><br>
On May 21, 2013, at 1:14 PM, edmund ronald <<a href="mailto:edmundronald@gmail.com">edmundronald@gmail.com</a>> wrote:<br>
<br>
> Michael,<br>
><br>
</div><div class="im">> At this point let me be really clear. We wish to use apps like the GIMP to print our targets on a queue, with no color management. We do not wish to use "special" apps or call an API. We want to be able to do it with "normal" apps on a "normal" distribution.The option to disable color management can be set in the ppd, which means not accessible in a UI and thus not confusing. However if you disagree with providing this option after having discussed it "amongst yourselves", your chances of active cooperation from us re. color management will be very strongly diminished. Is this really what you want? Is it that important not to provide a ppd switch?<br>
<br>
</div>If it will work anything like the way lpadmin does on OS X, the original ppd isn't touched, a copy is made when a queue is made, and unique queue features that necessitate ppd modification go in that queue's ppd. So no I'd not expect the ppd to be directly editable by a person, that's really kludgy and risky. Rather the queue specific ppd is modified via lpadmin.<br>
<br>
It's up to GIMP developers if they want to present this as a GUI option within the app. It's not appropriate in my opinion for us to dictate to application developers what options they decide to reveal to their users.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
Chris Murphy<br>
</font></span><div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div>