Printing Secrets revealed: Grok some Basics about 'PPDs'... and quickly snatch them from a remote CUPS Server

PostScript printers traditionally have all their model specific job options represented in an ASCII file, the "PostScript Printer Description" (PPD). Each printjob option includes three things:

• how the specific option is named internally
• how this option is "translated" so a human computer user can make sense of it
• which option matching code to be injected (in PostScript, PJL or other format) into the printfile to make the printer use this print feature

Adobe developed, specified and published the exact format of PPD files, starting more than 20 years ago. Ever since, PPD files have been used on Apple Macs and Windows PCs (and a few other platforms) to describe and drive PostScript printers.

CUPS extended the concept of PPD files to non-PostScript printers as well (because CUPS uses a computer-based PostScript interpreter, and it can direct each job through a conversion filter to create a jobfile with a format feasible for the target printer).

A CUPS printer named foobaz has its own model-specific print options represented in the file foobaz.ppd that lives in /etc/cups/ppd/. You can of course look at it in an editor.

You may know already, that there is a web page listing of all installed printers on a CUPS server: http://localhost:631/printers/. Every printer on a CUPS server even has its own individual web page. For printer "foobaz", it is at http://localhost:631/printers/foobaz. If you use CUPS, you probably have seen it fairly often already. (Or maybe not... if you are a Mac user: Go try it.)

Once you successfully share a printer (and hence turn your computer a print server for other workstations), this web page is accessible from other computers in your neighbourhood (maybe even over the Internet, if you are not careful!). Just replace the 'localhost' part of above URL with the IP address or the hostname of your CUPS computer.

Now here is the first little secret of today: use the same URL as above, but add the extension string '.ppd' to the printers's web page URL. Make it http://localhost:631/printers/foobaz.ppd. Point your browser to it. Sishshsh!, opens up the PPD in its full ASCII glory for you to look at.

If a printer is shared, its PPD is shared as well. You can look at it from a remote computer, with any browser: http://remote.cups.server:631/printers/foobaz.ppd. This sharing of the PPD is the secret sauce behind CUPS' amazing capability where it allows each remote CUPS client to access and use every single one of a printdriver's job options without ever needing to install that driver locally, on each client!

Windows admins may be familiar with 'Point and Print' installations of shared printers. These are a fairly comfortable way to get a print client install a printer and its driver to use what they call a 'network printer' in the Microsoft empire (that is, a printer with its printqueue hooked to a Windows print server). But still, there is a need to initially 'Point and Print' on each client, for each printer, before that network printer can be used.

CUPS trumps that convenience: no need for 'Point and Print'. Just share a printer from the print server. Provided your Linux (and Unix, and *BSD and Mac OS X...) print clients are correctly set up for this function, they don't need to do anything else: their GUI printing dialogs (like kprinter, xpp, gtklp, ...) will just display all printers as they are shared.

And more, these dialogs will display all available job options, including the printer specific ones, without ever needing to install a local queue, a local driver, or going through the 'Point and Print' procedure. Install a new shared printer on the central CUPS server, wait a few seconds ... and Bang!, all clients will 'see' and be able to use that printer with all its capabilities!

Now assume you know a CUPS server somewhere on the net (local, or on the other side of the globe), that shares its printer named infotec_isc_2525 with you. Then you can put our second little secret of today to some use: snatch that printer's PPD for you. This command:

  wget http://cupsserver.remote:631/printers/infotec_isc_2525.ppd

will fetch the PPD file for you.

Assume, your boss told you to migrate the existing CUPS 1.1.23 server to a 1.3.0 system, and place it on a new, more powerfull hardware. You can't simply copy the old configuration files over, because of some format changes. And how do you get all the PPDs from "there" to "here"? Here are a few initial tips. First, get a list of all existing queues (with their current status) from the remote server:

  lpstat -h cupsserver.remote -p \
          | tee remote.queuenames.full.list

Next, get the info about each queue's method to connect to its actual print device:

  lpstat -h cupsserver.remote -v \
          | tee remote.backends.list \
          | awk '{print $3}' \
          | sed 's#:$##' \
          | tee queuenames.list

Last, fetch each of the available PPDs and store them in a local repository:

  for i in $(cat queuenames.list); do
      wget http://cupsserver.remote:631/printers/${i}.ppd
  done

You now only need to figure how to use this information harvest (and the PPD files) to re-install all the queues locally. And if your old CUPS server hosted 100 queues or more, you really don't want to re-install them all manually. How to automate this, by creating a little script is left as an exercise to the readers....