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

[edmund ronald]

On Sun, Nov 15, 2009 at 6:08 AM, Michael Sweet <msweet at apple.com> wrote:

Michael,
 It's pretty clear that some people at vendors are now very very
angry, and a lot of graphics users are now very confused and and
hassling profiling vendors; it's not your or their fault that you are
isolated behind a big tall wall at Apple which prevented vendors from
talking to you, but their stuff is now broken and for some color is
their income source.  You despise the old user-experience, for the
hassles it creates, that's understandable, and now you've explained
it, we appreciate  your ambition to better the user experience. But
we'd like to be consulted rather than have some new scheme enforced on
us. And please, pretty please, leave us a workaround which will allow
our old stuff to work - This is a case of retiring the space shuttle
but not leaving the ISS astronauts stranded.

>
> I'm not arguing that Linux duplicate Apple's current ColorSync user experience - that much is clearly broken since users and vendors regularly have so many problems.

Your opinion is certainly well informed because you're on the front
lines at Apple. And as you are responsible for a considerable fraction
of the software involved in Linux printing, your voice certainly
counts for much.

>
> I'm similarly not advocating a continuation of the current "application color management" experience because that is similarly broken for anyone but a professional, and >even then individual driver and application issues make it problematic.

Ok, deprecate it, but provide some sort of compatibility mode with the
old experience so users can employ their old stuff. Please. I even had
ladies in their late fifties as customers who were printing with
custom profiles on the Mac - there was screenshot documentation, and
once they had it working they were happy. This population needs a lot
of time to transition to anything new.


>
> Instead, I'm suggesting that a different user experience be employed: when printing, the user sees no color controls. Color profiles are auto-selected based on the print >settings - users can install new profiles, media types, and ink sets separately as needed. These profiles can be "canned" profiles the user downloads from somewhere or >custom profiles the user creates using profiling software.
>

Maybe one needs a Simple mode and an Advanced mode? The "Simple Mode"
is a very nice idea, but it needs to be refined into usability. In
particular the user needs to be able to check which set of "canned"
presets are being used, and have an interface to edit, save, import
and export them. Paper size presets and color presets are
complementary and should be handled in a complementary manner.

>
> Applications that need to do their own color management (hopefully few and far between) can specify so using an API, which disables color management and profile >selection so that the color data the application provides is treated as device color all the way through to the printer.
>
Sounds good, however this API needs to be clearly documented, which
the present Apple API is not, as Roy's post demonstrates. Personally,
I think even specialist users should be able to easily invoke
deviceColor Space easily, because there are a lot of annoying little
cases where you need it.  Now that computers have become popular,
there are a lot of domain experts who can do quite sophisticated stuff
but who cannot program, and they are important in their organizations.


> Keep in mind that when there is a problem that requires coordination between multiple vendors, a solution inevitably takes longer.
Which is exactly why the old stuff needs to keep working.

> Prior to joining Apple, I wrote and sold commercial printer drivers and RIPs for 13 years, and did printer software for 6 years before that "just for fun".  My company was a member of the ICC...
I'm a member of the ICC Digital Photography Workgroup.

Edmund