No subject

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.