AW: [Desktop_printing] Role of CUPS and error handling

Robert L Krawitz rlk at alum.mit.edu
Sat Apr 1 19:45:25 PST 2006


   From: Kurt Pfeifle <k1pfeifle at gmx.net>
   Date: Sat, 1 Apr 2006 23:40:33 +0000

   On Saturday 01 April 2006 21:20, Robert L Krawitz wrote:
   >    From: Kurt Pfeifle <k1pfeifle at gmx.net>
   >    Date: Sat, 1 Apr 2006 18:59:24 +0000
   >    Cc: Robert L Krawitz <rlk at alum.mit.edu>
   > 
   > But that only gets you to the file installation, which is the easy
   > part whether you install from source or from binary. 

   I repeat again: I was talking about printer vendors/manufacturers,
   and what kind of work it means for them to develop a "Linux printer
   driver" from scratch. It means the 2 files I enumerated.

I read that discussion a bit differently -- how printer vendors could
provide a driver CD.  We're in agreement that actually providing the
driver means potentially nothing more than those two files.

   > Gutenprint could very easily provide a top level installation
   > file that runs configure; make; make install and hide all of that
   > from the end user.

   Uhmmm... you are missing the "oh, check if there are is a build
   environment present at all" before you run "configure".

Yup.  OK.  That was a bit silly on my part.

   > Ulrich was talking about something quite different: setting up a
   > printer in Windows is "Insert the printer manufacturer driver CD
   > and follow the directions".

   And then somebody asked "But why are there no driver CDs for
   Linux"? (which implies for many that it may be too complicated
   and/or too much work to do).

Right, and we seem to have gone off into the weeds a bit.

   > Last I was aware, not all Linux distributions had settled on udev for
   > device hotplugging, and BSD uses something different, Solaris uses
   > something different yet again, and so forth.  CUPS would have to be
   > awfully smart to deal with all of this.  Maybe it is.
   > 
   > Let's try that Aunt Tillie test again: 

   That will mostly fail for Windows too  :-)

Given my experience trying to get a printer working every time we go
to my in-laws, you're probably right.

   > give her a random printer model 
   > with a CD with a driver and ask her to set it up. You said that only 
   > two files (rastertofoobar and a PPD file) are needed.  Put just those
   > two files on the CD.

   First, give me a third file: allow me to add in a README (preferably
   one that gets displayed via autorun).

