[Openicc] Introduction / Gutenprint

[Robert L Krawitz]

   Date: Sun, 10 Apr 2005 21:57:47 +0200 (CEST)
   From: Kai-Uwe Behrmann <ku.b at gmx.de>

   Am 10.04.05, 11:38 -0400 schrieb Robert L Krawitz:

   >    Sounds like an good direction if CUPS will transport some information:
   >    - sending a custom linearistation profile to Gutenprint
   >    - request a gamut profile from the CMS layer (kind of an other issue)
   > 
   > So the problem here is how the spooler, driver, and CMS layer talk to
   > each other.  Right now the spooler basically firewalls the driver from
   > everything else, unless you're using something like the GIMP/Cinepaint
   > print plugin, which incorporates the driver directly.  All of the *x
   > spooling systems appear to basically be designed to accept jobs and
   > route them to the correct printer, maybe with a little bit of job
   > control information on the side from a static PPD file.  The JCL is
   > quite limited; it allows some number of keyword/value pairs, but not
   > anything really extensive like curves or tables.

   I dont come with an complete solution here just a listing of outstanding 
   issues for late colour binding:

   o users want to set parameters (in libgutenprintui or a PPD interface )
     - the ui should prevent users from changing colour relevant settings or
       pop up a dialog to break the "colour managed" status, eighter through
       bidirectional comunication or more dangerous by carefully handling 
       such cases in in the GUI

That's easy to do in the Gutenprint framework, and likewise in the
Print plugin, since options can be made conditional on other options.
Therefore, if the user turns on color management, other options could
be turned off.  We already do that kind of thing.  It's harder to do
in the CUPS driver since it requires statically analyzing dependencies
between all possible options and figuring out what's legal and what
isn't for the PPD files.

   o the CMS layer needs to know about parameters of the "logical
     printer", as a set of textual strings for selecting the correct
     profile. This allowes on the fly queries of colour managed
     settings : select a profile and see the appropriate driver
     settings in the gui.

Makes sense.

   o users want to easily use/install profiles (including belonging
     settings) without beeing asked for administrator rights (target
     profiles as part of the job/document is possible in pdf?)

Also makes sense, and this is something that you don't want to be
doing in a spooler (or a driver after a spooler).  If a job can embed
a target profile, and if the spooler (or RIP) is willing to pass this
on to the driver, it would be possible.

   One partitial solution could be to embed driver settings into the
   profile itself. Texts are allowed as tags. And as such settings are
   highly specialized, I have no trouble to use even if they can not
   been interpreted as by the intended driver. The CMS layer can
   easily extract such a tag and proceed to the driver for
   interpreatation. So the profile handling would become a one file
   thing.

Gutenprint doesn't really care where the settings come from.

   Anyway binary blobs outside of image data remain as an issue for the 
   transportation.

Right, and we need the spooler folks here for that general discussion.

One thing I'd really like to try -- and I recall you did a prototype,
but it wasn't stable on my machine for some reason -- is to put
together a Cinepaint or GIMP plugin that knows about color management.
I could easily put a boolean External Color Management option in
Gutenprint that would turn off all the color correction options and
otherwise set appropriate defaults, but that probably isn't necessary
for a prototype.

My own intuition suggests that if we split the job/option management
part out of the libgutenprintui layer we could put the color
management into libgutenprintui fairly easily.  There are a few things
that would have to change -- in particular, the data fetch callout
would have to be intercepted by this layer and delegated back to the
application -- but I suspect it wouldn't be too hard to do this.

-- 
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