ppad-interfaces - PPR Printer Interface Programs
PPR uses interface programs to communicate with printers. An interface is selecte with the ppad interface command. Its options are set with the ppad options command. Please see the the ppad.8 manpage manpage for details.
At the end of this document there is a discussion of various printer devices and the recomended interfaces.
These are the interfaces which are distributed with PPR:
The interface simple is a shell script which sends the job to a Unix port. The address is the port name, such as /dev/lp0. It has no provision for setting baud rate or other port options as the serial interface can. By default, this interface uses the jobbreak method control-d, however, the method control-d/pjl is also suitable if the printer understands the HP PJL. See the ppad jobbreak section of this document. PostScript errors will not be detected when using this interface. If your printer is connected to the parallel port or the print spooling computer, you should probably use the newer parallel interface instead of the simple one.
The interface serial sends the job to a serial port on the server. The address is the port name, such as /dev/ttyS00.
The default is ``online=dsr/cts'' which will work in many cases. Other options include ``dsr'', ``cts'', and ``none''.
For this feature to work, your printer must make at least one of its modem control lines go false when it is taken off-line and your null modem cable must feed this signal to one of the receiving modem control lines on the computer and you must indicate the correct receiving line as the value for the ``online='' option. Setting this up correctly may require the use of an RS-232 breakout box to determine if there is a line which goes false when the printer is offline.
The default for this option is 15 if feedback is true and jobbreak is control-d, 0 otherwise. In previous versions, the default was always 0.
The default options for the serial interface are expressed by the string ``speed=9600 xonxoff=yes rtscts=no bits=8 parity=none online=dsr/cts detect_hangups=false hangup_on_close=true idle_status_interval=0''.
By default, this interface uses the jobbreak method control-d, however, the method pjl is also suitable if the printer understands the HP PJL. See the ppad jobbreak section of this document.
This interface sends the print job to the parallel port specified in its address.
Currently, the ``status_interval='', ``reset_before='', and ``reset_on_cancel='' options only work on Linux systems. On other platforms they do nothing. It should be a simple matter to add support for other operating systems.
If your printer, parallel port hardware, and operating system's parallel port driver support bidirectional communication, then you may use the ppad feedback command to enable PostScript error detection.
This interface sends the print job to a USB printer. It is still experimental. You may get better results with the parallel or simple interface. At this time, the only address format supported is device file name, such as /dev/usb/lp0. In the future it will support alternative address formats which may specify USB bus position or make, model, and serial number.
The interface dummy is for testing purposes. It is a shell script which copies the job to a file. The address is the name of the file.
The interface atalk sends the job to an AppleTalk printer using the Printer Access Protocol. The address is the AppleTalk address of the printer in the form ``name:type@zone''. The name is the name that appears in the chooser. The type is usually ``LaserWriter'' but it may be anything including ``LaserJet 4M'' and ``LaserShared''. If the printer is not found using the indicated type, then it is tried again with a type of ``LaserWriter''; if it is found that time, PPR changes the printer's type to the Type originally specified. This ``hides'' or ``captures'' the printer, preventing Macintosh user's from sending jobs to it directly.
This interface has some options which may be set with the ppad options command. (None of these options are implemented yet in the CAP version of the interface.)
The interface tcpip opens a connection to a specified TCP socket on a specific host and sends the data. Aliases for this interface automatically select appropriate options to implement the SocketAPI, AppSocket, and JetDirect protocols.
The address format for the tcpip interface is host or host:port. For example: ``bigjohn.prn.trincoll.edu:9100''. If port is omitted, 9100 will be used. Port 9100 is the default port for many devices which use this protocol including those from HP, and Extended Systems.
This interface currently supports all jobbreak methods except signal and signal/pjl. (See the ppad jobbreak section of this man page.)
By default the ppad feedback setting is set to ``true'' for this interface. A setting of ``true'' indicates that the network device supports bidirectional communication with the printer. HP printers with JetDirect cards support bidirectional communication. However, some external Ethernet adapters designed to be connected to the parallel port don't have bidirectional parallel ports themselves. Thus, even if the printer has a bidirectional parallel port, bidirectional communication will be impossible. The manual that comes with the adapter may be able to tell you whether it has a bidirectional parallel port. If not, experiment. If jobs hang in the queue after they have been printed, then try setting the feedback parameter to ``false''.
When using the tcpip interface, PostScript errors will be detected only if the interface supports bidirectional communication.
The tcpip interface has many options. You will seldom have to set any of them.
If feedback is true and jobbreak is control-d, then the default for this the ``idle_status_interval='' option is 15, otherwise it is 0. In previous versions of PPR, the default is always 0.
This option is especially useful with HP printers with JetDirect network cards. These cards have TCP timeout which by default is 90 seconds. If the card does not receive any characters for 90 seconds it will decide the sender has malfunctioned and hang up the connexion. This is a problem because PPR will wait until the job is finished in case there are any PostScript error messages to receive. If it takes more than 90 seconds for the printer to finish the job after it has received the last byte then it will hang up the network connexion, which PPR will interpret as a printer fault. The result is that PPR will print the same job again and again. The solution is to set an option of ``idle_status_interval=30'' or some other value significantly less them the timeout. The control-T's will reset the JetDirect card's timeout.
This interface is the same as tcpip.
This interface differs from the tcpip interface only in its default options and jobbreak method. The default jobbreak method is newinterface and the default option that differs is ``appsocket_status_interval=15''.
This interace differs from the tcpip only in its default options. The default option that differs is ``snmp_status_interval=15''.
This interface implements the PROS protocol used by Axis print servers. The
address format is printer@host:portnum. For example
LPT1@myprn.myorg.org:35
. If you leave off printer@, LPT1
is assumed.
If you leave off :portnum, 35
is assumed.
This interface accepts the options connect_timeout=, refused_retires=, refused=, and sndbuf_size=. They work exactly as they do for the tcpip interface.
In addition, this interface accepts the option password=. You should use this if you have set the printing password on your Axis print server to something other than the default which is ``netprinter''.
Some may wonder whether this interface supports PROS A or PROS B. While the Axis documentation claims that their print servers support two variants of PROS, called PROS A and PROS B, this is not actually the case. PROS A and PROS B are simply two different implementations of the client. One accepts the print data on stdin, the other runs as a daemon and accepts the print data over a named pipe. Thus the protocol which this interface program supports is simply PROS.
The interface lpr sends the job to another system using the Berkeley LPR/LPD protocol (described in RFC 1179). The filter can be useful for forwarding jobs to other spoolers such as those on Unix systems or Windows NT (with the appropriate service installed).
Most printers with Ethernet cards which claim to support TCP/IP support this protocol. However, because this interface must copy the entire job to a temporary file before transmitting it to the printer, it is much better to use the tcpip interface when the printer's network card supports its protocol.
The address format for the lpr interface is printer@host. For example: ``pooh@sanders.trincoll.edu''. If you really want to, you can specify a port to connect to instead of the normal lpd port. Do it like this: ``pooh@sanders.trincoll.edu:2000''.
If the remote system has a full spooler rather than an Ethernet device connected directly to a printer, jobs could disappear from PPR's queue long before they are printed.
The lpr interface supports all jobbreak methods except signal and signal/pjl. The suitability of any given jobbreak method depends much on the remote system. The default is control-d which is suitable for simple devices such as Ethernet devices which attached directly to the printer. When sending to a real spooler it is sometimes necessary to choose a jobbreak method of newinterface because the remote spooler objects to the control-d's in the data stream. In such a case, the remote spooler will itself insert whatever control codes are necessary.
PostScript errors will not be detected when using the lpr interface because the protocol it implements has no provision for bidirectional communication.
These are the lpr interface's options:
This interface also has the experimental options ``chunk_size='', ``exaggerated_size='', and ``temp_first=''. No documentation is provided for these at this time.
The interface clispool (formerly called client) sends the job to an MS-DOS LAN Manager client running spooling software. This interface is compatible with the client spooling system found in AT&T's LAN Manager for Unix. An AT&T client spooler consists a an MS-DOS computer running LAN Manager client software, the MS-DOS background spooler PRINT, and a program called CLISPOOL. CLISPOOL advertises an NetBIOS name on the network. This name consists of the NetBIOS machine name with ``.P'' appended. The print server writes the print data to a temporary file in a LAN Manager accesable directory, opens a NetBIOS connexion to CLISPOOL, and sends a packet giving the LAN Manager path and name of the temporary file. CLISPOOL then submits the file to PRINT and waits for it to finish. When PRINT is done printing the file, CLISPOOL sends a response packet to the print server and close the connexion.
The address to use with this interface is the NetBIOS name advertised by CLISPOOL, but without the trailing ``.P''. There are no options.
This interface has no options.
Though it will compile on System V Release 4.0 derived systems, this interface has not been tested in several years.
PostScript errors will not be detected when using the clispool interface because the protocol it implements does not support bidirectional communication with the printer.
The interface smb uses Samba's smbclient to send the job.
This interface looks in /etc/ppr/ppr.conf to learn the location of the smbclient program.
The address should be the UNC name of the print queue. It should be in the format ``\\server\queue''.
If access restrictions require it, you may use the options ``smbuser='' and ``smbpassword='' to indicate the user name and password that the interface should use when logging on to the remote print server. Note that anyone with access to the computer running PPR will be able to read the password. Suggestions for a better scheme are welcome.
In order for this interface to work correctly, Samba must be correctly configured. If it does not work, try using smbclient to connect to the printer server.
PostScript errors will not be detected when using the smb interface because the protocol it implements does not support bidirectional communication with the printer.
This section contains notes about various printers and embedded print servers as recommendations as to which PPR interface programs to use with them.
Please send contributions to this section to ppr-bugs@trincoll.edu.
The Apple LaserWriter II and many other printers of that era have internal networking such as the QMS-PS 810 support only the LocalTalk variant of AppleTalk.
LaserWriter
.
HP made a version of the DeskJet with LocalTalk support. They called it the DeskWriter. Since these printers don't have internal PostScript interpreters, they were tested with Ghostscript.
PPR has been extensively tested with HP printers with internal JetDirect cards.
LaserWriter
, which is probably what you should use in the address.
Some printers will give better status reporting if one selects the signal/pjl jobbreak method. However the 4M will malfunction. The 4M+ works fine though.
RAW
.
HP external JetDirect devices which strap to the backs of DeskJets have received basic testing. The printers tested did not have internal PostScript interpreters and so were used with Ghostscript.
This product works but does not support bidirectional communication at all. It is a small box with a parallel port on one end and 10BaseT and 2BaseT connectors on the other.
This print server is a small box with a parallel connector at one end and a 10BaseT Ethernet connection at the other. It supports numberous networking protocols including PROS, SMB, SocketAPI, LPR, FTP, and AppleTalk PAP. The product information page is at http://www.axis.com/techsup/prtsrv/axis_540/. It costs less than US$100.
LPT1
.
LPT1
.
HOLD
, PRINT
, and DIRECT
.
This is a network interface board for a Ricoh Aficio 450 combination photo copier and laser printer. At the time of testing in 1999 it performed poorly, manifesting numberous bugs in its network protocol implementations. Among other things, the bidirectional communication was slow and jerky and lost characters. End of job handshaking generally didn't work. It also frequently dropt off the network.
This entry is here to give you some ideas as to how to work around crippling bugs.
PORT1
. The capitalization is
said to be important. The printer will accept other queue names but will
drop the connexion right after replying that they are OK.
ppad(8)
PPR was written at Trinity College during 1993--2003. It was first released to the public on 26 April 1995.
David Chappell, Trinity College Computing Center, Hartford Connecticut.