[Openicc] GoSoC 2011: CPD and Color Management

[edmund ronald]

Richard,

We can bring up a wizard on first use of the printer to set up things.
If the printer is a known office printer eg Laserjet it would get to
set it up by default for plain paper.
If the printer is a photo printer it would ask the user to determine
the papertype.
This is essential anyway on Epsons because of the Matte ink/ Photo Ink issue.

Edmund


On Tue, May 3, 2011 at 11:57 AM, Richard Hughes <hughsient at gmail.com> wrote:

> Sure, colord can do whatever it needs to do, but I would like to
> mention a more general point before we start talking architecture and
> code.
>
> If we use a GTK / QT / CPD or whatever dialog with something like this:
>
> ____________________
> [   Print settings
> [
> [   Color management:
> [        [_ EpsonStylusColor600PlainPaperGenuineInks.icc {>} ]
> [        Black point compensation [X]
> [____________________
>
> Then, we've **TOTALLY FAILED** at user-centric design and abstracting
> all the low level technical details. We'd be asking users to fix the
> gaping cracks in our architecture and blaming them when they get it
> wrong.
>
> From a 40,000ft viewpoint, color management is not interesting to the
> end user. Sorry; I know a lot of people care about it greatly (the
> majority of this mailing list) but most people don't know what it is,
> and just expect pressing 'print' to Do The Right Thing. Of course,
> that doesn't include hiding options from people that what to change
> the settings, but such color management setup is not per-document, but
> is a setting that is relevant to the device and maybe a handful of
> other easily discoverable parameters.
>
> So in that way, it makes a lot of sense to just embed the document
> space and the rendering intent in the ps/pdf that gets sent to CUPS.
> The document doesn't need to know what device it's being printed on,
> and on mobile we certainly don't want it to.
>
> It also makes sense to set up the printer to have a profile, for use
> when we don't know the paper type, or we don't care. If the user
> selects some glossy photo paper we might use another profile, but only
> if the user or vendor has set that up beforehand.
>
> It makes no sense whatsoever to decouple the color profile selection
> from the device selection (e.g. sending a document to the colorspace
> EpsonStylusColor600PlainPaperGenuineInks when it's being printed on a
> HP Laserjet. It also makes no sense to use
> EpsonStylusColor600PlainPaperGenuineInks when we're using glossy paper
> and a Glossy profile is available.
>
> So, in talking about color management with embedded output profiles,
> and per-document settings being piped through cups into gimp-print
> then we're kinda loosing sight of where we should be going.
>
> Don't get me wrong, I think it makes a lot of sense to have a
> super-dialog for people printing on modified hardware on 42" canvas
> with 9 custom inks. But we can't design a general purpose architecture
> to be compatible with that, and also for a regular user just wanting
> to print his tax return without being bamboozled with gobbledygook.
>
> Richard.
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
>