Mr. Tharan tells us how to use the PPR spooler for large networks.
PPR is a PostScript printer spooler. It allows users to queue jobs for printing on different PostScript printers. A single host can be the printing spooler for a whole department or even a campus. It is well suited for managing a large number of printers.
Its main advantage over traditional printing servers, such as the System V LP or the Berkeley LPD, is that PPR is able to use every feature of the PostScript standard or the Adobe Document Structuring Conventions (DSC).
While many Linux users are pleased with the lpd printing daemon, I found it was not as easy to use when it came to support four TCP/IP HP 5M PostScript printers with more than 160 Linux, Macintosh and Windows computers on my LAN (local area network).
PPR has been designed specifically for the purpose of operating PostScript printers, accepting jobs from different systems such as UNIX (remote or local), Windows with Samba or Macintosh with AppleTalk. PPR can talk to any PostScript printer connected via a parallel port, a serial port, AppleTalk or TCP/IP. It can even talk to a remote lpd server. Beginning with version 1.00 (the first public release), PPR includes a GhostScript interface which enables it to print on every non-PostScript printer supported by GhostScript. PPR is therefore very well adapted to a heterogeneous environment.
PPR was designed with optimizing the use of PostScript and the Adobe DSC in mind. As such, PPR is able to stop a job if the printer indicates that the job contains a PostScript error (a queue listing will show “arrested” for that job). Many PostScript interpreters are “cool” about the errors one can find in PostScript files, but a program generating PostScript should be strict. Remember that PostScript is a programming language. What if gcc let you forget a semicolon or undeclared variables?
Moreover, for printers that support it, PPR is able to capture the error messages sent by the printer and process them, sending a notice to the user or the administrator if something went wrong. After a job has completed, the user can be notified by various means: a mail message can be sent if he's a UNIX user; a WinPopup if he used Samba, and so on, so that batch and queue printing take their true meanings here.
If a user submits a non-PostScript file to PPR, it converts the file to PostScript using a set of tools determined at installation time. For example, a .tex file will be passed through LaTeX and dvips if these programs are available on the system; a .gif file could be passed though the netpbm utilities, etc. Then, PPR hands the converted file to the printer.
The queue handling is also well done. Any user can hold or cancel his job once submitted; any administrator (any trusted user belonging to a certain access list) can hold, release or cancel a job. Finally, a job can be moved from one printer to another one if desired.
PPR has also support for PPD files (PostScript Printer Description files), which are a convenient way to describe a printer's capability in just one file. PPR reads a PPD file and determines automatically what type of paper the printer can handle, what sort of bins it can use, and so on. PPD files can be downloaded from Adobe's FTP site, or you can have generally have them on the drivers' disk shipped with your printer.
As of January 1999, the latest version of PPR is 1.40a4 and Linux is the primary development system. Version 1.31 and later are stable enough to be used in a production system. PPR uses very little resources other than the spool area, the size of which depends on how many users print on the site. We used to run PPR on a Pentium 66 Linux box which was also serving e-mail and Web. We have moved to a more powerful machine only because we felt it was better to separate the printing spool from the mail spool.
You can find the PPR FAQ at http:tarzan.trincoll.edu/printing/pprfaq.html and all the documentation at http:mouse.trincoll.edu/ppr/docs/index.html. They are written in an easy to understand style.
Installing PPR is easily done by following the steps described in “Installing and Using PPR” which is a beginner's guide to running PPR. Compiling and installing the program in place is not difficult. If you plan on using AppleTalk with PPR, you will need AppleTalk support (either from NetaTalk or CAP, depending on the platform), and a separate library called NATALI (if you use Netatalk), shipped with PPR.
Next comes the configuration process. You may need to add a user and a group to your system files for PPR to work correctly. An access list system allows the administrator to delegate some powers; thus, he can assign some trusted users the task of cleaning up the printers' queues from time to time, without constantly requiring the administrator's help. There used to be some UNIX groups to which one had to belong in order to have PPR privileges, but this has been phased out in favour of the access list system.
Every printer on your network must be defined as well as the interface to use: tcpip for TCP/IP or atalk for AppleTalk. Then set some configuration variables, such as selecting a PPD file suitable for the printer or even adding a comment for the current printer.
You can even group printers and define groups. Jobs submitted to a group will go to the first non-idle printer in the group. The printers can even be rotated: jobs will be submitted in a round-robin fashion to each printer in a group.
Next, you can configure your system for different PPR access methods. With Samba, for example, the program ppr2samba is included which generates a simple file describing all the PPR-defined printers; include this file in your smb.conf file.
To add support for your AppleTalk users, you will have to launch the papsrv daemon which lists the printers on the AppleTalk network and handles jobs sent to PPR. You can even throw away your lpd server and use lprsrv to serve lpd jobs the same way papsrv does for AppleTalk.
PPR also allows for quota charging on a per-user basis, if you are concerned about who is doing what or if you simply want to charge for every sheet of paper coming out of your expensive printers.
PPR proves to be useful in a wide variety of configurations and should not be difficult to adapt to your needs. We use it here on a daily basis with very little maintenance: the main printing problems come from the printers themselves.
Many thanks to David Chappell, the author of PPR, who kindly reviewed this article.
