colord

[Richard Hughes <hughsient gmail com>]

In the last couple of months, I've been talking quite a bit with Tim
Waugh about color management of printers, and how to achieve working
CM with CUPS. At the moment, gnome-color-manager locates CUPS devices
and allows the user to calibrate them and assign profiles, but CUPS
doesn't actually use the assigned profiles for printing. Oops.

Needless to say, the combination of CUPS, ghostscript and other
complicated little-known parts of the printing stack make this look
almost impossible. OSX uses CUPS and CM works really well on printers
using Apple products -- and so it must be possible. We need to make it
work on Linux too before Linux can become a serious option for artists
and media professionals.

OSX uses a system-wide framework called ColorSync that does all the
device<->profile mapping, and allows the user to change the ICC color
profile for each device, and also allows the user to choose internal
profiles listed in the printer definition file. ColorSync works really
well, and is an integral piece of the OSX operating system.

GCM is a session process that provides session programs access to the
per-user color management settings. Because GCM is running in the
session it can integrate deeply into the GNOME desktop environment and
is not particularly security sensitive. But, because the framework is
per-session, system frameworks like CUPS cannot access the data, and
we also have to rely on cludges like naming the display ICC file to be
the same as the device ID and putting it in a well know location to be
able to have a color corrected GDM screen. Urgh.
So, we need a trivial device<->profile daemon that works like a subset
of ColorSync that the session GCM instances can use for defaults and
also set profiles system wide for projects like CUPS. Over the
Christmas holidays I wrote a small dameon called colord that provides
a way for applications (or other daemons) to create, destroy and
assign devices and profiles.

colord[1] doesn't do any file parsing or anything terribly unsafe,
it's just a simple system activated system DBus PolicyKit enabled
daemon that has a simple database of devices[2] that can reference
specific profiles[3]. Profiles are optionally assigned ICC profiles,
and also have qualifiers that can be used to match them. For instance,
a qualifier could be Epson.RGB.300dpi, which would match from the
qualifier search of "Epson*".

One thing to note: colord isn't anything related to systemd. The name
was chosen because colordaemon was too long to type and ColorManager
and ColorKit names were already taken. It's also intentionally techy,
as users are not going to have to interact with colord whatsoever.

At the moment there is a test GTK application for developers and color
geeks shipped in the colord package, but long term GCM is just going
to use colord and all the configuration and settings will be done in
the session by GCM itself.

Tim is working on the CUPS parts as I speak, and hopefully we can have
something working in a few days. Feedback more than welcome.

Thanks,

Richard

[1] http://gitorious.org/colord
[2] http://people.freedesktop.org/~hughsient/temp/colord-gui-devices.png
[3] http://people.freedesktop.org/~hughsient/temp/colord-gui-profiles.png