The Common UNIX Print System (CUPS) has become quite popular. All major Linux distributions now ship it as their default printing system. To many, it is still a mystical tool. Mostly, it just works. People tend to regard it as a “black box” that they do not want to look into as long as it works. But once there is a little problem, they have trouble finding out where to start debugging it. Refer to Classical Printing, which contains much information that is also relevant to CUPS.

CUPS sports quite a few unique and powerful features. While its basic functions may be grasped quite easily, they are also new. Because it is different from other, more traditional printing systems, it is best not to try to apply any prior knowledge about printing to this new system. Rather, try to understand CUPS from the beginning. This documentation will lead you to a complete understanding of CUPS. Let's start with the most basic things first.

CUPS is more than just a print spooling system. It is a complete printer management system that complies with the new Internet Printing Protocol (IPP). IPP is an industry and Internet Engineering Task Force (IETF) standard for network printing. Many of its functions can be managed remotely (or locally) via a Web browser (giving you platform-independent access to the CUPS print server). Additionally, it has the traditional command line and several more modern GUI interfaces (GUI interfaces developed by third parties, like KDE's overwhelming KDEPrint).

CUPS allows creation of raw printers (i.e., no print file format translation) as well as smart printers (i.e., CUPS does file format conversion as required for the printer). In many ways, this gives CUPS capabilities similar to the MS Windows print monitoring system. Of course, if you are a CUPS advocate, you would argue that CUPS is better! In any case, let us now explore how to configure CUPS for interfacing with MS Windows print clients via Samba.

Samba has a special relationship to CUPS. Samba can be compiled with CUPS library support. Most recent installations have this support enabled. By default, CUPS linking is compiled into smbd and other Samba binaries. Of course, you can use CUPS even if Samba is not linked against libcups.so but there are some differences in required or supported configuration.

When Samba is compiled and linked with libcups, printcap = cups uses the CUPS API to list printers, submit jobs, query queues, and so on. Otherwise it maps to the System V commands with an additional -oraw option for printing. On a Linux system, you can use the ldd utility to find out if smbd has been linked with the libcups library (ldd may not be present on other OS platforms, or its function may be embodied by a different command):

root# ldd `which smbd`
libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x4002d000)
libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x4005a000)
libcups.so.2 => /usr/lib/libcups.so.2 (0x40123000)
[....]

The line libcups.so.2 => /usr/lib/libcups.so.2 (0x40123000) shows there is CUPS support compiled into this version of Samba. If this is the case, and printing = cups is set, then any otherwise manually set print command in smb.conf is ignored. This is an important point to remember!

To summarize, the Simplest Printing-Related smb.conf file shows the simplest printing-related setup for smb.conf to enable basic CUPS support:

This is all you need for basic printing setup for CUPS. It will print all graphic, text, PDF, and PostScript files submitted from Windows clients. However, most of your Windows users would not know how to send these kinds of files to print without opening a GUI application. Windows clients tend to have local printer drivers installed, and the GUI application's print buttons start a printer driver. Your users also rarely send files from the command line. Unlike UNIX clients, they rarely submit graphic, text, or PDF formatted files directly to the spooler. They nearly exclusively print from GUI applications with a “printer driver” hooked between the application's native format and the print data stream. If the backend printer is not a PostScript device, the print data stream is “binary,” sensible only for the target printer. Read on to learn what problem this may cause and how to avoid it.

The Overriding Global CUPS Settings for One Printer example is a slightly more complex printing-related setup for smb.conf. It enables general CUPS printing support for all printers, but defines one printer share, which is set up differently.

This special share is only for testing purposes. It does not write the print job to a file. It just logs the job parameters known to Samba into the /tmp/smbprn.log file and deletes the job-file. Moreover, the printer admin of this share is “kurt” (not the “@ntadmins” group), guest access is not allowed, the share isn't published to the Network Neighborhood (so you need to know it is there), and it allows access from only three hosts. To prevent CUPS from kicking in and taking over the print jobs for that share, we need to set printing = sysv and printcap = lpstat.

Many small office or home networks, as well as badly organized larger environments, allow each client a direct access to available network printers. This is generally a bad idea. It often blocks one client's access to the printer when another client's job is printing. It might freeze the first client's application while it is waiting to get rid of the job. Also, there are frequent complaints about various jobs being printed with their pages mixed with each other. A better concept is the use of a print server: it routes all jobs through one central system, which responds immediately, takes jobs from multiple concurrent clients, and transfers them to the printer(s) in the correct order.

Most traditionally configured UNIX print servers acting on behalf of Samba's Windows clients represented a really simple setup. Their only task was to manage the “raw” spooling of all jobs handed to them by Samba. This approach meant that the Windows clients were expected to prepare the print job file that is ready to be sent to the printing device. In this case, a native (vendor-supplied) Windows printer driver needs to be installed on each and every client for the target device.

It is possible to configure CUPS, Samba, and your Windows clients in the same traditional and simple way. When CUPS printers are configured for raw print-through mode operation, it is the responsibility of the Samba client to fully render the print job (file). The file must be sent in a format that is suitable for direct delivery to the printer. Clients need to run the vendor-provided drivers to do this. In this case, CUPS will not do any print file format conversion work.

The easiest printing configuration possible is raw print-through. This is achieved by installation of the printer as if it were physically attached to the Windows client. You then redirect output to a raw network print queue. This procedure may be followed to achieve this:

The printer drivers on the Windows clients may be installed in two functionally different ways:

The second method is recommended for use over the first as it reduces the administrative efforts and prevents that different versions of the drivers are used accidentally.

If you use the first option (drivers are installed on the client side), there is one setting to take care of: CUPS needs to be told that it should allow “raw” printing of deliberate (binary) file formats. The CUPS files that need to be correctly set for raw mode printers to work are:

Both contain entries (at the end of the respective files) that must be uncommented to allow RAW mode operation. In /etc/cups/mime.types, make sure this line is present:

application/octet-stream

In /etc/cups/mime.convs, have this line:

application/octet-stream   application/vnd.cups-raw   0   - 

If these two files are not set up correctly for raw Windows client printing, you may encounter the dreaded Unable to convert file 0 in your CUPS error_log file.

Background.  That CUPS is a more security-aware printing system than traditional ones does not by default allow a user to send deliberate (possibly binary) data to printing devices. This could be easily abused to launch a “Denial of Service” attack on your printer(s), causing at least the loss of a lot of paper and ink. “Unknown” data are tagged by CUPS as MIME type: application/octet-stream and not allowed to go to the printer. By default, you can only send other (known) MIME types “raw.” Sending data “raw” means that CUPS does not try to convert them and passes them to the printer untouched.

This is all you need to know to get the CUPS/Samba combo printing “raw” files prepared by Windows clients, which have vendor drivers locally installed. If you are not interested in background information about more advanced CUPS/Samba printing, simply skip the remaining sections of this chapter.

This section describes three familiar methods, plus one new one, by which printer drivers may be uploaded.

If you want to use the MS-RPC-type printing, you must upload the drivers onto the Samba server first ([print$] share). For a discussion on how to deposit printer drivers on the Samba host (so the Windows clients can download and use them via “Point'n'Print”), please refer to the Classical Printing chapter of this book. There you will find a description or reference to three methods of preparing the client drivers on the Samba server:

These three methods apply to CUPS all the same. The cupsaddsmb utility is a new and more convenient way to load the Windows drivers into Samba and is provided if you use CUPS.

cupsaddsmb is discussed in much detail later in this chapter. But we first explore the CUPS filtering system and compare the Windows and UNIX printing architectures.

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 it is so.

You can't expect to throw just any file format at a printer and have it get printed. A file format conversion must take place. 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 Hewlett-Packard) have developed into semi-official “standards” by being the most widely used 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).

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.