Granted.

   > I realize I'm being a bit argumentative here, but I'm trying to
   > make the point that it's not quite as simple as "create a PPD
   > file and a driver, and it will magically all Just Work Anywhere".
   > It won't, at least not yet.

   I'm still not convinced. 

   It will be very easy to write a wizard for reliable discovering any
   locally connected printer and the exact model. Remember, this is
   the *vendor* creating a driver for his own model; a vendor has all
   freedom to stick any amount of uniq digital identifiers onto his
   models that would serve to get such IDs back from the device. Heck,
   they could even use the very same protocols they use on Windows for
   that; they know how it works, they don't need to reverse engineer
   it. And remember, I'm talking about Linux only here; not *BSD, OS X
   or Solaris (adding these would be very simple though, once it works
   for Linux; I bet it is no more than one friendly email exchange
   away with the respective developers list that would be started by
   $engineer from $vendor with these words: "Hi, I'm $name from
   $vendor. We are planning to provide a $your_os printer driver for
   our new $acme superprinter model, due to hit the market this
   autumn. The device may be attached via parallel, USB, Bluetooth and
   IrDA connections. Can you tell us how to reliably discover the
   interfaces for each of these?" or something like that...

This is something we need to explore -- we're not going to figure this
out this way.

   > The problem here is that "most" means "everything but the more
   > interesting things".
   > 
   > * Ability to "turn off" certain options.  Some of our floating point
   >   options allow a value within a certain range, or the option can be
   >   turned off.  For example, we support GCR upper and lower bound
   >   points and gamma value.  The GCR lower bound can range between 0 and
   >   1 (if the total gray value is less than the lower bound, the gray is
   >   printed entirely with color ink).  It can also be turned off,
   >   allowing the driver to select an appropriate value.
   > 
   >   This could be done with two options: EnableGCRLower and GCRLower.
   >   It could also be done by allowing a range of -1 to +1 and if the
   >   value is less than 0 it's treated as "automatic".  Either of these
   >   would be very messy.  The Print plugin for the GIMP has a checkbox
   >   next to the option to turn it on or off.  PPD files don't let us do
   >   that.  At least from a cursory glance, the CUPS 1.2 extensions don't
   >   have this.
   > 
   > * Curves (arbitrary piecewise linear or dense or what have you).  If
   >   you want to do your own linearization -- and I've had recent
   >   requests about this -- you need control at that level.  Gamma curves
   >   aren't enough.  Again, the CUPS 1.2 extensions don't have this.
   > 
   > * Ability to hide certain options depending upon the values of other
   >   options.  For example, if the output mode is set to black and white,
   >   hide all of the color options.  We're doing a somewhat crude hack by
   >   offering two sets of PPD files (simplified and full-featured), but
   >   I'm sure the usability folks will be all over us for that.
   > 
   > * Ability to change imageable area based on other option values
   >   (e. g. if you select full bleed the imageable area should change).
   >   That can be done by duplicating the paper sizes, but given that we
   >   already blew up some older versions of CUPS with more than 100 paper
   >   sizes I doubt that this would be very popular.

   What you want here goes *way* beyond a general purpose printing and
   spooling and ripping system for desktop OS usage.

   Of course, this doesn't make your wish invalid. It is a perfectly
   good request for a specialist user group like professional
   photographers (or even all ambitious amateur ones).

   But this same set of features is also impossible to be covered by
   the standard set of drivers, APIs and interfaces on Windows. It is
   the realm of speciality software. Drivers which would support the
   "arbitrary piecewise gamma correction curves" can't be had within
   the general framework of Windows printing. (Granted, I do not even
   know an example from outside that framework).

   So, for Linux this kind of software would probably have to provide
   its own, separate GUI that talks to the "driver" or "filter" (which
   would run standalone, not as part of the CUPS filtering chain). To
   print, the software would just generate the data and hand them down
   to CUPS as "raw".

   I see no other way.

   And you have that already: you have it in the Gimp print plugin
   that way, no?

We do it that way because there's not much choice right now.

I'm really not a fan of spooling raw data.  It's just too darned
*big*.  A 6.75x10" image that I test printed on an Epson R2400 at
2880x2880 DPI was over 400 MB!  Try that on, say, a Stylus Pro 4800
with a 17x25" print and we're talking something like 3 GB.  That's a
huge amount of data to spool, particularly if it's over a network.

   > In any event, the CUPS 1.2 extensions don't help applications that
   > don't know about them.

   True. The same way as Gimp 2.0 will not know about the Gutenprint 5.0
   "extensions".  :-P

Except that I really don't think that that has to be the case,
particularly if Qt and GTK provided printing services that
applications can use.  The Gutenprint 5.0 GIMP plugin is actually
split into two components, libgutenprintui2 and the actual plugin.
All of the GIMP-specific code is in the plugin, which is about 650
SLOC; the UI library (which isn't all that general purpose, but it
isn't GIMP-specific either) is about 9000 lines.  I'd think that print
panels like this would make life a lot easier for applications, also.

One thing I've noticed on Windows is that when you go to print from
any application you get a driver-specific print panel.  I'm not
familiar with the Windows printing system internals, but that would
suggest that the driver provides at least some of the UI itself.

   > Right now, all we can really do is live with it.  We handle the
   > enable/disable and floating point stuff by using traditional PPD
   > options (floating point values enumerated) with a distinguished value;
   > for floating point options we offer an additional fine adjustment.
   > Curves are something users of the CUPS driver simply don't have access
   > to; since we have no way to selectively hide options, the users just
   > have to live with the rat's nest we provide.  As for the imageable
   > area, we cheat (change the imageable area internally), and users
   > complain that if they turn on full bleed the dimensions aren't what
   > they expect.
   > 
   > What it really comes down to is that PPD files just plain aren't
   > expressive enough for some purposes.  I'm NOT satisfied with a
   > solution that works only for 95% of users; the problem is that the
   > other 5% are trying to push the boundaries and can't.

   Fair enough.

   But these 5% users need their own special applications. Their needs
   simply can't be satisfied with the standard tools. But these 5% are
   extremely important too: without them, no technical progress.

   The interesting part will be how and how much of the new conquests
   made by the pioneers can be translated to simple usage and trickle
   down to the Joe Doe users.

I guess by now it's pretty clear where I stand -- I want to see this
stuff driven down as fast and far as it can be.

We aren't going to make inroads into the desktop by simply matching
Windows in this area (printing in general).  We need to provide a more
compelling proposition.  While I will grant that very few users want
to manipulate linearization curves, it's not going to be very
compelling to tell people that they have to give up their current
special application for a new special application.  It has to outright
blow Windows out of the water in this regard for it to be compelling.

   > There are third party RIP's for Windows that get around all of this
   > stuff by means of providing the user interface, RIP, and output
   > generation all in one package. 

   Yes, and the reason is 

   > They're expensive, highly proprietary, 

   That does not *need* to be so on Linux/FOSS. As long as people like
   you keep pushing the boundaries, and share their code in return for...
   ...nothing more than fame, luke-warm "Thank you"s, a warm "community
   feeling"... and even more support+feature requests and criticism 
   coming in.    

It does get mighty lonely out here at the end of the limb.

   > and...well...for Windows only.  We (or at least I) don't want to tell
   > professional photographers and graphic artists that they can't do what
   > they need to in Linux.

   I don't think it is within the scope of CUPS to provide all these
   functionalities.

Maybe not directly, but I'd like to see more support for capabilities
like this.  1.2 is an improvement, but I don't know that it's enough
to get us there.

   >    And CUPS, with the filters it ships itself, and with all the Free
   >    raster-to-whatever filters provided by third parties (such as
   >    Gutenprint) *IS* in fact such a host based RIP, combined with an
   >    IPP-based spooler, combined with a backward-compatible LPD- client
   >    supporting spooler, combined with some more utilities.
   > 
   > Yes it is, but it's missing a lot of the critical capabilities found
   > in those high end RIP's: the ability to specify printing parameters
   > precisely, and flexible user interfaces.

   OK, CUPS is not (yet?) a "high end RIP" for professional photographers.

I see room for compromise there :-)

   > If I had the time -- which I don't, remember that this is a sideline
   > for me -- I'd take Alastair Robinson's PhotoPrint program and add the
   > ability to process Postscript and PDF with it (by means of calling out
   > to Ghostscript to rasterize them).  That would give a full general
   > purpose RIP using Gutenprint.  Of course, it would be separate from
   > the spooler, but I'm not convinced that integrating the RIP and
   > spooler is necessarily the best way to do things.  

   It is for "most" needs.

   It isn't for *your* needs.

   (But thanks to your hard work, today many Linux users have a much
   better photo and color printing for their devices, even if they do
   not use any of the "piecewise linear curves" you want for yourself.
   And similarly, they may benefit from your future work where you are
   pushing the current boundaries.)

Part of why I want these capabilities to be exposed is to take
advantage of the FOSS community -- if people can come up with settings
that work for particular combinations of printer, resolution, ink, and
paper, maybe we could have a database of settings that can be freely
shared.  But those capabilities need to be accessible for that to
happen.

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



More information about the Printing-summit mailing list