18.4 Advanced Intelligent Printing with PostScript Driver Download

We now know how to set up a " dump " printserver, that is, a server which is spooling printjobs " raw ", leaving the print data untouched.

Possibly you need to setup CUPS in a smarter way. The reasons could be manifold :

• Maybe your boss wants to get monthly statistics: Which printer did how many pages? What was the average data size of a job? What was the average print run per day? What are the typical hourly peaks in printing? Which department prints how much?

• Maybe you are asked to setup a print quota system: Users should not be able to print more jobs, once they have surpassed a given limit per period.

• Maybe your previous network printing setup is a mess and must be re-organized from a clean beginning.

• Maybe you have experiencing too many " blue screens " originating from poorly debugged printer drivers running in NT " kernel mode "?

These goals cannot be achieved by a raw print server. To build a server meeting these requirements, you'll first need to learn about how CUPS works and how you can enable its features.

What follows is the comparison of some fundamental concepts for Windows and UNIX printing; then follows a description of the CUPS filtering system, how it works and how you can tweak it.

18.4.1 GDI on Windows “ PostScript on UNIX

Network printing is one of the most complicated and error-prone day-to-day tasks any user or administrator may encounter. This is true for all OS platforms. And there are reasons for this.

You can't expect most file formats to just throw them toward printers and they get printed. There needs to be a file format conversion in between. The problem is that there is no common standard for print file formats across all manufacturers and printer types. While PostScript (trademark held by Adobe) and, to an extent, PCL (trademark held by HP) have developed into semi-official " standards " by being the most widely used PDLs Page Description Languages (PDLs), there are still many manufacturers who " roll their own " (their reasons may be unacceptable license fees for using printer-embedded PostScript interpreters, and so on).

18.4.2 Windows Drivers, GDI and EMF

In Windows OS, the format conversion job is done by the printer drivers. On MS Windows OS platforms all application programmers have at their disposal a built-in API, the Graphical Device Interface (GDI), as part and parcel of the OS itself to base themselves on. This GDI core is used as one common unified ground for all Windows programs to draw pictures, fonts and documents on screen as well as on paper (print). Therefore, printer driver developers can standardize on a well-defined GDI output for their own driver input. Achieving WYSIWYG (" What You See Is What You Get ") is relatively easy, because the on-screen graphic primitives, as well as the on-paper drawn objects, come from one common source. This source, the GDI, often produces a file format called Enhanced MetaFile (EMF). The EMF is processed by the printer driver and converted to the printer-specific file format.

N OTE

To the GDI foundation in MS Windows, Apple has chosen to put paper and screen output on a common foundation for their (BSD-UNIX-based, did you know?) Mac OS X and Darwin Operating Systems. Their Core Graphic Engine uses a PDF derivative for all display work.

18.4.3 UNIX Printfile Conversion and GUI Basics

In UNIX and Linux, there is no comparable layer built into the OS kernel(s) or the X (screen display) server. Every application is responsible for itself to create its print output. Fortunately, most use PostScript and that at least gives some common ground. Unfortunately, there are many different levels of quality for this PostScript. And worse , there is a huge difference (and no common root) in the way the same document is displayed on screen and how it is presented on paper. WYSIWYG is more difficult to achieve. This goes back to the time, decades ago, when the predecessors of X.org, designing the UNIX foundations and protocols for Graphical User Interfaces, refused to take responsibility for " paper output " also, as some had demanded at the time, and restricted itself to " on-screen only ." (For some years now, the " Xprint " project has been under development, attempting to build printing support into the X framework, including a PostScript and a PCL driver, but it is not yet ready for prime time.) You can see this unfavorable inheritance up to the present day by looking into the various " font " directories on your system; there are separate ones for fonts used for X display and fonts to be used on paper.

Figure 18.1. Windows printing to a local printer.

The PostScript programming language is an " invention " by Adobe Inc., but its specifications have been published to the full. Its strength lies in its powerful abilities 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. Because of its open specification, anybody with the skill can start writing his own implementation of a PostScript interpreter and use it to display PostScript files on screen or on paper. Most graphical output devices are based on the concept of " raster images " or " pixels " (one notable exception is pen plotters ). Of course, you can look at a PostScript file in its textual form and you will be reading its PostScript code, the language instructions which need to be interpreted by a rasterizer . Rasterizers produce pixel images, which may be displayed on screen by a viewer program or on paper by a printer.

18.4.4 PostScript and Ghostscript

So, UNIX is lacking a common ground for printing on paper and displaying on screen. Despite this unfavorable legacy for UNIX, basic printing is fairly easy if you have PostScript printers at your disposal. The reason is these devices have a built-in PostScript language " interpreter ," also called a Raster Image Processor (RIP) (which makes them more expensive than other types of printers); throw PostScript toward them, and they will spit out your printed pages. Their RIP is doing all the hard work of converting the PostScript drawing commands into a bitmap picture as you see it on paper, in a resolution as done by your printer. This is no different to PostScript printing a file from a Windows origin.

N OTE

