PPR FAQ

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 "x@mine.prn.trincoll.edu".

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.

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".

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.

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.)

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.

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.

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.

No, not yet.

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.

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.

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.

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.

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.

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]".

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.

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.

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?

Pavol Ferko <p.ferko@labe.vlp.cz> 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:

nwserv -h

And I think that is all.

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.