Articles / Printing Software

Printing Software

To print something from a Free Unix, you use an application, which uses a client program to speak with a daemon process, which eventually executes some sort of driver or filter, which eventually sends print data to your printer. There are no universal standards for any step in this process; indeed, in many installations, hand-tooled scripts provide the glue between the various parts. This makes for a rather unpleasant configuration experience, to say the least.

In this review, I'll describe the most popular programs used at each stage in the printing process. Describing how to integrate any of them into any particular printing setup is way beyond the scope of this document; see the program's documentation or the Printing HOWTO for more information.


All printers are connected to your computer through a device of some sort. The most popular device is perhaps the parallel port, but USB is now quite common. Beyond local device connections, a wide variety of protocols can be used to send print jobs over the network to a printer.

Parallel, USB
For local devices, you just need to determine the proper device name and make sure that your kernel contains the proper driver. Typical device names include /dev/lp0 and /dev/usb/lp0.
The LPD protocol (not to be confused with LPD software) is the most common network printing protocol on Unix. Frequently, it can also be used to submit jobs to network-connected "Ethernet" printers or standalone print servers. If you need a standalone LPD client for scripting (or interactive!) purposes, use rlpr.
The new Internet Printing Protocol is a modern printing protocol built atop MIME and HTTP. It is implemented by CUPS, Windows, and a few other systems.
The so-called "appsocket protocol" is nothing more than print data stuffed through a TCP connection. If you need to send print data this way, use the program nc, aka NetCat. Many spoolers (CUPS, LPRng, etc.) include native support for this.
If you need to print to a Novell network printer, the ncpfs suite includes a printing client program.
If you need to send jobs to a Windows server, the Samba suite includes a client utility.
If you need to print to a networked Apple printer, the Netatalk distribution includes a client program.


Drivers are probably one of the most active areas of development these days. The best modern Free Software drivers produce quality that rivals or even surpasses that from vendor-provided drivers. Given the software-centric and highly complex nature of modern printing, this is no small accomplishment.

To be useful for general-purpose work, all drivers must interoperate somehow with the de facto standard RIP Ghostscript. Ghostscript converts Postscript data into printer-specific data; drivers basically perform the bottom half of this task.

Usually, a filter package is used to glue the driver together with the spooler, and to preprocess print jobs in various ways. Popular filter packages include magicfilter, apsfilter, and foomatic.

Laser Printers
Most mid-range and up lasers include native Postscript support, so they really don't need much of a driver. Many personal-sized lasers, however, speak PCL or another proprietary language, and require drivers. For most of the PCL devices, the selection of standard drivers in Ghostscript does the job; the ljet4 driver is the workhorse of the bunch, but there are several others. All are included in any sensible Linux distribution's standard Ghostscript.
Inkjet Printers
Here's where it gets interesting. Inkjet print quality is largely influenced by the software used to drive the printer. The gimp-print project has produced a driver suite that drives most Epson Stylus and many other brands of color inkjet printers. The output quality on properly-supported devices gives Epson's software group a run for their money.

Also of note are the HP-provided hpijs inkjet drivers for DeskJets. They're simpler than the gimp-print system, but they do work quite well on the DeskJets. The license is not free, but not very far off; you certainly get the source and the right to modify it.

Also interesting is IBM's OMNI driver system, ported from OS/2. IBM provides quite good support for a wide array of devices. The architecture is mature and data-driven; look for interesting development to happen here.

Where to find drivers

There are roughly 200 individual printer drivers in the world. Only a few distributions make any effort to ship them all, so there's likely to be a driver for you out there even if your printer isn't supported by your distribution. A good index of printer drivers for Free Unix users is the database at


There are several major and as many more minor print spoolers for Unix. Most distributions ship several, but steer you toward one which they support (i.e., Red Hat with LPRng and printconf, Mandrake with CUPS and KUPS, etc). Among the more popular spoolers are:

LPD, or Line Printer Daemon, is the traditional Unix spooler. As the name suggests, it was originally implemented to support text-only line printers, but with a bit of scripting, it can usefully manage modern print jobs. Most LPDs out there tend to have security problems, usability problems, or both; major Linux distributions are moving away from traditional LPD in favor of other spoolers.
LPRng, by Patrick Powell, is a more powerful reimplementation of the basic LPD daemon. Many additional job control and security features are available. Several distributions, including Red Hat, ship this as the core of the primary printing system.
CUPS, or Common Unix Printing System by Michael Sweet, is a fairly new spooler designed around the IETF Internet Printing Protocol (IPP). CUPS is quite featureful, compared to LPD-style systems. It especially includes many features leveraging the fact that most print jobs on Free Unix are either submitted as PostScript or rendered via PostScript or both. Many distributions now ship CUPS as the default printing system.
PDQ, or "Print, Don't Queue" by Jacob Langford, is a fresh take on the whole problem; it doesn't really spool at all, but instead merely processes print jobs and sends them to the printer immediately. A simple configuration format incorporates all the necessary scripts, metadata, etc.
PPR is a Postscript-centric system written for use at Trinity College.

User Interfaces

These are programs which make it easier to submit a print job. Merely submitting jobs isn't hard, but modern drivers have many options, so having a GUI which lets you adjust printtime options is actually fairly important.

The lpr command is the de facto commandline interface for submitting print jobs. All software which can submit print jobs on your behalf can send jobs by running lpr. Bad software is limited to this; most software lets you specify an arbitrary command with options.
There are several client programs which fit into KDE. The latest is the KPrinter class by Michael Goffioul, which provides standard dialogs with support for a number of underlying print spoolers. Also available is the QtCups application, which presents a KDE-friendly interface to the CUPS system.

