[Omniprint-user] Re: [Inkjet-list] Re: Taking a step back

[Robert L K. <rl...@al...>]

   From: Michael Sweet <mi...@ea...>
   Date: Fri, 28 Dec 2001 09:59:29 -0500

   On Thursday 27 December 2001 07:12 pm, Robert L Krawitz wrote:
   > ...
   > I'm generally in favor of a dynamic view of what the driver can do,
   > because the constraints might be very complex, but this is an
   > interesting thought.  However, why do we need an actual file in the
   > filesystem (as opposed to some virtualized way of getting a handle to
   > a PPD file)?  Do applications rely on open()/fopen() of PPD files, or
   > is there some more abstract way of getting this information?

   Well, the printing system layer could generate the file for the
   client, however I'm pretty sure all existing clients need to
   ultimately read the PPD file from an actual file, although the
   KDEprint stuff might be just loading from the HTTP data, I dunno...

It's a pity that UNIX domain sockets don't quite have plain-file
semantics about open/read and the like; that would be a great way to
emulate static files with dynamic semantics.

   That said, there are enough existing apps that read PPDs directly
   from files (e.g. StarOffice) that we'll need to support a static
   snapshot file of some sort.  *How* that file is generated is a
   design decision, however I know of two developers that are using a
   background device daemon that monitors the print devices and update
   the local PPD files for the current configuration.  I suspect that
   this will remain the most flexible (i.e. least printing-system
   centric) design...

That would probably work, although applications would need to reread
the PPD whenever they wanted to start a new print job.  For that
matter, so would CUPS.

   > Extensions like this don't scale very well either; everybody will
   > define their own extensions (look at what Cups-o-matic does; it uses
   > structured comments in the PPD file to encode a perl data
   > structure!).

   Well, for CUPS-based drivers at least it will work, and other apps
   will "see" the standard PPD file that will still work everywhere.

I'm nervous about what this leads to.  If CUPS has one set of
extensions, another IPP-based system has another, and so forth, we get
into trouble fast.

   > I don't think we should think in terms of a single-threaded
   > server-based driver, but having some way of querying the driver (even
   > if it's a different process) would be useful.  I'm not convinced that
   > we need to address this in the first go-round, but ultimately we
   > will.

   The problem is that in most cases you can't query the printer while
   printing, and there are some major security issues with an app
   talking directly to a device.  Better to define a common set of
   attributes (there are a lot of them defined by IPP already) that
   the driver can report to the printing system, which can be provided
   to a client on request.  If you are monitoring the device when not
   printing, the scheduler status data can be updated on-the-fly...

I certainly don't want applications talking directly to the printer.
In my view, the driver handles all of this.  Of course, "driver" means
more than just the blitter (to use the OMNI terminology); it may well
mean a few cooperating programs (the blitter, the option enumerator,
and so forth).  How those (hypothetical) programs (driver components)
interact with each other is beyond the scope of what we're trying to
do here.

================================================================

Of course, there's the whole issue of what we're really trying to
accomplish; I think we're going around in circles.  I'd rather
understand specifically what IPP in general and CUPS specifically
don't do that we need, and understand whether the problems are
reasonably fixable, before going off to design yet another piece of
middleware.  While I like a dynamic view of the driver myself, it's
unclear to me that this is the most important problem to solve.  We
can emulate dynamic semantics with PPD files, as you note; if
applications will only read a PPD file once, it doesn't help.  I don't
think the weakest part of the UNIX printing system is at the blitter
stage; we as a group (both the people on these lists and the free
source community in general) are good at this kind of thing.

The problem that all this points to, as I see it, is that the
interface between applications and the printing system is weak.  The
traditional interface is a one-way pipe from application to printing
command (lpr or lp).  Postscript is a nice bolt-on that fits very well
within this, as long as you don't try to do anything fancy (like
understand what the printer can actually do beyond what /etc/printcrap
is able to express).  The problem is that modern printers (or drivers;
it's completely irrelevant whether the printer can actually do
something or the driver emulates it) are much more capable than the
guys at Berkeley designed for back in the late 1970's, and
applications are a lot more sophisticated.  KDE and GNOME are at least
asking some of the right questions, even if some of the answers might
be a bit strange.

The issue I noted about applications possibly not rereading PPD files
really has little to do with the use of PPD files vs. any other
mechanism.  Using PPD files as an IL is probably fine.  The problem is
that each application takes its own view of the world, and takes a
completely noninteractive view of printing (Netscape actually bothers
to give you a popup with the output of the lpr command, which is
better than a lot of things).  It is my belief that we cannot fix
things as long as this is the prevailing approach; we need to
standardize something more powerful at this layer before it even makes
sense to talk about the driver interface.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for Gimp Print/stp --  http://gimp-print.sourceforge.net

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