Printing de-mystified (was Re: To CUPS or not to CUPS)
steveb at creek-and-cowley.com
Thu Jul 10 21:56:26 PDT 2003
On Thu, 2003-07-03 at 19:09, Craig Colton wrote:
> Steve, it seem that you may have mixed quotes from Jeroen and I.
Yes, I noticed that right after I sent that last message. I am sorry
> The other is that, although I have some knowledge of printing, I don't
> consider myself an expert, so I may not be qualified. You, on the other hand
> don't seem to suffer from this encumbrance : ) Perhaps you could help put
> together something?
I don't qualify as an expert either. If I have any advantages over
anyone it's from twenty-plus years of perspective running and installing
a lot of different print systems and getting myself out of different
self-made messes! People tell me I write well, though, so I'll attempt
to put down something here, and that should at least be a good start to
the layout. I'm sure others will jump in to correct any mistakes I make
-- Begin Explanation --
Before getting started, it may be helpful to understand this: a printer
is not a device in the usual sense. That is, one does not run it the
same way one would control a sound card or a hard disk. Think of it as
a black box connected through a very simple two-device network, similar
to a modem.
Before you can use one at all you must configure your communication
device. For practically all printers this will be either the parallel
port, USB or a serial port (although serial printers seem rare nowadays
and I will ignore them from here on). Find out which your printer is,
and if you have a choice of connections decide which to use. Personally
I prefer parallel over USB, and parallel ports are still better
supported in Linux, but there are often good reasons to go the other way
(for example to run more than one printer).
The different kinds of ports ARE devices in the sense you are used to.
To be specific, they are character devices, and you must configure the
Linux kernel appropriately to use them:
1) For parallel ports:
Turn on "Parallel port support". In the submenu, also turn on
"PC-Style hardware." Consider "IEEE 1284 transfer modes" as
well. It may not be necessary but probably won't hurt (this
relates to ECP/EPP fussiness below).
Then go down to the "Character devices" menu and turn on
"Parallel Printer Support" there, too.
2) For USB ports:
Turn on "USB Support". Pick the right USB controller. You
have several choices of USB controller driver. You must pick
one and they are mutually exclusive: which you want depends on
your motherboard. Beware: in some kernel versions the config
defaulted to the "UHCI alternate JE" driver, which in my
experience did not work well. After turning on the USB
controller driver, you must also turn on USB Printer Support.
Make sure the devices are enabled and configured in the BIOS. With
parallel printers you have a choice of a bunch of different operating
modes, which I will oversimplify as being ECP, EPP and ECP/EPP. The
latter is what you want for most printers BUT there are some that will
only operate in one mode or another. Problems here will often show up
as bad flow control: the printer simply stops receiving data or it
appears the connection is "jammed". If this happens try a different
Also make sure your printer device is configured correctly. The first
printer usually is /dev/lp0 (or /dev/printers/0) under Linux, but if you
run a USB printer it might appear at some other point in the device
tree, and the easiest fix will probably be to change /dev/lp0 to point
to the right place.
Do not confuse the printer device with the port devices (other things
can be connected to the ports besides the printer).
You can test your device different ways: make sure it shows up in
/proc/devices and the port shows up in /proc/ioports (remember, the port
and the printer device nodes are different). You can try sending simple
character strings to the printer, such as `echo -e "\0" >/dev/lp0`, to
see if they make the light flash. However, in my experience these often
do nothing even if the printer is working, and any string more complex
than a null is potentially dangerous to send since printers have
different command languages.
If you know the details of your print system you may be able to think of
a better test. For example, if you have a native PostScript printer you
can test it by simply cat'ing an entire .ps file to the printer device:
cat /tmp/print_test.ps >/dev/lp0
This may cause problems with the page not feeding out, but should be
enough to test the connection.
After getting the basic printer device up the next step is to set up the
software to control it. This means specifically to receive and queue
all the things that you want to send to the printer, manage the
connection so print data is transmitted smoothly, and perhaps monitor
printer status as well. This is the job of the print spooler program,
which is the equivalent of a driver in the sense we usually mean.
Packages called "printer drivers" are actually a quite different beast,
There are a few print spooler systems around and they make a nice
alphabet soup of names: LPR, LPRng, CUPS, PPR, PDQ, and others.
Although there are differences between the packages, they all fill the
same logical niche: receive, queue, send to printer, monitor status.
Thus, they are largely interchangeable and which one you use depends on
your particular biases.
LPR is the original BSD Unix print spooler. It is outdated,
insecure, dangerous, buggy and generally horrible. Nobody
should use it.
LPRng is the improved version of LPR. It solves LPRs worst
problems and is generally reliable, but is also showing
its age and the weight of added complexities over years
PDQ another replacement for LPR, intended to be simpler than
LPRng. Not that common and therefore not recommended.
PPR A replacement for the System V print spooler. Intended
specifically for postscript printers (which are easier
to handle). Not that common and not recommended.
CUPS The latest spooler, a fresh design incorporating many
accumulated ideas such as exchange-able back ends, XML-
style configuration, a web controller interface.
Since it is completely new it often has small and
annoying bugs. Nevertheless it is a well-organized
system and has the weight of developer support behind
it, so this is the one to bet on. Recommended.
You can also use Declan's (or others') hint and set up your own very
simplified system. This will be particularly attractive if you want to
educate yourself on details of printing.
There are FAQs available for whichever spooler you decide to install.
Before plunging into them, read ahead here a bit more. Printing has too
MUCH documentation, often explaining things you don't need to know about
and muddying the waters as to what is and isn't needed.
When the print spooler is installed, you should have a few commands such
as "lpr" (to print) and "lpq" (to check the queue). These names date
from the original LPR system. They are as close to a standard as we
have for printing and are about the only things you can count on to
appear in any print spooler. In particular, some spoolers will set up a
file called /etc/printcap. This is not necessary.
All the print spoolers use a spool directory, usually under /var/spool.
This will require particular permissions which might change depending on
the exact package, but in general a separate user & group should own the
directory and some bit of the print system will be setuid/setgid for
that group. The files in this directory should stay only till they have
been printed, then should be automatically deleted. Configuration
problems sometimes break this, though, and it is something to keep an
eye on when first setting up a print system.
Do not confuse the print spooler with the extras that go with it. A
print spooler is a system by itself, but all of the print spool packages
also come with selections of other goodies; printer drivers, filters,
utilities. If these work for you they are great but they are not needed
to run the basic print system, and they can all be replaced in any of
Print spool systems all support network printing (although how well they
do so is one of the things that distinguishes them). If you don't need
this you can usually just ignore it. If you do need it you will also
need to pay attention to network access permissions, in /etc/host.allow
and so on. Some spooler also expect to see special files such as
/etc/host.lpd or /etc/host.equiv, which basically just list machines
that are allowed to print.
Before we get into filters and drivers, it will help a lot to understand
how printers work. Remember the comparison with modems: both things
just receive data from whichever communication port, and then it is
completely up to them what they do with it.
The simplest case would be a teletype which does almost nothing
special. It just prints the characters it receives. Even these
printers, though, will still process control characters. Dot-matrix
printers are almost as simple but also have control sequences similar to
those used for a terminal. Thus it is almost always possible to send
characters to a printer that will cause it to hang up in confusion. Be
careful with testing them.
Practically all modern printers are so advanced they have entire
well-developed languages that control what they print. The two most
common of these are PostScript (from Adobe) and PJL (from HP), although
inkjet printers in particular have all sorts of different print
languages. You can think of these as being similar to HTML or XML.
PostScript is the best-supported under Linux. It is basically
human-readable (although not very friendly).
With any of these languages, the printer sees commands in its input
stream and interprets them accordingly. In theory the same printer
usually should have a simple default mode in case it just receives bare
text. In practice I find this rarely works, so it is important to make
sure you have things set up to print in the right language.
Filters are programs that take data to print and re-process it in
different ways. Some of these are obvious and some less obvious: a
filter might add a banner page, or count the number of pages you print,
or sort pages to print in a particular order, or simply dump data to a
bit bucket for testing, or an infinite range of other jobs. Basically
filters do ALL the processing of print data. They are logically
separate from the print spooling system (which really just handles the
files without looking inside them), although of course spoolers must
have some way of locating & interfacing with filters. The most common
way to do this is to set up a PPD file for your printer (explained
below) that points to the right kind of filter. All the print spooler
packages will come with some filters.
Filters are generally chained together. For example, one filter might
check the size of a file to decide whether to handle it at all, then
another might add a banner, a third would format it with margins, and
the last would be the driver that actually converted it to print on your
When we discuss printing, by "printer driver" we really mean a
particular filter that converts data to a specific printer language.
These are not Linux drivers in the usual sense; they are completely
independent of the kernel and their workings really have nothing to do
with the details of your computer at all. They are, however, drivers in
the sense that they control the devices in the printer as well as simply
Since drivers must handle different kinds of input data (for example,
pictures and text) they are often not just one file even though they are
only dealing with one kind of printer. Instead there are entire
packages of them to be installed and managed and confused. This is
probably the single biggest source of trouble in printing.
Note that you might not need to install any driver system. If you have
a native PostScript printer you can forget entirely about ghostscript
and its related parts. If you are simply setting up a print server and
trust your clients to format data themselves, then you can just spool
data directly to the printer (this is a common arrangement with Windows
FILTER & DRIVER SYSTEMS
The basic rule as far as Linux goes is this: PostScript=good.
Everything else is a hassle. Almost all the software we use will
generate PostScript files. If you have a native PostScript printer (ie
most laser printers) then your needs are minimal. You can just feed it
directly to the printer with no special driver at all. Most inkjet
printers do not support Postscript, though, so will need a special
JPEGs, PNGs, TIFFs, PNGs and other picture formats are all different
from PostScript and require separate filters and drivers.
Some of the filter/driver systems you will see are:
a2ps - Converts plain text to PostScript, with various controls for
formatting. Not a driver, a filter to be used before a driver.
mpage - Re-formats PostScript files in various ways, as well as
formatting plain text. A filter much like a2ps.
ghostscript - A filter and driver package which converts between
PostScript data and other things. It will change PostScript to various
printer languages (and so ghostscript is a driver of sorts), has limited
filters to convert images to (encapsulated) PostScript, and also
contains useful utilities to dump PostScript files to other formats like
hpijs - a driver system specifically for HP inkjet printers, useful for
printing pictures particularly.
omni - a driver system intended for processing graphics files. Included
gimp-print - a confusing collection of a few things. It has the plugin
to print from GIMP. It also has drivers for various sorts of printers,
and was originally intended to drive Epson printers. Nowadays the
drivers are more important than the GIMP plugin and gimp-print is a
parallel system to ghostscript. Think of ghostscript as being the text
driver and gimp-print as being a graphic driver.
stp - the original Epson driver from gimp-print, included in ghostscript
nowadays although superseded by gimp-print itself
PPD - part of the PostScript language, PPDs are files that contain
control options for printers. They're a type of standard interface for
printer drivers which are supposed to point to everything else you need
Foomatic - a collection of scripts that attempt to organize the mess of
different drivers. This is closely related to the linuxprinting.org web
site. If you have the foomatic scripts installed (and the other drivers
they point to, such as omni and hpijs) then you can download a PPD for
your printer from the web site and in theory that should be all you need
ifhp - an all-purpose print filter system, usually used with LPRng
The different filters (especially the graphic-related ones) are
intertwined and borrow each other very often so it can be a bit of a
chore to get them all set up. Also the PPD files from Foomatic are easy
to install but useless without the drivers they point to.
For printing text your options are simple: if you don't have a
PostScript printer then you need to run ghostscript.
For printing graphics you will probably have a choice of different
options. For example, to print a picture to an HP inkjet you might be
able to use any of the stp (ghostscript), omni (gimp-print) or hpijs
(semi-proprietary) drivers. Which is best depends on your printer.
The driver that is best for printing graphics might not be the same one
that is best for printing text. It would be nice if the PPD were smart
enough to choose between two drivers, and this might actually be
possible although I haven't noticed it. If not, you could look at
having two different printer names which point to the same queue and
port. For example, you might have a printer "HP" driven by ghostscript,
intended for text, and another printer "HPg" driven by hpijs.
Steve Bougerolle <steveb at creek-and-cowley.com>
Creek & Cowley Consulting
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe blfs-support' in the subject header of the message
More information about the blfs-support