Traditional UNIX programs and printing systems ” while using PostScript ” are largely not PPD-aware. PPDs are " PostScript Printer Description " files. They enable you to specify and control all options a printer supports: duplexing , stapling and punching . Therefore, UNIX users for a long time couldn't choose many of the supported device and job options, unlike Windows or Apple users. But now there is CUPS.

Figure 18.2. Printing to a PostScript printer.

However, there are other types of printers out there. These do not know how to print PostScript. They use their own Page Description Language (PDL, often proprietary). To print to them is much more demanding. Since your UNIX applications mostly produce PostScript, and since these devices do not understand PostScript, you need to convert the printfiles to a format suitable for your printer on the host before you can send it away.

18.4.5 Ghostscript ” the Software RIP for Non-PostScript Printers

Here is where Ghostscript kicks in. Ghostscript is the traditional (and quite powerful) PostScript interpreter used on UNIX platforms. It is a RIP in software, capable of doing a lot of file format conversions for a very broad spectrum of hardware devices as well as software file formats. Ghostscript technology and drivers are what enable PostScript printing to non-PostScript hardware.

Figure 18.3. Ghostscript as a RIP for non-postscript printers.

T IP

Use the " gs -h " command to check for all built-in " devices " of your Ghostscript version. If you specify a parameter of -sDEVICE=png256 on your Ghostscript command line, you are asking Ghostscript to convert the input into a PNG file. Naming a " device " on the command line is the most important single parameter to tell Ghostscript exactly how it should render the input. New Ghostscript versions are released at fairly regular intervals, now by artofcode LLC. They are initially put under the " AFPL " license, but re-released under the GNU GPL as soon as the next AFPL version appears. GNU Ghostscript is probably the version installed on most Samba systems. But it has some deficiencies. Therefore, ESP Ghostscript was developed as an enhancement over GNU Ghostscript, with lots of bug-fixes, additional devices and improvements. It is jointly maintained by developers from CUPS, Gimp-Print, MandrakeSoft, SuSE, RedHat, and Debian. It includes the " cups " device (essential to print to non-PS printers from CUPS).

18.4.6 PostScript Printer Description (PPD) Specification

While PostScript in essence is a Page Description Language (PDL) to represent the page layout in a device-independent way, real-world print jobs are always ending up being output on hardware with device-specific features. To take care of all the differences in hardware and to allow for innovations, Adobe has specified a syntax and file format for PostScript Printer Description (PPD) files. Every PostScript printer ships with one of these files.

PPDs contain all the information about general and special features of the given printer model: Which different resolutions can it handle? Does it have a Duplexing Unit? How many paper trays are there? What media types and sizes does it take? For each item, it also names the special command string to be sent to the printer (mostly inside the PostScript file) in order to enable it.

Information from these PPDs is meant to be taken into account by the printer drivers. Therefore, installed as part of the Windows PostScript driver for a given printer is the printer's PPD. Where it makes sense, the PPD features are presented in the drivers' UI dialogs to display to the user a choice of print options. In the end, the user selections are somehow written (in the form of special PostScript, PJL, JCL or vendor-dependent commands) into the PostScript file created by the driver.

W ARNING

A PostScript file that was created to contain device-specific commands for achieving a certain print job output (e.g., duplexed, stapled and punched) on a specific target machine, may not print as expected, or may not be printable at all on other models; it also may not be fit for further processing by software (e.g., by a PDF distilling program).

18.4.7 Using Windows-Formatted Vendor PPDs

CUPS can handle all spec-compliant PPDs as supplied by the manufacturers for their PostScript models. Even if a vendor might not have mentioned our favorite OS in his manuals and brochures , you can safely trust this: If you get the Windows NT version of the PPD, you can use it unchanged in CUPS and thus access the full power of your printer just like a Windows NT user could!

T IP

To check the spec compliance of any PPD online, go to http://www.cups.org/testppd.php and upload your PPD. You will see the results displayed immediately. CUPS in all versions after 1.1.19 has a much more strict internal PPD parsing and checking code enabled; in case of printing trouble, this online resource should be one of your first pitstops.

W ARNING

For real PostScript printers, do not use the Foomatic or cupsomatic PPDs from Linuxprinting.org. With these devices, the original vendor-provided PPDs are always the first choice!

T IP

If you are looking for an original vendor-provided PPD of a specific device, and you know that an NT4 box (or any other Windows box) on your LAN has the PostScript driver installed, just use smbclient//NT4-box/print\$ -U username to access the Windows directory where all printer driver files are stored. First look in the W32X86/2 subdir for the PPD you are seeking.

18.4.8 CUPS Also Uses PPDs for Non-PostScript Printers

CUPS also uses specially crafted PPDs to handle non-PostScript printers. These PPDs are usually not available from the vendors (and no, you can't just take the PPD of a PostScript printer with the same model name and hope it works for the non-PostScript version too). To understand how these PPDs work for non-PS printers, we first need to dive deeply into the CUPS filtering and file format conversion architecture. Stay tuned .