[cups.general] PPD generation on the fly

Till Kamppeter till.kamppeter at gmx.net
Tue May 30 08:01:42 PDT 2006


Johannes Meixner wrote:
> Hello,
> 
> from a printer manufacturer I got the following information
> (at the moment anonymized)
> ------------------------------------------------------------------
> "ACME PrintSystem" is developed with the purpose of providing
> a general purpose, model independent driver.
> To this end, the driver queries the printer directly for its
> capabilities and creates an optimized PPD file based on the
> printer's reply.  
> This way it is no longer necessary to download and install
> drivers when the user changes or adds new printers.
> ------------------------------------------------------------------
> 
> For me this is a new concept which seems to be not in compliance
> how printer setup works in CUPS because as far as I know this
> requires ready-made PPD files in /usr/share/cups/model/
> (more exactly in "echo $(cups-config --datadir)/model/").
> 
> I would like to know what you think how it could work in
> compliance to the usual printer setup in CUPS.
> 
> Something which I have in mind up to now:
> 
> 1.
> Use a postinstall script in the RPM for this driver
> which runs the driver and creates the PPD file.
> Drawbacks:
> Doesn't work if the printer is not connected while
> the RPM is installed.
> Doesn't work when the user changes or adds new printers.
> 
> 2.
> Use a special backend and let this backend autodetect
> the printers which are supported by this driver and for
> each autodetected printer let the backend run the driver
> and create the PPD file.
> Drawbacks:
> Normally a backend is not allowed to create files
> in /usr/share/cups/model/ (except it runs as root).
> At the moment I don't know if cupsd runs the backends first
> and then scans /usr/share/cups/model/ for new PPD files
> or vice versa.
> 
> 3.
> This driver seems to cause the same problems as using the
> Foomatic setup tool when it creates the PPD on the fly
> from XML sources instead of using ready-made PPDs.
> Is there a solution for this problem?

With CUPS 1.2 it is no problem, as it supports dynamic PPD generation.
It only needs a PPD generator in /usr/lib/cups/driver/, where the PPD
generator has the command line options "list" to list all PPDs which it
is capable to generate and "cat <PPD name>" to actually generate one of
the PPDs announced by the the call with "list".

A small example for such a PPD generator you find as "testdriver.c" in
the driver/ subdirectory of the CUPS 1.2.x source tree. Compile it with
(libcups-devel must be installed):

gcc -lcups -o testdriver testdriver.c

and drop the resulting binary in /usr/lib/cups/driver. Now the web
interface will show you three new printers and if you set up queues with
these choices, they will have valid PPDs. These PPDs are not in
/usr/share/cups/model, but they are generated on-the-fly by
/usr/lib/cups/driver/testdriver. Try to run "testdriver" manually and
have a look at its output.

There is also the first real-live PPD generator for CUPS 1.2: Foomatic.
Get the newest daily snapshot of foomatic-db-engine from linuxprinting.org:

http://www.linuxprinting.org/download/foomatic/foomatic-db-engine-3.0-current.tar.gz

and install it on a box running CUPS 1.2 (Use "./configure
--prefix=/usr" to replace your current foomatic-db-engine). You should
have a file named

/usr/lib/cups/driver/foomatic

after that which is a link to /usr/bin/foomatic-ppdfile. If not, create
the link. Make also sure that foomatic-db is on your box (there must be
/usr/share/foomatic/db/source/).

Now go into the web interface and you will see LOTS of printer models.
These PPDs are now generated on-the-fly by Foomatic.

Now to your case:

The user will have the printer connected and turned on (so that the
"usb" or "snmp" backend of CUPS detects it). As soon as you reach the
step of the "Add this printer" button is clicked or the page with the
list of the manufacturers is about to be displayed, CUPS calls your PPD
generator as follows:

/usr/lib/cups/driver/acme list

Your PPD generator will then connect to your printer polling its model
name and IEEE-1284 device ID (it could call the "usb" and "snmp"
backends of CUPS for that, to avoid re-inventing the wheel). Then it
outputs (example):

"acme:ACME-FooJet_2000-Postscript.ppd" en "ACME" "ACME FooJet 2000
PostScript" "MFG:ACME;MDL:FooJet 2000;DES:ACME FooJet 2000;CMD:PS3,PCLXL;"

First column is the PPD name to be used with "acme cat <ppdname>",
second is the UI language of the PPD, third is the manufacturer for the
manufacturer list in the web interface, forth is the entry for the model
 menu in the web interface and fifth is the device ID string.

If the PPD is actually requested by CUPS, either when it matches the
output shown above with the auto-detection output or if the user chooses
this model in the web interface, CUPS calls

/usr/lib/cups/driver/acme cat acme:ACME-FooJet_2000-Postscript.ppd

and your PPD generator polls the information about the options from the
printer and builds an appropriate PPD file which it drops on standard
output. CUPS happily picks it up and makes a perfectly working queue for
you.

I hope this is exactly what you need.

   Till





More information about the cups mailing list