The Printing HOWTO should contain everything you need to know to help you set up printing services on your GNU/Linux box(en). As life would have it, it's a bit more complicated than in the point-and-click world of Microsoft and Apple, but it's also a bit more flexible and certainly easier to administer for large LANs.
This document is structured so that most people will only need to read the first half or so. Most of the more obscure and situation-dependent information in here is in the last half, and can be easily located in the Table of Contents, whereas some information through section 10 or 11 is probably needed by most people.
If you find this document or the linuxprinting.org website useful, consider buying something (ink, for example) through the referral links on the site; such purchases support this effort.
The linuxprinting.org website is a good place to find the latest version; it is also, of course, distributed from tldp.org and your friendly local LDP mirror.
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:
Unix is an operating system constructed at Bell Labs by various researchers. A variety of operating systems, mostly commercial, are based on this code and are also included in the name Unix.
Un*x is an awkward word used to refer to every Unix-like operating system. A Unixlike operating system provides something similar to a POSIX programming interface as its native API. GNU/Linux, FreeBSD, Solaris, AIX, and even special-purpose systems like Lynx and QNX are all Un*x.
Linux is a Unixlike kernel and a small assortment of peripheral software written by Linus Torvalds and hundreds of other programmers. It forms the foundation of the most widely used Un*x operating system.
The GNU (GNU's Not Unix) project is a longtime development effort to produce an entirely free Unixlike operating system. The GNU Project is in many ways the father of most modern free software efforts.
A GNU/Linux operating system is a complete system comprised of the Linux kernel, its peripheral programs, and the GNU runtime environment of libraries, utilities, end-user software, etc. Red Hat, Debian, Caldera, SuSE, TurboLinux, and similar companies are all commercial vendors of complete GNU/Linux systems.
This have been severel generations of the Printing HOWTO. The history of the PHT may be chronicled thusly:
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.
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.
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 (!).
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.
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.
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.
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.
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.
The quickest way to get started is simply to use the setup tools provided by your vendor. Assuming that this includes support for your driver, and assuming that your vendor shipped the driver for your printer, then it should be easy to get a basic setup going this way. For information on vendor-provided setup tools, see Section 9.
If your vendor's tool doesn't work out, you should figure out if your printer is supposed to work at all. Consult the printer compatibility listings in Section 5.3.1 as well as the online version described there.
If your printer is known to work with a driver, check that you have that driver, and install if it not. Typically you will be able to find a contributed Ghostscript package including newer Ghostscript code and assorted third-party drivers. If not, you can compile it yourself; the process is not trivial, but it is well documented. See Section 10 for more information on Ghostscript.
After installing the proper driver, attempt again to configure your printer with your vendor's tools. If that fails, select a suitable third party tool from those described in Section 8. If that also fails, you'll need to construct your own setup; again see Section 8.
If you're still stuck, you've got a little troubleshooting to do. It's probably best to read most of this document first to get a feel for how things are supposed to work; then you'll be in a better position to debug.
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.
You actually use a different command to print depending on which spooling software you use.
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.
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.
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.
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.
KDEPrint allows users access to printing subsystems (CUPS, LPD, RLPR, LPRng etc.) through a KDE graphical user interface. With KDEPrint, you can easily print, administer jobs and printers and the printing daemon. KDEPrint is a replacement for the old QtCUPS and KUPS. It is easy to use for both developers and users. KDEPrint is already a part of KDE since 2.2.0 and has several nice features.
kprinter is the print dialog of KDEPrint which allows you to select the destination printer and change printer options. Among the destination printers, there are a few virtual printers allowing you to print to email, fax or pdf.
You can use KDEPrint's kprinter in any application that lets you configure your print command. Examples of these are Mozilla and OpenOffice.
KDEPrint also features a Print Preview. that you can select from the Print Dialog. This is accomplished by passing the print file through the filters which make it suitable for displaying on screen using KGhostView or an external application like gv.
The KDEPrint Job Viewer KJobViewer allows you to view, move and cancel print jobs.
You can find more information about KDEPrint at http://printing.kde.org/.
Another good choice for CUPS is the program XPP (see Figure 4). XPP is built from the FLTK library and is therefore desktop agnostic.
To print with XPP, simply run the xpp program, and specify a file (or nothing, if you're using xpp in place of lpr to print from stdin). Then select a printer from the list of configured printers, and select any options you'd like to apply from the various tabbed panels. See Figure 5 for an example options panel highlighting the standard CUPS options.
When used with Foomatic driver interface system, XPP will also let you control numeric parameters not normally supported by CUPS. This typically includes such things as extended color tuning, cartridge alignment, and so forth. See Figure 6 for an example of this.
You can save your selected printer and all the options with the `Save Settings' button.
GPR, by Thomas Hubbell, uses code from CUPS to filter Postscript jobs and offer easy user control over job options. Some options (like n-way printing, page selection, etc) are implemented directly by GPR, while most others are implemented by the printer or by the spooler's filter system.
GPR works with LPD or LPRng; or can be compiled specifically for use with GNUlpr. When compiled normally, it uses VA's libppd directly to produce printer-specific PostScript which it will then submit to the lpr command. When compiled for GNUlpr, it will submit your unmodified Postscript job to the lpr command, along with the set of job options you specify. This is arguably the better route, since it allows the Postscript to be redirected to a different printer by the spooler when appropriate; unfortunately it requires GNUlpr, which is not in wide circulation (although it is of course trivial to install).
To use GPR, first select a printer (by LPD queue name) and check that GPR has loaded the proper PPD file. If it hasn't, you'll need to specify the PPD filename, and specify your printer's options in the Printer Configuration dialog (you get this dialog by pressing the Printer Configuration button; it contains assorted printer setup options defined by the PPD).
Once you've configured your printer in GPR, you can print jobs by specifying the filename and selecting the proper options from the `Common' and `Advanced' tabbed panels. The `Common' options are implemented directly by GPR for all printers, while the `Advanced' options are defined by the PPD file for your printer. You can see these option panels in Figure 8 and Figure 9.
There are two completely different device drivers for the parallel port; which one you are using depends on your kernel version (which you can find out with the command uname -a). The driver changed in Linux 2.1.33; essentially all current systems will be running kernel 2.2 or later, so you'll probably want to skip ahead to the parport driver section.
A few details are the same for both styles of driver. Most notably, many people have found that Linux will not detect their parallel port unless they disable "Plug and Play" in their PC BIOS. (This is no surprise; the track record for PnP of non-PCI devices with Windows and elsewhere has been something of a disaster).
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.
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:
Some GNU/Linux distributions don't ship with a properly setup /etc/modules.conf (or /etc/conf.modules), so the driver isn't loaded properly when you need it to be. With a recent modutils, the proper magical lines from modules.conf seem to be:
alias /dev/printers lp # only for devfs? alias /dev/lp* lp # only for devfs? alias parport_lowlevel parport_pc # missing in Red Hat 6.0-6.1 |
Many PC BIOSes will make the parallel port into a Plug-and-Play device. This just adds needless complexity to a perfectly simple device that is nearly always present; turn off the PnP setting for your parallel port ("LPT1" in many BIOSes) if your parallel port isn't detected by the Linux driver. The correct setting is often called "legacy", "ISA", or "0x378", but probably not "disabled".
You can also read the parport documentation in your kernel sources, or look at the parport web site.
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.
Linux supports USB pretty well. USB should work with any late-model 2.2 kernel, and any 2.4 kernel or newer. Of course you need kernel support for USB, either linked in or through a module (recommended).
If you have a modular kernel, the following modules need to be loaded:
usb-core.o
usb-uhci.o or uhci.o or usb-ohci.o
printer.o
To get high speed transfers out of a USB 2.0 capable device you must attach it to an USB 2.0 controller and use the EHCI driver (ehci-hcd.o). A recent 2.4 kernel or higher is recommended if you want to use USB 2.0.
One thing to remember is that USB devices are dynamically allocated. A USB printer gets assigned a device file (/dev/usb/lp*) when it is turned on or connected. This could mean that print jobs are sent to the wrong printer because you turned them on in a certain order. CUPS uses special Uri's containing manufacturer, model and printer serial number to keep sending the jobs to the correct physical printer.
Although most USB printers work fine on Linux, there are exceptions. For example the new MF devices from Epson (Stylus CX3200/CX5200) return garbage when one polls the IEEE-1284 ID string via IOCTL, for example with the code of the CUPS "usb" backend. Whereas one can poll the ID string via an Epson-proprietary method.
Till Kamppeter has written some tools to retrieve the device ID string from USB printers. getusbprinterid.pl and usb_id_test.c are the same thing but respectively in Perl and C. As mentioned above, the new MF devices from Epson are an exception, but the "Epson proprietary method" is implemented in the ttink tool of the MTink package.
More documentation about USB is available at the Linux USB Website.
The Linux kernel will let you speak with any printer that you can plug into a serial, parallel, or usb port, plus any printer on the network. Unfortunately, this alone is insufficient; you must also be able to generate data that the printer will understand. Primary among the incompatible printers are those referred to as "Windows" or "GDI" printers. They are called this because all or part of the printer control language and the design details of the printing mechanism are not documented. Typically the vendor will provide a Windows driver and happily sell only to Windows users; this is why they are called Winprinters. In some cases the vendor also provides drivers for NT, OS/2, or other operating systems.
Many of these printers do not work with free software. A few of them do, and some of them only work a little bit (usually because someone has reverse engineered the details needed to write a driver). See the printer support list below for details on specific printers.
A few printers are in-between. Some of NEC's models, for example, implement a simple form of the standard printer language PCL that allows PCL-speaking software to print at up to 300dpi, but only NEC knows how to get the full 600dpi out of these printers.
Note that if you already have one of these Winprinters, there are roundabout ways to print to one, but they're rather awkward. SeeSection 12 in this document for more discussion of Windows-only printers.
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:
Postscript arrived as part of the Apple Laserwriter, a perfect companion to the Macintosh, the system largely responsible for the desktop publishing revolution of the 80s.
Postscript programs can be run to generate output on a pixel screen, a vector screen, a fax machine, or almost any sort of printer mechanism, without the original program needing to be changed. Postscript output will look the same on any Postscript device, at least within the limits of the device's capabilities. Before the creation of PDF, people exchanged complex documents online as Postscript files. The only reason this standard didn't "stick" was because Windows machines didn't usually include a Postscript previewer, so Adobe specified hyperlinks and compression for Postscript, called the result PDF, distributed previewers for it, and invented a market for their "distiller" tools (the functionality of which is also provided by ghostscript's ps2pdf and pdf2ps programs).
Postscript is a complete programming language; you can write software to do most anything in it. This is mostly useful for defining subroutines at the start of your program to reproduce complex things over and over throughout your document, like a logo or a big "DRAFT" in the background. But there's no reason you couldn't compute π in a Postscript program.
Postscript is fully specified in a publically available series of books (which you can find at any good bookstore) and also online at http://partners.adobe.com/asn/developer/technotes/postscript.html. Although Adobe invented it and provides the dominant commercial implementation, other vendors like Aladdin produce independently coded implementations as well.
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.
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.
This section is a summary of the online database. The online version includes device specifications, notes, driver information, user-maintained documentation, manufacturer web pages, and interface scripts for using drivers with several print spooling systems (including LPR, LPRng, PDQ, and CUPS). The online version of this list is also interactive; people can and do add printers all the time, so be sure to check it as well. Finally, if your printer isn't listed, add it!
Note that this listing is not gospel; people sometimes add incorrect information, which are eventually weeded out. Entries which have not been sanity-checked are marked with an asterisk (*). Verify from Google Groups that a printer works for someone before buying it based on this list.
Printers here are categorized into four types:
Perfect printers work perfectly - you can print to the full ability of the printer, including color, full resolution, etc. In a few cases printers with undocumented "resolution enhancement" modes that don't work are listed as perfect; generally the difference in print quality is small enough that it isn't worth worrying about.
You can print fine, but there may be minor limitations of one sort or another in either printing or other features.
You can print, but maybe not in color, or only at a poor resolution. See the online listing for information on the limitation.
You can't print a darned thing; typically this will be due to lack of a driver and/or documentation on how to write one. Paperweights occasionally get "promoted", either when someone discovers that an existing driver works, or when someone creates a new driver, but you shouldn't count on this happening.
And without further ado, here is the printer compatibility list:
Table 1. Linux Printer Support
Manufacturer | Perfectly | Mostly | Partially | Paperweight |
|---|---|---|---|---|
Alps | MD-1000 | |||
Anitech | M24 | |||
Apollo | P-1200 | |||
Apple | 12/640ps | Color StyleWriter 1500 | ||
Avery | Personal Label Printer+* | Personal Label Printer | ||
Brother | HL-4Ve | HJ-400 | DCP-1200 | 4550* |
CItoh | M8510 | |||
CalComp | Artisan 1023 penplotter* | |||
Canon | BJ-5 | BJC-50* | BJ F100* | BJC-5000* |
Citizen | ProJet II* | printiva700 | ||
Compaq | IJ750* | IJ900 | IJ300* | |
DEC | DECWriter 500i* | 1800* | ||
Daewoo | DP-3630H* | |||
Dymo-CoStar | ASCII 250* | |||
Epson | ActionLaser 1100* | EPL-5700 | 9-pin 136 Col* | AcuLaser C1000 |
Fujitsu | 1200* | |||
Generic | PostScript Printer | 9-pin 136 Col* | ||
GoldStar | GLP-1450* | |||
HP | 2000C | Color LaserJet 5 | C LaserJet 4500* | DeskJet 3320 |
Hansum | BJ-330H* | |||
Heidelberg | Digimaster 9110* | |||
Hitachi | DDP 70 (with MicroPress)* | |||
IBM | 3853 JetPrinter* | 4029 030 LaserPrinter 10* | ||
Imagen | ImPress* | |||
Infotec | 4651 MF* | |||
Jepcom | JP-B330* | |||
Kodak | DigiSource 9110* | |||
Kyocera | F-800T* | FS-3500* | F-800A/F-800* | |
LaserMaster | LM 1000 | |||
Lexmark | 4039 10plus | 1020 Business* | 1000 | Winwriter 100* |
Minolta | PagePro 6* | PagePro 8L* | PagePro 6L | |
Mitsubishi | CP50 Color Printer* | |||
NEC | MultiWriter* | SuperScript 100C* | SuperScript 610plus* | |
Oce | 3165* | |||
Okidata | ML 320 | DP 5000 | ML-184 Turbo* | Okijet 2010 |
Olivetti | JP350S* | JP450 | ||
Others | BJ-230* | |||
PCPI | 1030* | |||
Panasonic | KX-P1123* | KX-P2123* | KX-P1124i* | KX-P6100* |
Pentax | PocketJet 200 | |||
Printrex | 820 DL* | |||
QMS | 2425 Turbo EX* | ps-810* | magicolor 2 | |
Qnix | PICASSOI* | |||
Raven | LP-410 | |||
Ricoh | 4081* | Aficio 401* | Aficio Color 2206* | |
Sambo | PageJet P1* | |||
Samsung | ML-85* | ML-85G | MJ 630V* | ML-5050G* |
Seiko | SpeedJET 200* | SLP* | ||
Sharp | AR-161* | AJ-1800 | AJ-2100 | |
Sindo | ExecJet 4072* | |||
Sony | IJP-V100 | |||
Star | JJ-100* | LC 90* | LC 24-15 Multi-Font* | WinType 4000* |
Tally | MT908* | |||
Tektronix | 3693d color printer, 8-bit mode* | Phaser 350* | ||
Xerox | 2700 XES | Able 1406 | DocuPrint C8* | DocuPrint P8* |
It's a bit difficult to select a printer these days; there are many models to choose from. Here are some shopping tips:
You get what you pay for. Most printers under $200-300 can print reasonably well, but printing costs a lot per page. For some printers, it only takes one or two cartridges to add up to the cost of a new printer! This is specially true for cheap inkjets. Similarly, the cheapest printers won't last very long. The least expensive printers, for example, have a MTBF of about three months; obviously these are poorly suited for heavy use.
Inkjet printheads will clog irreparably over time, so the ability to replace the head somehow is a feature. Inkjet printheads are expensive, with integrated head/ink cartridges costing ten times (!) what ink-only cartridges go for, so the ability to replace the head only when needed is a feature. Epson Styluses tend to have fixed heads, and HP DeskJets tend to have heads integrated into the cartridges. Canons have three-part cartridges with independently replaceable ink tanks; I like this design. OTOH, the HP cartridges aren't enormously more expensive, and HP makes a better overall line; Canon is often the third choice from the print quality standpoint. Epson Styluses and HP inkjets are the best supported by free software at the moment.
Laser printers consume a drum and toner, plus a little toner wiping bar. The cheapest designs include toner and drum together in a big cartridge; these designs cost the most to run. The best designs for large volume take plain toner powder or at least separate toner cartridges and drums.
The best color photograph output is from continuous tone printers which use a silver halide plus lasers approach to produce—surprise!—actual photographs. Since these printers cost tens of thousands to buy, Ofoto.com offers inexpensive print-by-print jobs. The results are stunning; even the best inkjets don't compare.
The best affordable photo prints come from the dye-sublimation devices like some members of the Alps series (thermal transfer of dry ink or dye sublimation), or the few consumer-grade Sony photo printers. Unfortunately the Alps devices have poor free software support (the one report I have from a Alps user of the Ghostscript driver speaks of banding and grainy pictures), and even then it's unclear if the dye-sub option is supported. I have no idea if the Sonys work at all.
The more common photo-specialized inkjets usually feature 6 color CMYKcm printing or even a 7 color CMYKcmy process. All photo-specialized printers are expensive to run; either you always run out of blue and have to replace the whole cartridge, or the individual color refills for your high-end photo printer cost an arm and a leg. Special papers cost a bundle, too; you can expect top-quality photo inkjet output to run over a US dollar per page. See also the section on printing photographs later in this document, and the sections on color tuning (such as it is) in Ghostscript.
Lately color lasers have been getting a lot cheaper, these devices may be interesting for color reports. Color lasers are a lot cheaper per page than inkjets. However they may still not be suited for photographs. One day color lasers may become common and replace those boring monochrome laser printers.
Speed is proportional to processing power, bandwidth, and generally printer cost. The fastest printers will be networked Postscript printers with powerful internal processors. Consumer-grade printers will depend partly on Ghostscript's rendering speed, which you can affect by having a reasonably well-powered machine; full pages of color, in particular, can consume large amounts of host memory. As long as you actuallyhave that memory, things should work out fine.
If you want to print on multicopy forms, then you need an impact printer; many companies still make dot matrix printers, most of which emulate traditional Epson models and thus work fine.
There are two supported lines of label printer; look for the Dymo-Costar and the Seiko SLP models. Other models may or may not work. Avery also makes various sizes of stick-on labels in 8.5x11 format that you can run through a regular printer.
Big drafting formats are usually supported these days by monster inkjets; HP is a popular choice. Mid-sized (11x17) inkjets are also commonly used for smaller prints. Much plotting of this sort is done with the languages RTL, HP-GL, and HP-GL/2, all of which are simple HP proprietary vector languages usually generated directly by application software.
Until recently, the choice for free software users was simple - everyone ran the same old lpd lifted mostly verbatim out of BSD's Net-2 code. Even today, some vendors ship this software. But this is beginning to change. SVR4-like systems including Sun's Solaris come with a completely different print spooling package, centered around lpsched.
Today, there are a number of good systems to chose from. They are all described below; read the descriptions and make your own choice. CUPS is a good option and recommended for most users; it has excellent Postscript printer support, offers IPP support, a web interface, and a number of other features. For business environments with mainly networked Postscript printers, a front-end program like GPR with LPRng is another option; it handles PPD options directly and has a nice interface.
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 default CUPS installation contains generic PPDs for 9-pin and 24-pin Epson matrix printers, Epson Stylus Color, Stylus Photo printers, HP LaserJet, DeskJet printers and Dymo Label printers. These will enable you to print to a lot of printer models, but will not give you access to specific capacities of the models
Foomatic can generate a suitable PPD for use with any printer driver that has full details entered in the linuxprinting.org database. The PPD gets used together with a backend script named foomatic-rip. foomatic-rip uses free software drivers. At the moment there is support for a rather large number of printers in this system. Foomatic forms a basis for non-Postscript printer support in most GNU/Linux distributions. CUPS and Foomatic are becoming quite popular and this is currently the recommended printing system for most situations.
CUPS can use vendor-supplied PPD files for Postscript printers directly. Often these come with the Windows drivers for a printer, or can be found on the printer vendor's website. If you have a choice between a driver for Windows 9x and Windows NT/W2K, than select the driver for Windows NT. Adobe also distributes PPD files for many Postscript printers.
Easy Software Products, Inc. sells CUPS bundled with a collection of proprietary drivers. Although they are not free software, they do drive many common printers. The bundle is somewhat expensive measured against the price of a single supported printer, but it certainly has a place. The package includes graphical front-end tools.
The Gimp-Print drivers are high quality drivers for Canon, Epson, Lexmark, and PCL printers for use with Ghostscript, CUPS, Foomatic, and the Gimp.
Omni is a package made by IBM, now containing support for more than 450 printers. The OMNI printer driver model is distributed by IBM under LGPL License.
HPIJS supports around 150 of HP's own printers at excellent print quality now (currently only via the Foomatic path). As of Version 1.0.1 , the "hp Product Only" clause has been removed from the license and the drivers are distributed with a BSD license.
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.
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.
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.
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.
PDQ stands for "Print, Don't Queue", and the way it works reflects this design. 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.
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.
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.
There's a real place for PDQ; it has a simple design that doesn't subtract user control. And the normal control path crosses no security boundaries, so it can't have the classes of security bug people are always finding in other systems. And to top it off, it's small.
However there is no active development done on PDQ. A new maintainer would be most welcome.
GNUlpr began its life in some work that HP sponsored VA Linux to do. Unfortunately, GNUlpr is now pretty much dead.
The Coherent Printing System is a set of Perl scripts called "lpr", "lpd", "lprm", and "lpq". These replace the programs of the same name which come with many Linux systems.
The Cisco Enterprise Print System was developed by Damian Ivereigh when he was a sysadmin at Cisco. He did more than he was hired to do, he developed a new printing system to improve the administrative hassle. Cisco authorized the release of the software for free under the GNU General Public License. Installing CEPS will however only pay off at large organisations.
In order to get printing working well, you need to understand how your spooling software works. All systems work in essentially the same way, although the exact order might vary a bit, and some systems skip a step or two:
The user submits a job along with his selection of options. The job data is usually, but not always, Postscript.
The spooling system copies the job and the options over the network in the general direction of the printer.
The spooling system waits for the printer to be available.
The spooling system applies the user's selected options to the job, and translates the job data into the printer's native language, which is usually not Postscript. This step is called filtering; most of the work in setting things up lies in getting the proper filtering to happen.
The job is done. The spooling system will usually do assorted cleanup things at this point. If there was an error along the way, the spooler will usually notify the user somehow (for example, by email).
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.
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:
The spooling daemon. One of these runs to control everything on a machine, AND one is run per printer while the printer is printing.
The user spooling command. Lpr contacts lpd and injects a new print job into the spool.
Lists the jobs in a print queue.
The Lpd system control command. With lpc you can stop, start, reorder, etc, the print queues.
lprm removes a job from the print spool.
So how does it fit together? The following things happen:
At boot time, lpd is run. It waits for connections and manages printer queues.
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).
When the printer becomes available, the main lpd spawns a child lpd to handle the print job.
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:
Ghostscript is a host-based Postscript interpreter (aka a Raster Image Processor or RIP). It accepts Postscript and produces output in various printer languages or a number of graphics formats. Ghostscript is covered in Section 10.
ppdfilt is a standalone version of a CUPS component. It filters Postscript, executing a few basic transformations on it (n-up printing, multiple copies, etc) and adding in user option statements according to a Postscript Printer Definition (PPD) file usually included with Postscript printers.
ppdfilt is best used together with an option-accepting LPD system (like the GNUlpr, or LPRng) and a filter script which parses user-provided options into the equivalent ppdfilt command. VA Linux and HP provide a modified rhs-printfilters package which does exactly this; it produces nice results if you have a Postscript printer. See Section 8.2.2 for information on this system.
ps2ps is a utility script included with Ghostscript. It filters Postscript into more streamlined Postscript, possibly at a lower Language Level. This is useful if you have an older Postscript printer; most modern software produces modern Postscript.
mpage is a utility which accepts text or Postscript, and generates n-up output—that is, output with several page images on each piece of paper. There are actually several programs which do this, includingenscript, nenscript, anda2ps.
a2ps, aka any-to-ps, is a program which accepts a variety of file types and converts them to Postscript for printing.
For common configurations, you can probably ignore this section entirely - instead, you should jump straight to Section 9 below, or better yet, your vendor's documentation. Most GNU/Linux distributions supply one or more "idiot-proof" tools to do everything described here for common printers.
If your vendor's tool doesn't work out for you, or you'd like the ability to interactively control printing options when you print, then you should use some other system. APS Filter is another good system; it configures LPD queues and filters very easily on most any sort of Unix system.
You can also use the printing system interfaces from the linuxprinting.org website to connect many free drivers into several spooling systems. Once this project is complete, these interfaces will offer the best functionality: all styles of free software drivers are supported, user-settable options are available, and most common spooling systems are supported. Currently the foomatic print system is used in most modern distributions anyway. However, your distro may include a slightly outdated version of foomatic.
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.
Example 3. command-line examples
/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.
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.
The minimal setup for lpd results in a system that can queue files and print them. It will not pay any attention to whether or not your printer will understand them, and will probably not let you produce attractive output. But we have to start somewhere.
To add a print queue to lpd, you must add an entry in/etc/printcap, and make the new spool directory under /var/spool/lpd.
An entry in /etc/printcap looks like:
# LOCAL djet500
lp|dj|deskjet:\
:sd=/var/spool/lpd/dj:\
:mx#0:\
:lp=/dev/lp0:\
:sh:
|
Go now and read the man page for printcap.
The above looks very simple, but there a catch - unless I send in files a DeskJet 500 can understand, this DeskJet will print strange things. For example, sending an ordinary Unix text file to a deskjet results in literally interpreted newlines, and gets me:
This is line one. This is line two. This is line three. |
Clearly more is needed, and this is the purpose of filtering. The more observant of you who read the printcap man page might have noticed the spool attributes if andof. Well, if, or the input filter, is just what we need here.
If we write a small shell script called filter that adds carriage returns before newlines, the staircasing can be eliminated. So we have to add in an if line to our printcap entry above:
lp|dj|deskjet:\
:sd=/var/spool/lpd/dj:\
:mx#0:\
:lp=/dev/lp0:\
:if=/var/spool/lpd/dj/filter:\
:sh:
|
#!perl
# The above line should really have the whole path to perl
# This script must be executable: chmod 755 filter
while(<STDIN>){chomp $_; print "$_\r\n";};
# You might also want to end with a form feed: print "\f";
|
The only remaining problem is that printing plain text is really not too hot - surely it would be better to be able to print PostScript and other formatted or graphic types of output. Well, yes, it would, and it's easy to do. The method is simply an extension of the above linefeed-fixing filter.
Such a filter is called a magic filter. Don't bother writing one yourself unless you print strange things - there are a good many written for you already, and most have easy-to-use interactive configuration tools. You should simply select a suitable pre-written filter:
foomatic-rip is a filter designed to use data from the LinuxPrinting.org printer database. It supports essentially all free software printer drivers, including regular Ghostscript drivers, Uniprint drivers, and the assorted filter programs floating around out there. foomatic-rip works with CUPS, LPRng, LPD, GNUlpr, PPR, PDQ, no spooler.
apsfilter is a filter designed for use on a wide variety of Unices. It supports essentially all Ghostscript drivers. It, too, works with various strains of LPD, including stock BSD and LPRng.
RHS-Printfilters is a filter system constructed by Red Hat. It shipped beginning, I think, in version 4 of Red Hat Linux, as the backend to the easy-to-use printtool GUI printer configuration tool.
The rhs filter system is built on an ASCII database listing distributed with it. This listing supports many Ghostscript and Uniprint drivers, but not filter-style drivers. The filters constructed also do not support much in the way of user-controllable options at print time.
The printtool places a configuration file named postscript.cfg in the spool directory. Inside this Bourne shell-style file, each setting is a variable. In unusual cases, you can make useful changes directly to the config file which the printtool won't allow; typically this would be the specification of an unusual Ghostscript driver, or a PPD filename for the VA rhs-printfilters version.
VA Linux has made some enhancements to the rhs-printfilters system under contract from HP. With the proper versions, it is possible to select options for Postscript printers under control of Adobe PPD files. I cover this system inSection 8.2.2.
There's one catch to such filters: older version of lpd don't run the if filter for remote printers, while most newer ones do (although often with no arguments). The version of LPD shipped with modern GNU/Linux and FreeBSD distributions does; most commercial Unices that still ship LPD have a version that does not. See the section on network printing later in this document for more information on this. If you only have locally-connected printers, then this won't affect you.
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
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:
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.
LPR passes the options to LPD as an extended attribute in the LPD control file.
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.
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. |
Once you've setup VA's Postscript-capable LPD system (GNUlpr), you can control your printer's options in two ways:
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.
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 |
% 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:
You can specify a range of pages to print. For example,page-ranges:2-3.
You can print only odd or even pages. For example,page-set:odd.
You can print multiple pages on each piece of paper. For example, number-up:2.
By popular demand, I include below a listing of the permissions on interesting files on my system. There are a number of better ways to do this, ideally using only SGID binaries and not making everything SUID root, but this is how my system came out of the box, and it works for me. (Quite frankly, if your vendor can't even ship a working lpd you're in for a rough ride).
-r-sr-sr-x 1 root lp /usr/bin/lpr* -r-sr-sr-x 1 root lp /usr/bin/lprm* -rwxr--r-- 1 root root /usr/sbin/lpd* -r-xr-sr-x 1 root lp /usr/sbin/lpc* drwxrwxr-x 4 root lp /var/spool/lpd/ drwxr-xr-x 2 root lp /var/spool/lpd/lp/ |
Lpd must currently be run as root so that it can bind to the low-numbered lp service port. It should probably become UID lp.lp or something after binding, but I don't think it does. This is simply one more reason to avoid the stock BSD LPD.
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 bes