[Openicc] Assuring that all CUPS filter chains under Linux accept ICC profiles

[Richard Hughes]

On 2 February 2012 11:10, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
> 1. colord user selectable per session print profile
>  (as patched into CUPS by RedHat team members)

It's "Red Hat", as I've said before. No space. It's also being used by
Ubuntu and OpenSuse, so the fact that I'm a Red Hat employee doesn't
really come into things. Please stop creating a conspiracy out of
nothing.

>  - side stepping CUPS API

Err, it uses the same mechanism that ColorSync uses on OSX. It also
allows CUPS to specific a default ICC profile in the ppd, but allows
the user to override it.

>  - needs permanent root access (might be fixed now by security team
>    members)

Sure, it needs root. Ubuntu and OpenSuse worked together recently on a
patch to make it run as it's own privileged user. It no different to
all the other DBus daemons in existence, I assure you.

>  - non transparent to applications through the document or the CUPS API

I have no idea what this means.

>  - potentially affects print job of other users as selection is time
>    based

Well, the idea is you set up some print profiles for the printer ahead
of time, i.e. you set profile X for color printing on glossy paper,
and set up profile Y for draft color printing on plain paper. Users
should not "choose" an ICC profile in a print dialog in the same way
they don't choose ink limits and ink-dry parameters. It's an
implementation detail, and not useful to add as a control. Sure, show
the user what profile would be chosen for a set of media types (which
is what the GTK print dialog does) but don't let the user control such
low level details.

>  - thus it may override other profiles in a more or less undefined way

It's not undefined. It's perfectly defined. You just don't understand
how it works.

>  - not network transparent (which is only a missed feature)

Sure, it's not network transparent. The idea is you install the print
profiles on the print server (the remote CUPS instance) rather than
controlling it all client side. If you want client side control, you
just embed the output profile in the pdf that gets sent to CUPS.

>  - three CUPS identifiers are non sufficient for complete calibration
>    state control in PPDs

I never said they were, it's just the default identifier I've been
using to match the format in the ppd and also the format used by
ColorSync. I'm sure color geeks will want to set the identifier format
as something else. In colord the identifier isn't hardcoded as any
format, it's just a string that gets matched by a regular expression.

>  - all these concerns from the colour community are long known

Heh.

> 2. user configurable per print-queue-assigned profile
>  (as investigated by Edmund Ronald)

This is not either or. How much more simple can I make things. If you
specify a print profile in the ppd file, then it gets used. colord
only gets involved when you override that profile for whatever reason.
The two schemes work perfectly together now, and I wish you would stop
spreading FUD that the two systems are in some kind of competition.

Thanks,

Richard.