Overview of Linux Printing Systems

A tour of printing options under Linux.

This article presents a brief overview of the main printing systems in use on most Linux systems, with an introduction to the concepts and procedures at the core of UNIX printing. We will finish by approaching the future of Linux printing, and how it is quickly improving.

It is important to understand that printing in the Unix world revolves almost entirely around the PostScript page description language, developed by Adobe Corp. as a full-fledged programming language used to describe the contents of each page of a document. Many printers nowadays have an embedded PostScript interpreter, which is in charge of rendering the pages to paper using their PostScript description. All modern Linux desktop applications that have a print option will produce PostScript data to print full-page documents.

This approach is widely different from other desktop-oriented operating systems, and from it stems most of the problems that made Unix printing such a daunting task. Operating systems like Windows or MacOS have much more tightly integrated APIs made available to applications, often exposing the capabilities of the printers and providing an abstraction layer so that applications don't have to worry about device-specific details. Moreover, the printing API is usually integrated with the graphics API used for displaying on the screen, something that has yet to happen with X11.

On most Unix systems, the only available interface pretty much boils down to "submit a job to a queue and hope that it prints correctly". There is no unified way of gathering printer or job status, which seriously impairs the possibilities offered by Linux applications with regards to printing.

While PostScript is the de facto standard for producing documents to be printed on Linux, the printer itself doesn't have to understand PostScript, which stays a relatively expensive technology. In many cases, especially with lower-end printers, the PostScript data will have to be translated to the native page description language of the printer. This is done through the use of a special conversion filter. Generally speaking, a filter is a special program that will process its input and produce processed data on its output. There are different types of filters that are used in the context of Linux printing : conversion filters, I/O filters (responsible for transferring data to the device), processing filters (that transform the document data).

The basis of a printing system is the spooler. The spooler manages queues of print jobs. A queue is usually associated with a single printer, and jobs submitted by users are processed on a first come, first serve basis. When a job gets to be processed, its data is usually passed through a certain number of filters before it gets to the printer itself. UNIX print spoolers come in many different forms. We will focus here on the most popular variants that are widely present in most Linux distributions.

The BSD LPD printing system

As its name implies, this print system spawned from the Berkeley distribution of UNIX. The Line Printer Daemon (LPD) is still the basis for many other printing systems and spoolers that borrowed its interface and configuration file format, the printcap files. While LPD was initially developed for use with line printers that could only print a line of text at a time, it can be used for full page printers as well.

This was the printing system that made it in the first complete Linux distributions, like the early versions of Slackware. Nowadays, many distributions still ship this print spooler (Debian, Slackware), often alongside other more modern print systems like the other ones discussed in this article. There are many variants of the original BSD spooler still in use today.

The BSD printing system is really just a spooler - that is, its core functionality is limited to queuing jobs. It consists of a daemon (lpd), a couple of configuration files in /etc where queues and their properties are defined, a spooling directory where pending jobs will be held (usually /var/spool/lpd), and a set of basic commands to submit, delete and manipulate jobs (lpq, lprm, lpc).

Queues are defined in the /etc/printcap file, which follows the same format as termcap files, used to describe the capabilities of UNIX terminals. A typical printer entry would look like this :

# Sample queue definition for BSD LPD

Each entry defines a queue. There can be several queues referring to the same physical printer (for instance to distinguish certain options). A queue can also have several aliases. In the example above, the queue lp has an alias 'printer1'. Jobs can be sent to either of these printer names, and will be dropped in the same queue. As a side note, 'lp' is usually considered the default queue in the BSD world.

Jobs are submitted to the spooler via the lpr command. A specific queue can be specified with the -P argument. For instance :

lpr -Pprinter1 /path/to/some/file

Jobs that have been submitted but have not yet been processed can be removed from the queue, using the lprm command. The job ID number, as well as various status information, can be obtained by running the lpq command.

BSD LPR is significant because it also defined the LPD network protocol, which is used to submit jobs to remote LPD daemons, and allows UNIX workstations to function as print servers. This protocol is nowadays natively supported by virtually all networked printers. Because of its widespread usage, all other printing systems have had the requirement to at least be able to talk to other LPD daemons and thus implement this protocol.

Here is an example of how to define a remote queue in a printcap file. The jobs will be immediately transferred to the remote queue on the remote LPD daemon, and won't be processed on the original host.

# Sample queue definition for a remote LPD queue on a client

The rm attribute indicates the address of the remote LPD server. The rp attribute is the name of the queue on this server where jobs will be sent.

The /etc/lpd.hosts file is used to define which hosts are allowed to forward jobs to the local LPD daemon.

The LPD protocol sends data in two different pieces. First, a control file describing the job will be constructed and sent. This control file includes information about the originating user, the name of the files, and any options attached to the job. Then, the data file follows - it is the document itself and its format is entirely dependent on the printing language in use at the time.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Also dont forget about xprint

Anonymous's picture

Another alternative printing system based on X

Re: ESP Print Pro

Anonymous's picture

