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 :
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.
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.
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.
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.
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!
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 .