[Openicc] Print-colormanagement, application->CUPS->gutenprint

[Robert L Krawitz]

   From: Hal V Engel <hvengel at astound.net>
   Date: Tue, 19 Apr 2005 07:49:38 -0700

   On Monday 18 April 2005 06:12 pm, Michael Sweet wrote:
   > Hal V Engel wrote:
   > > ...
   > > This is exactly the point that I was trying to get across.  This is not
   > > about users that don't have exacting color output requirements.  I am
   > > sure that most of those users are perfectly happy with how this works
   > > now.
   >
   > The currently available open source drivers are capable of excellent
   > quality, but configuring the drivers for optimal quality is something
   > that many users just aren't up to.  On the ease-of-use scale, the HP
   > IJS drivers are among the easiest and the most limited from a color
   > management standpoint, and Gimp-print/Gutenprint is by far the most
   > difficult to use and very advanced from a color management standpoint.

   Again from my point of view Gimp-print/Gutenprint does not have
   color management.  Sorry but that is the way I see it.
   Gimp-print/Gutenprint does have good color output with standard ink
   sets but is totally off base and requires extensive tweaks and
   manually applied custom profiles to get close with 3rd party inks
   such as archival inks from MediaStreet.

To be perfectly clear, as Gutenprint project lead, I completely agree
with you.  Indeed, the primary reason I joined this list was to work
out how to implement color management within Gutenprint.  It was a
goal of ours to implement color management in 5.0, but we didn't make
it, and so 5.0 will go out without color management.  However, color
management will be the driving functionality behind 5.2.

Between this list and the Colorsync list, the one thing that has
become abundantly clear is that a lot of people do color management
very badly.  I'm *not* an expert in that area, and have no desire to
repeat other people's mistakes in Gutenprint, so I want to work with
others here to do the right thing, and also to help drive the right
architecture for color management in the free source printing chain.

I've seen enough prototypes that people have done to believe that the
Gutenprint core platform has (or can easily have) the necessary
capabilities to implement color management well.  Some of these
solutions use very arcane technology, but people have achieved
excellent results.  The challenge is getting from those prototypes to
a production-quality solution.  It certainly wouldn't be too hard to
put LCMS lookup in the GIMP/Cinepaint front end (indeed, the Cinepaint
folks have done so), but that solution doesn't scale.  Unfortunately,
the back end is somewhat inaccessible when driven by today's spoolers,
and that's a problem that needs to be solved.

   I don't want the above to be taken in the wrong way as there are
   many that don't understand what color management means.  One major
   example is Microsoft which claims that Windows supports color
   management.  They even have places where the user can install ICC
   profiles for the display and printers.  But if you try to work with
   this stuff you find out that it simply does not work the way it
   should.  In most cases users figure this out only after working
   very hard trying to make it work.  Many give up out of frustration
   having never gotten it to work thinking that this color management
   stuff is BS.  Eventually some users figure out that what Microsoft
   is calling CM is really a bunch of junk that was thrown together in
   a hurry by someone in Redmond who had no idea what he was doing and
   that to do CM on Windows you must do everything manually.  For
   Windows users there are a few applications that are CM aware and
   that allow the user to do what is needed to implement a manual work
   flow (Photoshop, Vuescan, Silverfast AI).  There are now rumors
   that they are doing a major rewrite of the CM systems for Longhorn.
   Could this be because they messed up bad the first time?

Again, I don't want to repeat those kinds of mistakes with
Gutenprint.  My goal with Gutenprint is for it to be the best driver
for inkjet printers, bar none.  That's a tall order, and getting the
color management right is critical.

   So how might this be done?  This is just one possibility that
   perhaps could be kicked around some.  Visualize the gimp-print
   plug-in The GIMP uses.  In that plug-in you can create a "logical
   printer" that ".. can be used to name a collection of settings you
   wish to remember for future use."  Now add a few new fields such as
   ICC printer profile, rendering intent, black point compensation and
   the ability to make the driver always handle the data the same way
   and the hooks to pass the CM information through to CUPS and you
   are most of the way there.  In fact this is all that is needed for
   single user workstations assuming that we are only concerned with
   printed output from apps that use the gimp-print plug-in.

Now we're talking.  The Gutenprint core has the capability to accept
files as parameters, and there are other data types as well.  It can
handle arbitrary parameters with dependencies, and these dependencies
can be dynamic if need be.

BTW, there's a UI layer on top of Gutenprint called gutenprintui2 (for
GTK2).  It's somewhat generalized.  Currently the interface is rather
ugly, but if people think it's the right thing (and a good UI person
volunteers), we can beef it up.

The other thing we need to do is fix up the Postscript family driver
(back end).  It's currently buggy and cannot use all of the parameters
in a PPD file.

   For multi user systems you would add the following.  Give
   administrators the ability to lock down the settings for a "logical
   printer" and make this available to other users on the system.
   Then add the ability to make the print dialog that uses these
   "logical printers" the default system print GUI.  Assuming that
   this correctly interfaces to CUPS to handle CM you have a solution
   to the printing work flow problem that provides for both expert and
   normal users.

Till Kamppeter of Mandriva asked me to implement a system-wide
printrc.  I wasn't too keen on it, but it's certainly something we
could consider for 5.2 (we could probably even do it in a 5.0 point
release because it wouldn't require an interface change).

   Adding the additional fields to the plug-in would be easy and I
   suspect that setting it up to pass the addition arguments to CUPS
   would not be very difficult.  In fact I would be willing to bet
   dollars to donuts that Robert or one of his people could have this
   done in short order if they decided to.  But putting together the
   multi user administrative stuff could be a real challenge since
   there are likely all kinds of issues that would need to be
   resolved.

My biggest constraint right now is time.  My biggest goal right now is
getting Gutenprint 5.0 out.  We're about to do beta 4, and then there
will be some bug fixes, testing, documentation, and translation before
we can release it.  Then we can start really working on 5.1 (which
will become 5.2).

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton