This page was last modified on 18 October 2005.
PPR is a Unix print spooler expressly designed for operating PostScript printers. Its features are numerous, and it supports PostScript printers connected to parallel or serial ports, or over the network through AppleTalk, LanManager, LPD, and TCP/IP protocols. It accepts jobs from SMB clients (such as Microsoft Windows), Macintosh, and Unix clients. PPR is designed for PostScript printing, so it can detect PostScript errors. If the input file is not PostScript, it can pipe the input through a filter. PPR has been designed to manage large numbers of printers with minimal operator attention.
The announcement of the latest stable release contains a longer description of the package.
The PPR home page may be found at http://ppr.trincoll.edu/.
Almost all of PPR was written at the Trinity College computing center in Hartford, Connecticut, USA. It was written by David Chappell who is a system administrator there. He began writing it in 1993 because he was unhappy with the Unix System V release 4.0 print spooler, particularly its poor ability to report on and recover from printer faults.
Please refer to the PPR Download page at http://ppr.trincoll.edu/download.html page.
This FAQ is maintained by David Chappell and corrections or contributions should be sent to him.
Reports of bugs in PPR itself should be sent to email@example.com.
Send questions about PPR to the PPR mailing list. Selected questions and answers from the PPR mailing list will be added to this document.
Instructions may be found on the PPR Mailing List page at http://ppr.trincoll.edu/mailinglist.html page.
Yes there is. Read about it on the PPR Mailing List page at http://ppr.trincoll.edu/mailinglist.html.
|Operating System||Notes||AppleTalk Support|
|Linux||Current principal developement system. Current testing is done with Redhat 7.0 and Mandrake Cooker.||PPR works with Netatalk if you add a PAP implementation I have written, called NATALI. It is not know if it works with any Linux port of CAP.|
|System V release 4 for AT&T WGS systems||This is the origional operating system on which PPR was written. Though support for this OS is install included in PPR, recent releases have not been tested on this OS.||Works with an AT&T AppleTalk stack which they called the AppleTalk Network Program.|
|SunOS 4.1.3||No test reports received.||This port is reported to work. CAP60 should work. It should also be possible to port NATALI with little trouble.|
|Solaris 2.6||Some testing||Works with CAP 6.0 patch level 194, other patch levels not tested. Netatalk/NATALI not attempted.|
|Solaris 9||Some testing||AppleTalk not attempted.|
|OSF/1 & Digital Unix 4.0)||Tested by one user at Trinity College.||AppleTalk not attempted.|
|IRIX 6.3||A handful of people use this at Trinity College.||AppleTalk not attempted.|
|NetBSD||PPR version 1.00 probably worked with NetBSD version 1.00. Little testing then, no testing at all with more recent versions of PPR or NetBSD.||May have worked with CAP60.|
|Windows NT with Cygnus Win32 POSIX tools||This port doesn't work yet.||AppleTalk not attempted.|
|Windows NT with UWIN 2.9||This port doesn't work yet.||AppleTalk not attempted.|
|HP-UX 10.2||The port seems to work. There is one user at Trinity College. The xwin responder doesn't work because of a bug in xterm.||Works with CAP 6.0.|
|ULTRIX 4.4||Changes are in, but they probably aren't quite right yet.||AppleTalk not attempted.|
|MacOS X||Coming in version 1.51. Necessary changes are already in CVS version.||Researching AppleTalk support.|
If you can help by testing it on any of these operating systems or porting it to additional ones, please write to David Chappell.
I asked earlier about getting PPR to talk to a Apple laserwriter 12/640 with the tcpip interface. I wasn't able to get that interface to work but I was able to use the lpr interface. This way I could tell ppr that the printer expected postscript to "firstname.lastname@example.org".
Hopefully a future version of the manual could explain when one should use the tcpip interface versus the lpr interface or maybe a list of printers that should use one or the other.
That is a difficult question to answer. The logical answer is "look in your printer manual," but some printer manuals are very unhelpful in this regard.
Most if not all printer that claim TCP/IP support support something called the LPR/LPD protocol. This is a protocol which first appeared in BSD Unix. It allowed one BSD system to send a print job to another BSD system for printing on a printer attached to that system. (This protocol is discribed in RFC 1179.)
Printers supporting the LPR/LPD protocol pretend to be a BSD Unix systems. Since there is actually only one printer attached to the "host", specifying the printer name would seem unnecessary, but the protocol requires that you specify it. Often you can use a name you pull out of the air, the printer will ignore the actual name. In this case you can use an address such as "email@example.com".
A few printers give special meaning to certain names. When these names are used, the printer may select a specific printer language or line ending translation. For example, the HP JetDirect Print Server Software Installation Guide (publication number J2552-90101 page 10-8) says that the printer name should be "text" or "raw". I suggest you choose "raw".
The manual for a Pocket Print Server from Extended Systems says that if you append "LF" to the printer name, it will add a carriage-return before each line-feed and if you append "FF", it will add a form-feed to the end of the job if the last character is no alredy a form-feed. You should not use either of these suffixes with PPR.
The interface called "tcpip" simply connects to the specified port and blasts data at the printer. The end of job is indicated by sending a control-D. I call this the raw TCP/IP protocol. If the feedback option is set to true with the "ppad feedback" command, and the printer supports it, it will also wait to detect PostScript errors. This protocol is hinted at in the manual for the Pocket Print Server from Extended Systems. I can find no reference to it in my HP JetDirect manual, but have found by experiment that it works.
If you are using this protocol with an HP printer with a JetDirect cards, you should use "ppad feedback" to set the feedback option to true since this is not the default setting for the tcpip interface.
This protocol is also supported by the Pocket Print Servers mentioned above, however at least for there parallel port product, which is unidirectional, "ppad feedback" must remain set to false.
I do not know what other products, if any, support the raw TCP/IP protocol.
Is there a way to define an alias for a printer name?
Printer aliases are implemented as groups with only one member. For example, to create an alias for "myprinter" called "ourprinter":
$ ppop group add ourprinter myprinter
Once this is done, jobs sent to the group "ourprinter" will be printed on its only member which is "myprinter".
Is there a way I can specify default ppr command line options for a printer or group?
Each printer or group can have a set of options called a "switchset" defined. The switchset is defined with the "ppad switchset" command (for printers) or the "ppad group switchset" command (for groups). Normally, when a job is submitted with the program "ppr" this switchset is not used, but if ppr is invoked with the -I switch these switches will be inserted in the command line at the point where the -I switch appears.
The -I switch can be used when ppr is invoked by other programs. For example, the server "lprsrv" invokes ppr with the -I switch. The sample Samba setups described in the manual pages and in "Installing and Using PPR" use the -I switch. The AppleTalk print server "papsrv" does not use the -I switch by default since it provides the "PPRparms:" configuration file option, but if you want Macintosh jobs to use the -I switch, you can add a line which says "PPRparms: -I" to each record in the papsrv configuration file.
Groups and switchsets can be usefully combined. For example, if you have a printer called "pubprn" and you want to make two names for it, one of which will print in duplex, the other in simplex, you could do it with these commands:
$ ppad group add pub_dup pubprn $ ppad group switchset pub_dup -F '*Duplex DuplexNoTumble' $ ppad group add pub_sim pubprn $ ppad group switchset pub_sim -F '*Duplex None' $ ppad group comment pub_dup 'Public printer, duplex' $ ppad group comment pub_sim 'Public printer, simplex'
Once this is done, remote jobs ariving by LPR will be forced to print in duplex or simplex mode depending on whether they are spooled to "pub_dup" or "pub_sim". On the other hand, jobs arriving for "pubprn" will not be coerced.
Is there a way to force the atalk interface to give printer updates more often? Right now, the status message on the lpq listing doesn't get updated to the real status of the printer too often (or at all?)...
Normally, during the printing of a job it is updated only when the printer sends an update. When updates are sent varies from printer to printer.
In PPR version 1.30 and later there is an interface option status_update_interval=. Try setting it to 60. (In version 1.32, the name of this parameter is changed to "idle_status_interval=", but the old name is still accepted.)
What does the mfmode= setting in the default filter options? What bad thing will happen if PPR can't figure out the proper setting for this option?
The "mfmode" is a set of settings used by Donald Knuth's MetaFont. MetaFont is a program which takes font outlines (in MetaFont format) and converts them to bitmaps. MetaFont is generally used with Donald Knuth's typesetting TeX.
A MetaFont mode is a description of the physical characteristics of a certain printers print engine. MetaFont needs to know these physical characteristics in order to produce highly legible bitmaps. Basically this physical information is the number of dot positions per inch and a series of numbers which describe how big the dots are how they smear. Remember that a 600 DPI printer will likely produce dots larger than 1/600th of an inch. The dots overlap.
One K. Berry maintains a list of MetaFont settings for a large number of printers. This list is incorporated in distributions of TeX and MetaFont. This list assign a name to the set of settings for each printer. These are the MetaFont mode names.
Some of PPR's filters call DVIPS to convert TeX DVI files to PostScript. These include the "dvi", "tex", and "texinfo" filters. Since DVIPS calls MetaFont, PPR has to tell DVIPS what MetaFont mode to use for the printer. PPR figures out the MetaFont mode to use for a given printer by opening the printer's PPD file, reading out the resolution and the printer "model name" and "product". These are then looked up in mfmodes.conf. If a matching MetaFont mode is found, it is used as the value of "mfmode=" in the default filter options.
If PPR can't find a match in mfmodes.conf, it will leave the "mfmode=" setting out of the default filter options. DVIPS will use some default of its own. The results are difficult to predice, but this has sometimes resulted in nearly blank pages.
I'm using ppr-1.31 on Linux (2.0.32) printing to a HP Laserjet 5 SIMX. Normally all is working OK, but in a few situation ppr prints multiple copies without asking for it.
The problem you describe is caused by a design flaw in the idle connection timeout in the JetDirect card. If more than 90 seconds elapse between the time PPR sends the last byte and the time the job is finished, then the printer will hang up the connection. (PPR keeps the connection open until the PostScript program has terminated so it can collect the error messages.)
There are two things you can do. One is to telnet to the printer and disable to timeout or make it longer. The other is to upgrade to PPR 1.32 or later and set a new printer option:
$ ppad options myprn "idle_status_interval=15"
This will cause the tcpip interface program to send a control-T (a status inquiry) whenever it hasn't sent anything for approximately 15 seconds. This will convince the JetDirect card that the sending computer is still alive.
In PPR 1.40 and later, idle_status_interval is set to 15 by default if feedback is true.
When I try to compile ppr, after compiling NatALI successfully, I get the following message:
Making printer interfaces gcc -Wall -O2 -fno-strength-reduce -fomit-frame-pointer -m486 -I ../include -o atalk atalk.o \ /usr/local/lib/libnatali.a /usr/local/atalk/lib/libatalk.a ../libppr.a /usr/local/lib/libnatali.a(natali_pap.o): Undefined symbol _resend_request referenced from text segment make: *** [atalk] Error 1 make: *** [all] Error 2
This results in not getting the papsrv file.
It is necessary to modify one of the Netatalk source files and recompile part of it. The full instructions can be found in the NATALI README file.
Does PPR work with Netatalk under SunOS 4.x and Solaris 2.x?
No, not yet.
When you use the signal/pjl method, it sends the username of the job to the HP printer's display before starting the job. Neat. However, if you cancel the job before printing is done, PPR doesn't seem to clean up after itself, and the printer's status display continues to print the username it seems...
Yes. It would be easy to reset the display if the job was printing normally when it was killed, but if written simplemindedly such code would prevent a printer from being halted when it was off-line. (Pprdrv would say, "Wait! I mustn't exit before the printer accepts this little command.") Something may get done about this eventually, but right now it isn't a sufficiently high priority.
When I print to a queue which uses Ghostscript to print to a non-PostScript printer it won't do multiple copies.
This is a problem with Ghostscript 3.33 and possibly other versions. The level 1 multiple copies command works but the level 2 command does not. This problem does not exist in Ghostscript version 4.03 and later, so upgrading is probably the best solution.
When I try to print from a Macintosh to a PPR queue shared with papsrv, the Macintosh says:
A PostScript error has occured. The error is: bad ppr invokation syntaxand the message:
Unrecognized -Q option "Type42"appears in /var/spool/ppr/logs/papsrv.
Where is this -Q option coming from and why is it invalid?
The -Q option is inserted by papsrv using information derived from the PPD file. The problem is that the PPD file has MS-DOS/MS-Windows line termination rather than the correct Unix line termination. The result is that the argument to the -Q option ("Type42") has a spurious and invisible cariage return added to it.
To convert MS-DOS/MS-Windows PPD files to Unix format, use FTP's ASCII mode to transfer them from the MS-DOS/MS-Windows computer to the Unix computer or use the following Perl command to remove the carriage returns once it is on the Unix computer:
$ perl -p -ibak -e 's/\r//g' SOMEPRN.PPD
where SOMEPRN.PPD is obviously the name of the PPD file you want to convert.
A future version of PPR will detect this problem automatically and will have a command for installing PPD files.
I have set the default page size to A4 in /etc/ppr/ppr.conf but PPR contines to print TeX DVI files in US Letter format.
Delete the files in /var/spool/ppr/dvips. These are DVIPS configuration files which are created as needed. The default page size is read from ppr.conf only at the time that each of these files is created. This is to be considered a bug in PPR which will be corrected at some point.
PPR is having trouble printing some of the documents my Macintosh users are sending because the documents contain incorrect DSC comments. So, I have tried setting PPR to transparent mode by putting "-H transparent" on the "PPDparms:" line in papsrv.conf. However, this results in some of the fonts being replaced with Courier.
Unfortunatley, -H transparent wasn't origionally intended for this purpose. The problem is that -H transparent tells PPR not to edit the job in any way. However, during the query phase LaserWriter has learned that PPR can insert fonts into the document. So, PPR has agreed to do something and then doesn't do it.
The solution is to get PPR to stop agreeing to do it. If it refuses, then the Macintosh will include the fonts inline. In PPR 1.40a2 and later you can put a line in the papsrv.conf section for the queue which says:
query font cache = no
This will tell papsrv to tell the Macintosh client that it can only supply the fonts that are in the printer and not those that are in the PPR font cache. This will increase the time it takes the Macintosh to print a document with downloaded fonts, but it will allow you to use -H transparent.
Whenever I submit a job brom a Macintosh, it doesn't show up in the queue. Instead I find this error in the papsrv log file:
fatal error: qentry->For is empty.
Your Macintosh is nameless. You should enter a name in the "File Sharing" control panel on your Mac. PPR 1.41 and later have special code to compensate for this problem. These newer versions will replace the empty name (which PPR considers illegal) with something "[blank Macintosh owner]".
I noticed that -K true is needed for printing A3 on an HP DJ 1100C using gstcpip, since otherwise the coordinates-settings (%%BeginFeature *PageSize ISO-A3) from a windows driver) is commented out by ppr.
This is not supprising, the Windows PostScript driver 4.0 is broken when it comes to feature code. It uses the human readable name in the comment rather than the machine readable name. You did the right thing. Adobe distributes a fixed driver from their web server.
I need to learn PS is a hurry. (Any good books you could recommend?)
The Red Book (PostScript Language Reference Manual, second edition is good to have, but it is very thick in both senses. Appendix G, is also available as the DSC specification from Adobe's Web server and FTP site.
As a tutorial I would recomend PostScript Language Tutorial and Cookbook (the Blue Book). It was published before PS Level 2 came out and it does not cover DSC comments, but it is good anyway.
I would also recomend the PostScript Printer Description File Specification and other technical notes available from Adobe.
The HP Printer Job Language, known as PJL is described in the booklet "Printer Job Language Technical Reference Manual" which is distributed with some recent HP printers.
We are searching for a more detailed documentation about a Protocol called ppr/ppd which is introduced by LEXMARK. This is a protocol for binding IBM-Mainframe / AS/400 printers via tcp/ip instead of using sna-protocols. Searching the web for this topic directed us to your faq.
PPR has nothing to do with this protocol. In the context of this FAQ, PPR is a print spooler and a PPD is a PostScript Printer Description file in the format defined by Adobe. I know nothing about the protocol PPR/PPD.
Can someone tell us about this protocol? Would it be worth implementing in PPR?
How can I use PPR with MARS to accept jobs from Novell clients?
Pavol Ferko <firstname.lastname@example.org> provides this explanation:
It is very simple to configure Mars to work together with PPR. The Mars server has one configuration file named "nwserv.conf". The print queues are define in section 21 of this confuration file. It looks like this:
# Section 21: print queues (optional) # # Which of the printers connected to your Linux-box should be accessible # from the DOS-clients? # Multiple entries are allowed. # # ------------------------------------------------------------------------- # Syntax: # 21 QUEUE_NAME [QUEUE_DIR] [PRINT_COMMAND] # # QUEUE_NAME: the name of the print queue on client-side (to make it # perfectly clear: _not_ the Linux-queue) # QUEUE_DIR: spooling directory for the print-jobs. # The name is the DOS (not Unix) name of this # directory. # It must be placed on the first defined volume. # (standard name is SYS volume). # Then it will be created at starttime of mars_nwe. # It must exist before printing. # (_not_ the spooling-directories of the Linux-lpd) # NOTE ! # A '-' sign as QUEUE_DIR has special meaning of # 'standard' queuedir name. ( SYS:\SYSTEM\queueid.QDR ) # # PRINT_COMMAND: command used for serving the print-jobs under Linux # (see "man lpr" and "man magicfilter" for details) # if the '!' is last parameter of command then # the queue-packet fields 'banner_user_name' # and 'banner_file_name' will be added to the # command as last parameters. # NOTE ! # If a print command is not specified the job can/must be # printed by any print server. # (e.g. pserver (ncpfs utils) or external printserver) # # Examples: # 21 LASER - lpr -Plaser # 21 OCTOPUSS # 21 FAXPRINT - /usr/bin/psfaxprn /var/spool/fax/faxqueue # ------------------------------------------------------------------------- 21 A4_INZ - ppr -d A4 -f Novell -w log -U 21 A3_INZ - ppr -d A3qms -f Novell -w log -U 21 A4_INZ_SD - ppr -d A4_SD -f Novell -w log -U # End section
Mars first places the job file in the standard queue directory and then runs the print command. It is important to use the ppr command with the switch -U. When anything is change in the conf file, Mars must be told to reload the configuration file with the command:
And I think that is all.
Where do I find dpost, postreverse and postprint? These are the first tree prog that were searched by ppr-index filters.
These programs are part of AT&T Troff and LP. If you have Groff installed, these programs are not needed since Groff includes programs which perform the same functions.