Overview of Linux Printing Systems
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).
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.
- Nmap—Not Just for Evil!
- Resurrecting the Armadillo
- High-Availability Storage with HA-LVM
- March 2015 Issue of Linux Journal: System Administration
- Real-Time Rogue Wireless Access Point Detection with the Raspberry Pi
- DNSMasq, the Pint-Sized Super Dæmon!
- Localhost DNS Cache
- Days Between Dates: the Counting
- The Usability of GNOME
- Linux for Astronomers