[Openicc] colord Printing Plans, CPD and Gutenprint

[Richard Hughes]

On 28 February 2011 08:51, Jan-Peter Homann <homann at colormanagement.de> wrote:
> So Gutenprint should make the actual settings (with assigned profiles)
> available to CPD (or another UI).

I don't think you want layer n-3 talking directly to layer n (where n
is the user application).

> If the user chooses a setting we need to be shure, that Gutenprint tells
> colord, which profile is valid for the setting choosed by the user.

Other way up I think. If the CPD has to show a dropdown if there is
more than one exact profile match, then the CPD can just set a hint on
colord to make it influence the profile selection. The same with the
GTK chooser.

> Furthermore, the experienced user should be able to have "Color expert
> Options" in the printing GUI (e.g. CPD) to deactivate colormanagement
> through printing a testchart for profiling.

No, I don't think options are a good idea in this case. You really
just want the profiling software to do this automatically, or at very
most, a single checkbox that controls the Inhibit interface:
http://gitorious.org/colord/master/blobs/master/src/org.freedesktop.ColorManager.Device.xml#line312

> In this case the printing UI (e.g. CPD) has directly to communicate with
> colord to deactive usage of profile in p*toraster.

Right, although I'm not sure that belongs in the UI, and more in the
application that's actually doing the profiling (argyllcms?)

> If the testchart is printing and measured, the user will assign his
> individual profile to the Gutenprint setting through the Gutenprint UI. In
> this case, we need to be shure, that colord gets an update, that for an
> actual driver setting a new profile has been assigned.

What's the Gutenprint UI?

> Richard,
> if I look at yout workflow. I get an impression, that colord setups
> p*toraster or foomatic RIP. But I don´t see:
> - the layer, where the driver tells colord, which profils is assigned to
> actual driver setting

CUPS tells colord a "soft" mapping between the linked  icc profile in
the PPD and the device. The user can specify a "hard" mapping between
a custom profile and the driver, which is saved in a database by
colord. If the profile appears on the system, and the device appears
on the system at the same time, the mapping is applied automatically
by colord.

> - the UI layer where the user chooses a driver setting

What driver setting would they be choosing?

> Please take in consideration, that in the described workflow, the process of
> assigning a profile to driver setting is always done in the driver and not
> GNOME Colormanager !!

By driver, do you mean in the gutenprint layer? If so, the profile has
to be added waaay before the raster output gets handed to gutenprint,
as it's already been through ghostscript. Why would gutenprint be
dealing with icc profiles? Surely the ICC profiles would already be in
the PPD and have been added to colord by CUPS?

Richard.