The example in Windows Printing to a Local Printer illustrates local Windows printing.

Figure 22.1. Windows Printing to a Local Printer.

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”, 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.

Background.  The PostScript programming language is an “invention” by Adobe, but its specifications have been published extensively. 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 or her 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 that 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.

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 that 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. The RIP does 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 than PostScript printing a file from a Windows origin.

Figure 22.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 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 print files to a format suitable for your printer on the host before you can send it away.

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. This is shown in Ghostscript as a RIP for Non-PostScript Printers.

Figure 22.3. Ghostscript as a RIP for Non-PostScript Printers.

While PostScript in essence is a 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.

CUPS can handle all spec-compliant PPDs as supplied by the manufacturers for their PostScript models. Even if a vendor does not mention our favorite OS in his or her 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!

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.

CUPS reads the file /etc/cups/mime.types (and all other files carrying a *.types suffix in the same directory) upon startup. These files contain the MIME type recognition rules that are applied when CUPS runs its autotyping routines. The rule syntax is explained in the man page for mime.types and in the comments section of the mime.types file itself. A simple rule reads like this:

application/pdf         pdf string(0,%PDF)

This means if a filename has a .pdf suffix or if the magic string %PDF is right at the beginning of the file itself (offset 0 from the start), then it is a PDF file (application/pdf). Another rule is this:

application/postscript  ai eps ps string(0,%!) string(0,<04>%!)

If the filename has one of the suffixes .ai, .eps, .ps, or if the file itself starts with one of the strings %! or <04>%!, it is a generic PostScript file (application/postscript).

CUPS can handle ASCII text, HP-GL, PDF, PostScript, DVI, and many image formats (GIF, PNG, TIFF, JPEG, Photo-CD, SUN-Raster, PNM, PBM, SGI-RGB, and more) and their associated MIME types with its filters.

CUPS reads the file /etc/cups/mime.convs (and all other files named with a *.convs suffix in the same directory) upon startup. These files contain lines naming an input MIME type, an output MIME type, a format conversion filter that can produce the output from the input type, and virtual costs associated with this conversion. One example line reads like this:

application/pdf         application/postscript   33   pdftops

This means that the pdftops filter will take application/pdf as input and produce application/postscript as output; the virtual cost of this operation is 33 CUPS-$. The next filter is more expensive, costing 66 CUPS-$:

application/vnd.hp-HPGL application/postscript   66   hpgltops

This is the hpgltops, which processes HP-GL plotter files to PostScript.

application/octet-stream

Here are two more examples:

application/x-shell     application/postscript   33    texttops
text/plain              application/postscript   33    texttops

The last two examples name the texttops filter to work on text/plain as well as on application/x-shell. (Hint: This differentiation is needed for the syntax highlighting feature of texttops).

There are many more combinations named in mime.convs. However, you are not limited to use the ones predefined there. You can plug in any filter you like to the CUPS framework. It must meet, or must be made to meet, some minimal requirements. If you find (or write) a cool conversion filter of some kind, make sure it complies with what CUPS needs and put in the right lines in mime.types and mime.convs; then it will work seamlessly inside CUPS.

As previously stated, PostScript is the central file format to any UNIX-based printing system. From PostScript, CUPS generates raster data to feed non-PostScript printers.

But what happens if you send one of the supported non-PS formats to print? Then CUPS runs “prefilters” on these input formats to generate PostScript first. There are prefilters to create PostScript from ASCII text, PDF, DVI, or HP-GL. The outcome of these filters is always of MIME type application/postscript (meaning that any device-specific print options are not yet embedded into the PostScript by CUPS and that the next filter to be called is pstops). Another prefilter is running on all supported image formats, the imagetops filter. Its outcome is always of MIME type application/vnd.cups-postscript (not application/postscript), meaning it has the print options already embedded into the file. This is shown in Prefiltering in CUPS to Form PostScript.

Figure 22.4. Prefiltering in CUPS to Form PostScript.

