PPR: PostScript Printer Spooling
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.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- SUSE LLC's SUSE Manager
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide