<br><div class="gmail_quote">On Sun, May 8, 2011 at 2:27 PM, Richard Hughes <span dir="ltr"><<a href="mailto:hughsient@gmail.com">hughsient@gmail.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">On 8 May 2011 12:27, Jan-Peter Homann <<a href="mailto:homann@colormanagement.de">homann@colormanagement.de</a>> wrote:<br>
> - offering a "one click install" for additional printer setups with<br>
> integrated ICC-profil<br>
<br>
</div>I've dealt with one-click install before with my dealings with<br>
PackageKit. The conclusion I came to was that one click install is<br>
very difficult to get right, and probably impossible to do legally and<br>
securely when not dealing with the distribution metadata directly.<br>
<div class="im"><br>
> - offering robust opt-out for printing profiling testcharts<br>
<br></div></blockquote><div>I would prefer per-document opt-out.</div><div><br></div><div>- because I consider opt-out to be a reasonable thing to have easily available on your system, whatever privileges you happen to have, and also available to people sending stuff rom another machine (targets, preconverted files) to a print server, when the print server has a rudimentary instance of our color management system. These may be foobarred workflows, but they allow the use of a CMM on the Photoshop host, black point conversion etc, and I find them useful enough to offer my users, at least until the Linux color management is as robust as the one found on a Photoshop host. To those who mock my reference to proprietary software, let me remind them that we are playing catch up, and that Linux was also a copy of Unix which was a very functional system. </div>
<div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
</div>Is this a per-document opt out? I.e. do I expect to send a normal<br>
document with color management, a testchart and then normal document<br>
to the queue and expect it all to work correctly? At the moment, the<br>
way colord does this is really designed for scanners and displays,<br>
where we inhibit the device for the duration of the calibration. For<br>
printers this works as long as the user does not try to print a<br>
"normal" document when we're in inhibit "mode". If this needs to be<br>
changed we can probably add an additional method for the ghostscript<br>
and foomatic projects to use that pass document-specific hints. I'm<br>
not sure if that's required yet.<br>
<div class="im"></div></blockquote><div> </div><div><br></div><div>If someone can help us implement a clean way to test getting the ink-settings through to Gutenprint, at least for testing, we could get a lot of this stuff protototyped by implementing just sRGB and opt-out. This would allow Gutenprint to transition from the present hand-runed state to profiled printing *now* rather than later. </div>
<div><br></div><div>Edmund</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">I'm being a little cautions relying on the CPD being adopted before we</div>
can color manage printers. Until KDE and GNOME have significant buy in<br>
to CPD, I think it's a dangerous dependency to rely on for the promise<br>
of a color managed printing system. I'm sure that statement that won't<br>
make me super-popular with most of the people on this mailing list.<br>
:-)<br>
<div class="im"><br></div></blockquote></div>