Overview of Linux Printing Systems

A tour of printing options under Linux.
The LPRng printing system

While BSD provided the basis of Unix print spoolers, its functionality is limited. Several projects were started to improve on it and add better configurability and more flexibility. The most wide-spread BSD-based printing system on Linux nowadays is LPRng (LPR Next Generation), written by Patrick Powell. It is essentially a rewrite of the original BSD LPR system, but all of the previous concepts still apply.

While LPRng keeps the printcap file format, it introduces a number of new attributes that make its configuration much more flexible. Filter definitions can be separated and true I/O filters can be defined. Users can also define their own queues, by writing a .printcap file in their home directory.

LPRng also provides commands that emulate the UNIX System V-style printing commands (lp, lpstat, etc).

LPRng comes with the IFHP filter, which can be used with queues to automatically perform some data format conversions (for example to print ASCII text or images).

The Common Unix Printing System (CUPS)

CUPS is a relatively recent project started by Easy Software. Designed from the ground up, it aims at replacing the BSD-derived printing systems, and integrates a number of emerging standards and technologies making it a very cutting-edge printing system. Recently, CUPS became even more popular as Apple selected it to become the new standard printing system in MacOS X 10.2 (Jaguar).

CUPS is based around the Internet Printing Protocol standard (IPP), which is an IETF protocol derived from HTTP. The CUPS daemon understands IPP requests and it is the primary means of communication with its client applications. As an Internet protocol, IPP makes it easy to deploy print servers on wide-area networks. CUPS also supports other popular protocols used to communicate with printers, and thus can be used to act as a bridge for networked printers that don't have native IPP support. Just like HTTP on which it is based, IPP can be secured by using authentication and SSL connections. CUPS provides native support for this, allowing for secure printing.

Another standard that CUPS embraces is the PostScript Printer Definition file format (PPD), which is another Adobe standard used to describe the capabilities of Postscript printers. CUPS extends their usage to non-Postscript printers, making it one of the cornerstones of modular drivers in this architecture.

CUPS also uses many filters as a means of translating and transporting data to the printers. However, unlike BSD-like print spoolers, this is done in a much more intelligent way. There are different classes of filters available for CUPS.

  • Back-end filters provide the endpoint where the final data will be delivered. There are filters for parallel ports, TCP/IP socket connections, LPD, and other endpoints.

  • Document conversion filters ship in standard with CUPS, and are available to convert images, ASCII text, PDF files and HP-GL/2 vector documents to Postscript.

  • Interface or raster filters are referred to from the PPDs and are called to convert the documents from Postscript to an intermediary file format.

As with other printing systems, a translation filter is needed in order to print to non-PostScript printers. CUPS allows PPD files to describe the filter used to translate to the device's native language, as such :

*cupsFilter:    "application/vnd.cups-raster 0 rastertohp"
This example is from a PPD file for HP Deskjet printers. What this line means, is that the "rastertohp" program, a filter usually located in /usr/lib/cups/filter, will take data of the MIME type "application/vnd.cups-raster" as its input and convert it to a format suitable to be sent directly to the printer, in this case HP PCL data. This MIME type is a special CUPS type meaning rasterized data, which is basically a raw bitmap format in a format that CUPS filters understand. CUPS ships with a modified version of Ghostscript that is able to translate PostScript into CUPS raster data: the pstoraster filter. The number 0 in the line above indicates the "cost" of the filter, and is a value used by CUPS to prioritize the filters in the chain.

Printer classes are also implemented by CUPS. Originally a feature implemented by some System V printing systems, printers can be grouped into 'classes', to implement automatic load balancing. A class can be sent jobs to just like a regular queue. A job submitted to a class will be dispatched to the first available printer in that class.

Another neat feature of CUPS is its automatic network configuration. Using a broadcasting protocol, all CUPS daemons on the same LAN communicate with each other, and queues configured on a server are automatically browsable and made available on other systems. CUPS also provides "implicit classes" for several printers that have the same name on different servers, providing automatic load balancing. CUPS also has support for SLP (Service Location Protocol), that some devices may implement to broadcast their presence.

On the client side, CUPS has both LPD-like and System V-like interfaces, meaning it provides both lpr, lpq... as well as lp, lpstat, et al. commands to the system. All of these commands are essentially IPP clients communicating with the CUPS daemon through IPP requests.

Additionally, CUPS comes with a Web-based administration interface to directly let administrators and users configure queues from a Web browser, or just check their status. This is generally a lot more user-friendly than using cryptic commands, or manually defining queues by editing the printers.conf file in /etc/cups.

One last feat of the CUPS printing system is that it is not necessarily limited to PostScript as its input data. While it could be argued that other printing systems do not necessarily have this limitation either, CUPS makes it a lot easier. We've seen previously how a conversion filter could be specified in a PPD file for use with CUPS, and how this involved specifying a MIME type. CUPS makes extensive use of the MIME types to determine the flow of data between job submission and the final data on the printer. Filters can be defined in *.convs files (usually in /etc/cups), that describe each of the filter programs : the type of data they accept as input, their "cost", and the type of data they output. Given a job of a certain type, CUPS will then intelligently decide on the chain of filters to be called in order to obtain the final type accepted by the printer: PostScript, or the type specified in the PPD on the cupsFilter line as we saw previously.



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.