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.
|Using Django and MongoDB to Build a Blog||Mar 05, 2014|
|What virtualization solution do you use/manage at work?||Mar 04, 2014|
|Our Assignment||Mar 04, 2014|
|March 2014 Issue of Linux Journal: 20 Years of Linux Journal||Mar 03, 2014|
|Have Resume - Will Travel||Feb 28, 2014|
|March 2014 Video Preview||Feb 28, 2014|
- Using Django and MongoDB to Build a Blog
- Our Assignment
- Sign Up to Win a Silicon Mechanics Swag Pack!
- March 2014 Issue of Linux Journal: 20 Years of Linux Journal
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- RSS Feeds
- Have Resume - Will Travel
- Zedge, for All Your Annoying Ringtones!
- You have to be careful there
1 week 2 days ago
- Wonder when LJ is going to
1 week 3 days ago
- Puerto Rico Free Software
1 week 4 days ago
1 week 5 days ago
- I hate voice commands
1 week 6 days ago
- usabilty --- AGAIN with this nonsense
1 week 6 days ago
- Don't make excuses
1 week 6 days ago
- Sorry to let you know, but
1 week 6 days ago
- Ridiculous statement. Not a
2 weeks 10 hours ago
2 weeks 14 hours ago