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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- SourceClear Open
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide