[Openicc] Google Summer of Code 2011: The Common Printing Dialog and Color Management

[Richard Hughes]

On 15 May 2011 18:43, Hal V. Engel <hvengel at gmail.com> wrote:
> I would like to start with a short description of the current state.

Great email, thanks. A few comments:

> A. None of the standard tool kits (QT, GTK+...) produce PDF spool files that
> are well formed. In general these PDF spool files are garbage from a CM
> point of view. There are no exceptions to this and it will likely take a
> long time (several years is probably optimistic) before these issues are
> corrected.

I'm going to be looking at the GTK side of this in the next couple of months.

> F. Only a few open source apps support soft proofing and it must be hand
> configured by the user (IE. no integration with the printing back end). In
> addition, if the user is using a remote print server there is no way to get
> the profiles used by CUPS without doing some tricks in the servers
> installation/configuration to make this possible.

Yup, I tried to get the remote stuff to work, and after talking to
people at LGM I'm more confident I can make colord and a remote CUPS
instance play nicely. I have a few weeks of work to do with GNOME 3.2
planning, and then I'm back to color stuff.

> A. We have two different approaches and both use different application
> interfaces. I think it would be helpful to get both using the same
> interfaces so that these could be interchanged depending on user or distro
> preferences.

I'm not so sure having colord and oyranos as replaceable modules makes
sense. At the moment we've got 0 frameworks that cover just the simple
use cases and having an abstraction just makes the problem n squared
harder. I think I've pushed the advantages of DBus to the right people
here at LGM, and from my point of view a DBus interface to oyranos
would make my life a lot easier. I'm not adverse to changing interface
names, method names and that kind of thing, but interoperability does
come with an explicit cost that we should be aware of.

> B. Colord appears to be somewhat farther along as we now have a working
> version of it that is integrated with CUPS and a front end configuration
> app. Although it does not appear to have the level of integration (user
> apps, print UI.. are not integrated) that is needed for a full print work
> flow.

Right. I really wanted to add some options to the GTK UI, but the
GNOME design team vetod even having adding one color managed checkbox
to the default dialog. Hopefully for 3.2 we will just show a label
with the color profile title of the profile that is going to be used,
for power users to verify.

> C. Colord appears to take a more simplistic approach in it's printer support
> than Oyranos. This is not a critical comment rather it is a comment that it
> may at some point prove to be too simplistic but this remains to be seen.
> And it might also be argued that Oyranos is too complex. Again we do not
> know at this point.

Sure, I'd agree with that. One thing that's probably worth knowing is
that colord supports more than just the tri-dotted selector notation
of ColorSync, and in the future we could append to the qualifier with
custom XML without breaking API or something like that. Again, the
specification is work in progress and I don't mind changing API at
this stage if colord is deemed too limiting. One method that's
waiting-in-the-wings if required is a GetProfileForSelector variant
that can query based on CUPS job hints. I've not yet found a use-case
that justifies creating it, but it's in the back of my mind in case
it's required.

> Use a specialized app. A slight variation on this would be to approach one
> of the existing OSS apps and ask them to provide options for printing
> targets although I don't think this has been mentioned by anyone here yet.
> Allow any app to print targets and have specialized target printing
> functionality in the print UI.

This is my preferred solution, to have gnome-color-manager and the KDE
control panel adding custom widgets to the GTK print dialog.

> I think the main issue with this approach is finding such a
> person and I think this makes this approach less viable or even perhaps
> impossible.

I'm planning to maintain gnome-color-manager, and Alex is planning to
maintain the KDE panel.

> A. We should be able to leverage the work done on the colord integration if
> the GSoC project is based on Oyranos.

If oyranos implemented the same service name and interface
specification then all the client code does not have to be modified.
I'm not sure Kai-Uwe wants to put oyranos code in CUPS, as the oyranos
architecture is somewhat different to colord, but I'll let him do the
talking there.

> There is a Oyranos GSoC
> project this summer and perhaps this could add a colord style DBUS
> interface?

Makes sense to me.

> C. If the approach is to embed the printer settings into the profile (I
> support this approach) then we need to be able to capture the settings
> bundle at the time the target is printed and we need a tool to embed it into
> the profile once it is generated (IE. usually the next day to allow for ink
> stabilization).

Yup, and define a key-value standard for DICT support so that CMS's
can read the data. I for one am waiting for the next lcms2 release
before I "turn on" the metadata saving functionality already in colord
and gnome-color-manager.

Richard.