[Openicc] printer, driver, CUPS, PPD, printing GUI, ICC-profiles, colord, Oyranos, taxi....

[Richard Hughes]

On 13 January 2012 11:05, Jan-Peter Homann <homann at colormanagement.de> wrote:
> - Relations to GNOME project and Red Hat

I'm not sure that's completely accurate; I've designed colord to be a
desktop independent system-wide daemon that's accessed with DBus, so
there's nothing stopping KDE shipping a policy module too. Alex
Fiestas was interested in doing one last sprint, but I don't know how
far he got. Certainly a colord desktop policy module is an easy thing
to implement and would only take a few weeks of someone familiar with
the innards of the particular desktop:
http://www.freedesktop.org/software/colord/faq.html#gcm

Also it's probably not right to say it's a Red Hat project. I work for
Red Hat, and I work on color stuff in work time, but it's not
explicitly a Red Hat project -- quite a few other the other
contributors are from Ubuntu and OpenSuse. I don't know if that's
being pedantic or not.

> Both colord / GNOME colormanager and Oyranos have a basic infrastructure to
> work with CUPS and provide a link to the printing GUI / print choose.

In the colord architecture, we've patched CUPS to talk directly to
colord just like it does with ColorSync. I don't believe you can do
the same with Oyranos as there's no system process to talk to. From an
architectural point of view the distinction is pretty important.

> Concerning new printer profiles, colord / Gnome Colormanageg has a focus on
> profiles which are generated inside the solution. Importing printer profiles
> with embedded metadata for profile device matching and links to the printing
> GUI is currently not implemented.

Nearly. We've implemented the MAPPING stuff in so far that you can
download a printer profile, and it'll get automatically mapped to a
specific ink/paper/quality type. What's not implemented is
automatically assigning "external" icc profile with devices based on
metadata.

....but that's a lame excuse and it's not hard to fix, so I've just pushed:

commit 6e7b251867ba3b74751b53f1ba563e98a6e3df1a
Author: Richard Hughes <richard at hughsie.com>
Date:   Fri Jan 13 13:59:26 2012 +0000

    Add profile metadata MAPPING_device_id for automatic profile mapping

    This allows us to automatically soft-add a profile for a given device.
    This would let us profile a device, and by setting the MAPPING_device_id
    metadata key to the device_id we could share the profile with
other people with
    the same hardware.

    If this profile was then installed elsewhere, then it would automatically be
    mapped to the device if present, just like it would be done from a PPD file.
    This of course can be overriden using the mapping database, which uses hard
    mappings.

I've just also added the 7 lines to GNOME Color Manager to fully
support it as well.

> 1) Should the complete printing GUI for the enduser should be always
> generated from the PPD ?

There's not enough data in just the PPD to show the user what's going
to happen. External (for instance, user-created printer profiles)
won't be understood by the PPD, and at least for colord trump the
vendor supplied profiles.

> 2) Should there instead be a stripped PPD without any informations for
> mediatypes and mapped ICC profiles ?

I don't think this is how PPDs were designed to be used.

> 3) Should we have the possibility of embedded low level driver setttings
> into the printer profile ?

Sure, it's just other things that influence the profile selection. The
hard part is working out what matching criteria to use, and make it
easy for the user to understand what's going on. This is why we show
the user what icc profile is going to used (as a label) in the
GtkPrintDialog which we use in GNOME3, and this changes as you change
options like paper type and ink colors.

> If only high
> level metadata are embedded in the profile (e.g. CUPS qualifiers for
> mediatype and resolution) we have to define a process that makes secure that
> driver settings during profile generation and profile application are always
> identical.

Right, if this is what the user wants. I think this only affects a
very small number of people, but just for those (important,
not-the-less) few we could define a MAPPING_profile_settings metadata
key that *has* to match perfectly for the profile to match. This
MAPPING_profile_settings just has to be defined by somebody so we know
how to populate it. The hard part is then getting from CUPS the
low-level profile settings, as CUPS is geared towards the
MAPPING_format way of doing things.

Richard.