[Openicc] Introduction / Gutenprint
Robert L Krawitz
rlk at alum.mit.edu
Sun Apr 10 07:09:27 EST 2005
From: Hal V Engel <hvengel at astound.net>
Date: Sat, 9 Apr 2005 13:47:01 -0700
When you are in the printer dialog in GIMP you have the ability to
add a new logical printer and use that to "name a collection of
settings you wish to remember for future use." This is the ideal
place for printer profiles to be specified. So the user should be
able to set the default profile and rendering intents for each
logical printer along with all of the other settings for the
driver. This would be a way better setup than how this is handled
in photoshop and would be a great way to simplify and facilitate
the management this part of a CM work flow."
The point is that when you are dealing with devices like printers,
scanners and cameras significant parts of the color management
system need to be close to the device. To my list of CM related
items that belong in the print driver I would now also include the
lineariztion-file that Jan-Peter described so well. This is
something that can not even be done in Windows with the standard
printer drivers but I know in my gut that this would allow even
better results.
I think that the "logical printer" stuff is part of the gimp-print
GIMP plug-in. Is this correct? If that is the case then to
properly support CM system wide the "logical printer" functionality
should be migrated from the GIMP plug-in to Gutenprint to make this
available in other applications.
In Gutenprint 5, the "logical printer" mechanism is in a (fairly
ill-defined) layer between the Print plugin and the Gutenprint core.
It's currently called gutenprintui2 (for GTK2) and gutenprintui (for
GTK). Actually, this layer is really two things in one: one piece
manages the printrc file (which contains the logical printers) and
creating and managing the actual print command (calling lpr and
monitoring its health). The other piece is the user interface.
We could conceivably separate these two layers into a "printer
manager" layer and a UI layer. The printer manager layer could be
used by Qt, fltk, etc. apps just fine, if we cleaned out a handful of
glib things in there; the UI layer is completely GTK-specific.
I don't believe this problem is particularly hard to solve. There are
certainly ways of injecting color management into the GIMP plugin,
where the driver is called directly from the application. The harder
problem is when your application simply generates Postscript and hands
it off to CUPS (or LPRng, or whatever). PPD files don't really make
it very easy to pass arbitrary blobs like profiles. My concern is
what to do here, and what the Gutenprint level interface would be.
My own take is that the traditional UNIX printing system, where
applications generate Postscript data and interface with drivers
through PPD files, is very limiting. I'd much rather have a model
like the GIMP plugin, where the printing interface is still fairly
simple (the actual core of the GIMP plugin is now something like 500
lines of code, and the large majority of that is to handle
GIMP-specific things) but the driver has an opportunity to interact
with the user.
There's no obvious reason why the logical printer stuff should be part
of the Gutenprint core. A logical printer is simply a bundle of
settings defined by the user; it turns into a collection of
stp_set_*_parameter() calls, which are the low level calls to set
parameters. However, perhaps I'm looking at this incorrectly.
You might be interested to know that Gutenprint allows you to set the
individual linearization curves, with floating point precision (this
is truncated down to 16 bits internally). If you care to, you can set
the linearized value for every possible input value (0-65535) per
channel.
--
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
More information about the openicc
mailing list