[Openicc] CC Profiles In X Specification and dispwin

[Robert Krawitz]

I've taken the liberty of adding a few more folks to this...

   Date: Wed, 16 Jan 2008 03:16:49 +0100
   From: "edmund ronald" <edmundronald at gmail.com>

   I agree that you are open to input, but this obsession of mine
   -saving and loading settings- is very serious.

I'm not saying that it's not important -- why do you think I rant
about PPD files all the time -- but we have a lot of other problems to
solve first before this reaches the top of the list.  Furthermore, the
issue of saving and loading settings is considerably more complex than
it would appear at first glance.  Are you interested in saving or
loading settings within an application, within the context of the RIP,
across all applications on your system, or across applications across
multiple systems?  That's for starters.  Do you want a prototype
solution, or a fully polished one?

Gutenprint, at its core, is a library of printer drivers that does
nothing on its own.  It does provide ways to serialize curves, arrays,
and such, so at least we have primitives to express these structures
at the programmatic and file levels.  This particular issue needs to
be solved on top of Gutenprint, and as I explain below, it really
needs to be solved on top of what's on top of Gutenprint.
						  
						  If you can get
   Gutenprint into a state such that domain experts can set up canned
   printer configurations and send them to end-users, then the domain
   experts -who often cannot program- will do much of the rest of the
   work for you. If I may use an analogy, zillions of sysadmins run the
   Interne's HTTP servers by writing Apache etc config files, not by
   programming. Only the Apache team programs. But the sysadmins know
   where to change the config parameters because they've all been dumped
   in a couple of known files.

Fine.  Right now the ways of saving print settings are:

1) PPD files.  The less said, the better.  I think one of our dogs
threw up a few of them this morning.

2) Application-specific state files (printrc, for example).  The best
that can be said for this is that it can definitely be made to work,
with relatively little effort.

3) Environment-specific data stores (I'm not sure exactly how GNOME
and KDE save print settings, whether they use .lpoptions or something
else specific to the environment).  In any case, these are (currently)
limited to what can be expressed in PPD files, since the printing
system (typically CUPS) doesn't provide anything else.  See figure 1.

4) Printing-system based files.  CUPS uses .lpoptions, which is even
worse than "see figure 1" because it's not very apparent where the
saved settings are coming from unless you know about .lpoptions.

If you want to store something more than what the PPD files contain,
we're going to need to define an architecture for that storage.  This
architecture should not be specific to Gutenprint, and it shouldn't be
specific to particular applications unless you want only those
applications to be able to print.  I don't know exactly what OS X does
-- I think there's some way for drivers to basically bypass a lot of
CUPS -- but maybe we can leverage something from that.

The problem can be solved, but we need a better definition of the
problem to figure out what constitutes a reasonable solution.  I'd
much rather solve this in a general way if at all possible.

But if you're willing to solve it for one particular RIP (say,
PhotoPrint, or the Cinepaint/Gutenprint plugin, or the GIMP/Gutenprint
plugin), it shouldn't be too hard to solve, at least for a prototype.

   As for print quality, Gutenprint is now good enough that you really
   need to collaborate with the domain experts on the needed controls
   and adjustments that would really improve things. To put my money
   where my mouth is, I'll be delighted to run profiles for FREE for
   anyone in the open source community who needs a profile, during
   calendar 2008, this may create a crowd of people who provide
   feedback on the quality of existing media configurations.

I'm participating on this (and colorsync-users) precisely for this reason.

-- 
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 Gutenprint   --    http://gimp-print.sourceforge.net

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