pstops is a filter that is used to convert application/postscript to application/vnd.cups-postscript. As stated earlier, this filter inserts all device-specific print options (commands to the printer to ask for the duplexing of output, or stapling and punching it, and so on) into the PostScript file. An example is illustrated in Adding Device-Specific Print Options.

Figure 22.5. Adding Device-Specific Print Options.

This is not all. Other tasks performed by it are:

pstoraster is at the core of the CUPS filtering system. It is responsible for the first stage of the rasterization process. Its input is of MIME type application/vnd.cups-postscript; its output is application/vnd.cups-raster. This output format is not yet meant to be printable. Its aim is to serve as a general-purpose input format for more specialized raster drivers that are able to generate device-specific printer data. This is shown in the PostScript to Intermediate Raster Format diagram.

Figure 22.6. PostScript to Intermediate Raster Format.

CUPS raster is a generic raster format with powerful features. It is able to include per-page information, color profiles, and more, to be used by the downstream raster drivers. Its MIME type is registered with IANA and its specification is, of course, completely open. It is designed to make it quite easy and inexpensive for manufacturers to develop Linux and UNIX raster drivers for their printer models should they choose to do so. CUPS always takes care of the first stage of rasterization so these vendors do not need to care about Ghostscript complications (in fact, there are currently more than one vendor financing the development of CUPS raster drivers). This is illustrated in the CUPS-Raster Production Using Ghostscript illustration.

Figure 22.7. CUPS-Raster Production Using Ghostscript.

CUPS versions before version 1.1.15 shipped a binary (or source code) standalone filter, named pstoraster. pstoraster, which was derived from GNU Ghostscript 5.50 and could be installed instead of and in addition to any GNU or AFPL Ghostscript package without conflicting.

Since version 1.1.15, this feature has changed. The functions for this filter have been integrated back into Ghostscript (now based on GNU Ghostscript version 7.05). The pstoraster filter is now a simple shell script calling gs with the -sDEVICE=cups parameter. If your Ghostscript fails when this command is executed: gs -h |grep cups, you might not be able to print, update your Ghostscript.

In the section about prefilters, we mentioned the prefilter that generates PostScript from image formats. The imagetoraster filter is used to convert directly from image to raster, without the intermediate PostScript stage. It is used more often than the previously mentioned prefilters. We summarize in a flowchart the image file filtering in the Image Format to CUPS-Raster Format Conversion illustration.

Figure 22.8. Image Format to CUPS-Raster Format Conversion.

CUPS ships with quite a variety of raster drivers for processing CUPS raster. On my system, I find in /usr/lib/cups/filter/ the following: rastertoalps, rastertobj, rastertoepson, rastertoescp, rastertopcl, rastertoturboprint, rastertoapdk, rastertodymo, rastertoescp, rastertohp, and rastertoprinter. Don't worry if you have fewer drivers than this; some of these are installed by commercial add-ons to CUPS (like rastertoturboprint), and others (like rastertoprinter) by third-party driver development projects (such as Gutenprint) wanting to cooperate as closely as possible with CUPS. See the Raster to Printer-Specific Formats illustration.

Figure 22.9. Raster to Printer-Specific Formats.

The last part of any CUPS filtering chain is a backend. Backends are special programs that send the print-ready file to the final device. There is a separate backend program for any transfer protocol for sending print jobs over the network, and one for every local interface. Every CUPS print queue needs to have a CUPS “device-URI” associated with it. The device URI is the way to encode the backend used to send the job to its destination. Network device-URIs use two slashes in their syntax, local device URIs only one, as you can see from the following list. Keep in mind that local interface names may vary greatly from my examples, if your OS is not Linux:

It is easy to write your own backends as shell or Perl scripts if you need any modification or extension to the CUPS print system. One reason could be that you want to create “special” printers that send the print jobs as email (through a “mailto:/” backend), convert them to PDF (through a “pdfgen:/” backend) or dump them to “/dev/null”. (In fact, I have the systemwide default printer set up to be connected to a devnull:/ backend: there are just too many people sending jobs without specifying a printer, and scripts and programs that do not name a printer. The systemwide default deletes the job and sends a polite email back to the $USER asking him or her to always specify the correct printer name.)

Not all of the mentioned backends may be present on your system or usable (depending on your hardware configuration). One test for all available CUPS backends is provided by the lpinfo utility. Used with the -v parameter, it lists all available backends:

	$ lpinfo -v
	

cupsomatic filters may be the most widely used on CUPS installations. You must be clear that these were not developed by the CUPS people. They are a third-party add-on to CUPS. They utilize the traditional Ghostscript devices to render jobs for CUPS. When troubleshooting, you should know about the difference. Here the whole rendering process is done in one stage, inside Ghostscript, using an appropriate device for the target printer. cupsomatic uses PPDs that are generated from the Foomatic Printer & Driver Database at Linuxprinting.org.

You can recognize these PPDs from the line calling the cupsomatic filter:

*cupsFilter: "application/vnd.cups-postscript  0  cupsomatic"

You may find this line among the first 40 or so lines of the PPD file. If you have such a PPD installed, the printer shows up in the CUPS Web interface with a foomatic namepart for the driver description. cupsomatic is a Perl script that runs Ghostscript with all the complicated command line options autoconstructed from the selected PPD and command line options given to the print job.

However, cupsomatic is now deprecated. Its PPDs (especially the first generation of them, still in heavy use out there) are not meeting the Adobe specifications. You might also suffer difficulties when you try to download them with “Point'n'Print” to Windows clients. A better and more powerful successor is now available: it is called foomatic-rip. To use foomatic-rip as a filter with CUPS, you need the new type of PPDs, which have a similar but different line:

*cupsFilter: "application/vnd.cups-postscript  0  foomatic-rip"

The PPD-generating engine at Linuxprinting.org has been revamped. The new PPDs comply with the Adobe spec. They also provide a new way to specify different quality levels (hi-res photo, normal color, grayscale, and draft) with a single click, whereas before you could have required five or more different selections (media type, resolution, inktype, and dithering algorithm). There is support for custom-size media built in. There is support to switch print options from page to page in the middle of a job. And the best thing is that the new foomatic-rip works seamlessly with all legacy spoolers too (like LPRng, BSD-LPD, PDQ, PPR, and so on), providing for them access to use PPDs for their printing.

If you want to see an overview of all the filters and how they relate to each other, the complete picture of the puzzle is at the end of this chapter.

CUPS autoconstructs all possible filtering chain paths for any given MIME type and every printer installed. But how does it decide in favor of or against a specific alternative? (There may be cases where there is a choice of two or more possible filtering chains for the same target printer.) Simple. You may have noticed the figures in the third column of the mime.convs file. They represent virtual costs assigned to this filter. Every possible filtering chain will sum up to a total “filter cost.” CUPS decides for the most “inexpensive” route.

You can tell CUPS to print (nearly) any file “raw”. “Raw” means it will not be filtered. CUPS will send the file to the printer “as is” without bothering if the printer is able to digest it. Users need to take care themselves that they send sensible data formats only. Raw printing can happen on any queue if the “-o raw” option is specified on the command line. You can also set up raw-only queues by simply not associating any PPD with it. This command:

$ lpadmin -P rawprinter -v socket://11.12.13.14:9100 -E

sets up a queue named “rawprinter”, connected via the “socket” protocol (a.k.a. “HP JetDirect”) to the device at IP address 11.12.1.3.14, using port 9100. (If you had added a PPD with -P /path/to/PPD to this command line, you would have installed a “normal” print queue.)

CUPS will automatically treat each job sent to a queue as a “raw” one if it can't find a PPD associated with the queue. However, CUPS will only send known MIME types (as defined in its own mime.types file) and refuse others.