For configuration, the Qt program KUPS can configure printers in the CUPS system.

GNOME also includes a standard printing dialog, and a GConf-based configuration system is under development by Chema Celorio.
XPP by Till Kamppeter is another nice GUI for the CUPS system. It's based on FLTK.


All of this is useless if you have no software to generate something printable. Here are some of the most popular packages for doing this:

Traditionally, Unix was often used for text processing. Most of the original Unix tools were markup languages like HTML. The most mature such system for producing printable output is undeniably TeX or LaTeX. Also available are a number of markup strains implemented atop Free SGML and XML tools, most notably DocBook.
These days, many people prefer a more visual package than vi or Emacs; several projects are designing regular word processors, including AbiWord, KWord, OpenOffice, and others. If MS Office interoperability is needed, the current choice is Sun's StarOffice, a no-cost commercial product. If merely a workable word processor is needed, KWord and AbiWord are both quite usable.

For bitmap graphics work, The GIMP is the package to use. It can use the gimp-print inkjet driver software directly for fine control over output quality.

Vector graphics can be done with Dia, XFig, or Kontour.

Free Unices are often used as servers. In this role, scriptable tools are extremely useful. psutils provides for fairly complex slicing and dicing of Postscript print jobs. Also available are such conversion apps as a2ps, enscript, htmldoc, and ImageMagick, Ghostscript and its PDF and Postscript processing companions ps2pdf, ps2ps, etc., and a host of other utilities. Together with the usual Unix scripting features, these provide ways to automate all sorts of printing tasks.


All things considered, desktop Linux users suffer from the somewhat disjointed system that passes for printing infrastructure on Unix. Various individual projects produce exceptional printing-related software, while vast swaths of "plumbing" logic simply don't exist. Driver quality varies widely. Interfaces are not standardized. User interfaces are often absent.

Fortunately, several players in the printing industry are working to improve this situation. For example, HP funds several development projects, Epson shares usable programming information, Easy Software develops the CUPS spooler, and Mandrake and Ximian experiment with packaging, integration, and user interface issues. The next few years should see interesting developments in all kinds of Linux printing.

Recent comments

21 Sep 2001 02:39 Avatar intek

The high-quality printer driver solution for Linux!

TurboPrint makes it possible to use the latest color printers with Linux. It is designed to produce maximum quality photo prints as
well as high-speed text documents. Printer set-up and configuration is as simple as on Windows or MacOS.
TurboPrint benefits from more than 10 years' know-how and experience in printer driver development.

"If you want to get the optimum out of your printer, TurboPrint is a real must" (German Linux computing magazine 3/2001)

16 Sep 2001 22:28 Avatar gtaylor

Re: It's up to the hardware developers to speed up Linux printing support

> Hardware developers, particularly in
> the area of printers need to take hold
> of the Linux OS and begin support. I'm
> sure if some printer manufacturers
> started shipping printers with
> vendor-provided Linux support, they'd
> have a very large market within the
> Linux software industry.

It's beginning to happen. HP provides a driver kit
replete with source (including their color code!), for the
DeskJets, and they provide
support (and a job) for the lead HPOJ developer.
Epson provides reasonable specifications for their
inkjets. Lexmark provides and supports binary-only
driver kits for several inkjets.
Indeed, of the biggies only Canon has no Linux story
to date, at least for inkjets.

16 Sep 2001 22:16 Avatar gtaylor

Re: It's up to the hardware developers to speed up Linux printing support

> Even then, has anyone considered
> producing libs/proggys that
> would work with both CUPS and
> lpr/apsfilter?

But of course!

Mandrake, Red Hat, Progeny, and probably several
other distributions all ship default printing systems built
atop <a
>Foomatic, which uses XML driver descriptions to
make all drivers and most spoolers work together.

CUPS, LPRng, LPD, and PDQ should work with every
free software printer driver on the planet using
Foomatic. Bigger projects like Gimp-Print and OMNI
ship Foomatic generator tools, while smaller drivers
have simpler interfaces constructed by volunteers.

15 Sep 2001 22:22 Avatar drfickle

More printer drivers than 200
FYI...Omni alone supports over 300 printers

15 Sep 2001 19:30 Avatar simmons75

Re: It's up to the hardware developers to speed up Linux printing support
% If you want to write a printer driver
> for Linux you first
> have to chose which printing systems
> you want to
> support. Every system is different,
> and there is no
> compatibility standard. Assuming you
> have a driver
> for at least one printing system, you
> should provide
> RPMs. But for which distribution? You
> need one set
> of RPMs for each single distributions,
> and usually
> even for each version.

Ignoring, of course, Slackware and Debian, which don't use
RPM as the "native" packaging format. And this "analysis" of
course ignores the *BSD world.

And also, of course, this "analysis" ignores the role of the
distribution package maintainer.

If you want near-universal support for a printer, well man, I
dunno. CUPS seems to want to become the universal print
system, and why merely supporting it is such a bad thing is
beyond me.

Even then, has anyone considered producing libs/proggys that
would work with both CUPS and lpr/apsfilter?


Project Spotlight

Kigo Video Converter Ultimate for Mac

A tool for converting and editing videos.


Project Spotlight


An efficient tagger for MP3, Ogg/Vorbis, and FLAC files.