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

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

   From: Michael Sweet <mi...@ea...>
   Date: Wed, 26 Dec 2001 19:05:00 -0500

   Ultimately, you *really* want a static snapshot of what a driver
   can do.  This ideally should be a data file that can be read by a
   driver/ filter (using a standard API of course) to handle any
   printer/job specific setup.  For devices whose options depend on,
   say, what kind of ink cartridge is installed, a background driver
   process can monitor the printer and update the static snapshot as
   needed (and obviously any driver would need to reject/stop a job
   that won't print on the current configuration)

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?

   > The capabilities subgroup needs to query the printer driver at
   > runtime and not though a static file (like a PPD).  Also, I
   > believe that applications will want to be able to select between
   > different print paths based on the printer's capabilities.

   This isn't Windows or OS/2.  Applications will almost universally
   produce PostScript until another format is universally supported.
   Also, many PostScript apps already support PPD files, so it makes
   sense to try to support it (even if you add your own extended
   attributes which the standard apps ignore)

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!).

   Also, trying to get printer drivers and applications to talk to
   each other directly is a mistake.  It doesn't scale.  Better to
   have the driver maintain a snapshot of the current configuration
   than to introduce potentially long round-trip times which may
   require UI intervention ("your printer is not connected or turned
   off") or have to be postponed because the device is busy.

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.

   > While inkjets may not need acceleration, there are other printers
   > that do. It is much more efficient to transfer a high level call
   > like drawing a rounded box than it is to transfer a bitmap image
   > of that box.  Some examples of high level languages are: HP-GL/2,
   > PCL6, and even Postscript. Should there be two different code
   > paths for printing to an inkjet printer vs printing to a
   > Postscript printer?

   PostScript, with all its weaknesses, is still the defacto standard
   printing format for UNIX apps.  Any printing solution will have to
   support it to be accepted, which is why CUPS includes a version of
   GNU Ghostscript for non-PS printers, and why we use PPDs.

I agree wholeheartedly with this.  Applications normally shouldn't
generate raw printer data; Postscript is no worse of an IL than
anything else.

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