[Openicc] [Gimp-print-devel] [Printing-architecture] Colour

[Michael Sweet]

On Nov 15, 2009, at 11:46 AM, Roy Harrington wrote:
> On Sat, Nov 14, 2009 at 9:08 PM, Michael Sweet <msweet at apple.com> wrote:
>> ...
>> In short, why make the user select everything every time and clutter the UI with unnecessary information?
>> 
> 
> I agree that a lot of this cluttered with too many options.  But all
> the major high end applications have
> a preview page -- this includes Photoshop, Lightroom and even Apple's
> Aperture.   Its the one and only
> place where you can see the image layout, potentially a soft-proof,
> the print profile, and the rendering intent.

Right, but you'll notice that these applications don't use the standard print dialog and (if they were ported to Linux) would likely not use the Common Print Dialog for the very reason that they are expert applications with very different user requirements.

> Neither the Color Matching PDE nor the Epson driver's PDE provide this
> "all on one screen" view of what
> the user wants to happen.   At least the Photoshop preview screen
> provides place to document what a
> user should do.

Right, the Mac OS X print dialog preview does not offer soft-proofing, mainly because most vendor profiles are not invertible and their color controls affect the print as well.

> This is mainly a philosophy issue to answer:  "how should this all
> work? "   There may be other (possibly
> better) ways to design the workflow, but I think the long history of
> how it has been done should be
> weighted very high.

That can be taken in at least a couple ways; IMHO the current "expert" workflow is broken, and the fact that you and many other professionals are used to a broken workflow doesn't make it better or "right".

> ...
> I don't think it was broken.  I'm OK with evolving new ideas, better
> ways.  But lets
> get the new things working and satisfying all the needs before breaking
> the old way.

I'm not suggesting that existing apps or workflows should suddenly stop working.

What I *am* suggesting is that the new Common Print Dialog should not bring along the old baggage and should focus on an improved UI that allows ordinary users to participate in a color-managed workflow without having to know what color profiles or color management is.

> ...
> Changing hats for a moment to my print driver role:   I've been told
> several times that there are
> "new requirements for print driver implementations"  but I've never
> been able to get any specs on this
> either.  I've read all the CUPS docs -- APSupportsCustomColorMatching
> and cupsICCProfile -- but
> it's counter-intuitive (at least to me) to need to add
> color-management issues to the driver in order
> to disable color-management there.

I'm not quite sure I understand what you wrote - can you rephrase?

From the standpoint of profiles and color spaces, we offer two ways for the vendor to participate in color management - cupsICCProfile for vendor-supplied ICC profiles and the AP* keywords that specify a "handoff" color space based on a standard ICC profile (sRGB, AdobeRGB, etc.) If neither is specified, we assume that the driver/printer takes Apple's GenericRGB. The default color space *did* change in Snow Leopard (GenericRGB now has a 2.2 gamma vs. the previous 1.8), but if your driver specified color profiles or a handoff color space then nothing has changed for you.

___________________________________________________
Michael Sweet, Senior Printing System Engineer



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/openicc/attachments/20091115/95cc010b/attachment-0001.htm