[Openicc] OpenICC GSoC 2011 ideas / driver setup to profile match

[Richard Hughes]

On 29 March 2011 10:57, Jan-Peter Homann <homann at colormanagement.de> wrote:
> A printer profile represents a driver setup. From the user experience, we
> have following workflow:
> - define a driver setup

With CUPS, would a print queue be equal to a "print setup" or could
one queue have more than setup? If so, that's quite an abstract thing
(queues) abstracted out into setups. I think it makes a lot of sense
to create one virtual printer per CUPS queue.

> 2) Usage of cupsICC approach
> The driver setups are organized in a way, that the user sees in the printing
> GUI only the selectors compatible with cupsICC definition (e.g. mediatype
> and resolution), the user has no possibility (or only with bi warnings !!)
> to change specific driver parameters.
> The CMM framework uses than cupsICC to identify the matching profile for the
> driver setup

I think reusing the cupsICC approach is a nice middle ground.

> For realizing this, we have to specify / develop
> - a place for driver specific metadata in ICC profile

I think it makes a ton of sense to put the metadata in user-created
printer profiles like we already do display profiles (for example, the
EDID_vendor dict entries). If we could do this, then colord could
automatically soft-match devices to profiles even if the user nukes
the configuration or the printer is shared.

> - a way for presenting profiles in the printing GUI

I'm not sure presenting the user with a dropdown of profiles is really
the user interaction I had hoped for. From my point of view, it would
be better to have a setting in the color panel to say "use this
profile for glossy paper" and "use this profile for plain paper" and
make it a configuration, rather than a setting that has to be sent to
CUPS with the document and checked by the user on each print run.

> Approach 3) could may be realized in a GSoc project, but would may need two
> mentors for a) ICC-profile and CMM framework aspects and b) the driver
> aspects to extract the metadata through the CMM framework. Approach 4) needs
> parts of approach 3) with addition of integration of calibration metadata in
> the process.

I think we're quite some way from asking a poor student to implement a
specification when we haven't even agreed on the high level concepts,
let alone the specification. That said, I'm glad we're having this
discussion.

Richard.