[Openicc] colord Printing Plans, CPD and Gutenprint

[Richard Hughes]

On 28 February 2011 14:32, Jan-Peter Homann <homann at colormanagement.de> wrote:
> Richards answers are seeming not be constent to me, either:
> - updated settings and assigned profiles need updating of the PPD, or
> - The PPD is used for static parameters only. Driver settings and profiles
> are handled beside the PPD

The PPD is never changed. If the PPD specifies an ICC profile (very
rare) then we add that, but most PPDs don't contain any ICC profile
links at all. So we support the "soft" profiles from the PPD, but also
support the "hard" profiles from the user.

> - importing new settings in the printer driver with assigned / bundled
> profiles,

CUPS reads the PPD file when the printer is connected and add the
profiles to colord.

> - printing a testchart from a standard application with deactivated profiles
> in p*toraster

I think in this case it's better to have a dedicated profiling package
for the desktop that can handle all the parameters automatically. If
users want to use eog to print the profile they've been sent by
someone else, I guess it makes sense to have a "[x] Disable automatic
color correction checkbox", but I would much prefer an integrated
experience.

> - creating own profile for a given setting

We create the tiff file in the profiler, which then uses something
like argyllcms to generate the actual icc file. We then add the
metadata to the icc file and save it somewhere in the user directory
by default, or in the system location if the profile is for all users.
At this point the profiler can add the qualifier automatically, as we
already know what the profile was printed on.

> - creatings own setting an then doing own profiling
> - or installing a profile provided from a profiling service for a given
> setting

In this case, the user would have to use the colorgui GUI client or
the colormgr text mode program. Documentation on both of those is
sparse, and colorgui certainly needs more love.

> - where is the place to assign a profile to a driver setting ?

GNOME Color Manager. I've not yet decided on whether we should show
the qualifier in the UI in GCM, as it all seems a bit geeky and
abstract. It might be better to keep GCM very high level for users and
for colorgui to be useable by experts. I'm not sure it's possible to
design an easy to use tool in this context, with power user features.

> - how is the driver setting presented in the printing UI

If there is one profile for the given media and printing type, then we
don't show any UI. If there are multiple entries (e.g. for
RGB.Plain.300dpi) then we show a dropdown for the relevant profiles.
I'm not sure that's going to be common on a typical system.

> - After the user chooses his setting in the printing UI, how does colord
> know, which profile is valid for the setting ?

I assumed the printing UI would be changing the default profile for
the profile qualifier, although this doesn't seem to work very well if
you've throwing lots of documents into a queue and hoping colord does
the right thing. If we want to support that use case, then we'll have
to send colord some kind of "hint" about the document-id so that some
special ordering is done. That's not specified at the moment, although
it would certainly be easy to add later.

There are a lot of edge-cases colord doesn't seem to support right
now, and I appreciate people might be concerned one or more use-cases
are being sidelined. At this point I'm very keen to push my patches to
ghostscript, cups, foomatic and GNOME so that we can at least get the
basics working in distros, and then work on all the edge cases when we
have some stable base. I'm not sure designing the perfect architecture
without any integration makes a lot of design sense as often
integration throws up design issues of its own.

Richard.