[Openicc] Synchronizing printer driver settings and printer profiles

Richard Hughes hughsient at gmail.com
Thu Jan 12 08:11:53 PST 2012


On 12 January 2012 15:34, Jan-Peter Homann <homann at colormanagement.de> wrote:
> How is the Gnome Color Manager handling the case, if two different drivers
> are available for the same printer ?

It really doesn't. I'm open for ideas here, and we can certainly
modify the MAPPING_ metadata to take in more than just three
parameters; it's free text afterall.

> Lets assume, both driver vendors delivering a profile for plain paper for
> the same printer with the same qualifiers.
> What happens in this case ?

A good question. In colord, you get the "most-default" profile, which
at the moment is the last one you added to the device, or if you
changed the "default" profile for the device, the profile that was
made default most recently.

What we should do is encode what printer driver the profile was
designed for, and encode that in the ICC profile, perhaps as simply as
adding a MAPPING_driver key, although I don't know offhand how to get
what printer driver is being used from a cupsd_printer_t or
ppd_file_t. I think it's sane enough to say that you can't use a icc
profile designed for gutenprint when using a different printing
subsystem (or is it?).

> Am I correct, that CUPS currently has no mechanism to automatically update
> an PPD with additional entries (or merge two PPDs) ?

I don't really understand all the PPD functionality inside CUPS, but
from what I do understand ppd's seem like a great way for a vendor to
ship pre-canned profiles for a device, but a pretty bad way to deal
with dynamic configuration and remote queue color management. I guess
this isn't really surprising as they're really only being used for
what they were designed to do.

> Richard, do you think, that this specifications would fit the needs of Gnome
> Color Manager / colord ?

I don't think we need a formal tag, this is only optional DICT
metadata. As soon as we register the tag with ICC, we have to define a
locked down format, with no way of fixing design bugs or adding
features, but I suppose it does give us a stick we can beat the
vendors with.

> (So one proper tagged printer profile could be used either with Oyranos or
> Gnome Color Manager...)

I think defining a shared standard is going to be the sticking point
there, as colord and Oyranos have very different focuses and target
audiences.

For reference, the stuff I'm doing in colord is documented here:
https://gitorious.org/colord/master/blobs/master/doc/metadata-spec.txt

Richard.


More information about the openicc mailing list