An introduction to Linux printing systems

Printing is one of the key desktop applications today. And Linux is growing by leaps and bounds too. Sabyasachi Dey provides an overview of printing technology used on Linux-based systems

The printing system remains a key application on any operating system. The requirements to print data of different types, forms, and size from any application, most often using a shared printer or network printer calls for a solid printing architecture This article gives a brief overview of printing technology used on most Linux systems, with a focus on UNIX printing.

The PostScript page description language, developed by Adobe plays an important role in UNIX printing systems. This is a full-fledged programming language used to describe the contents of each page in 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. 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 relatively expensive technology. In many cases, especially with lower-end printers, 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. 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,

A Linux printing system is designed keeping the spooler at the core. In general UNIX print spoolers come in various flavours. We will focus here on the most popular variants that are widely present in most Linux distributions. Print jobs are queued and managed by the spooler. Queues are maintained on a 1-1 basis with each printer, and jobs submitted by users are processed on a ‘first come, first serve’ basis. When a job is being processed, its data is usually passed through a certain number of filters before it gets to the printer itself.

For a long time the choice for free software users was simple—everyone relied on BSD’s LPD. But this is beginning to change. Now there are a number of good systems to chose from. They are all described below; 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.

Common Unix Printing System (CUPS)

CUPS (www.cups.org) has become the standard printing system in most Linux distributions today. Basically , 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 over the ancient LPD protocol.

As mentioned, CUPS is based around the Internet Printing Protocol standard (IPP), which is an IETF protocol based on the popular and widely used HTTP protocol. 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. CUPS also provides support for secure printing. IPP can be secured by using standard authentication and SSL connections just like HTTP.

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 extend 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 printers. A filter modifies data passed through it as required by the next level of software. There are different classes of filters available for CUPS. There are filters for parallel ports, TCP/IP socket connections, LPD, etc.

Similarly there are document conversion filters like image converters, ASCII text, PDF files and HP-GL/2 vector documents to Postscript.

CUPS also implement s printer classes. 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, 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 lpr, lpq as well as lp, lpstat, etc, 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.

LPD printing system

LPD, the original BSD UNIX Line Printer Daemon, has been the standard on UNIX for years. It is available in every flavour 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 a 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 they do all the 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.

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 just a spooler in reality—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. 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. 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. 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 kinds of status information can be obtained by running the lpq command.

LPRng printing system

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 set-ups 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 users effectively utilise free software drivers for many printers. LPRng is distributed under either the GPL or an Artistic license.

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 widespread 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).

Application interface

Over the period PostScript language became the primary interface for printing in the UNIX world. All major applications will output at least generic PostScript that will then be processed by the printing system until it gets printed. This is obviously very limited, because applications have no unified way of querying printing features, or even knowing if a job printed correctly. Very few applications are able to use PPD files to access printer features, although StarOffice and OpenOffice are notable exceptions.

But the situation is improving. For instance, CUPS provides a basic C API that allows applications to be integrated more easily with their printing system. This API includes functions to communicate with a CUPS daemon through IPP, as well as functions to read and parse PPD files, and thus gather detailed information about printers and their capabilities. This still stays quite limited for the application developer, as this only works with CUPS and similar IPP servers.

On the free software side, the Gnome and KDE desktop projects now both include middle-level layers to facilitate printing: KDEPrint and Gnome-Print. These frameworks propose to provide a unified APIs to the applications, by abstracting the underlying printing system.

Epilogue

One of the key desktop applications is printing documents. And Linux is also targeting to reach maximum desktops apart from the high-end server segment. As a result, printing on Linux is evolving as fast as other services. The good news is that Linux printing is beginning to see support from big name vendors like HP or IBM that strive to improve on its infrastructure. Moreover, the Free Standards Group is working on the OpenPrinting project, whose goal is to define the next generation of printing infrastructure for the Linux operating system. This workgroup, comprised of many industry experts, is defining APIs and standards that will bring Linux up to speed with its competitors.