1.1. Terminology

I try to use consistent terminology throughout this document, so that users of all free Unix-like systems, and even users of non-Unix-like free software, can benefit. Unfortunately, there are many handy ambiguous names and many awkward unambiguous names, so just to be clear, here's a quick glossary of what each name means:

1.2. History

This have been severel generations of the Printing HOWTO. The history of the PHT may be chronicled thusly:

1. Grant Taylor wrote the printing HOWTO in 1992 in response to all the 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>; Grant Taylor continued to co-author the PHT for two years or so. At some point he 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 incorporated 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, Grand found out about the PDQ print "spooler". PDQ provides a printing mechanism so much better than lpd ever did that he 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, Grant moved his printing website to www.linuxprinting.org, and began offering more powerful configuration tools there. He also converted the HOWTO to DocBook, and initiated coverage of CUPS, LPRng, and GPR/libppd.

6. In early 2001, Grant began using the GNU Free Documentation License, which seems quite suitable. He also began an effort to clarify what is and isn't Linux-specific; there are several free Unixlike kernels out there, and they all use the same printing software.

7. In early 2003, after listening to a presentation from Till Kampeter at FOSDEM, I (Dirk) decided to update this HOWTO. Since Grant last edited the HOWTO, CUPS has gotten more mature and a lot more popular.

1.3. Copyright

Copyright (c) 1992-2001 Grant Taylor.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in Appendix A.

2.1. Where to Get Help

The Usenet newsgroups comp.os.linux.hardware, comp.os.linux.setup, and comp.periphs.printers all have a share of general printing questions. These are well-trafficked newsgroups where an answer is sure to be found; check in the Google Groups archives, too. There are also the linuxprinting.foo newsgroups; these are available both as web-based forums and via NNTP; see the website.

Please also poke around the web looking for your answers. LinuxPrinting.org is an excellent place to start; other websites and projects are linked to from there.

If you need more help, please try newsgroups, mailing lists, your distribution's support line, and so forth. If do want to contact me, please do so via the discussion forums on LinuxPrinting.org; this will give others a chance to respond, and will archive your problem and any solution publicly for the next hapless user.

3.1. With BSD 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.

lpr /etc/hosts
lpr -J "my hosts file" /etc/hosts
lpr -P mylaserjet /etc/services

3.2. With System V LPD and the lp command

There are two sets of commands that you may encounter if you have to deal with several brands of Unix. The BSD based LPD print system (*BSD, Linux) uses lpr (print),lpq (display queue),lprm (remove jobs). System V based systems on the other hand use lp (print), lpstat (display queue), cancel (remove jobs). Solaris, SCO and others are System V Unix systems.

On SYSV systems, you can of course consult the man page of the lp command. To specify a queue you use the -d option and a filename to print a file, or nothing to print from stdin.

lp /etc/hosts
lp -d mylaserjet /etc/services

3.3. With CUPS

CUPS provides both the System V and Berkeley command-line interfaces. This means that you can use either lpr or lp to print. This is really nice if you have a bunch of scripts that already use eg. lp or you have prior experience with either a System V or a BSD flavor.

3.4. 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 areio=port0,port1,port2 and irq=irq0,irq1,irq2. Read the man page forinsmod for more information on this.

**For those of you who 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" command-line 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

5.1. Postscript

As for what printers do work with free software, the best choice is to buy a printer with native PostScript support in firmware. Nearly all Un*x 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.

Un*x 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 GNU/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 GNU/Linux (if 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?

You can look in several places to see if a particular printer will work. The cooperatively maintained Printing HOWTO printer database aims to be a comprehensive listing of the state of GNU/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.

The best bet for new printer shoppers is to consult the list of suggested printers. These center around color inkjets and mono laser devices. You can even help support this document and the website by buying from one of affiliated vendors.

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

Google groups 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.

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

CUPS has become the standard printing system in most distributions today. What makes CUPS different from the rest ? CUPS is an implementation of the Internet Printing Protocol (IPP), a new standard intended to solve some of the deficiencies of the old LPD protocol. CUPS also supports LPD, SMB and AppSocket (JetDirect) with reduced functionality. The implementation of CUPS has been driven by Michael Sweet of Easy Software Products; CUPS is distributed under the GPL. Being a new protocol, the IPP has a number of advantages on the ancient LPD protocol:

• the scheduler is a HTTP 1.1 web server and also delivers a web interface

• printer options, you can even ask the IPP device what options and document formats it supports.

• access control which restricts print jobs, job controls, and system administration commands coming from and to specified computers and printers. Like Apache, you can control access to CUPS using Allow and Deny directives.

• proxy support (since IPP uses HTTP)

• encryption support

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.

There are several sets of PPDs 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.4.2.

6.2. 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. LPRng is essentially an enhanced LPD implementation with better security and extra features.

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, GNUlpr offers one with a few minor modifications that make the user interface much more flexible. The GNUlpr 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.

If you go with LPD, the best way to use it is via a front-end. There are several to chose from; KDEPrint, GPR (see Section 3.4) and XPP are perhaps the best. Others exist; tell me about them.

6.3. LPRng

Some GNU/Linux vendors 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. LPRng uses more or less the same basic filter model as does BSD lpd, so the LPD support offered by the linuxprinting.org 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.

PPR was written by, and is in use at, Trinity College. The license is BSD-style; free for all use but credit is due.

6.5. Others

7.1. CUPS

To print a job with CUPS, you can use both the BSD (see Section 5.3.1) and System V commands making it really easy for people with prior experience with either system.

Initially CUPS lacked an LPD backend. This was of course quickly added. Currently there are backends available for at least IPP, LPD, SMB, JetDirect, USB, Netatalk, parallel and serial printers. You may find others on the net or write your own.

There are only a handfull of built-in drivers, allowing you to print with most printers but probably not at the maximum resolution. A PPD file for a Postscript driver can be added to CUPS but if you want to print at best quality with your fancy new HP Deskjet you are out of luck. It is here that Foomatic comes to the rescue. You can use Foomatic in combination with CUPS. Foomatic uses a CUPS filter called foomatic-rip to do its magic. foomatic-rip uses PPD files to describe printer capabilities, even for non-Postscript printers. CUPS + Foomatic is currently the recommended printing system. Some Linux distributions already use it and the number that do will only grow.

The CUPS scheduler does not only accept jobs, it is also a administrative webinterface. Currently you can add/delete printers, cancel jobs, start/stop printers. Moving jobs will be available in a later release.

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 CUPS

If you are using a client with CUPS and a CUPS server has already been configured, installing the printers on your client can not get much easier than this: do nothing. Through broadcasting, the client should find the CUPS server and automatically configure the printers that are installed on that print server. This is one of the features of CUPS that will be really appreciated on large networks.

Manually configuring printers with CUPS, also is a peace of cake. If you are new to CUPS and/or Unix printing, the way to go is probably the web interface. If you have to configure lots of printers, using the command-line will probably be faster.

The URL to access the CUPS web interface is http://hostname:631/admin by default. The port can be changed in cupsd.conf if necessary.

To add a printer from the command-line the general syntax is lpadmin -p printer -E -v device -m ppd Lpadmin with the -p option adds or modifies a printer. The printers are saved in the file The -x option deletes the named printer. Read the lpadmin man page for available options.

/usr/sbin/lpadmin -p testpr1 -E -v socket://192.168.1.9 -m deskjet.ppd
/usr/sbin/lpadmin -p testpr2 -E -v parallel:/dev/lp0 -m laserjet.ppd
/usr/sbin/lpadmin -x testpr1

More information about configuring printers and options can be found in the CUPS documentation. The Software Administrators Manual will teach you all you need to know about configuring printers with CUPS.

8.2. Configuring LPD

Until recently most GNU/Linux distributions shipped with LPD. This section describes a very basic setup for LPD; further sections detail the creation of complex filters and network configuration.

---

8.2.2. LPD for PostScript Printers

While most versions of LPD don't gracefully handle PostScript (never mind user options), VA Linux modified LPD and Red Hat's filtering software to support PostScript printers fairly well. Because the intention was to donate the code to the gnu project, they called it GNUlpr

---

8.2.2.1. How it works

VA's system uses Postscript Printer Definition, or PPD, files. PPD files are provided by printer manufacturers and declare the available options on a printer, along with the Postscript code needed to activate them. With the VA system, the normal LPD scheme works a little differently:

1. The user can specify options with the -o flag. For example, you might specify -o MediaType:Transparency if you were about to print on overhead film. Alternatively, the front-end GPR can be used to specify options in a dialog box; you can see screenshots of GPR in Section 3.4.3.

2. LPR passes the options to LPD as an extended attribute in the LPD control file.

3. A modified version of the rhs-printfilters package is given the extended options data in an environment variable, and uses ppdfilt to add these options to the print data.

---

8.2.2.2. Obtaining and Installing

You can obtain RPM packages, or source tarballs, from the project's website on SourceForge. For installation details, consult the project's installation micro-HOWTO. In essence, you need to uninstall the Red Hat version of printtool, lpd, and rhs-printfilters entirely, and then install the VA versions, plus ppdfilt, gpr, and a few other utilities.

You will also need PPD files for your Postscript printers. PPD files are usually fairly easy to find. VA Linux and HP distribute PPD files for many Laserjet models. Other vendors provide PPDs for their own printers, and Adobe distributes PPD files for many printers.

At the moment, much of this is a bit difficult to install. But future installation tools will build upon the printer configuration library libprinterconf, which enables both the autodetection and rhs-printfilter configuration of both networked and local printers.

It is possible to use GPR alone, without the modified LPD or even rhs-printfilters. GPR can be compiled with all the logic needed to massage Postscript jobs directly. This may be an easier-to-install option suitable for people who never really need to print using lpr directly.

---

8.2.2.3. Controlling Postscript Options

Once you've setup VA's Postscript-capable LPD system (GNUlpr), you can control your printer's options in two ways:

With the GUI

To use GPR, you first make sure that you've specified the proper PPD file. Then the printer's options will be available on the `Advanced' panel. Basic ppdfilt options will be available on the `Common' panel.

With the command line

This lpr supports the -o option. You may specify any option/value pair from your printer's PPD file with -o. For example, consider this PPD file option clause:

*OpenUI *PrintQuality/Print Quality: PickOne *DefaultPrintQuality: None *OrderDependency: 150 AnySetup *PrintQuality *PrintQuality None/Printer Setting: "" *PrintQuality Quick/QuickPrint: "<< /DeviceRenderingInfo ... *PrintQuality Normal/Normal: "<< /DeviceRenderingInfo << /... *PrintQuality Pres/Presentation: "<< /DeviceRenderingInfo ... *PrintQuality Image/1200 Image Quality: "<< /DeviceRenderi... *CloseUI: *PrintQuality

For the option PrintQuality, the possible values are Quick, Normal,Pres, or Image. You might give a command like:

% lpr -o PrintQuality:Image file.ps

There are a number of options common to all printers which will work in addition to the ones from your PPD. These include:

page-ranges

You can specify a range of pages to print. For example,page-ranges:2-3.

page-set

You can print only odd or even pages. For example,page-set:odd.

number-up

You can print multiple pages on each piece of paper. For example, number-up:2.

Other options are detailed in the ppdfilt man page.

8.3. Large Installations

Large installations, by which I mean networks including more than two printers or hosts, have special needs. Below are some tips.

CUPS has some nice features that make a good choice for a large network. Printer classes, access control and automatic client configuration to name a few.

If you use LPD, for really large environments, merely distributing printcap/filter information becomes a difficult problem; the Cisco Enterprise Print System addresses this and is probably either a good starting point or a nearly complete solution, depending on your needs. Medium to large environments can be well supported by native LPRng features.

• Each printer should have a single point of control, where an administrator can pause, reorder, or redirect the queue. To implement this, have everyone printing to a local server, which will then queue jobs and direct them to the proper printer. For large campuses or distributed networks, have one server per building or other suitable network subset.

• Use CUPS or LPRng, at least on servers; the BSD LPD is too buggy for "real" use. But don't take my word for it—you should test a number of spoolers and see which suits you best.

• Client systems should not have unique printing configurations. CUPS provides automatic client configuration of printers on the same subnet. You can even configure CUPS (BrowsePoll) to poll servers on other subnets for available printers. These features limit the amount of configuration that needs to take place at the client. To implement a uniform printing configuration with LPRng, use LPRng's extended printcap syntax so that you have one printcap to use everywhere. CEPS provides for this by building atop a lightweight distributed database instead of traditional printcap files.

• Print queues should not be named for make or model; name print queues for something sensible like location (floor2_nw) or capability (color_transparency). Three years from now, when a printer breaks, you will be able to replace it with a different make or model without causing confusion.

• Operate a web page which shows detailed information on each printer, including location, capabilities, etc. Consider having it show the queue and include a button to remove jobs from the queue. Complex networked environments are unmanageable for users without proper documentation.

• On Windows and Apple systems, use either the platform-specific drivers everywhere (Samba supports the Windows automagical driver-download mechanism) or, better, use generic Postscript drivers everywhere. Do not mix and match; primitive word processors often produce different output when the installed printer driver changes; users cannot deal with output that varies depending on the particular client/printer pair.

• If at all possible, buy a large-volume printer for large-volume printing. If on a budget, use LPRng's multiple printers/one queue facility or CUPS printer classes and assign a babysitter; printers are complex mechanical devices that will often jam and run out of paper in such configurations.

• Do not feel that printers must be plugged into workstations; Ethernet "print servers" now cost under $100. The ability to locate printers anywhere you can network is a big improvement over forced location near a host; locate printers in sensible, central locations.

• Use any SNMP trap or other monitoring/alert facility available to you - someone should be tasked with running around and fixing printers with no ink or paper. Npadmin (see Section 11.10.1) can be used to do some management operations with SNMP printers.

8.4. Accounting

Regular LPD provides very little to help you with accounting. You can specify the name of an accounting file in the af printcap attribute, but this is merely passed as an argument to your if filter. It's up to you to make your if filter write entries to the accounting file, and up to you to process the accounting file later (the traditional format is mainly useful for line printers, and is nontrivial to parse in Perl, so there's no reason to preserve it). Also, if you're using foomatic-rip program as your filter, you'll need to make changes, since it depends on being given a configuration file as the ``accounting'' file name.

CUPS provides page accounting by passing jobs through the pstops filter. This filter expects Postscript input. If you use print "raw" jobs, this is always counted as 1 page. This means that accounting will not work, if you print from Windows client with the native printer driver.

Ghostscript provides a PageCount operator that you can use to count the number of pages in each job; basically you just tack a few lines of postscript onto the end of the job to write an accounting file entry; for the best example of this see the fileunix-lpr.sh in the Ghostscript source distribution.

Note that the unix-lpr implementation of accounting writes to a file from the Ghostscript interpreter, and is thus incompatible with the recommended -dSAFER option. A better solution might be to query the printer with a PJL command after each job, or to write a postscript snippet that prints the pagecount on stdout, where it can be captured without having to write to a file.

The LPRng print spooler includes an HP-specific sample implementation of accounting; I assume that it queries the printer with PJL. This technique should work for most PJL, Postscript, or SNMP printers with which you have two-way communications.

If you have a networked printer that supports SNMP, you can use the npadmin program to query a pagecount after each job. This should work properly for all print jobs. See Section 11.10.1 for more information on npadmin.

9.1. Red Hat

Red Hat has a GUI printer administration tool called printtool which can add remote printers and printers on local devices. It lets you choose a ghostscript-supported printer type and Unix device file to print to, then installs a print queue in/etc/printcap and uses a filter program from the rhs-printfilters package to support postscript and other common input types. This solution works fairly well, and is trivial to setup for common cases.

