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 doesnt
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
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 simpleeveryone
relied on BSDs 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 dont 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 realitythat 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 securethere are no SUID binaries, and
it supports authentication via PGP or Kerberos.
LPRng also includes some example set-ups for common network printersHP
LaserJets, mainlythat 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
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).
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.
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.