Any MIME type with no rule in the /etc/cups/mime.types file is regarded as unknown or application/octet-stream and will not be sent. Because CUPS refuses to print unknown MIME types by default, you will probably have experienced that print jobs originating from Windows clients were not printed. You may have found an error message in your CUPS logs like:

Unable to convert file 0 to printable format for job

To enable the printing of application/octet-stream files, edit these two files:

Both contain entries (at the end of the respective files) that must be uncommented to allow raw mode operation for application/octet-stream. In /etc/cups/mime.types make sure this line is present:

application/octet-stream

This line (with no specific autotyping rule set) makes all files not otherwise auto-typed a member of application/octet-stream. In /etc/cups/mime.convs, have this line:

application/octet-stream   application/vnd.cups-raw   0   -

This line tells CUPS to use the Null Filter (denoted as “-”, doing nothing at all) on application/octet-stream, and tag the result as application/vnd.cups-raw. This last one is always a green light to the CUPS scheduler to now hand the file over to the backend connecting to the printer and sending it over.

Background.  That CUPS is a more security-aware printing system than traditional ones does not by default allow one to send deliberate (possibly binary) data to printing devices. (This could be easily abused to launch a Denial of Service attack on your printer(s), causing at least the loss of a lot of paper and ink.) “Unknown” data are regarded by CUPS as MIME type application/octet-stream. While you can send data “raw”, the MIME type for these must be one that is known to CUPS and allowed by it. The file /etc/cups/mime.types defines the “rules” of how CUPS recognizes MIME types. The file /etc/cups/mime.convs decides which file conversion filter(s) may be applied to which MIME types.

Originally PPDs were meant to be used for PostScript printers only. Here, they help to send device-specific commands and settings to the RIP, which processes the job file. CUPS has extended this scope for PPDs to cover non-PostScript printers too. This was not difficult, because it is a standardized file format. In a way it was logical too: CUPS handles PostScript and uses a PostScript RIP (Ghostscript) to process the job files. The only difference is that a PostScript printer has the RIP built-in, for other types of printers the Ghostscript RIP runs on the host computer.

PPDs for a non-PostScript printer have a few lines that are unique to CUPS. The most important one looks similar to this:

*cupsFilter: application/vnd.cups-raster  66   rastertoprinter

It is the last piece in the CUPS filtering puzzle. This line tells the CUPS daemon to use as a last filter rastertoprinter. This filter should be served as input an application/vnd.cups-raster MIME type file. Therefore, CUPS should autoconstruct a filtering chain, which delivers as its last output the specified MIME type. This is then taken as input to the specified rastertoprinter filter. After the last filter has done its work (rastertoprinter is a Gutenprint filter), the file should go to the backend, which sends it to the output device.

CUPS by default ships only a few generic PPDs, but they are good for several hundred printer models. You may not be able to control different paper trays, or you may get larger margins than your specific model supports. See Table 21.1“PPDs Shipped with CUPS” for summary information.

Native CUPS rasterization works in two steps:

Often this produces better quality (and has several more advantages) than other methods. This is shown in the cupsomatic/foomatic Processing Versus Native CUPS illustration.

Figure 22.10. cupsomatic/foomatic Processing Versus Native CUPS.

One other method is the cupsomatic/foomatic-rip way. Note that cupsomatic is not made by the CUPS developers. It is an independent contribution to printing development, made by people from Linuxprinting.org.^[6] cupsomatic is no longer developed, maintained, or supported. It now been replaced by foomatic-rip. foomatic-rip is a complete rewrite of the old cupsomatic idea, but very much improved and generalized to other (non-CUPS) spoolers. An upgrade to foomatic-rip is strongly advised, especially if you are upgrading to a recent version of CUPS, too.

Like the old cupsomatic method, the foomatic-rip (new) method from Linuxprinting.org uses the traditional Ghostscript print file processing, doing everything in a single step. It therefore relies on all the other devices built into Ghostscript. The quality is as good (or bad) as Ghostscript rendering is in other spoolers. The advantage is that this method supports many printer models not supported (yet) by the more modern CUPS method.

