Re: [Gnome-print] GPr/libppd

[Thomas Hubbell <thubbell compumetric com>]

Thanks for the response, Miguel.

You asked for an "executive summary" so I will attempt to do this now. I
will also address some of points you raised one-by-one below the
summary. (If I'm covering some things that people already know, please
bear with me)

libppd:
libppd is a library of functions used to deal with Postscript Printer
Description, or PPD files. The PPD file specification was developed by
Adobe to allow the device-dependent features of a postscript printer to
be merged with a device-independent postscript description of a page (or
several pages). A PPD file is a plain text file containing, among other
things, information about printer options that can be displayed in a
user interface, as well as the PostScript code required to enable these
options on the printer.

libppd allows a programmer to interface with the various structures in
the ppd file. Using libppd, all of the user interface options contained
in the ppd file can be accessed to create a GUI. The other important
aspect of libppd is its pstops filter, which takes the device-dependent
postscript code from the ppd and inserts it in the proper spot in a
device-independent PS file. The resulting device-dependent file can then
be sent to the printer, enabling all of the special functions of the
printer to be accessed.

GPr:
GPr essentially provides a GUI to interact with libppd. It allows the
user to choose a destination printer and a corresponding ppd file. Based
upon this ppd file, a user-interface is constructed, allowing users to
choose all of the particular device-dependent features of their printer.
GPr then calls the libppd filter with the chosen options and sends the
filtered job to the printer.

GPr also contains a "saved settings" feature that allows users to save
groups of frequently-used settings with an easy-to-remember name.

Currently GPr operates as a standalone app, with some workarounds to
allow printing from X apps. Users can either call it from the
command-line (e.g. "gpr -Pmyprinter myfile.ps") or they can install a
script and configure some of their apps to allow them to print through
gpr. In either case, gpr will intercept the print job and pop-up a UI to
allow users to choose their options. (This is not necessarily the best
solution, but it works for now.)

So how would this integrate with gnome-print?

Well, first of all, it can only work with PostScript printers at this
point in time. There are some possible alternatives that could use a
similar approach to handle PCL or inkjet/raster devices, but more about
that later. . .

gnome-print can produce a postscript file. libppd/gpr could interact
with gnome-print in a couple of ways. Either the device-dependent ps
code from the ppd could be added during the creation on the ps file by
gnome-print, or it could be added after by a pstops filter. In either
case, it would be necessary to introduce some of the gpr functionality
into the gnome-print dialog to allow these device-depenedent features to
be easily controlled by the user.

> well, one of our drivers is Postscript, but one of the "big wins" of
> GnomePrint is that we can rasterize directly to a printer, and we can
> have native printer drivers.  I wonder how libpppd interacts with
> this.

> Sounds nice.  But we need this to work in a non-Postscript world as
> well.
> 
> Could you research this please?
> 

I think I covered the PostScript case above. 

The PPD file is a great mechanism because it describes all of the items
needed to construct a user interface as well as the ps code needed to
activate these items on the printer. The only drawback is that it only
works with postscript printers.

The ppd approach seems to be sound, however. You can create a file which
contains everything you need to build a UI as well as all the code you
need for your device. Instead of building a new driver for every
printer, you create a "universal" driver that can parse this description
file to create a UI and get device-specific formatting code.

There are some possible alternatives for non-PS printer. The Printer
Working Group is developing something called the UPDF (Universal Printer
Description File) which is an XML-based file that is supposed to
accomplish the same goal as a PPD file without being limited to PS
printers only. This would be a good approach for the non-PS printers,
but the spec seems to be far from complete and the group does not seems
to work at a very quick pace. The other alternative for gnome-print is
to develop PPD-like files for the raster drivers (or any other standard
drivers that plug-in to gnome-print). Or, we could start from the
existing UPDF spec and just extend it and customize it to work with the
various components of gnome-print.

In any case, it seems to me that this approach would be beneficial to
many. I think some printer manufacturers would like this because they
would have to do very little to support their printer - simply supply a
PPD and/or UPDF file. All current PS printers have PPDs anyway, so this
would instantly provide support for all existing PS printer.

Additionally, if the gnome-print dialog were based on libglade (it may
be already, forgive me for not remembering) then it would be quite
simple for a manufacturer to create a custom user-interface in glade and
plug it into the driver. When a user user chooses a particular printer,
the default UI or the custom UI is seen, depending on the printer. A
manufacturer could then have full printer support with a customized UI
and all he would need to provide is two files - PPD (or a  UPDF-like
file) and a .glade file for the user interface. It sounds like a good
deal to me!

> > At this point, it would require some work to more properly GNOME-ify
> > GPr. But, I think that it would be well worth it. Does anyone else think
> > this would be valuable?
> 
> Yes.  I do.  Want to contribute in this area?

Yes. I would certainly be interested in contributing. Where do I sign
up?

-- 

Thomas Hubbell
CompuMetric Labs, Inc.
thubbell@compumetric.com