Hi, I bought a copy of ESP Print Pro in 1999, to help support this effort (I don't know C C++), I'm glad that CUPS has flourished.

Re: Overview of Linux Printing Systems

Anonymous's picture

Also seems to have missed a very simple system that does not even require you to have root (admin) privliges.

A small overview http://pdq.sourceforge.net:

Throw away lpr, lp, lpq, lpstat, and lprm, and start planning your vacation! Pdq is guaranteed to be the most straightforward, flexible print subsystem you have ever used, or your money back! (Actually pdq is free software, distributed without warranty.)


* modular driver and interface support
* jobs can be monitored through completion
* job status can be checked after completion
* users can only print files of declared types
* users can define their own printers
* multitasking, with no queues to get clogged
* scripts can be embedded in the rc files
* custom command-line options
* root privileges not required

This is amazing stuff, I have been using it for years in all kinds of companies/schools/home environments.

Why do it the hard way, when it can be so simple?

Eric Schabell

PDQ is not wide-spread enough

megastep's picture

While I agree with your points, and was fully aware of PDQ when I started writing this article, I chose not to mention it and instead focus on the printing systems that are commonly bundled on most Linux distributions.

AFAIK, PDQ used to be offered as a choice in earlier Mandrake distributions, but I think most distros these days just offer CUPS (or sometimes LPRng).

Re: Overview of Linux Printing Systems

Anonymous's picture

Agreed. I have been using pdq for the past year with a variety of printers and it has performed admirably while maintaining simplicity. I cannot understand why this application does not get more recognition.

Re: Overview of Linux Printing Systems

mkomarinski's picture

Why anyone is still using anything other than CUPS is beyond me.

While CUPS itself is listed as relatively new, I've been using it for at least 4 years, so in comparison to lpr, it's new.

The browsing functionality of IPP allows users with laptops to instantly see what printers are available on the network, and adding a new printer to everyone's desktop is as easy as adding it to one location.

Support for Postscript-capable printers is very well done, and there's always foomatic and other drivers for inkjet and other non PS printers.

In addition is the support for SSL encryption and authentication, if desired. This can limit who prints, but could allow you to print from anywhere on the Internet.

The only downside to IPP is that Windows does not support browsing, nor does it support encryption or authentication. You can, however, have Samba export printers listed in CUPS and print that way.

Re: Overview of Linux Printing Systems

Anonymous's picture

> Support for Postscript-capable printers is very well done

It could be much better I think. It is not possible to define per-printer PostScript filters without modifying the PPD. If one uses the web interface to modify a configuration, your filter additions get overwritten and you have to add all your diffs back into the PPD.

That being said, CUPS still has many nice attributes. gnulpr is another project I keep tabs on. (ppdfilt is a nice little utility.)

Re: Overview of Linux Printing Systems... You Forgot One....

Anonymous's picture

Try TurboPrint (http://www.turboprint.de/english.html) I've used it for Client sites that have wierd printer configurations or international printers. It's as easy to use as the HTML GUI for CUPS and has plenty of conf./drivers.

It's a commercial product but there is a free version.



Re: Overview of Linux Printing Systems

Anonymous's picture

Excuse the word but what a lot of wank ? - you can either produce an O/S that has universal printing abilaties or you can not - all this advance talk about it is just a failing of the volanteer code writers who can only do half a job - as an end users I do not care for the excuses (the manufacture has not relesed the code) - it either works or it does not work - complcated solutions are un-acceptable. I can either download a bianary installer as a RPM, DEB or tar.gz and have it work imediately or it is not worth bothering with the O/S.

Raise your standards - Computing in todays world is for idiots - not for Geeks

Re: Overview of Linux Printing Systems

Anonymous's picture

If u want something to work just right out of the box make sure u pay for it. go for some proprietary os that does that and quit whining about oss not meeting YOUR standards. Oss will reach its destination once its ready. Rather than giving opinion based on facts don't whine on things. Remeber that

Re: Overview of Linux Printing Systems

Anonymous's picture

BITE ME, luser.

Then you don't use Windows either, do you?

Anonymous's picture

because when I did Win support on my last job the printing almost never worked right out of the box.

Re: Overview of Linux Printing Systems

Anonymous's picture

The printing abilities exist, it's just the user interfaces that suck.

I must ask the question: Did you even read that?

Stuff doesn't work immediately anywhere. I don't know if you've noticed, but you're supposed to know a little bit about your system even when installing Mac applications. Grow up.

As for standards; They're already almost so high as to above everyone's heads. It takes time to implement them, buddy; we're almost there.

Cups/Linux as Windows replacement

Anonymous's picture

I work in a small educational institution and have been trying to slowly integrate linux into an all Win98 environment. Printing remains one of the biggest obstacles for the extremely NON-technical students (its a religious institution.) I had thought that Cups would solve this problem but I have a major problem with canceling print jobs. Cups works great as long as everyone does everything just right. However, if someone has turned the printer off or just wants to cancel the job because s/he forgot to change something in the document then all hell breaks loose. Either the printer starts spewing junk or refuses to quit printing even though the Cups web interface indicates the jobs have been cleared. The only solution for a none tech person is a reboot - yuck. I have tried kups but the results are the same. This is all that is holding me back from employing it as a print server. Any thoughts anyone?

Re: Cups/Linux as Windows replacement

Anonymous's picture

There may be a parellel process that you can kill instead of rebooting. This happens because the "job" has already left the CUPS queue and been sent to the printer port. Killing the parellel process with the printer off should fix the issue. You do not need to reboot linux machines!

Re: Cups/Linux as Windows replacement

Anonymous's picture

Printing remains one of the biggest obstacles for the extremely NON-technical students (its a religious institution.)

What does that have to do with anything? Are you saying that you can't be religious and a geek at the same time?

Re: Cups/Linux as Windows replacement

OilyFish's picture

Gee, there's always someone with a chip on the old shoulder.