CUPS is the abbreviation for Common UNIX Printing System. It is a modularized computer printing system for UNIX-like operating systems, which provides a common printing interface across a local network, masking differences among the printing systems on each computer. A computer running CUPS is a host that can accept print jobs from client computers, process them, and send them to the appropriate printer. It was developed by Easy Software Products (ESP) and is now owned and maintained by Apple Inc. Now CUPS is the standard printing system in most Linux distributions.
Note
Common UNIX Printing System (CUPS) is the base for streamlined printing systems for Mac OS X. CUPS can also work independently on Mac OS X. You can get more information on this at:
In this chapter, we will discuss the various features of CUPS, and the support of PostScript Printer Driver (PPD) in detail.
CUPS consists of a print spooler and a scheduler, a filter system that converts the print data to a format that the printer will understand, and a backend system that sends this data to the print device.
CUPS uses the Internet Printing Protocol (PP) to manage print jobs and queues. It also provides the traditional System V and Berkeley command line interfaces. It also provides limited support for the Server Message Block (SMB) protocol.The device drivers supplied by CUPS are based on PostScript Printer Description (PPD) files. There are a number of user interfaces for different computing platforms that can configure CUPS, and it has a built-in, web-based interface.
CUPS consists of a print spooler and a scheduler, a filter system that converts the print data to a format that the printer will understand, and a backend system that sends this data to the print device.
CUPS uses the Internet Printing Protocol (PP) to manage print jobs and queues. It also provides the traditional System V and Berkeley command line interfaces. It also provides limited support for the Server Message Block (SMB) protocol.The device drivers supplied by CUPS are based on PostScript Printer Description (PPD) files. There are a number of user interfaces for different computing platforms that can configure CUPS, and it has a built-in, web-based interface.
In the early versions of UNIX, the line printer daemon (LPD) was used to spool text to a printer. This LPD also known as Berkeley printing system (BSD) is able to send any kind of file to a printer.
The model of this printing system consists of the following features:
A number of hosts request print services from a LPD process running on a host
The output of the print job will be produced when a file is sent as a request input
The print job will have a unique number from 0 to 999
Users who request print jobs shouldn't have their user name starting with digits
Apart from its main command
lpd, the system also supportslpr(assign to queue),lpq(display the queue),lprm(remove from queue), andlpc(control the queue)
The biggest disadvantage with the Berkeley printing system is that it doesn't provide any feature for print jobs and filtering systems. These features were added in a new line printer (LP) system. The following URL shows information about this system in detail:
http://tools.ietf.org/html/rfc1179
Note
A printer that supports LPD/LPR is sometimes referred to as a "TCP/IP printer". The LPD/LPR protocol listens on TCP port 515.
The System V printing system is one of the several standard architectures for printing on the UNIX platform which uses the lp command. The following are some of the features of System V printing system:
This printing system is applicable to commercial System V based OS such as Solaris SCO OpenServer
Solaris has done a lot of modifications due to its open source project OpenSolaris by keeping original System V printing system intact
Note
OpenSolaris is an open source project created by Sun Microsystems to build a developer community around Solaris Operating System technology. You can get more information on this at: http://opensolaris.org/os/
Apart from its main command
lp, System V uses other commands such aslpstat(shows the current print queue),cancel(deletes a job from the print queue),lpadmin(an administrative command to configure the print system),lpmove(an administrative command to configure moves jobs between queues)
CUPS emulates both System V and Berkeley print architectures at the interface level, though its internal architecture is different from both. We will see the architecture of CUPS with its features shortly.
Early personal computers, such as the ones from IBM, and printers only handled text. So they worked in a fashion similar to the UNIX mainframes of that time. Each application came with its own code to handle text-based printing to popular printers. Most of those applications are shipped with modules that help users print to their specific printers.
As the technology improved, printers began to support graphics, so applications had to adapt support the expanded printer features. The complexity of the software used to communicate with printers soon began to rival the applications themselves, and it wasn't long before that these "printer drivers" were an industry of their own. Unfortunately, a printer driver for one application rarely worked with another, so the applications had to adapt support the expanded printer features.
Apple's release of the Macintosh computer changed the manner in which printing was done on the personal computer. Designed from the beginning to be a desktop publishing system, the Macintosh abstracted the printing interface from the application. Applications only had to tell the printing system where and what to print, and the printing system would translate that request into the desired output on the selected printer. Printer drivers were provided with the Mac OS or with the printer you purchased for your computer. The same driver supported all Mac OS applications. Arguably, the Mac OS has dominated desktop publishing since its inception. To this day, a large number of printing shops use the Mac OS for their work.
Microsoft's first Windows operating environment duplicated this paradigm. The printing and information display systems are nothing alike, technically. However, to an end user, they seem to work similarly. Applications for these operating systems were able to produce professional-quality output with a generic printing interface. Yet until recently, UNIX only had a print file spooling system.
In 1993, a company called Easy Software Products (ESP) was started, aimed at supporting the Digital UNIX and Linux operating systems. Unfortunately, these operating systems used the original LPD for printing, so you couldn't pass options to the printer drivers. This alone would cripple any drivers you could develop. To make matters more complicated, at least three versions of the LPD were in common use, and they were not 100% compatible with each other.
The original design of the Common UNIX Printing System (CUPS) was based around the LPD network protocol. Later, developers added support for various features such as remote administration, and authentication when the Internet Printing Protocol (IPP) working group was created. The IPP working group originally was just going to update the LPD network protocol, but quickly changed direction to create a much more functional and extensible protocol that could evolve as needed to support new technologies.
CUPS provides a mechanism that allows print jobs to be sent to printers in a standard fashion. The data is sent to a scheduler, which then sends jobs to a filter system that converts the print job into a format which the printer will understand. The filter system then passes the data on to a backend—a special filter that sends print data to a device or a network connection.
The primary advantage of CUPS is that it is a standard and modularized printing system that can process numerous data formats on the print server. Previously, it was difficult to find a standardized solution that would allow numerous printers to print their full feature sets. For instance, the System V and Berkeley printing systems were largely incompatible with each other, and they required setting up complicated scripts and workarounds to convert from the program's data format to a format the printer understood. They often didn't know how to detect the file format that was being sent to the printer and thus could not convert data correctly. They also did their data conversion on the workstation and not on the server.
With CUPS, it is far easier for printer manufacturers and printer driver developers to create drivers that work natively on the print server than before. As the processing is done on the server, it is also easier to allow for network-based printing. Another advantage that CUPS has is that when it is used with Samba software, the printers can be used for remote print from and to Windows PCs.
Scheduler
The scheduler is a HTTP/1.1 server application that handles HTTP requests. Besides handling printer requests via IPP POST requests, the scheduler also acts as a full-featured web server for documentation, status monitoring, and administration. The scheduler also manages a list of available printers on the LAN and dispatches print jobs as needed using the appropriate filters and backends.
The configuration files consist of:
The HTTP server configuration file
Printer and class definition files
MIME type and conversion rule files
PostScript Printer Description (PPD) files
The HTTP server configuration file is purposely similar to the Apache web server configuration file and defines all the access control properties for the server.
The printer and class definition files list the available printer queues and classes. Printer classes are collections of printers. Jobs sent to a class are forwarded to the first available printer in the class, in a round-robin fashion.
The MIME type files list the supported MIME (Multipurpose Internet Mail Extensions) types (text/plain, application/postscript, and so on) and the "magic" rules for automatically detecting the format of a file. These are used by the HTTP server to determine the Content-Type field for GET and HEAD requests and by the IPP request handler to determine the file type when a Print-Job or Send-File request is received with a document format of application/octet-stream.
The MIME conversion rule files list the available filters. The filters are used when a job is dispatched, so that an application can send a convenient file format to the printing system which then converts the document into a printable format as needed. Each filter has a relative cost associated with it, and the filtering algorithm chooses the set of filters that will convert the file to the needed format with the lowest total "cost".
The PPD files can describe the capabilities of all the printers, not just PostScript printers. There is one PPD file for each printer. PPD files for non-PostScript printers define additional filters through CUPS Filter attributes to support printer drivers.
CUPS API
The CUPS API contains CUPS-specific convenience functions for queuing print jobs, getting printer information, accessing resources via HTTP and IPP, and manipulating PPD files. Unlike the rest of CUPS, the CUPS API is provided under the terms of the GNU LGPL, so it may be used by non-GPL applications.
Note
You can get detailed information on the license of CUPS and other supported software at: http://www.cups.org/documentation.php/license.html
Berkeley and System V Commands
CUPS provides the System V and Berkeley command-line interfaces for submitting jobs and checking the printer status. The lpstat and lpc status commands also show network printers ("printer server") when printer browsing is enabled.
The System V administration commands are supplied for managing printers and classes. The Berkeley printer administration tool (lpc) is only supported in a "read-only" mode to check the current status of the printer queues and the scheduler.
Filters
A filter program reads from the standard input or from a file if a filename is supplied, and then sends the output to the backend in a format the printer recognizes. The filters supports a common set of options including printer name, job ID, username, job title, number of copies, and job options. Filters are provided for many file formats and include image file and PostScript raster filters that support non−PostScript printers. Multiple filters are run in parallel to produce the required output format.
The PostScript raster filter is based on the GNU Ghostscript. Instead of using the Ghostscript printer drivers and frontend, the CUPS filter uses a generic raster printer driver and CUPS-compliant frontend to support any kind of raster printer. This allows the same printer driver filter to be used for printing raster data from any filter. We will discuss all CUPS based drivers such as PostScript Printer Drivers (PPD), Ghostscript drivers and so on in detail in the section, Printer Drivers in Chapter 3 on Printer Management.
CUPS Imaging
The CUPS Imaging library provides functions for managing large images, doing colorspace conversion and color management, scaling images for printing, and managing raster page streams. It is used by the CUPS image file filters, the PostScript RIP, and all raster printer drivers.
Note
PostScript Raster Image Processors (RIP) are the filters that convert PostScript files into high resolution raster images. This means that the RIP can take the digital information about fonts and graphics that describe the appearance of your file and translate it into an image composed of individual dots that the imaging device.
Backends
A backend program is a special filter that sends print data to a device or network connection. This program is usually located in /usr/lib/cups/backend/. The backends for parallel, serial, usb, lpd, ipp, and socket (for AppSocket & JetDirect) connections are provided in CUPS 1.1 & the later versions. The SAMBA version 2.0.6 and higher includes a SMB backend (smbspool) that can be used with CUPS 1.0 or higher for printing to Windows.
Traditionally, network printing has been one of the hardest things to get working under UNIX. One reason is that each vendor added his or her own extensions to the LPD protocol (the previous standard for network printing), making cross-platform printing difficult, if not impossible.
Another reason is that you have to administer each network printer on each client machine. In some cases, you can "clone" the printer configuration from a "master" client to each of the others, but even that can be time consuming and error-prone. Something better is needed.
CUPS provides printer browsing, which allows clients to automatically see and use printers from any server on a LAN. This means that you only need to configure the server, and the clients will automatically see the printers and classes on it. The feature will be discussed in Chapter 8—Monitoring CUPS where we explore SNMP protocol within CUPS.
In addition, CUPS can automatically merge multiple identical network printers into "implicit classes". This allows clients to send jobs to the implicit class and have them print on the first available printer. In addition, failsafe and load-balancing functions are enabled simply by defining the same printer on multiple servers. The feature of classes will be discussed in Chapter 4—Managing Multiple Printers at a Time.
The following are the features of CUPS. We will discuss each of this features in detail:
Support for Internet Printing Protocol (IPP)
Compatibility with other Print Systems
Support for Web Interface
Modular Architecture
Support For PostScript Printer Description Drivers (PPDs)
IPP is a protocol for an industry and Internet Engineering Task Force (IETF) standard that supports network printing. CUPS supports the Internet Printing Protocol (IPP) that is supported under all UNIX/Linux platforms, and also under Novell's Netware and recent Windows OS. Since it is widely supported and well-documented, IPP alone comes close to solving one of the biggest administration nightmares on most networks, cross-platform printing. Some higher end network printers now support IPP too. In addition to supporting sending and receiving print jobs, the IPP protocol also supports features such as browsing. Browsing allows the automatic configuration of printers on a network. An IPP host may broadcast information about its printer list to a particular network. The other IPP hosts on the network may then add this printer information to their printer list. This allows the administrator to add the printer to one host and have the new printer appear as an option on all of the desktop PCs in the organization.
Since IPP is destined to work across all operating system platforms, you can create unified sets of query functions that can be used on IPP-enabled printers and servers for transferring files, and setting job-control attributes among others. However, rollout of IPP will not happen overnight, as many legacy print devices will still be in use for many years to come. To overcome this, IPP has a provision for backward compatibility of all IPP implementations including CUPS.
The most striking advantage of IPP is its integration into the existing set of other robust IP protocols. Internet Printing Protocol (IPP) being an extension of the proven and robust HTTP 1.1 protocol is also very easy to plug in other standards as they are being developed and deployed for the special task of handling print file and related data. The following are some of the features of IPP. We will discuss each of this in detail later in this book:
Supports various authentication methods such as basic, digest, Kerberos, and local certificate for users seeking access to print services
Supports SSL3 and TLS encryption for transferring data. Both these points will be covered in Chapter 10—Security
Bi-directional communication of clients with print devices, using the HTTP/IPP GET and POST mechanism
LDAP (Lightweight Directory Address Protocol) directory service integration to keep a consistent database of available printers, their capabilities and page costs, and so on, as well as user passwords, ACL's among others
Pull (as opposed to the usual "Push" model) printing, where a server or printer just needs to be told the URL of a document, whereupon it is retrieved from the resource on the internet and printed
The following are the systems that are compatible with CUPS:
BSD and SysV print systems over network and command-line tools
Windows print system with the help of Samba
Socket printing for printing to AppSocket, HP JetDirect, and other similar devices
We will see printer related commands in Chapter 3—Managing Printers. In Chapter 6, we will cover CUPS printing with clients working on different platforms. The same chapter will also cover printing with Samba and other systems.
CUPS provides web interface for management. The interface provides various features for printer, classes, and jobs. Since the IPP protocol is very similar to the HTTP protocol, it was quite easy for the CUPS team to write a web-based configuration tool into the CUPS service. The interface also includes options to view important log files, configuration files, authentication, and administration options. You can also configure and maintain a CUPS host's print queues from any machine that has a web browser. CUPS owes lots of to the web interface for its popularity and that's why we will be using various features of CUPS web interface in almost all the chapters in this book.
CUPS is designed to be very modular. To add new functionality, such as better accounting or support for a new network print protocol, someone just needs to write a small component that serves the intended purpose and plugs it into the CUPS print system.
Before we learn about PostScript drivers, let's first understand PostScript.
The PostScript programming language is an invention by Adobe, but its specifications have been published extensively. Its strength lies in its powerful ability to describe graphical objects (fonts, shapes, patterns, lines, curves, and dots), their attributes (color, linewidth), and the way to manipulate (scale, distort, rotate, shift) them. Since it is relatively easier, anybody with the required skill can start writing his or her own implementation of a PostScript interpreter and use it to display PostScript files on screen, or on paper.
PPD (Postscript Printer Description) file is a file that describes the fonts, paper sizes, resolution, and other capabilities that are standard for a particular Postscript printer. PostScript Printer Descriptions Driver (PPDs) is a program that uses these PPD file to understand the capabilities of a particular printer. CUPS not only supports PPD Drivers for all PostScript printer drivers, but also for non-PostScript Printers.
We will discuss PPDs in the section Printer Drivers of Chapter 3 and also in Chapter 9 in detail where we shall discuss Filtering in detail.
The Common UNIX Print System (CUPS) has become quite popular. All major Linux distributions now ship it as their default printing system. People tend to regard it as a "black box", and they do not want to look at too closely as long as it works properly. But once there is a problem, they have trouble finding out where to start debugging.
CUPS supports quite a few unique and powerful features. The basic functions of CUPS is relatively quite easy, but since CUPS has various new features such as support of IPP, availability of web interface, a modular architecture, and so on. It is best not to try to apply any prior knowledge about printing to this new system.
CUPS is more than just a print spooling system. It is a complete printer management system that complies with the new Internet Printing Protocol (IPP). Many of its functions can be managed remotely (or locally) or via a web browser (giving you platform-independent access to the CUPS print server). Additionally, it has a traditional command-line and several more modern GUI interfaces, which we shall explore in the forthcoming chapters. In the next chapter, we will discuss how to install and configure CUPS.