The Common UNIX Print System (CUPS) has become very popular. All major Linux distributions now ship it as their default printing system. To many it is still a very mystical tool. Mostly, it "just works" (TM). People tend to regard it as a "black box" which they don't want to look into, as long as it works. But once there is a little problem, they are in trouble to find out where to start debugging it. Refer to the "Classical Printing" chapter also, it contains a lot of information that is relevant for CUPS.

CUPS sports quite a few unique and powerful features. While their basic functions may be grasped quite easily, they are also new. Because they are different from other, more traditional printing systems, it is best to try and not apply any prior knowledge about printing upon 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 IPP (Internet Printing Protocol). IPP is an industry and IETF (Internet Engineering Task Force) standard for network printing. Many of its functions can be managed remotely (or locally) via a web browser (giving you a 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 3rd parties, like KDE's overwhelming KDEPrint).

CUPS allows creation of "raw" printers (ie: 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 similar capabilities 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 move on to explore how one may configure CUPS for interfacing with MS Windows print clients via Samba.

Samba has a very special relationship to CUPS. Samba can be compiled with CUPS library support. Most recent installations have this support enabled. Per 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 then.

When Samba is compiled against libcups, printcap = cups uses the CUPS API to list printers, submit jobs, query queues, etc. 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 details (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, here is 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 file submitted from Windows clients. However, most of your Windows users would not know how to send these kind 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 very rarely send files from the command line. Unlike UNIX clients, they hardly submit graphic, text or PDF formatted files directly to the spooler. They nearly exclusively print from GUI applications, with a "printer driver" hooked in between the applications 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 which problem this may cause and how to avoid it.

Here 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 there 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 jobfile. Moreover, the printer admin of this share is "kurt" (not the "@ntadmins" group); guest access is not allowed; the share isn not published to the Network Neighbourhood (so you need to know it is there), and it only allows access from only three hosts. To prevent CUPS 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 also 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 usage of a "print server": it routes all jobs through one central system, which responds immediately, takes jobs from multiple concurrent clients at the same time and in turn 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 it s ready to be sent to the printing device. Here a native (vendor-supplied) Windows printer driver for the target device needed to be installed on each and every client.

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 printer drivers on the Windows clients may be installed in two functionally different ways:

The second method is recommended for use over the first.

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) which 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.  CUPS being 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 the 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 (see next chapter for even more background explanations).

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.

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 that the Windows clients can download and use them via "Point'n'Print") please also refer to the previous chapter of this HOWTO Collection. There you will find a description or reference to three methods of preparing the client drivers on the Samba server:

These 3 methods apply to CUPS all the same. A new and more convenient way to load the Windows drivers into Samba is provided if you use CUPS:

cupsaddsmb is discussed in much detail further below. But we will 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 an administrator may encounter. This is true for all OS platforms. And there are reasons for this.

You can't expect for most file formats to just throw them towards printers and they get printed. There needs to be a file format conversion in between. The problem is: 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), there are still many manufacturers who "roll their own" (their reasons may be unacceptable license fees for using printer-embedded PostScript interpreters, etc.).

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 GDI (Graphical Device Interface), 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, produces often a file format called EMF (Enhanced MetaFile). The EMF is processed by the printer driver and converted to the printer-specific file format.

Figure 19.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. That gives at least 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 how 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 over 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.

Background.  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, 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 are 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.

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 towards 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 of a file from a Windows origin.

Figure 19.2. Printing to a Postscript Printer

However, there are other types of printers out there. These don't 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 don't understand PostScript, you need to convert the printfiles 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 to do a lot of file format conversions, for a very broad spectrum of hardware devices as well as software file formats. Ghostscript technology and drivers is what enables PostScript printing to non-PostScript hardware.

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

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 to be output on a 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 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 as 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 UNIX/Linux-illiterate vendor might not have mentioned our favorite OS in his manuals and brochures -- you can safely trust this: if you get hold of 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 which are applied when CUPS runs its auto-typing 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 either 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>%!)

