1.1. History

This is the fourth generation of the Printing HOWTO. The history of the PHT may be chronicled thusly:

1. I wrote the printing-howto in 1992 in response to too many printing questions in comp.os.linux, and posted it. This predated the HOWTO project by a few months and was the first FAQlet called a `howto'. This edition was in plain ascii.

2. After joining the HOWTO project, the Printing-HOWTO was merged with an Lpd FAQ by Brian McCauley <B.A.McCauley@bham.ac.uk>; we continued to co-author the PHT for two years or so. At some point we incorporated the work of Karl Auer <Karl.Auer@anu.edu.au>. This generation of the PHT was in TeXinfo, and available in PS, HTML, Ascii, and Info.

3. After letting the PHT rot and decay for over a year, and an unsuccessful attempt at getting someone else to maintain it, this rewrite happened. This generation of the PHT is written in SGML using the LinuxDoc DTD and the SGML-Tools-1 package. Beginning with version 3.27, it incorporates a summary of a companion printer support database; before 3.27 there was never a printer compatibility list in this HOWTO (!).

4. In mid-January, 2000, I found out about the PDQ print "spooler". PDQ provides a printing mechanism so much better than lpd ever did that I spent several hours playing with it, rewrote parts of this HOWTO, and bumped the version number of the document to 4.

5. In mid-2000, I moved my printing website to www.linuxprinting.org, and began offering more powerful configuration tools there. I also converted the HOWTO to DocBook, and initiated coverage of CUPS, LPRng, and GPR/libppd.

1.2. Copyright

This document is Copyright (c) 1992-2000 by Grant Taylor. Feel free to copy and redistribute this document according to the terms of the GNU General Public License, revision 2 or later.

3.1. With PDQ

Most systems today ship with lpd, so this section won't apply. That said, I now recommend that people install and use PDQ in most cases instead of (or in addition to) lpd. PDQ just has much better support for printer options and such.

With PDQ, instead of the lpr command, you use the command pdq or xpdq. Both work much like the traditional lpr in that they will print the files you specify, or stdin if no files are given.

3.2. With LPD and the lpr command

If you've already got lpd setup to print to your printer, or your system administrator already did so, or your vendor did so for you, then all you need to do is learn how to use the lpr command. The Printing Usage HOWTO covers this, and a few other queue manipulation commands you should probably know. Or just read the lpr(1) man page.

In a nutshell, you specify the queue name with -P, and specify a filename to print a file, or nothing to print from stdin. Driver options are traditionally not controllable from lpr, but various systems accept certain options with -o, -Z, or -J.

If, however, you have a new system or new printer, then you'll have to set up printing services one way or another before you can print. Read on!

3.3. GUI Printing Tools

Most spooling systems alone offer only a rather basic command-line interface. Rather than use lpr directly, you may wish to obtain and use a front-end interface. These generally let you fiddle with various printing options (the printer, paper types, collation, n-up, etc) in an easy-to-use graphical way. Some may have other features, as well.

4.1. The lp device (kernels <=2.1.32)

The Linux kernel (<=2.1.32), assuming you have compiled in or loaded the lp device (the output of cat /proc/devices should include the device lp if it is loaded), provides one or more of /dev/lp0, /dev/lp1, and /dev/lp2. These are NOT assigned dynamically, rather, each corresponds to a specific hardware I/O address. This means that your first printer may be lp0 or lp1 depending on your hardware. Just try both.

A few users have reported that their bidirectional lp ports aren't detected if they use an older unidirectional printer cable. Check that you've got a decent cable.

One cannot run the plip and lp drivers at the same time on any given port (under 2.0, anyway). You can, however, have one or the other driver loaded at any given time either manually, or by kerneld with version 2.x (and later 1.3.x) kernels. By carefully setting the interrupts and such, you can supposedly run plip on one port and lp on the other. One person did so by editing the drivers; I eagerly await a success report of someone doing so with only a clever command line.

There is a little utility called tunelp floating about with which you, as root, can tune the Linux 2.0 lp device's interrupt usage, polling rate, and other options.

When the lp driver is built into the kernel, the kernel will accept an lp= option to set interrupts and io addresses:

When the lp driver is built in to the kernel, you may use the LILO/LOADLIN command line to set the port addresses and interrupts that the driver will use. Syntax: lp=port0[,irq0[,port1[,irq1[,port2[,irq2]]]]] For example: lp=0x378,0 or lp=0x278,5,0x378,7 ** Note that if this feature is used, you must specify *all* the ports you want considered, there are no defaults. You can disable a built-in driver with lp=0.

When loaded as a module, it is possible to specify io addresses and interrupt lines on the insmod command line (or in /etc/conf.modules so as to affect kerneld) using the usual module argument syntax. The parameters are io=port0,port1,port2 and irq=irq0,irq1,irq2. Read ye the man page for insmod for more information on this.

**For those of you who (like me) can never find the standard port numbers when you need them, they are as in the second example above. The other port (lp0) is at 0x3bc. I've no idea what interrupt it usually uses.

The source code for the Linux 2.0 parallel port driver is in /usr/src/linux/drivers/char/lp.c.

4.2. The parport device (kernels >= 2.1.33)

Beginning with kernel 2.1.33 (and available as a patch for kernel 2.0.30), the lp device is merely a client of the new parport device. The addition of the parport device corrects a number of the problems that plague the old lp device driver - it can share the port with other drivers, it dynamically assigns available parallel ports to device numbers rather than enforcing a fixed correspondence between I/O addresses and port numbers, and so forth.

The advent of the parport device has enabled a whole flock of new parallel-port drivers for things like Zip drives, Backpack CD-ROMs and disks, and so forth. Some of these are also available in versions for 2.0 kernels; look around on the web.

The main difference that you will notice, so far as printing goes, is that parport-based kernels dynamically assign lp devices to parallel ports. So what was lp1 under Linux 2.0 may well be lp0 under Linux 2.2. Be sure to check this if you upgrade from an lp-driver kernel to a parport-driver kernel.

The most popular problems with this device seems to stem from misconfiguration:

You can also read the parport documentation in your kernel sources, or look at the parport web site.

4.3. Serial devices

Serial devices are usually called something like /dev/ttyS1 under Linux. The utility stty will allow you to interactively view or set the settings for a serial port; setserial will allow you to control a few extended attributes and configure IRQs and I/O addresses for non-standard ports. Further discussion of serial ports under Linux may be found in the Serial-HOWTO.

When using a slow serial printer with flow control, you may find that some of your print jobs get truncated. This may be due to the serial port, whose default behavior is to purge any untransmitted characters from its buffer 30 seconds after the port device is closed. The buffer can hold up to 4096 characters, and if your printer uses flow control and is slow enough that it can't accept all the data from the buffer within 30 seconds after printing software has closed the serial port, the tail end of the buffer's contents will be lost. If the command cat file > /dev/ttyS2 produces complete printouts for short files but truncated ones for longer files, you may have this condition.

The 30 second interval can be adjusted through the "closing_wait" commandline option of setserial (version 2.12 and later). A machine's serial ports are usually initialized by a call to setserial in the rc.serial boot file. The call for the printing serial port can be modified to set the closing_wait at the same time as it sets that port's other parameters.

4.4. USB Devices

I don't have any USB devices to play with, so all I can offer are pointers. Once set up, you end up with the device file /dev/usb/lp0, much as you do with parallel ports, which will work fine in printcap or as a PDQ local-port device.

USB is documented at the Linux USB Website.

5.1. Postscript

As for what printers do work with Linux, the best choice is to buy a printer with native PostScript support in firmware. Nearly all Unix software that produces printable output produces it in PostScript, so obviously it'd be nice to get a printer that supports PostScript directly. Unfortunately, PostScript support is scarce outside the laser printer domain, and is sometimes a costly add-on.

Unix software, and the publishing industry in general, have standardized upon Postscript as the printer control language of choice. This happened for several reasons:

5.2. Non-Postscript

Failing the (larger) budget necessary to buy a Postscript printer, you can use any printer supported by Ghostscript, the free Postscript interpreter used in lieu of actual printer Postscript support. Note that most Linux distributions can only ship a somewhat outdated version of Ghostscript due to the license. Fortunately, there is usually a prepackaged up to date Ghostscript made available in each distribution's contrib area.

Adobe now has a new printer language called "PrintGear". I think it's a greatly simplified binary format language with some Postscript heritage but no Postscript compatibility. And I haven't heard of Ghostscript supporting it. But some PrintGear printers seem to support another language like PCL, and these printers will work with Linux (iff the PCL is implemented in the printer and not in a Windows driver).

Similarly, Adobe offers a host-based Postscript implementation called PressReady. This works much like Ghostscript does to provide Postscript support for a non-Postscript printer, but has the disadvantage that it runs only on Windows.

5.3. What printers work?

If you want to buy a printer, you can look in several places to see if it will work. The cooperatively maintained Printing HOWTO printer database aims to be a comprehensive listing of the state of Linux printer support. A summary of it is below; be sure to check online for more details and information on what driver(s) to use.

Ghostscript's printer compatibility page has a list of some working printers, as well as links to other pages.

Dejanews contains hundreds of "it works" and "it doesn't work" testimonials. Try all three, and when you're done, check that your printer is present and correct in the database, so that it will be listed properly in this document in the future.

If you're lazy, I keep a short list of suggested printers on my website. These center around color inkjets and low-cost laser devices; fully compatible mid-range and high-end devices are much easier to find. You can even help support this document and the website by buying from buy.com or outpost.com through me.

5.4. How to buy a printer

It's a bit difficult to select a printer these days; there are many models to choose from. Here are some shopping tips:

6.1. LPD

LPD, the original BSD Unix Line Printer Daemon, has been the standard on Unix for years. It is available for every style of Unix, and offers a rather minimal feature set derived from the needs of timesharing-era computing. Despite this somewhat peculiar history, it is still useful today as a basic print spooler. To be really useful with modern printer, a good deal of extra work is needed in the form of companion filter scripts and front-end programs. But these exist, and it does all work.

LPD is also the name given to the network printing protocol by RFC 1179. This network protocol is spoken not only by the LPD daemon itself, but by essentially every networked print server, networked printer, and every other print spooler out there; LPD is the least common denominator of standards-based network printing.

LPRng (see Section 6.3) is a far better implementation of the basic LPD design than the regular one; if you must use LPD, consider using LPRng instead. There is far less voodoo involved in making it do what you want, and what voodoo there is is well documented.

There are a large number of LPD sources floating around in the world. Arguably, some strain of BSD Unix is probably the official owner, but everyone implements changes willy-nilly, and they all cross-pollinate in unknown ways, such that it is difficult to say with certainty exactly which LPD you might have. Of the readily available LPDs, VA Linux offers one with a few minor modifications that make the user interface much more flexible. The SourceForge LPD supports command-line option specification with a -o flag; options are then passed through to filters. This is similar to the features offered by a number of traditional Unix vendors, and similar to (although incompatible with) LPRng's -z option mechanism.

6.2. PDQ

PDQ is a non-daemon-centric print system which has a built-in, and sensible, driver configuration syntax. This includes the ability to declare printing options, and a GUI or command line tool for users to specify these options with; users get a nice dialog box in which to specify resolution, duplexing, paper type, etc (see Figure 7).

Running all of the filters as the user has a number of advantages: the security problems possible from Postscript are mostly gone, multi-file LaTeX jobs can be printed effectively as dvi files, and so forth.

This is what I now use; I've written driver spec files for my printers, and there are several included with the distribution, so there are plenty of examples to base yours on. I've also written a few tools to automate driver spec generation to help the rest of you.

PDQ is not without flaws: most notably it processes the entire job before sending it to the printer. This means that, for large jobs, PDQ may simply be impractical—you can end up with hundreds of megs being copied back and forth on your disk. Even worse, for slow drivers like the better quality inkjet drivers, the job will not start printing until Ghostscript and the driver have finished processing. This may be many minutes after submission.

If you have many users, many printers, or anything else complex going on, I recommend using PDQ as a front-end to LPD-protocol based network printing (you can print via the lpd protocol to the local machine). In most such situations, rather than using the traditional BSD lpd as the back-end, I recommend LPRng:

6.3. LPRng

Some Linux vendors (including Caldera) provide LPRng, a far less ancient LPD print spooling implementation. LPRng is far easier to administer for large installations (read: more than one printer, any serial printers, or any peculiar non-lpd network printers) and has a less frightfully haphazard codebase than does stock lpd. It can even honestly claim to be secure - there are no SUID binaries, and it supports authentication via PGP or Kerberos.

LPRng also includes some example setups for common network printers - HP LaserJets, mainly, that include some accounting abilities. If you'd like more information on LPRng, check out the LPRng Web Page. LPRng uses more or less the same basic filter model as does BSD lpd, so the LPD support offered by my website applies to LPRng as well. This can help you effectively use free software drivers for many printers.

LPRng is distributed under either the GPL or an Artistic license.

6.4. PPR

PPR is a Postscript-centric spooler which includes a rudimentary Postscript parsing ability from which it derives several nice features. It includes good accounting capabilities, good support for Appletalk, SMB, and LPD clients, and much better error handling than lpd. PPR, like every other spooler here, can call Ghostscript to handle non-Postscript printers.

I only recently found out about PPR; I don't know of anyone who has tried it. It was written by, and is in use at, Trinity College. The license is BSD-style; free for all use but credit is due.

According to the documentation, it's somewhat experimental. Malformed Postscript jobs won't print; instead they bounce, and it's up to the user to fix the Postscript. This may make it unsuitable for some environments, although most users generate Postscript with a small handful of well-characterized Postscript generators, so it probably wouldn't be that big an issue.

6.5. CUPS

One interesting newcomer on the scene is CUPS, an implementation of the Internet Printing Protocol (IPP), an HTTP-like RFC standard replacement protocol for the venerable (and klunky) LPD protocol. The implementation of CUPS has been driven by Michael Sweet of Easy Software Products; CUPS is distributed under the GPL.

I've finally done some work with CUPS, and it does work as advertised. There are a number of very good features in it, including sensible option handling; web, gui, and command-line interfaces; and a mime-based filtering system with strong support for Postscript. Since it is so new, however, it does have a number of quirks, and it is hard to recommend for large or secure installations at this time (as of version 1.1). It is a fine solution, however, for smaller installations or especially larger installatons with trusted users.

Like other systems, CUPS can be used with most existing drivers. Unfortunately, it's a bit tricky to configure an arbitrary driver for use with CUPS—at least if you want all the options to work—so it's best to find a preexisting PPD file and filter script to make your driver go. There are at least four sets of drivers which you can use with CUPS:

The third-party program XPP (see Figure 4) offers a very nice graphical interface to the user functionality of CUPS, including an marvelous interface to print-time options (shown in Figure 5). For information on using XPP, see Section 3.3.2.

7.1. PDQ

Pdq stands for "Print, Don't Queue", and the way it works reflects this design. The following sequence of events happens when you use PDQ to print:

• You run pdq or xpdq, specifying a file.

• You specify a printer.

• You specify the settings for the various options and arguments defined in the printer's PDQ driver file (duplex, copies, print quality, and so forth).

• PDQ analyzes the contents of what you printed, and follows the instructions in the PDQ driver file which tell it how to process your data for this printer with your options.

• PDQ sends the processed data to the printer according to the interface defined for that printer (straight to /dev/lp0, or to an LPD daemon on the network, over the network to an Apple or Microsoft system, or even to a fax machine).

• If PDQ can't send the data to the printer right away, it spawns a background process to wait and try again until it succeeds or hits a time limit.

7.2. LPD

Lpd stands for Line Printer Daemon, and refers in different contexts to both the daemon and the whole collection of programs which run print spooling. These are:

So how does it fit together? The following things happen:

1. At boot time, lpd is run. It waits for connections and manages printer queues.

2. A user submits a job with the lpr command or, alternatively, with an lpr front-end like GPR, PDQ, etc. Lpr contacts lpd over the network and submits both the user's data file (containing the print data) and a control file (containing user options).

3. When the printer becomes available, the main lpd spawns a child lpd to handle the print job.

4. The child lpd executes the appropriate filter(s) (as specified in the if attribute in /etc/printcap) for this job and sends the resulting data on to the printer.

The lp system was originally designed when most printers were line printers - that is, people mostly printed plain ascii. By placing all sorts of magic in the if filter, modern printing needs can be met with lpd (well, more or less; many other systems do a better job).

There are many programs useful for writing LPD filters. Among them are:

8.1. Configuring PDQ

PDQ can be configured by either the superuser or by a joeuser. Root's changes are made to /etc/printrc, and affect everyone, while joeuser can only modify his personal .printrc. Everything applies to both types of configuration.

If PDQ is not available prepackaged for your distribution, you should obtain the source distribution from the PDQ web page and compile it yourself. It is an easy compile, but you must first be sure to have installed the various GTK development library packages, the C library development package, the gcc compiler, make, and possibly a few other development things.

8.2. Configuring LPD

Most Linux systems ship with LPD. This section describes a very basic setup for LPD; further sections detail the creation of complex filters and network configuration.