[Openicc] Introduction / Gutenprint]

[Robert L Krawitz]

   Date: Tue, 12 Apr 2005 09:44:55 +0200 (CEST)
   From: Kai-Uwe Behrmann <ku.b at gmx.de>

   Am 11.04.05, 10:12 -0400 schrieb Michael Sweet:

   > Robert forwarded me part of this discussion about how to select
   > profiles in the print path; I'll summarize what Apple has done
   > for MacOS X and what we will be supporting in CUPS 1.2.
   > 
   > Basically you add cupsICCProfile attributes to your PPD file to
   > specify the output profiles for various printing modes supported
   > by your device.  Normally the output profile selection is done
   > automatically using the current job options (media type, color
   > model, resolution, etc.), however it is also possible to include
   > the cupsICCProfile attribute in a print job to select a specific
   > profile, overriding the auto selection, e.g.:
   > 
   >     lp -o cupsICCProfile=CMYK.Glossy.2880dpi filename.jpg

   This selection attributes are on the level of very generic profile 
   selection. I cannot imagine even canned profiles would fit in well.
   For instance a unichrome ink printer would beheave other than a older 
   model with the same parameters.

Mike, would the selection attributes also include the printer?

   > We are *not* supporting generic filenames ("-o
   > cupsICCProfile=/path/to/filename.icc") in the attribute due to
   > security concerns, however it is conceivable that we could
   > allow any installed profile to be referenced instead, e.g. "-o
   > cupsICCProfile=filename.icc" which maps to the
   > /usr/share/cups/profiles directory...

   At least one user defined path should be included. Otherwise one
   can not install and use profiles without administrator rights.  For
   further evolving of new ICC profile path standards on linux, would
   you go with alternative path configurations?

There are a couple of problems here:

1) The RIP runs as a user (usually lpd) other than the user submitting
the job.  Aside from the fact that the RIP or even spooler may not
even have access to a user-defined path (or to the files on it)
because of the user's chosen (or imposed) protections, allowing the
spooler to arbitrary access to any file in the filesystem is asking
for serious trouble in a multiuser environment.  Mike's whole point is
that he *cannot*, for security reasons, allow access to *any*
user-defined path.  With this architecture, that's the right decision.

2) The RIP may run on a server with no access to the user's files,
period.  It might even run on a server with a different filesystem
mapping, such that the path on the client points to an entirely
different file from the path on the print server.  So not only
wouldn't this work, it could potentially be used to access the wrong
file.  Again, very bad juju.

(BTW, while the Gutenprint system allows filenames as option values,
the CUPS driver does not accept parameters of filename type.)

In this situation, even a user *with* local administrative rights
might not be able to install a profile anywhere that the RIP can find
it.  The only real way to deal with this would be to treat the profile
specially, rather than as just another PPD file parameter.  This would
require the lp/lpr commands to recognize it and pass the actual file
contents (not just the file name) to the CUPS server, which would have
to validate that the content of the ICC blob is valid (to prevent
malicious attacks against the RIP).  Local security is hard enough;
network security is much harder, and generally means you can't trust a
whole lot of things that users think can be trusted ("I own this file,
right?  Well, how can you prove it to me!").  Everything has to be
done at arms' length.  Of course all of this seems capriciously
limiting if you're on a personal workstation or laptop with a local
printer, but CUPS is intended to be usable in a much broader
environment.  Think "large company with hundreds of locations,
thousands of printers, tens of thousands of users" here.

One other solution which would work in most cases (but which has other
problems) is to do all the smarts on the client side, generating a
printer data stream entirely within the context of the user and then
submitting the raw printer-specific data stream to the spooler.  This
is the model that the GIMP/Cinepaint Print plugin uses.  It's
certainly very flexible for the end user, but it results in huge spool
files (and therefore network traffic) as I've already mentioned and it
makes auditing printer use that much harder if the printer doesn't
have direct support for that.

Other possible solutions would involve making drivers bidirectional in
some sense, and use some kind of protocol like IJS scaled up to the
network for the RIP to talk to the application.  But that would make
RIPs and applications more complicated, and wouldn't address the
problem of a print server being firewalled off from the rest of the
network, or simply on a network segment with no IP connection to the
client.

To me, this is one of the big, difficult problems with color
management in UNIX/Linux.

   How can an applications request a printer profile? This kind of
   bidirectional communication is much desired.  Imagine print
   previews, selectable non standard gamut mappings, estimation of
   colour sets.

That's the rub -- bidirectional communication.  I find it frustrating
to have to dumb down the Gutenprint CUPS driver to this level, but I
admit that it's a hard problem when you're trying to look at it from
an infrastructure architectural point of view.

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