Red Hat 6.x shipped a BSD LPD flavor; Red Hat 7.x and 8.0 appear to default to using LPRng.

Where Red Hat 6.x and 7.x fail is when you have a printer which isn't supported by their standard Ghostscript (which is GNU rather than Aladdin Ghostscript, and which supports fewer printers). Check in the printer compatibility list above (or online) if you find that you can't print properly with the stock Red Hat software. If your printer isn't supported by Red Hat's tools, you may need to install a contributed venison of Aladdin Ghostscript, and will probably also be better off if you use the lpdomatic or apsfilter packages, which know all about the printers supported by late-model Ghostscripts, and others besides.

Red Hat 8.0 still installs LPRng by default although you can select CUPS. But even if you explicitly select only CUPS, LPRng is still installed. In Red Hat 8.1 CUPS will finally be the default spooler.

Red Hat 9.0 finally uses CUPS as default spooler.

9.2. Debian

Debian offers a choice between plain LPD, LPRng, or CUPS; LPRng or CUPS are probably the better choices. PDQ is provided in the unstable tree (currently called sid). Debian also offers a choice of printer configuration tools; apsfilter version 5 or later is probably your best bet, since that venison adds support for LPRng and Ghostscript's uniprint driver scheme. Red Hat's printtool is also supported, for those who like GUI administration tools.

9.3. SuSE

The printing system on SuSE Linux is based on apsfilter, with some enhancements; SuSE's apsfilter will recognize all common file formats (including HTML, if html2ps is installed). There are two ways to setup printers on SuSE systems:

• YaST will let you configure "PostScript", "DeskJet" and "Other printers", supported by Ghostscript drivers; it's also possible to setup HP's GDI printers (DeskJet 710/720, 820, 1000, via the "ppa" package). YaST will provide/etc/printcap entries for every printer ("raw", "ascii", "auto" and "color", if the printer to configure is a color printer). YaST will create spool directories and it will arrange apsfilterrc files, where you're able to fine tune some settings (Ghostscript preloads, paper size, paper orientation, resolution, printer escape sequences, etc.). With YaST it's also possible to setup network printers (TCP/IP, Samba, or Novell Netware Printer).

• In addition SuSE includes the regular SETUP program from the original apsfilter package (with some enhancements); runlprsetup to invoke this configuration script. Once you get accustomed to its GUI, you'll be able to configure local and network printers.

The SuSE installation manual explains both of these setup procedures.

Wolf Rogner reported some difficulties with SuSE. Apparently the following bugs may bite:

• Apsfilter's regular SETUP script is a bit broken, as are the KDE setup tools. Use YaST. [ Ed: does this still apply? It's been some time Wolf's report. ]

• For networked printers that need to be fed from Ghostscript, you'll need to first uncomment the line REMOTE_PRINTER="remote" in /etc/apsfilterrc. Then run YaST to configure the printer and, under Network configurations, set up a remote printer queue.

• YaST's setup doesn't allow color laser printers, so configure a mono printer and then change mono to color everywhere in the printcap entry. You may have to rename the spool directory, too.

9.4. Caldera

Caldera ships LPRng. I have no idea what sort of setup tools they offer.

I've just signed up a Caldera employee as a maintainer of the LinuxPrinting.org database; evidently they plan to ship a CUPS and Foomatic-based print system in future releases.

9.5. Corel

Corel is Debian-based, so all the Debian facts above should still apply. In addition, they've written their own setup tool, based on the sysAPS library which in turn uses my database. They've certainly done so as part of WordPerfect.

Corel operates a printing support newsgroup named corelsupport.linux.printing. The bulk of the traffic appears to be WordPerfect and Corel Linux related.

9.6. Mandrake

As of version 7.2b1, Mandrake ships with CUPS standard. The program QtCUPS is used to provide a clean GUI administration interface. Till went to some trouble to include as many drivers as possible, and they ship CUPS PPD files build with my own foomatic interface code. Mandrake was the first distro to ship CUPS.

I think Earlier Mandrake versions shipped with the Red Hat printtool.

9.7. Slackware

Slackware ships with APS Filter. The apsfilter SETUP script is installed as the command `apsfilterconfig'. You should be able to get a reasonable setup by simply running that.

As of Slackware 9.0, CUPS is included in the extras dir of slackware but the default is still LPRng + APSFilter.

9.8. Other Distributions

Please send me info on what other distributions do!

10.1. Invoking Ghostscript

Typically, Ghostscript will be run by whatever filter you settle upon (I recommend Foomatic if your vendor didn't supply anything that suits you), but for debugging purposes it is often handy to run it directly.

gs -helpwill give a brief listing of options and available drivers (note that this list is the list of drivers compiled in, not the master list of all available drivers).

You might run gs for testing purposes like: `gs <options> -q -dSAFER -sOutputFile=/dev/lp1 test.ps'.

10.2. Ghostscript output tuning

There are a number of things one can do if Ghostscript's output is not satisfactory (actually, you can do anything you darn well please, since you have the source).

Some of these options, and others are described in the Ghostscript User Guide (the file Use.htm in the Ghostscript distribution; possibly installed under /usr/doc or/usr/share/doc on your system) are all excellent candidates for driver options in your filter system.

11.1. Printing to a Unix/lpd host

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 thathosts.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 using the rs attribute; read the lpd man page for information on this.

11.2. Printing to a Windows or Samba printer

There is a Printing to Windows mini-HOWTO out there which has more info than there is here.

11.3. Printing to a NetWare Printer

The ncpfs suite includes a utility called nprint which provides the same functionality as smbprint but for NetWare. You can get ncpfs from Metalab. From the LSM entry for version 0.16:

"With ncpfs you can mount volumes of your NetWare server under Linux. You can also print to NetWare print queues and spool NetWare print queues to the Un*x print spooler. You need kernel 1.2.x or 1.3.54 and above. ncpfs does NOT work with any 1.3.x kernel below 1.3.54."

11.4. Printing to an EtherTalk (Apple) printer

The netatalk package includes something like nprint and smbclient. Others have documented the procedure for printing to and from an Apple network far better than I ever will; see the Linux Netatalk-HOWTO.

11.5. Printing to a networked printer

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:

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.

Note that the ISS company has identified an assortment of denial of service attacks which hang HP Jetdirect interfaces. Most of these have been addressed beginning in Fall 98. These sorts of problems are common in embedded code; few appliance-style devices should be exposed to general Internet traffic.

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 GNU/Linux box to act as a spool server for the printer so that your network users can complete their print jobs quickly and get on with things without waiting for the printer to print any other job that someone else has sent. This is suggested too if you have unfixable older HP Jetdirects; it reduces the likelihood of the printers wedging.

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

The full range of settings can be controlled with HP's webJetAdmin software. This package runs as a daemon, and accepts http requests on a designated port. It serves up forms and Java applets which can control HP printers on the network. In theory, it can also control Unix print queues, but it does so using the rexec service, which is completely unsecure. I don't advise using that feature.

11.6. Running an if for remote printers with old LPDs

One oddity of older versions of lpd is that the if is not run for remote printers. (Versions after 0.43 or so have the change originated on FreeBSD such that the if is always run). If you find that you need to run anif for a remote printer, and it isn't working with your lpr, you can do so by setting up a double queue and requeueing the job. As an example, consider thisprintcap:

lj-5:\ :lp=/dev/null:sh:\ :sd=/var/spool/lpd/lj-5:\ :if=/usr/lib/lpd/filter-lj-5: lj-5-remote:sh:rm=printer.name.com:\ :rp=raw:sd=/var/spool/lpd/lj-5-raw:

in light of this filter-lj-5 script:

#!/bin/sh gs <options> -q -dSAFER -sOutputFile=- - | \ lpr -Plj-5-remote -U$5

The -U option to lpr only works if lpr is run as daemon, and it sets the submitter's name for the job in the resubmitted queue correctly. You should probably use a more robust method of getting the username, since in some cases it is not argument 5. See the man page for printcap.

11.7. From Windows.

Printing from a Windows (or presumably, OS/2) client to a Un*x server is directly supported over SMB through the use of the SAMBA package, which also supports file sharing of your Un*x filesystem to Windows clients.

Samba includes fairly complete documentation, and there is a good Samba FAQ which covers it, too. You can either configure a magic filter on the Un*x box and print PostScript to it, or run around installing printer-specific drivers on all the Windows machines and having a queue for them with no filters at all. Relying on the Windows drivers may in some cases produce better output, but is a bit more of an administrative hassle if there are many Windows boxes. So try Postscript first. Modern versions of Samba should support the automagical driver download mechanism offered by Windows NT servers to deal with this problem.

11.8. From an Apple.

Netatalk supports printing from Apple clients over EtherTalk. See the Netatalk HOWTO Page for more information.

Really, though, any modern Mac can print over TCP/IP using the LPD protocol just fine. UVa provides a very nice support page detailing how to set this up.

11.9. From Netware.

The ncpfs package includes a daemon named pserver which can be used to provide service to a NetWare print queue. From what I understand, this system requires a Bindery-based NetWare, eg 2.x, 3.x, or 4.x with bindery access enabled.

For more information on ncpfs and it's pserver program, see the ncpfs FTP site.

11.10. Networked Printer Administration

Most networked printers support some method of remote administration. Often there are easy-to-use web pages for configuration. More usefully, there is often support for SNMP management. Typically you can find out interesting information on printer status like ink and paper levels, print volumes, and so forth, and you can usually change certain settings. SNMP printer control, and a number of other printing-related things, are being standardized by the IEEE's Printer Working Group

12.1. The Ghostscript Windows redirector

