In line below.<br clear="all"><div> </div>
<div>Best regards,</div>
<div>Ann L McCarthy</div>
<div>Imaging Systems R&D</div>
<div>Lexmark International, Inc.</div><br>
<br><br><div class="gmail_quote">On Wed, May 4, 2011 at 3:07 PM, Chris Murphy <span dir="ltr"><<a href="mailto:lists@colorremedies.com">lists@colorremedies.com</a>></span> wrote:<br><blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;" class="gmail_quote">
<div class="im">On May 3, 2011, at 3:57 AM, Richard Hughes wrote:<br>
<br>
> On 2 May 2011 13:37, Jan-Peter Homann <<a href="mailto:homann@colormanagement.de">homann@colormanagement.de</a>> wrote:<br>
>> 1) Kai-Uwe, Richard, Graeme,<br>
>> Lets imagine the OpenICC community would develop a tool for adding an ICC<br>
>> dictType entry with Gutenprint driver setup to an existing ICC printer<br>
>> profile.<br>
>> What would be a good development strategy, that both Oyranos, g-c-m or<br>
>> ArgyllCMS can make use of this tool<br>
><br>
> Sure, colord can do whatever it needs to do, but I would like to<br>
> mention a more general point before we start talking architecture and<br>
> code.<br>
><br>
> If we use a GTK / QT / CPD or whatever dialog with something like this:<br>
><br>
> ____________________<br>
> [ Print settings<br>
> [<br>
> [ Color management:<br>
> [ [_ EpsonStylusColor600PlainPaperGenuineInks.icc {>} ]<br>
> [ Black point compensation [X]<br>
> [____________________<br>
><br>
> Then, we've **TOTALLY FAILED** at user-centric design and abstracting<br>
> all the low level technical details. We'd be asking users to fix the<br>
> gaping cracks in our architecture and blaming them when they get it<br>
> wrong.<br>
<br>
</div>Yes.<br>
<div class="im"><amc> Yes, however user context choices can be presented to guide the underlying logic to know whether black point compensation is desired. Part of the problem is lack of abstraction -- i.e., presenting the techie low level choice instead of the 'why would the user want to do this' choice.<br>
<br>
<br>
><br>
> From a 40,000ft viewpoint, color management is not interesting to the<br>
> end user.<br>
<br>
</div>Yes.<br>
<br>
Basically what I hear being proposed is a way to use ICC profiles by default, rather than proprietary tables provided by the printer manufacturers, like what we see on Mac OS and Windows, with a default assumption that the source space is sRGB in all cases. In the case of Windows, embedded profiles indicating the source space is something other than sRGB, are routinely dropped. On Mac OS, ColorSync is used almost exclusively (by default) as a means to normalize to sRGB and then handoff to proprietary printer color management in the driver.<br>
</blockquote><div><amc> Yes - select profiles by default - guided by the goals the user has for the project. One size fits all doesn't.</div><blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;" class="gmail_quote">
<div class="im"><br>
><br>
> It makes no sense whatsoever to decouple the color profile selection<br>
> from the device selection (e.g. sending a document to the colorspace<br>
> EpsonStylusColor600PlainPaperGenuineInks when it's being printed on a<br>
> HP Laserjet. It also makes no sense to use<br>
> EpsonStylusColor600PlainPaperGenuineInks when we're using glossy paper<br>
> and a Glossy profile is available.<br>
<br>
</div>This is a constant source of error, repetition, consternation, confusion, with existing UI. I agree. I think it should be buried. It should have been buried a long time ago.<br>
<div class="im"><amc> Yes,<br>
<br>
> Don't get me wrong, I think it makes a lot of sense to have a<br>
> super-dialog for people printing on modified hardware on 42" canvas<br>
> with 9 custom inks. But we can't design a general purpose architecture<br>
> to be compatible with that, and also for a regular user just wanting<br>
> to print his tax return without being bamboozled with gobbledygook.<br>
<br>
</div>Depends on context. If I want to print my taxes on 42" canvas with 9 custom inks, the general purpose printing architecture should print that document, by default, with black only ink, just like any other device. And if I print a pretty picture, it should know to use the perceptual intent, also by default.<br>
</blockquote><div><amc> which perceptual intent ;) </div><blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;" class="gmail_quote">
<br>
It's an interesting and open question if the CPD should have an advanced panel for more complex requirements. Or if this "Advanced CPD" panel is something apps can subscribe to optionally. That way they can choose to keep options constrained for their users. I think that's a nice way to do this. And then if the "Advanced CPD" isn't enough, the application can customize yet another panel.<br>
</blockquote><div><amc> if we abstract to the what am I trying to accomplish level and then provide a default something like 'system knows best' -- then 'Advanced' does not have to be limited to technical gurus. </div>
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;" class="gmail_quote">
<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>