Its meaning: 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 a lot of image formats (GIF. PNG, TIFF, JPEG, Photo-CD, SUN-Raster, PNM, PBM, SGI-RGB and some 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 which 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 pre-defined there. You can plug in any filter you like into 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 to what CUPS needs, and put in the right lines in mime.types and mime.convs, then it will work seamlessly inside CUPS!

As was said, 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 is happening if you send one of the supported non-PS formats to print? Then CUPS runs "pre-filters" on these input formats to generate PostScript first. There are pre-filters to create PS 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 pre-filter 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.

Figure 19.4. Prefiltering in CUPS to form Postscript

pstopsis the filter to convert application/postscript to application/vnd.cups-postscript. It was said above that this filter inserts all device-specific print options (commands to the printer to ask for the duplexing of output, or stapling an punching it, etc.) into the PostScript file.

Figure 19.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.

Figure 19.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 following downstream raster drivers. Its MIME type is registered with IANA and its specification is of course completely open. It is designed to make it very 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 for the first stage of rasterization so these vendors don't need to care about Ghostscript complications (in fact, there is currently more than one vendor financing the development of CUPS raster drivers).

Figure 19.7. CUPS-raster production using Ghostscript

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

From version 1.1.15, this has changed. The functions for this has 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 doesn't show a success on asking for gs -h |grep cups, you might not be able to print. Update your Ghostscript then!

Above 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 above mentioned prefilters. Here is a summarizing flowchart of image file filtering:

Figure 19.8. Image format to CUPS-raster format conversion

CUPS ships with quite some different raster drivers processing CUPS raster. On my system I find in /usr/lib/cups/filter/ these: rastertoalps, rastertobj, rastertoepson, rastertoescp, rastertopcl, rastertoturboprint, rastertoapdk, rastertodymo, rastertoescp, rastertohp and rastertoprinter. Don't worry if you have less than this; some of these are installed by commercial add-ons to CUPS (like rastertoturboprint), others (like rastertoprinter) by 3rd party driver development projects (such as Gimp-Print) wanting to cooperate as closely as possible with CUPS.

Figure 19.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" of sending printjobs over the network, or for every local interface. Every CUPS printqueue 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 are using 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 much 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 which send the printjobs 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 system-wide default printer set up to be connected to a "devnull:/" backend: there are just too many people sending jobs without specifying a printer, or scripts and programs which don't name a printer. The system-wide default deletes the job and sends a polite mail back to the $USER asking him to always specify a correct printername).

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 about the fact 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 which 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"

This line you may find amongst 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 commandline options auto-constructed from the selected PPD and commandline options give to the printjob.

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 in a very stable Beta-version available: it is called foomatic-rip. To use foomatic-rip as a filter with CUPS, you need the new-type PPDs. These 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 to the Adobe spec. On top, they also provide a new way to specify different quality levels (hi-res photo, normal color, grayscale, draft...) with a single click (whereas before you could have required 5 or more different selections (media type, resolution, inktype, 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: the new foomatic-rip now works seamlessly with all legacy spoolers too (like LPRng, BSD-LPD, PDQ, PPR etc.), providing for them access to use PPDs for their printing!

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

CUPS auto-constructs all possible filtering chain paths for any given MIME type, and every printer installed. But how does it decide in favor or against a specific alternative? (There may often 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 3rd 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" printqueue.

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 per default, you will probably have experienced the fact that printjobs 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) which 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 auto-typing 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.  CUPS being 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 an allowed one. The file /etc/cups/mime.types defines the "rules" 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 jobfile. CUPS has extended this scope for PPDs to cover non-PostScript printers too. This was not very 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 jobfiles. The only difference is: 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-PS 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 auto-construct 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 this the last filter has done its work ("rastertoprinter" is a Gimp-Print 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):

Native CUPS rasterization works in two steps.

Often this produces better quality (and has several more advantages) than other methods.

Figure 19.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 (see also http://www.cups.org/cups-help.html). cupsomatic is no longer developed and maintained and is no longer supported. It has now been replaced by foomatic-rip. foomatic-rip is a complete re-write 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.

Both the cupsomatic (old) and the foomatic-rip (new) methods from Linuxprinting.org use the traditional Ghostscript print file processing, doing everything in a single step. It therefore relies on all the other devices built-in 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 printfile after the application/vnd.cups-postscript stage and deviates it through the CUPS-external, system wide Ghostscript installation: Therefore the printfile bypasses the "pstoraster" filter (and thus also bypasses the CUPS-raster-drivers "rastertosomething"). After Ghostscript finished its rasterization, cupsomatic hands the rendered file directly to the CUPS backend. The flowchart above 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 a HP JetDirect-connected PostScript printer, but you want to print the pages 3-5, 7, 11-13 only, and you want to print them "2-up" and "duplex":

The resulting filter chain therefore is as drawn in the image below.

Figure 19.11. PDF to socket chain

Assume your 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 drawn in the image below.

Figure 19.12. PDF to USB chain

On the internet you can find now many thousand CUPS-PPD files (with their companion filters), in many national languages, supporting more than 1000 non-PostScript models.

CUPS also supports the usage 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 similar role as PPDs for PostScript printers. Interface scripts may inject the Escape sequences as required into the print data stream, if the user has chosen to select a certain paper tray, or print landscape, or use A3 paper, etc. Interfaces 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 most easy way to plug in your own custom-written filtering script or program into one specific print queue (some information about the traditional usage of interface scripts is to be 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 below.

In the first case the print server must spool the file as "raw", meaning it shouldn't touch the jobfile and try to convert it in any way. This is what traditional UNIX-based print server can do too; and at a better performance and more reliably than 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 are available it is sufficient to have the Windows client drivers available and installed on the clients.

Figure 19.13. Print Driver execution on the Client

The other path executes the printer driver on the server. The clients 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.

Figure 19.14. Print Driver execution on the Server

However, there is something similar possible with CUPS. Read on...

Here is a simple recipe showing how you can take advantage of CUPS 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.

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

When these parameters are specified, all manually set print directives (like print command, or lppause command) in smb.conf (as well as in samba itself) will be ignored. Instead, Samba will directly interface with CUPS through it's application program interface (API) - as long as Samba has been compiled with CUPS library (libcups) support. If Samba has NOT been compiled with CUPS support, and if no other print commands are set up, then printing will use the System V AT&T command set, with the -oraw option automatically passing through (if you want your own defined print commands to work with a Samba that has CUPS support compiled in, simply use printing = sysv).

Figure 19.15. Printing via CUPS/samba server

Samba must use its own spool directory (it is set by a line similar to path = /var/spool/samba, in the [printers] or [printername] section of smb.conf). Samba receives the job in its own spool space and passes it into the spool directory of CUPS (the CUPS spooling directory is set by the RequestRoot directive, in a line that defaults to RequestRoot /var/spool/cups). CUPS checks the access rights of its spool dir and resets it to healthy values with every re-start. We have seen quite some people who had used a common spooling space for Samba and CUPS, and were struggling for weeks with this "problem".

A Windows user authenticates only to Samba (by whatever means is configured). If Samba runs on the same host as CUPS, you only need to allow "localhost" to print. If they run on different machines, you need to make sure the Samba host gets access to printing on CUPS.

CUPS doesn't limit itself to "real" PostScript printers in its usage of PPDs. The CUPS developers have extended the scope of the PPD concept, to also describe available device and driver options for non-PostScript printers through CUPS-PPDs.

This is logical, as CUPS includes a fully featured PostScript interpreter (RIP). This RIP is based on Ghostscript. It can process all received PostScript (and additionally many other file formats) from clients. All CUPS-PPDs geared to non-PostScript printers contain an additional line, starting with the keyword *cupsFilter . This line tells the CUPS print system which printer-specific filter to use for the interpretation of the supplied PostScript. Thus CUPS lets all its printers appear as PostScript devices to its clients, because it can act as a PostScript RIP for those printers, processing the received PostScript code into a proper raster print format.

CUPS-PPDs can also be used on Windows-Clients, on top of a "core" PostScript driver (now recommended is the "CUPS PostScript Driver for WindowsNT/2K/XP"; you can also use the Adobe one, with limitations). This feature enables CUPS to do a few tricks no other spooler can do:

Using CUPS PPDs on Windows clients enables these to control all print job settings just as a UNIX client can do too.

The reason is that in Win NT printer drivers run in "Kernel Mode", this introduces a high risk for the stability of the system if the driver is not really stable and well-tested. And there are a lot of bad drivers out there! Especially notorious is the example of the PCL printer driver that had an additional sound module running, to notify users via soundcard of their finished jobs. Do I need to say that this one was also reliably causing "Blue Screens of Death" on a regular basis?

PostScript drivers generally are very well tested. They are not known to cause any problems, even though they run in Kernel Mode too. This might be because there have so far only been 2 different PostScript drivers: the ones from Adobe and the one from Microsoft. Both are very well tested and are as stable as you ever can imagine on Windows. The CUPS driver is derived from the Microsoft one.

In many cases, in an attempt to work around this problem, site administrators have resorted to restrict the allowed drivers installed on their WTS to one generic PCL- and one PostScript driver. This however restricts the clients in the amount of printer options available for them; often they can't get out more than simplex prints from one standard paper tray, while their devices could do much better, if driven by a different driver! )

Using a PostScript driver, enabled with a CUPS-PPD, seems to be a very elegant way to overcome all these shortcomings. There are, depending on the version of Windows OS you use, up to 3 different PostScript drivers available: Adobe, Microsoft and CUPS PostScript drivers. None of them is known to cause major stability problems on WTS (even if used with many different PPDs). The clients will be able to (again) chose paper trays, duplex printing and other settings. However, there is a certain price for this too: a CUPS server acting as a PostScript RIP for its clients requires more CPU and RAM than when just acting as a "raw spooling" device. Plus, this setup is not yet widely tested, although the first feedbacks look very promising.

More recent printer drivers on W2K and XP don't run in Kernel mode (unlike Win NT) any more. However, both operating systems can still use the NT drivers, running in Kernel mode (you can roughly tell which is which as the drivers in subdirectory "2" of "W32X86" are "old" ones). As was said before, the Adobe as well as the Microsoft PostScript drivers are not known to cause any stability problems. The CUPS driver is derived from the Microsoft one. There is a simple reason for this: The MS DDK (Device Development Kit) for Win NT (which used to be available at no cost to licensees of Visual Studio) includes the source code of the Microsoft driver, and licensees of Visual Studio are allowed to use and modify it for their own driver development efforts. This is what the CUPS people have done. The license doesn't allow them to publish the whole of the source code. However, they have released the "diff" under the GPL, and if you are owner of an "MS DDK for Win NT", you can check the driver yourself.

The cupsaddsmb utility (shipped with all current CUPS versions) is an alternative method to transfer printer drivers into the Samba [print$] share. Remember, this share is where clients expect drivers deposited and setup for download and installation. It makes the sharing of any (or all) installed CUPS printers very easy. cupsaddsmb can use the Adobe PostScript driver as well as the newly developed CUPS PostScript Driver for WinNT/2K/XP. Note, that cupsaddsmb does not work with arbitrary vendor printer drivers, but only with the exact driver files that are named in its man page.

The CUPS printer driver is available from the CUPS download site. Its package name is cups-samba-[version].tar.gz . It is preferred over the Adobe drivers since it has a number of advantages:

However, currently only Windows NT, 2000, and XP are supported by the CUPS drivers. You will need to get the respective part of Adobe driver too if you need to support Windows 95, 98, and ME clients.

Prior to running cupsaddsmb, you need the following settings in smb.conf:

CUPS users may get the exactly same packages from http://www.cups.org/software.html. It is a separate package from the CUPS base software files, tagged as CUPS 1.1.x Windows NT/2k/XP Printer Driver for Samba (tar.gz, 192k). The filename to download is cups-samba-1.1.x.tar.gz. Upon untar-/unzip-ing, it will reveal these files:

root# tar xvzf cups-samba-1.1.19.tar.gz
cups-samba.install
cups-samba.license
cups-samba.readme
cups-samba.remove
cups-samba.ss

These have been packaged with the ESP meta packager software "EPM". The *.install and *.remove files are simple shell scripts, which untars the *.ss (the *.ss is nothing else but a tar-archive, which can be untar-ed by "tar" too). Then it puts the content into /usr/share/cups/drivers/. This content includes 3 files:

root# tar tv cups-samba.ss
cupsdrvr.dll
cupsui.dll
cups.hlp  

The cups-samba.install shell scripts is easy to handle:

root# ./cups-samba.install
[....]
Installing software...
Updating file permissions...
Running post-install commands...
Installation is complete.        

The script should automatically put the driver files into the /usr/share/cups/drivers/ directory.

root# cp /usr/share/drivers/cups.hlp /usr/share/cups/drivers/

This new CUPS PostScript driver is currently binary-only, but free of charge. No complete source code is provided (yet). The reason is this: it has been developed with the help of the Microsoft Driver Developer Kit (DDK) and compiled with Microsoft Visual Studio 6. Driver developers are not allowed to distribute the whole of the source code as Free Software. However, CUPS developers released the "diff" in source code under the GPL, so anybody with a license of Visual Studio and a DDK will be able to compile for him/herself.

The CUPS drivers don't support the "older" Windows 95/98/ME, but only the Windows NT/2000/XP client:

Windows NT, 2000, and XP are supported by:

Adobe drivers are available for the older Windows 95/98/ME as well as the Windows NT/2000/XP clients. The set of files is different for the different platforms.

Windows 95, 98, and Me are supported by:

Windows NT, 2000, and XP are supported by:

Acquiring the Adobe driver files seems to be unexpectedly difficult for many users. They are not available on the Adobe website as single files and the self-extracting and/or self-installing Windows-exe is not easy to locate either. Probably you need to use the included native installer and run the installation process on one client once. This will install the drivers (and one Generic PostScript printer) locally on the client. When they are installed, share the Generic PostScript printer. After this, the client's [print$] share holds the Adobe files, from where you can get them with smbclient from the CUPS host. A more detailed description about this is in the next (the CUPS printing) chapter.

Users of the ESP Print Pro software are able to install their "Samba Drivers" package for this purpose with no problem. Retrieve the driver files from the normal download area of the ESP Print Pro software at http://www.easysw.com/software.html. You need to locate the link labelled "SAMBA" amongst the Download Printer Drivers for ESP Print Pro 4.x area and download the package. Once installed, you can prepare any driver by simply highlighting the printer in the Printer Manager GUI and select Export Driver... from the menu. Of course you need to have prepared Samba beforehand too to handle the driver files; i.e. mainly setup the [print$] share, etc. The ESP Print Pro package includes the CUPS driver files as well as a (licensed) set of Adobe drivers for the Windows 95/98/ME client family.

Once you have run the install script (and possibly manually moved the cups.hlp file to /usr/share/cups/drivers/), the driver is ready to be put into Samba's [print$] share (which often maps to /etc/samba/drivers/ and contains a subdir tree with WIN40 and W32X86 branches): You do this by running "cupsaddsmb" (see also man cupsaddsmb for CUPS since release 1.1.16).

Once the driver files are in the [print$] share and are initialized, they are ready to be downloaded and installed by the Win NT/2k/XP clients.

You are interested in a comparison between the CUPS and the Adobe PostScript drivers? For our purposes these are the most important items which weigh in favor of the CUPS ones:

The cupsaddsmb command copies the needed files into your [print$] share. Additionally, the PPD associated with this printer is copied from /etc/cups/ppd/ to [print$]. There the files wait for convenient Windows client installations via Point'n'Print. Before we can run the command successfully, we need to be sure that we can authenticate towards Samba. If you have a small network you are probably using user level security (security = user).

Here is an example of a successfully run cupsaddsmb command.

root# cupsaddsmb -U root infotec_IS2027
Password for root required to access localhost via Samba: ['secret']

To share all printers and drivers, use the -a parameter instead of a printer name. Since cupsaddsmb "exports" the printer drivers to Samba, it should be obvious that it only works for queues with a CUPS driver associated.

Probably you want to see what's going on. Use the -v parameter to get a more verbose output. The output below was edited for better readability: all "\" at the end of a line indicate that I inserted an artificial line break plus some indentation here:

root# cupsaddsmb -U root -v infotec_2105
Password for root required to access localhost via GANDALF:
Running command: smbclient //localhost/print\$ -N -U'root%secret' \
    -c 'mkdir W32X86; \
    put /var/spool/cups/tmp/3e98bf2d333b5 W32X86/infotec_2105.ppd; \
	put /usr/share/cups/drivers/cupsdrvr.dll W32X86/cupsdrvr.dll; \
    put /usr/share/cups/drivers/cupsui.dll W32X86/cupsui.dll; \
    put /usr/share/cups/drivers/cups.hlp W32X86/cups.hlp'
added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0
Domain=[CUPS-PRINT] OS=[UNIX] Server=[Samba 2.2.7a]
NT_STATUS_OBJECT_NAME_COLLISION making remote directory \W32X86
putting file /var/spool/cups/tmp/3e98bf2d333b5 as \W32X86/infotec_2105.ppd
putting file /usr/share/cups/drivers/cupsdrvr.dll as \W32X86/cupsdrvr.dll
putting file /usr/share/cups/drivers/cupsui.dll as \W32X86/cupsui.dll
putting file /usr/share/cups/drivers/cups.hlp as \W32X86/cups.hlp
  
Running command: rpcclient localhost -N -U'root%secret' 
   -c 'adddriver "Windows NT x86"   \
   "infotec_2105:cupsdrvr.dll:infotec_2105.ppd:cupsui.dll:cups.hlp:NULL:   \
    RAW:NULL"'
cmd = adddriver "Windows NT x86" \
    "infotec_2105:cupsdrvr.dll:infotec_2105.ppd:cupsui.dll:cups.hlp:NULL:RAW:NULL"
Printer Driver infotec_2105 successfully installed.
  
Running command: smbclient //localhost/print\$ -N -U'root%secret' \
-c 'mkdir WIN40; \
    put /var/spool/cups/tmp/3e98bf2d333b5 WIN40/infotec_2105.PPD; \
	put /usr/share/cups/drivers/ADFONTS.MFM WIN40/ADFONTS.MFM;   \
    put /usr/share/cups/drivers/ADOBEPS4.DRV WIN40/ADOBEPS4.DRV; \
    put /usr/share/cups/drivers/ADOBEPS4.HLP WIN40/ADOBEPS4.HLP; \
    put /usr/share/cups/drivers/DEFPRTR2.PPD WIN40/DEFPRTR2.PPD; \
	put /usr/share/cups/drivers/ICONLIB.DLL WIN40/ICONLIB.DLL; \
	put /usr/share/cups/drivers/PSMON.DLL WIN40/PSMON.DLL;'
  added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0
  Domain=[CUPS-PRINT] OS=[UNIX] Server=[Samba 2.2.7a]
  NT_STATUS_OBJECT_NAME_COLLISION making remote directory \WIN40
  putting file /var/spool/cups/tmp/3e98bf2d333b5 as \WIN40/infotec_2105.PPD
  putting file /usr/share/cups/drivers/ADFONTS.MFM as \WIN40/ADFONTS.MFM
  putting file /usr/share/cups/drivers/ADOBEPS4.DRV as \WIN40/ADOBEPS4.DRV
  putting file /usr/share/cups/drivers/ADOBEPS4.HLP as \WIN40/ADOBEPS4.HLP
  putting file /usr/share/cups/drivers/DEFPRTR2.PPD as \WIN40/DEFPRTR2.PPD
  putting file /usr/share/cups/drivers/ICONLIB.DLL as \WIN40/ICONLIB.DLL
  putting file /usr/share/cups/drivers/PSMON.DLL as \WIN40/PSMON.DLL
  
  Running command: rpcclient localhost -N -U'root%secret' \
   -c 'adddriver "Windows 4.0"      \
   "infotec_2105:ADOBEPS4.DRV:infotec_2105.PPD:NULL:ADOBEPS4.HLP: \
   PSMON.DLL:RAW:ADOBEPS4.DRV,infotec_2105.PPD,ADOBEPS4.HLP,PSMON.DLL, \
    ADFONTS.MFM,DEFPRTR2.PPD,ICONLIB.DLL"'
  cmd = adddriver "Windows 4.0" "infotec_2105:ADOBEPS4.DRV:infotec_2105.PPD:NULL:          \
    ADOBEPS4.HLP:PSMON.DLL:RAW:ADOBEPS4.DRV,infotec_2105.PPD,ADOBEPS4.HLP,  \
                   PSMON.DLL,ADFONTS.MFM,DEFPRTR2.PPD,ICONLIB.DLL"
  Printer Driver infotec_2105 successfully installed.
  
  Running command: rpcclient localhost -N -U'root%secret'  \
   -c 'setdriver infotec_2105 infotec_2105'
  cmd = setdriver infotec_2105 infotec_2105
  Successfully set infotec_2105 to driver infotec_2105.

If you look closely, you'll discover your root password was transferred unencrypted over the wire, so beware! Also, if you look further her, you'll discover error messages like NT_STATUS_OBJECT_NAME_COLLISION in between. They occur, because the directories WIN40 and W32X86 already existed in the [print$] driver download share (from a previous driver installation). They are harmless here.

What has happened? What did cupsaddsmb do? There are five stages of the procedure

Note, that you can run the cupsaddsmb utility with parameters to specify one remote host as Samba host and a second remote host as CUPS host. Especially if you want to get a deeper understanding, it is a good idea try it and see more clearly what is going on (though in real life most people will have their CUPS and Samba servers run on the same host):

root# cupsaddsmb -H sambaserver -h cupsserver -v printername

You must always check if the utility completed successfully in all fields. You need as a minimum these 3 messages amongst the output:

These messages probably not easily recognized in the general output. If you run cupsaddsmb with the -a parameter (which tries to prepare all active CUPS printer drivers for download), you might miss if individual printers drivers had problems to install properly. Here a redirection of the output will help you analyze the results in retrospective.

You can't get the standard cupsaddsmb command to run on a Samba PDC? You are asked for the password credential all over again and again and the command just will not take off at all? Try one of these variations:

root# cupsaddsmb -U MIDEARTH\\root -v printername
root# cupsaddsmb -H SAURON -U MIDEARTH\\root -v printername
root# cupsaddsmb -H SAURON -U MIDEARTH\\root -h cups-server -v printername

(Note the two backslashes: the first one is required to "escape" the second one).

Here is a chart about the procedures, commandflows and dataflows of the "cupaddsmb" command. Note again: cupsaddsmb is not intended to, and does not work with, "raw" queues!

Figure 19.16. cupsaddsmb flowchart

After cupsaddsmb completed, your driver is prepared for the clients to use. Here are the steps you must perform to download and install it via "Point'n'Print". From a Windows client, browse to the CUPS/Samba server;

After a few seconds, there should be a new printer in your client's local "Printers" folder: On Windows XP it will follow a naming convention of PrinterName on SambaServer. (In my current case it is "infotec_2105 on kde-bitshop"). If you want to test it and send your first job from an application like Winword, the new printer will appears in a \\SambaServer\PrinterName entry in the dropdown list of available printers.

C:\> net use lpt1: \\sambaserver\printershare /user:ntadmin

should you desire to use the CUPS networked PostScript RIP functions. (Note that user "ntadmin" needs to be a valid Samba user with the required privileges to access the printershare) This would set up the printer connection in the traditional LanMan way (not using MS-RPC).

Soooo: printing works, but there are still problems. Most jobs print well, some don't print at all. Some jobs have problems with fonts, which don't look very good. Some jobs print fast, and some are dead-slow. Many of these problems can be greatly reduced or even completely eliminated if you follow a few guidelines. Remember, if your print device is not PostScript-enabled, you are treating your Ghostscript installation on your CUPS host with the output your client driver settings produce. Treat it well:

First let's have a little check of the rpcclient man page. Here are two relevant passages:

adddriver <arch> <config> Execute an AddPrinterDriver() RPC to install the printer driver information on the server. Note that the driver files should already exist in the directory returned by getdriverdir. Possible values for arch are the same as those for the getdriverdir command. The config parameter is defined as follows:

Long Printer Name:\
Driver File Name:\
Data File Name:\
Config File Name:\
Help File Name:\
Language Monitor Name:\
Default Data Type:\
Comma Separated list of Files

Any empty fields should be enter as the string "NULL".

Samba does not need to support the concept of Print Monitors since these only apply to local printers whose driver can make use of a bi-directional link for communication. This field should be "NULL". On a remote NT print server, the Print Monitor for a driver must already be installed prior to adding the driver or else the RPC will fail

setdriver <printername> <drivername> Execute a SetPrinter() command to update the printer driver associated with an installed printer. The printer driver must already be correctly installed on the print server.

See also the enumprinters and enumdrivers commands for obtaining a list of installed printers and drivers.

The exact format isn't made too clear by the man page, since you have to deal with some parameters containing spaces. Here is a better description for it. We have line-broken the command and indicated the breaks with "\". Usually you would type the command in one line without the linebreaks:

 adddriver "Architecture" \
           "LongPrinterName:DriverFile:DataFile:ConfigFile:HelpFile:\
           LanguageMonitorFile:DataType:ListOfFiles,Comma-separated"

What the man pages denotes as a simple <config> keyword, does in reality consist of 8 colon-separated fields. The last field may take multiple (in some, very insane, cases, even 20 different additional files. This might sound confusing at first. Note, that what the man pages names the "LongPrinterName" in reality should rather be called the "Driver Name". You can name it anything you want, as long as you use this name later in the rpcclient ... setdriver command. For practical reasons, many name the driver the same as the printer.

True: it isn't simple at all. I hear you asking: How do I know which files are "Driver File", "Data File", "Config File", "Help File" and "Language Monitor File" in each case? -- For an answer you may want to have a look at how a Windows NT box with a shared printer presents the files to us. Remember, that this whole procedure has to be developed by the Samba Team by overhearing the traffic caused by Windows computers on the wire. We may as well turn to a Windows box now, and access it from a UNIX workstation. We will query it with rpcclient to see what it tells us and try to understand the man page more clearly which we've read just now.

We could run rpcclient with a getdriver or a getprinter subcommand (in level 3 verbosity) against it. Just sit down at UNIX or Linux workstation with the Samba utilities installed. Then type the following command:

root# rpcclient -U'USERNAME%PASSWORD' NT-SERVER-NAME -c 'getdriver printername 3'

From the result it should become clear which is which. Here is an example from my installation:

root# rpcclient -U'Danka%xxxx' W2KSERVER \
	-c'getdriver "DANKA InfoStream Virtual Printer" 3'
 cmd = getdriver "DANKA InfoStream Virtual Printer" 3

 [Windows NT x86]
 Printer Driver Info 3:
         Version: [2]
         Driver Name: [DANKA InfoStream]
         Architecture: [Windows NT x86]
         Driver Path: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\PSCRIPT.DLL]
         Datafile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\INFOSTRM.PPD]
         Configfile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\PSCRPTUI.DLL]
         Helpfile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\PSCRIPT.HLP]
 
         Dependentfiles: []
         Dependentfiles: []
         Dependentfiles: []
         Dependentfiles: []
         Dependentfiles: []
         Dependentfiles: []
         Dependentfiles: []
 
         Monitorname: []
         Defaultdatatype: []

Some printer drivers list additional files under the label "Dependentfiles": these would go into the last field ListOfFiles,Comma-separated. For the CUPS PostScript drivers we don't need any (nor would we for the Adobe PostScript driver): therefore the field will get a "NULL" entry.

From the manpage (and from the quoted output of cupsaddsmb, above) it becomes clear that you need to have certain conditions in order to make the manual uploading and initializing of the driver files succeed. The two rpcclient subcommands (adddriver and setdriver) need to encounter the following pre-conditions to complete successfully:

We are going to install a printer driver now by manually executing all required commands. As this may seem a rather complicated process at first, we go through the procedure step by step, explaining every single action item as it comes up.

The setdriver command will fail, if in Samba's mind the queue is not already there. You had promising messages about the:

 Printer Driver ABC successfully installed.

after the "adddriver" parts of the procedure? But you are also seeing a disappointing message like this one beneath?

 result was NT_STATUS_UNSUCCESSFUL

It is not good enough that you can see the queue in CUPS, using the lpstat -p ir85wm command. A bug in most recent versions of Samba prevents the proper update of the queuelist. The recognition of newly installed CUPS printers fails unless you re-start Samba or send a HUP to all smbd processes. To verify if this is the reason why Samba doesn't execute the setdriver command successfully, check if Samba "sees" the printer:

root# rpcclient transmeta -N -U'root%secret' -c 'enumprinters 0'| grep  ir85wm
        printername:[ir85wm]

An alternative command could be this:

root# rpcclient transmeta -N -U'root%secret' -c 'getprinter ir85wm' 
        cmd = getprinter ir85wm
        flags:[0x800000]
        name:[\\transmeta\ir85wm]
        description:[\\transmeta\ir85wm,ir85wm,DPD]
        comment:[CUPS PostScript-Treiber for WinNT/2K/XP]

BTW, you can use these commands, plus a few more, of course, to install drivers on remote Windows NT print servers too!

A Windows NT (Print) Server keeps track of all information needed to serve its duty toward its clients by storing entries in the Windows "Registry". Client queries are answered by reading from the registry, Administrator or user configuration settings are saved by writing into the Registry. Samba and UNIX obviously don't have such a kind of Registry. Samba instead keeps track of all client related information in a series of *.tdb files. (TDB = Trivial Data Base). These are often located in /var/lib/samba/ or /var/lock/samba/ . The printing related files are ntprinters.tdb, printing.tdb,ntforms.tdb and ntdrivers.tdb.

*.tdb files are not human readable. They are written in a binary format. "Why not ASCII?", you may ask. "After all, ASCII configuration files are a good and proofed tradition on UNIX." -- The reason for this design decision by the Samba Team is mainly performance. Samba needs to be fast; it runs a separate smbd process for each client connection, in some environments many thousand of them. Some of these smbds might need to write-access the same *.tdb file at the same time. The file format of Samba's *.tdb files allows for this provision. Many smbd processes may write to the same *.tdb file at the same time. This wouldn't be possible with pure ASCII files.

It is very important that all *.tdb files remain consistent over all write and read accesses. However, it may happen that these files do get corrupted. (A kill -9 `pidof smbd` while a write access is in progress could do the damage as well as a power interruption, etc.). In cases of trouble, a deletion of the old printing-related *.tdb files may be the only option. You need to re-create all print related setup after that. Or you have made a backup of the *.tdb files in time.

Samba ships with a little utility which helps the root user of your system to back up your *.tdb files. If you run it with no argument, it prints a little usage message:

root# tdbbackup
 Usage: tdbbackup [options] <fname...>
 
 Version:3.0a
   -h            this help message
   -s suffix     set the backup suffix
   -v            verify mode (restore if corrupt)

Here is how I backed up my printing.tdb file:

root# ls
.              browse.dat       locking.tdb     ntdrivers.tdb   printing.tdb
..             share_info.tdb   connections.tdb messages.tdb    ntforms.tdb
printing.tdbkp unexpected.tdb   brlock.tdb      gmon.out        namelist.debug  
ntprinters.tdb sessionid.tdb
 
root# tdbbackup -s .bak printing.tdb
 printing.tdb : 135 records
 
root# ls -l printing.tdb*
 -rw-------    1 root     root        40960 May  2 03:44 printing.tdb
 -rw-------    1 root     root        40960 May  2 03:44 printing.tdb.bak

Nowadays most Linux distros rely on the utilities of Linuxprinting.org to create their printing related software (which, BTW, works on all UNIXes and on Mac OS X or Darwin too). It is not known as well as it should be, that it also has a very end-user friendly interface which allows for an easy update of drivers and PPDs, for all supported models, all spoolers, all operating systems and all package formats (because there is none). Its history goes back a few years.

Recently Foomatic has achieved the astonishing milestone of 1000 listed printer models. Linuxprinting.org keeps all the important facts about printer drivers, supported models and which options are available for the various driver/printer combinations in its Foomatic database. Currently there are 245 drivers in the database: many drivers support various models, and many models may be driven by different drivers; it's your choice!

Here are the steps to install a foomatic-rip driven "LaserJet 4 Plus" compatible printer in CUPS (note that recent distributions of SuSE, UnitedLinux and Mandrake may ship with a complete package of Foomatic-PPDs plus the foomatic-rip utility. going directly to Linuxprinting.org ensures you to get the latest driver/PPD files):

Once you print to a printqueue set up with the Foomatic-PPD, CUPS will insert the appropriate commands and comments into the resulting PostScript jobfile. foomatic-rip is able to read and act upon these. foomatic-rip uses some specially encoded Foomatic comments, embedded in the jobfile. These in turn are used to construct (transparently for you, the user) the complicated ghostscript command line telling for the printer driver how exactly the resulting raster data should look like and which printer commands to embed into the data stream.

You need:

This is an example command how root would set a print quota in CUPS, assuming an existing printer named "quotaprinter":

root# lpadmin -p quotaprinter -o job-quota-period=604800 \
	-o job-k-limit=1024 -o job-page-limit=100

This would limit every single user to print 100 pages or 1024 KB of data (whichever comes first) within the last 604,800 seconds ( = 1 week).

For CUPS to count correctly, the printfile needs to pass the CUPS "pstops" filter, otherwise it uses a "dummy" count of "1". Some printfiles don't pass it (eg: image files) but then those are mostly 1 page jobs anyway. This also means that proprietary drivers for the target printer running on the client computers and CUPS/Samba, which then spool these files as "raw" (i.e. leaving them untouched, not filtering them), will be counted as "1-pagers" too!

You need to send PostScript from the clients (i.e. run a PostScript driver there) to have the chance to get accounting done. If the printer is a non-PostScript model, you need to let CUPS do the job to convert the file to a print-ready format for the target printer. This will be working for currently about 1,000 different printer models, see the driver list at linuxprinting.org/.

Before CUPS-1.1.16 your only option was to use the Adobe PostScript Driver on the Windows clients. The output of this driver was not always passed through the "pstops" filter on the CUPS/Samba side, and therefore was not counted correctly (the reason is that it often, depending on the "PPD" being used, wrote a "PJL"-header in front of the real PostScript which caused CUPS to skip pstops and go directly to the "pstoraster" stage).

From CUPS-1.1.16 onward you can use the "CUPS PostScript Driver for Windows NT/2K/XP clients" (which is tagged in the download area of http://www.cups.org/ as the "cups-samba-1.1.16.tar.gz" package). It does not work for Win9x/ME clients. But it guarantees:

You can read more about the setup of this combination in the manpage for "cupsaddsmb" (which is only present with CUPS installed, and only current from CUPS 1.1.16).

These are the items CUPS logs in the "page_log" for every single page of a job:

Here is an extract of my CUPS server's page_log file to illustrate the format and included items:

infotec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 1 3 #marketing 10.160.50.13
infotec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 2 3 #marketing 10.160.50.13
infotec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 3 3 #marketing 10.160.50.13
infotec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 4 3 #marketing 10.160.50.13
DigiMaster9110 boss 402 [22/Apr/2003:10:33:22 +0100] 1 440 finance-dep 10.160.51.33

This was job ID "401", printed on "infotec_IS2027" by user "kurt", a 64-page job printed in 3 copies and billed to "#marketing", sent from IP address 10.160.50.13. The next job had ID "402", was sent by user "boss" from IP address 10.160.51.33,printed from one page 440 copies and is set to be billed to "finance-dep".

What flaws or shortcomings are there with this quota system?

This is the best system currently available, and there are huge improvements under development for CUPS 1.2:

PrintAnalyzer, pyKota, printbill, LogReport.

Some important parameter settings in the CUPS configuration file cupsd.conf are:

(There are also additional settings for "MaxJobsPerUser" and "MaxJobsPerPrinter"...)

For everything to work as announced, you need to have three things:

If you want to do things manually, replace the printing = cups by printing = bsd. Then your manually set commands may work (haven't tested this), and a print command = lp -d %P %s; rm %s" may do what you need.

For Win9x clients require the printer names to be 8 chars (or "8 plus 3 chars suffix") max; otherwise the driver files won't get transferred when you want to download them from Samba.

Have you security = user? Have you used smbpasswd to give root a Samba account? You can do 2 things: open another terminal and execute smbpasswd -a root to create the account, and continue with entering the password into the first terminal. Or break out of the loop by hitting ENTER twice (without trying to type a password).

Have you enabled printer sharing on CUPS? This means: do you have a <Location /printers>....</Location> section in CUPS server's cupsd.conf which doesn't deny access to the host you run "cupsaddsmb" from? It could be an issue if you use cupsaddsmb remotely, or if you use it with a -h parameter: cupsaddsmb -H sambaserver -h cupsserver -v printername.

Is your "TempDir" directive in cupsd.conf set to a valid value and is it writeable?

Use smbstatus to check which user you are from Samba's point of view. Do you have the privileges to write into the [print$] share?

Once you are connected as the "wrong" user (for example as "nobody", which often occurs if you have map to guest = bad user), Windows Explorer will not accept an attempt to connect again as a different user. There won't be any byte transfered on the wire to Samba, but still you'll see a stupid error message which makes you think that Samba has denied access. Use smbstatus to check for active connections. Kill the PIDs. You still can't re-connect and get the dreaded You can't connect with a second account from the same machine message, as soon as you are trying? And you don't see any single byte arriving at Samba (see logs; use "ethereal") indicating a renewed connection attempt? Shut all Explorer Windows. This makes Windows forget what it has cached in its memory as established connections. Then re-connect as the right user. Best method is to use a DOS terminal window and first do net use z: \\GANDALF\print$ /user:root. Check with smbstatus that you are connected under a different account. Now open the "Printers" folder (on the Samba server in the Network Neighbourhood), right-click the printer in question and select Connect...

You see per smbstatus that you are connected as user "nobody"; while you wanted to be "root" or "printeradmin"? This is probably due to map to guest = bad user, which silently connects you under the guest account, when you gave (maybe by accident) an incorrect username. Remove map to guest, if you want to prevent this.

First delete all "old" Adobe-using printers. Then delete all "old" Adobe drivers. (On Win2K/XP, right-click in background of "Printers" folder, select "Server Properties...", select tab "Drivers" and delete here).

Do you use the "naked" root user name? Try to do it this way: cupsaddsmb -U DOMAINNAME\\root -v printername> (note the two backslashes: the first one is required to "escape" the second one).

Deleting a printer on the client won't delete the driver too (to verify, right-click on the white background of the "Printers" folder, select "Server Properties" and click on the "Drivers" tab). These same old drivers will be re-used when you try to install a printer with the same name. If you want to update to a new driver, delete the old ones first. Deletion is only possible if no other printer uses the same driver.

Local Security Policies may not allow the installation of unsigned drivers. "Local Security Policies" may not allow the installation of printer drivers at all.

Windows XP handles SMB printers on a "per-user" basis. This means every user needs to install the printer himself. To have a printer available for everybody, you might want to use the built-in IPP client capabilities of WinXP. Add a printer with the print path of http://cupsserver:631/printers/printername. Still looking into this one: maybe a "logon script" could automatically install printers for all users.

For "print change notify" functions on NT++ clients, these need to run the "Server" service first (re-named to File & Print Sharing for MS Networks in XP).

WinXP-SP1 introduced a Point and Print Restriction Policy (this restriction doesn't apply to "Administrator" or "Power User" groups of users). In Group Policy Object Editor: go to User Configuration, Administrative Templates, Control Panel, Printers. The policy is automatically set to Enabled and the Users can only Point and Print to machines in their Forest . You probably need to change it to Disabled or Users can only Point and Print to these servers in order to make driver downloads from Samba possible.

How are you doing it? I bet the wrong way (it is not very easy to find out, though). There are 3 different ways to bring you to a dialog that seems to set everything. All three dialogs look the same. Only one of them does what you intend. You need to be Administrator or Print Administrator to do this for all users. Here is how I do in on XP:

Do you see any difference? I don't either... However, only the last one, which you arrived at with steps "C.1.-6." will save any settings permanently and be the defaults for new users. If you want all clients to get the same defaults, you need to conduct these steps as Administrator (printer admin in smb.conf) before a client downloads the driver (the clients can later set their own per-user defaults by following the procedures A. or B. above).

Don't use Optimize for Speed: use Optimize for Portability instead (Adobe PS Driver) Don't use Page Independence: No: always settle with Page Independence: Yes (Microsoft PS Driver and CUPS PS Driver for WinNT/2K/XP) If there are problems with fonts: use Download as Softfont into printer (Adobe PS Driver). For TrueType Download Options choose Outline. Use PostScript Level 2, if you are having trouble with a non-PS printer, and if there is a choice.

Symptom: the last command of cupsaddsmb doesn't complete successfully: cmd = setdriver printername printername result was NT_STATUS_UNSUCCESSFUL then possibly the printer was not yet "recognized" by Samba. Did it show up in Network Neighbourhood? Did it show up in rpcclient hostname -c 'enumprinters'? Restart smbd (or send a kill -HUP to all processes listed by smbstatus and try again.

Have you by accident set the CUPS spool directory to the same location? (RequestRoot /var/spool/samba/ in cupsd.conf or the other way round: /var/spool/cups/ is set as path> in the [printers] section). These must be different. Set RequestRoot /var/spool/cups/ in cupsd.conf and path = /var/spool/samba in the [printers] section of smb.conf. Otherwise cupsd will sanitize permissions to its spool directory with each restart, and printing will not work reliably.

It is a very bad idea to name any printer "lp". This is the traditional UNIX name for the default printer. CUPS may be set up to do an automatic creation of "Implicit Classes". This means, to group all printers with the same name to a pool of devices, and loadbalancing the jobs across them in a round-robin fashion. Chances are high that someone else has an "lp" named printer too. You may receive his jobs and send your own to his device unwittingly. To have tight control over the printer names, set BrowseShortNames No. It will present any printer as "printername@cupshost" then, giving you a better control over what may happen in a large networked environment.

Use smbclient to connect to any Windows box with a shared PostScript printer: smbclient //windowsbox/print\$ -U guest. You can navigate to the W32X86/2 subdir to mget ADOBE* and other files or to WIN40/0 to do the same. -- Another option is to download the *.exe packaged files from the Adobe website.