[Openicc] colord 0.1.9 released - CM Framework - Printer Driver

Richard Hughes hughsient at gmail.com
Mon Jun 20 05:00:47 PDT 2011


On 20 June 2011 12:47, Jan-Peter Homann <homann at colormanagement.de> wrote:
> I would recommend, that we include following data as ICCdictype metadata
> into ICC printer profiles
> - CUPS qualifiers for
>    - mediatype
>    - resolution/quality

Yup, I already added MAPPING_format and MAPPING_qualifier in the last
release of colord:
http://gitorious.org/colord/master/blobs/master/doc/metadata-spec.txt

> The role of the CM framework (g-c-m / colord or Oyranos) would be to be
> 1) installing of new printer profiles into the system

Right.

> 5) send information to gstoraster for the printer profile according print
> chooser selection

Well, it's up to gstoraster to query the color profile to use from
colord for the given document qualifier (qualifier = RGB.Glossy.600dpi
for example).

> 6) send information to driver (e.g. Gutenprint) about the correct driver
> setup for the printjob

Again, what data needs to be sent to gutenprint? Can't gutenprint just
query some metadata value itself from the colord profile? So we embed
some kind of GUTENPRINT_gamma_curve=<xml><foo/></xml> either into the
ICC profile DICT tag, or onto the colord virtual profile instance, and
then just extract that in gutenprint?

> Could you please comment especially the point 3) and 6) from your
> perspective. Doy you plan to integrate such functionalizy into your CM
> framework, or do you would prefer another workflow for synchronizing printer
> profile selection and driver setup ?

I think it makes a lot of sense for the CMF to stay a device and
profile registration framework, and let the users (gstoraster, cups,
etc.) just add metadata where required. I don't actually think it's a
good idea for the CMF to understand all the GUTENPRINT_gamma_curve
type data at all. It's just profile metadata that happens to mean
something to gutenprint.

Richard.


More information about the openicc mailing list