There is now a Ghostscript printer driver available (called mswinpr2) that will print using Windows GDI calls. There is also a port redirection tool called redmon which will run a print job through Ghostscript before finally printing it. (Rather like an if filter in Unix's LPD). Taken all together, this allows a Windows machine to print PostScript to a Windows-only printer through the vendor's driver.

If you have a host-based printer that can't be used directly, you can export it as a "Postscript" printer by using redmon, Ghostscript, and mswinpr2 on a Windows PC and print through the vendor's drivers.

12.2. HP Winprinters

Some HP printers use "Printing Performance Architecture" (marketing speak for "we were too cheap to implement PCL"). This is supported in a roundabout way via the pbm2ppa translator written by Tim Norman. Basically, you use ghostscript to render PostScript into a bitmapped image in pbm format and then use pbm2ppa to translate this into a printer-specific ppa format bitmap ready to be dumped to the printer. This program may also come in ghostscript driver format by now.

The ppa software can be had from the ppa home page; pbm2ppa supports some models of the HP 720, 820, and 1000; read the documentation that comes with the package for more details on ppa printer support.

12.3. Lexmark Winprinters

Most of the cheap Lexmark inkjets use a proprietary language and are therefore Winprinters. However, Henryk Paluch has written a program which can print on a Lexmark 7000. Hopefully he'll be able to figure out color and expand support to other Lexmark inkjets. See here for more info.

Similarly, there are now drivers for the 5700, 1000, 1100, 2070, 3200, and others. See the supported printers listing above, and my web site, for more information on obtaining these drivers.

13.1. Using a faxmodem

There are a number of fax programs out there that will let you fax and receive documents. One of the most powerful is Sam Leffler's HylaFAX. It supports all sorts of things from multiple modems to broadcasting.

SuSE ships a Java HylaFax client which allegedly works on any Java platform (including Windows and GNU/Linux). There are also non-Java fax clients for most platforms; GNU/Linux can almost certainly handle your network faxing needs.

Also available, and a better choice for smaller installations, is efax, a simple program which sends and receives faxes. The getty program mgetty can receive faxes using efax (and do voicemail or interactive logins).

13.2. Using the Remote Printing Service

There is an experimental service offered that lets you send an email message containing something you'd like printed such that it will appear on a fax machine elsewhere. Nice formats like postscript are supported, so even though global coverage is spotty, this can still be a very useful service. For more information on printing via the remote printing service, see the Remote Printing WWW Site.

13.3. Commercial Faxing Services

A number of companies operate web-based faxing services. EFax, in particular, offers free inbound faxes (to your own dedicated fax number, no less) via email, and fax transmission for a fee. Other companies offer similar services.

14.1. Markup languages

Most markup languages are more suitable for large or repetitive projects, where you want the computer to control the layout of the text to make things uniform.

14.2. WYSIWYG Word Processors

There is no shortage of WYSIWYG word processing software. Several complete office suites are available, including one that's free for personal use (StarOffice).

Other vendors should feel free to drop me a line with your offerings.

15.1. Ghostscript and Photos

Ghostscript has some difficulties rendering color photographs through most drivers. The problems are several:

• Many drivers have poorly tuned color support. Often the colors don't match the Windows driver output or the screen. OTOH, all drivers, and Ghostscript as a whole, have readily adjustable color support; the "Gamma" settings (seeSection 10.2.2) are one thing to play with, and there are others documented in Ghostscript'sUse.htm documentation file.

• I'm only aware of one Ghostscript driver with support for 6 and 7 color printing; it's in beta at the moment and supports most Epson Stylus Photo models. It is rumored to produce better color than the Windows driver (!). The Ghostscript driver core itself provides no support for non CMYK or RGB colors; arguably, some work to put that there is needed.

• Ghostscript often ends up dithering coarsely, or generating printouts with artifacts like banding. The dithering can usually be corrected; see Section 10.2.3, and read the documentation for your driver.

That said, the obvious solution for now is to use non-Ghostscript software for printing photos, and indeed, such things do exist. The main contender is the print plugin in the Gimp, which supports pixel-for-pixel printing on Epson Styluses and Postscript printers (with basic PPD support). That Epson Stylus portion of that driver is available for Ghostcript, as well, as thestp driver. Also possible to use for this purpose are the assorted external pnm-to-foo programs used to print on printers like the cheap Lexmarks; these print attempt to print pixmaps pixel-for-pixel.

The best solution, of course, is to buy a Postscript printer; such printers can usually be completely controlled from available free software, and will print to the full capability of the printer.

15.2. Paper

Color inkjets are extremely dependent on the paper for good output. The expensive glossy coated inkjet papers will allow you to produce near-photographic output, while plain uncoated paper will often produce muddy colors and fuzzy details. Non-glossy coated inkjet papers will produce results in between, and are probably best for final prints of text, as well. Stiffer glossy coated "photo" papers will produce similar output to lighter-weight glossy papers, but will feel like a regular photo.

15.3. Printer Settings

For photo output on most color inkjets, you should use the most highly interlaced (and slowest) print mode; otherwise solid regions may have banding or weak colors. Generally with Ghostscript this is what will happen when you pick the highest resolution. With Postscript printers, you may need to add a snippet to the prologue based on the settings available in the PPD file. The Gimp's PPD support doesn't include (printer-specific) print quality settings, but I added one in an ugly way for my own use; contact me if you'd like that. If you use PDQ or CUPS, you can easily control all the printer settings you need. VA Linux'slibppd and the GPR front-end can also add these options for Postscript printers.

15.4. Print Durability

Color inkjet printouts usually fade after a few years, especially if exposed to lots of light and air; this is a function of the ink. Printers with ink-only consumables like the Epsons and Canons can buy archival inks, which are less prone to this problem. Newer printers often use pigment-based inks, which don't fade as much as the older dye-based ink did. No inkjet output is really particularly good for long-term archival use. Write the bits to a CD-R and store that instead.

15.5. Shareware and Commercial Software

There's a program called xwtools which supports photo printing with all the bells and whistles on an assortment of Epson, HP, and Canon printers. Unfortunately, it was written under NDA, so comes without source. Unless you use it for the Epson Stylus Color 300 on GNU/Linux x86, it costs E15 for personal use; commercial pricing is unknown.

The ESP Print Pro package from Easy Software supports some printers which might otherwise be unsupported. These drivers are not reported to be very well-tuned for photos, but they do work.

16.1. PostScript

Ghostscript has an X11 driver best used under the management of the PostScript previewer gv. The latest versions of these programs should be able to view PDF files, as well. Note that gv has replaced the older previewer "Ghostview"; the new user interface is much prettier and featureful that ghostview's plain old Athena GUI.

16.2. TeX dvi

TeX DeVice Independent files may be previewed under X11 withxdvi. Modern versions of xdvi call ghostscript to render PostScript specials.

A VT100 driver exists as well. It's called dgvt. Tmview works with GNU/Linux and svgalib, if that's all you can do.

16.3. Adobe PDF

Adobe's Acrobat Reader is available for GNU/Linux; just download it from the Adobe web site.

You can also use xpdf, which is free software, and I believegv supports viewing PDF files with gs under X11.

17.1. Setting up in printcap

Lpd provides five attributes which you can set in/etc/printcap to control all the settings of the serial port a printer is on. Read the printcap man page and note the meanings ofbr#, fc#,xc#, fs# andxs#. The last four of these attributes are bitmaps indicating the settings for use the port. Thebr# attribute is simply the baud rate, eg `br#9600'.

It is very easy to translate from stty settings to printcap flag settings. If you need to, see the man page for stty now.

Use stty to set up the printer port so that you can cat a file to it and have it print correctly. Here's what `stty -a' looks like for my printer port:

dina:/usr/users/andy/work/lpd/lpd# stty -a < /dev/ttyS2 speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; min = 1; time = 0; -parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl ixon -ixoff -iuclc -ixany -imaxbel -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke

The only changes between this and the way the port is initialized at bootup are -clocal, -crtscts, and ixon. Your port may well be different depending on how your printer does flow control.

You actually use stty in a somewhat odd way. Since stty operates on the terminal connected to it's standard input, you use it to manipulate a given serial port by using the `<' character as above.

Once you have your stty settings right, so that `cat file > /dev/ttyS2' (in my case) sends the file to the printer, look at the file /usr/src/linux/include/asm-i386/termbits.h. This contains a lot of #defines and a few structs (You may wish to cat this file to the printer (you do have that working, right?) and use it as scratch paper). Go to the section that starts out

/* c_cflag bit meaning */ #define CBAUD 0000017

This section lists the meaning of the fc# and fs# bits. You will notice that the names there (after the baud rates) match up with one of the lines of stty output. Didn't I say this was going to be easy?

Note which of those settings are preceded with a - in your stty output. Sum up all those numbers (they are octal). This represents the bits you want to clear, so the result is yourfc# capability. Of course, remember that you will be setting bits directly after you clear, so you can just use `fc#0177777' (I do).

Now do the same for those settings (listed in this section) which do not have a - before them in your stty output. In my example the important ones are CS8 (0000060), HUPCL (0002000), and CREAD (0000200). Also note the flags for your baud rate (mine is 0000015). Add those all up, and in my example you get 0002275. This goes in your fs# capability (`fs#02275' works fine in my example).

Do the same with set and clear for the next section of the include file, "c_lflag bits". In my case I didn't have to set anything, so I just use `xc#0157777' and `xs#0'.

17.2. Older serial printers that drop characters

Jon Luckey points out that some older serial printers with ten-cent serial interfaces and small buffersreally mean stop when they say so with flow control. He found that disabling the FIFO in his Linux box's 16550 serial port with setserial corrected the problem of dropped characters (you apparently just specify the UART type as an 8250 to do this).