Of course, you can use both methods side by side on one system (and even for one printer, if you set up different queues) and find out which works best for you.

cupsomatic kidnaps the print file after the application/vnd.cups-postscript stage and deviates it through the CUPS-external, systemwide Ghostscript installation. Therefore, the print file bypasses the pstoraster filter (and also bypasses the CUPS raster drivers rastertosomething). After Ghostscript finished its rasterization, cupsomatic hands the rendered file directly to the CUPS backend. cupsomatic/foomatic Processing Versus Native CUPS, illustrates the difference between native CUPS rendering and the Foomatic/cupsomatic method.

Here are a few examples of commonly occurring filtering chains to illustrate the workings of CUPS.

Assume you want to print a PDF file to an HP JetDirect-connected PostScript printer, but you want to print pages 3-5, 7, and 11-13 only, and you want to print them “two-up” and “duplex”:

The resulting filter chain, therefore, is as shown in the PDF to socket chain illustration.

Figure 22.11. PDF to Socket Chain.

Assume you want to print the same filter to an USB-connected Epson Stylus Photo Printer installed with the CUPS stphoto2.ppd. The first few filtering stages are nearly the same:

The resulting filter chain therefore is as shown in the PDF to USB Chain illustration.

Figure 22.12. PDF to USB Chain.

On the Internet you can now find many thousands of CUPS-PPD files (with their companion filters), in many national languages supporting more than 1,000 non-PostScript models.

CUPS also supports the use of “interface scripts” as known from System V AT&T printing systems. These are often used for PCL printers, from applications that generate PCL print jobs. Interface scripts are specific to printer models. They have a role similar to PPDs for PostScript printers. Interface scripts may inject the Escape sequences as required into the print data stream if the user, for example, selects a certain paper tray, or changes paper orientation, or uses A3 paper. Interface scripts are practically unknown in the Linux realm. On HP-UX platforms they are more often used. You can use any working interface script on CUPS too. Just install the printer with the -i option:

root# lpadmin -p pclprinter -v socket://11.12.13.14:9100 \
          -i /path/to/interface-script

Interface scripts might be the “unknown animal” to many. However, with CUPS they provide the easiest way to plug in your own custom-written filtering script or program into one specific print queue (some information about the traditional use of interface scripts is found at http://playground.sun.com/printing/documentation/interface.html).

Windows clients printing to an NT-based print server have two options. They may:

Both print paths are shown in the flowcharts in Print Driver Execution on the Client, and Print Driver Execution on the Server.

In the first case, the print server must spool the file as raw, meaning it shouldn't touch the job file and try to convert it in any way. This is what a traditional UNIX-based print server can do too, and at a better performance and more reliably than an NT print server. This is what most Samba administrators probably are familiar with. One advantage of this setup is that this “spooling-only” print server may be used even if no driver(s) for UNIX is available. It is sufficient to have the Windows client drivers available and installed on the clients. This is illustrated in the Print Driver Execution on the Client diagram.

Figure 22.13. Print Driver Execution on the Client.

The other path executes the printer driver on the server. The client transfers print files in EMF format to the server. The server uses the PostScript, PCL, ESC/P, or other driver to convert the EMF file into the printer-specific language. It is not possible for UNIX to do the same. Currently, there is no program or method to convert a Windows client's GDI output on a UNIX server into something a printer could understand. This is illustrated in the Print Driver Execution on the Server diagram.

Figure 22.14. Print Driver Execution on the Server.

However, something similar is possible with CUPS, so read on.

Here is a simple recipe showing how you can take advantage of CUPS's powerful features for the benefit of your Windows network printing clients:

This requires the clients to use a PostScript driver (even if the printer is a non-PostScript model. It also requires that you have a driver on the CUPS server.

First, to enable CUPS-based printing through Samba, the following options should be set in your smb.conf file [global] section: