Leaving print job filtering to be done on the remote server makes sense in most case, but it causes a problem when the printer is attached directly to the network, This is a common situation. The printer is considered remote because it is not connected to a serial or parallel port on the Linux computer. Network printers in many companies have their own IP addresses, which make it possible to send data directly to the printer without connecting it first to a computer's parallel or serial port. Because Linux applications do not preprocess a file based on a printer driver before submitting it for printing, the print filter must do this job. A network printer, however, does not have the ability to run a Linux-style print filter. To solve this problem, a bounce queue command is used.

A bounce queue (bq) is an option code in the printercap file that cause print jobs to be processed by the pint filter before being sent to a remote printer. For example, if the printcap file includes the folllowing lines, each print job will be processed by the filer, then sent to the print queue named cs4 on the server 131.162.130.250.

lp: :sd=/var/spool/lpd/lp: :mx#0: :sh: :bq=cs4@131.162.130.250: :if=/var/spool/lpd/lp/filter:

Note that no rm or rp lines are used here, because the bq option contains the remote printer information. In addition, no lp line is required, because no local printer port will be used to print files. However, as when using the rm and rp options to specify a stanard remote lpd-based server, you should include the sd option to specify a print spool directory so that lpd has a lcoation to store files between the time they are submitted and when they are processed.

To allow remote machines to print to your printer using the LPD protocol, you must list the machines in /etc/hosts.equiv or /etc/hosts.lpd. (Note that hosts.equiv has a host of other effects; be sure you know what you are doing if you list any machine there). You can allow only certain users on the other machines to print to your printer by usign the rs attribute; read the lpd man page for information on this.

11.1.1. With pdq

With PDQ, you define a printer with the interface type "bsd-lpd". This interface takes arguments for the remote hostname and queue name; the printer definition wizard will prompt you for these.

11.1.2. With lpd

To print to another machine, you make an /etc/printcap entry like this:

# REMOTE djet500
lp|dj|deskjet:\
        :sd=/var/spool/lpd/dj:\
        :rm=machine.out.there.com:\
        :rp=printername:\
        :sh:

Note that there is still a spool directory on the local machine managed by lpd. If the remote machine is busy or offline, print jobs from the local machine wait in the spool area until they can be sent.

11.1.3. With rlpr

You can also use rlpr to send a print job directly to a queue on a remote machine without going through the hassle of configuring lpd to handle it. This is mostly useful in situations where you print to a variety of printers only occasionally. From the announcement for rlpr:

Rlpr uses TCP/IP to send print jobs to lpd servers anywhere on a network.

Unlike lpr, it *does not* require that the remote printers be explicitly known to the machine you wish to print from, (e.g. through /etc/printcap) and thus is considerably more flexible and requires less administration.

rlpr can be used anywhere a traditional lpr might be used, and is backwards compatible with traditional BSD lpr.

The main power gained by rlpr is the power to print remotely *from anywhere to anywhere* without regard for how the system you wish to print from was configured. Rlpr can work as a filter just like traditional lpr so that clients executing on a remote machine like netscape, xemacs, etc, etc can print to your local machine with little effort.

Rlpr is available from Metalab. ftp://metalab.unc.edu/pub/Linux/system/printing/

.. Many printers come with an ethernet interface which you can print to directly, typically using the LPD protocol. You should follow the instructions that came with your printer or its network adaptor, but in general, such printers are "running" lpd, and provide one or more queues which you can print to. An HP, for example, might work with a printcap like:

lj-5|remote-hplj:\
        :sh:\
        :sd=/var/spool/lpd/lj-5:\
        :rm=printer.name.com:\
        :rp=raw:

or, using the PDQ bsd-lpd interface arguments of REMOTE_HOST=printer.name.com and QUEUE=raw.

HP Laserjet printers with JetDirect interfaces generally support two built in lpd queues - "raw" which accepts PCL (and possibly Postscript) and "text" which accepts straight ascii (and copes automatically with the staircase effect). If you've got a JetDirect Plus3 three-port box, the queues are named "raw1", "text2", and so forth.

In a large scale environment, especially a large environment where some printers do not support PostScript, it may be useful to establish a dedicated print server to which all machines print and on which all ghostscript jobs are run. This will allow the queue to be paused or reordered using the topq and lprm commands.

This also allows your Linux box to act as a spool server for the printer. To do this, set up a queue on your linux box that points at the ethernet equipped HP LJ (as above). Now set up all the clients on your LAN to point at the Linux queue (eg lj-5 in the example above).

Some HP network printers apparently don't heed the banner page setting sent by clients; you can turn off their internally generated banner page by telnetting to the printer, hitting return twice, typing "banner: 0" followed by "quit". There are other settings you can change this way, as well; type "?" to see a list.