Printing is often a mission-critical service for the users. Samba can provide this service reliably and seamlessly for a client network consisting of Windows workstations.

A Samba-3.0 print service may be run on a Standalone or a Domain member server, side by side with file serving functions, or on a dedicated print server. It can be made as tight or as loosely secured as needs dictate. Configurations may be simple or complex. Available authentication schemes are essentially the same as described for file services in previous chapters. Overall, Samba's printing support is now able to replace an NT or Windows 2000 print server full-square, with additional benefits in many cases. Clients may download and install drivers and printers through their familiar "Point'n'Print" mechanism. Printer installations executed by "Logon Scripts" are no problem. Administrators can upload and manage drivers to be used by clients through the familiar "Add Printer Wizard". As an additional benefit, driver and printer management may be run from the commandline or through scripts, making it more efficient in case of large numbers of printers. If a central accounting of print jobs (tracking every single page and supplying the raw data for all sorts of statistical reports) is required, this is best supported by CUPS as the print subsystem underneath the Samba hood.

This chapter deals with the foundations of Samba printing, as they implemented by the more traditional UNIX (BSD- and System V-style) printing systems. Many things apply to CUPS, the newer Common UNIX Printing System, too; so if you use CUPS, you might be tempted to jump to the next chapter -- but you will certainly miss a few things if you do so. Better read this chapter too.

Samba's printing support always relies on the installed print subsystem of the Unix OS it runs on. Samba is a "middleman". It takes printfiles from Windows (or other SMB) clients and passes them to the real printing system for further processing. Therefore it needs to "talk" to 2 sides: to the Windows print clients and to the Unix printing system. Hence we must differentiate between the various client OS types which behave differently as well as the various UNIX print subsystems, which have different features and are accessed differently. This part of the Samba HOWTO Collection deals with "the traditional" way of Unix printing first; the next chapter covers in great detail the more modern Common UNIX Printing System (CUPS). CUPS users, be warned: don't just jump on to the next chapter. You might miss important info contained only here!

We assume here that you have your printer(s) already configured to print from UNIX: At the very least they must be set up to print when you send pre-formatted printjobs to them. It is then Samba's job to "share" this service to Windows clients.

6.2.1. What happens if you send a Job from a Client

To successfully print a job from a Windows client via a Samba print server to a UNIX printer, there are 6 (potentially 7) stages:

6.2.2. Printing related Configuration Parameters

There are a number of configuration parameters in smb.conf controlling Samba's printing behaviour. Please do also turn to the man page for smb.conf to acquire an overview of these parameters. As with other parameters, there are Global (tagged with a "G" in the listings) and Service Level ("S") parameters.

6.2.3. Parameters recommended for Use

These configuration parameters are directly related to Samba-3.0 printing. Their meaning is explained further below.

Samba's printing support implements the Microsoft Remote Procedure Calls (MS-RPC) methods for printing. These are used by Windows NT (and later) print servers. The old "LanMan" protocol is still supported as a fallback resort, and for older clients to use. More details will follow further beneath.

6.2.4. Parameters for backwards Compatibility

There have been two new parameters added in Samba 2.2.2, still present in Samba-3.0:

Both of these options are described in the smb.conf(5) man page and are disabled by default. Use them with caution!

6.2.5. Parameters no longer in Use

Samba users upgrading from 2.2.x to 3.0 need to be aware, that some previously available settings are no longer supported (as was announced in time). Here is a list of them:

6.3. A simple Configuration to print with Samba 3.0

Here is a very simple example configuration for print related settings in the smb.conf file. If you compare it with your own system's smb.conf, you probably find some additional parameters included there (as pre-configured by your OS vendor). Further below is a discussion and explanation of the parameters. Note, that this example doesn't use many parameters. However, in many environments these are enough to provide a valid smb.conf which enables all clients to print.

This is only an example configuration. Many settings, if not explicitly set to a specific value, are used and set by Samba implicitly to its own default, because these have been compiled in. To see all settings, let root use the "testparm" utility. "testparm" also gives warnings if you have mis-configured certain things. Its complete output is easily 340 lines and more. You may want to pipe it through a pager program.

The syntax for the configuration file is easy to grasp. You should know that smb.conf is not very picky about its syntax. It has been explained elsewhere in this document. A short reminder: It even tolerates some spelling errors (like "browsable" instead of "browseable"). Most spelling is case-insensitive. Also, you can use "Yes|No" or "True|False" for boolean settings. Lists of names may be separated by commas, spaces or tabs.

6.3.1. Verification of "Settings in Use" with testparm

To see all (or at least most) printing related settings in Samba, including the implicitly used ones, try the command outlined below (hit "ENTER" twice!). It greps for all occurrences of "lp", "print", "spool", "driver", "ports" and "[" in testparm's output and gives you a nice overview about the running smbd's print configuration. (Note that this command does not show individually created printer shares, or the spooling paths in each case). Here is the output of my Samba, with exactly the same scarce settings in smb.conf as shown above:

You can easily verify which settings were implicitly added by Samba's default behaviour. Don't forget about this point -- it may be important in you future dealings with Samba.

6.3.2. A little Experiment to warn you

Should you need to troubleshoot at one stage, please always go back to this point first and verify if "testparm" shows the parameters you expect! To give you an example from personal experience as a warning, try to just "comment out" the "load printers" parameter. If your 2.2.x system behaves like mine, you'll see this:

Despite of my imagination that the commenting out of this setting should prevent Samba from publishing my printers, it still did! Oh Boy -- it cost me quite some time to find out the reason. But I am not fooled any more... at least not by this ;-)

Only if setting the parameter explicitly to "load printers = No" would Samba recognize my intentions. So my strong advice is:

This example should show you, that you can use testparm to test any filename for fitness as a Samba configuration. Actually, we want to encourage you to *not* change your smb.conf on a working system (unless you know exactly what you do)! Don't rely on an assumption that changes will only take effect after you re-start smbd! This is not the case. Samba re-reads its smb.conf every 60 seconds and on each new client connection. You might have to face changes for your productive clients you didn't mean to apply at this time! You will now note a few more interesting things. Just ask testparm what the Samba print configuration would be, if you used this minimalistic file as your real smb.conf:

However, this was not fatal, and Samba-3.0 will default to values that will work here. But, please!, don't rely on this and don't use this! This example was only meant to make you carefully design and spell out your setup what you really want it to be. The outcome on your system may vary on some parameters, since you may have a Samba built with a different compile time configuration. [WARNING: Don't put a comment sign *at the end* of a valid smb.conf line. It will make it to be ignored (just as if you had put it on the front). This I at first regarded as a bug in my Samba version(s). But the man page says: "Internal whitespace in a parameter value is retained verbatim." - This means a line consisting of "printing =lpring #This defines LPRng as the printing system" will regard the whole of the string after the "=" sign as the value you want to define. And this is an invalid value that will be ignored, and a default value used instead.]

6.4. Extended sample Configuration to print with Samba 3.0

Here we show a more verbose example configuration for print related settings in an smb.conf. Below is a discussion and explanation of the various parameters. We chose to use BSD-style printing here, because we guess it is still the most commonly used system on legacy Linux installations. (New installs now predominantly have CUPS, which is discussed entirely in the next section of this document). Note, that this example specifically names many parameters which don't need to be -- because they would be used anyway "by default". You might be able to do with a leaner smb.conf. (Tip: if you read access it with "SWAT", and then write it to disk again, it will be optimized in a way such that it doesn't contain any superfluous parameters and comments. SWAT organizes the file for best performance. Remember, that each smbd re-reads the Samba configuration once a minute, and that each connection spawns an smbd process of its own -- so it is not a bad idea to optimize the smb.conf in environments with hundreds or thousands of clients...).

This also is only an example configuration. For the [my_printer_name] service it defines a different "printer admin" than is defined in the [global] section, and a differfent spool path. Additionally, it includes a parameter which denies access to 3 hosts. You may not find all the settings in your own smb.conf (as pre-configured by your OS vendor). Many configuration parameters, if not explicitly set to a specific value, are used and set by Samba implicitly to its own default, because these have been compiled in. To see all settings, let root use the "testparm" utility. "testparm" also gives warnings if you have mis-configured certain things.

6.5. Detailed Explanation of the Example's Settings

6.5.1. The [global] Section

The [global] section is one of 4 special sections (along with [homes], [printers] and [print$]...) It contains all parameters which apply to the server as a whole. It is the place for parameters which have only a "global" meaning (G). It may also contain service level parameters (S) which then define settings for all other sections and shares. This way you can simplify the configuration and forego to set the same value repeatedly. (Within each individual section or share you may however override these globally set "share level" settings and specify other values).

6.5.2. The [printers] Section

This is the second special section. If a section with this name appears it the smb.conf, users are able to connect to any printer specified in the Samba host's printcap file, because Samba on startup then creates a printer share for every printername it finds in the printcap file. You could regard this section as a general convenience shortcut to share all printers with minimal configuration. It is also a container for settings which should apply as default to all printers. (For more details see the smb.conf man page.) Settings inside this container must be share level parameters (S).

6.5.3. Any [my_printer_name] Section

If a section appears in the smb.conf, which is tagged as "printable = yes", Samba presents it as a printer share to its clients. Note, that Win95/98/ME clients may have problems with connecting or loading printer drivers if the share name has more than 8 characters! Also be very carefull if you name a printer the same as an existing user or file share name: Upon a client's connection request to a certain sharename, Samba always tries to find file shares with that name first; if it finds one, it will connect to this and will never come round and attempt to connect to a printer with the same name!

6.5.4. Print Commands

In each section defining a printer (or in the [printers] section), a "print command" parameter may be defined. It sets a command to process the files which have been placed into the Samba print spool directory for that printer. (That spool directory was, remember?, set up with the "path" parameter). Typically, this command will submit the spool file to the Samba host's print subsystem, using the suitable system print command. But there is no requirement that this needs to be the case. For debugging purposes or some other reason you may want to do something completely different than "print" the file. An example is that your command just copies it to a save place for further investigation when you need to debug printing. If you craft your own print commands (or even print command shell scripts), make sure you pay attention to also remove the files from the Samba spool directory. Otherwise your hard disk may soon suffer from shortage of free space.

6.5.5. Default Print Commands for various Unix Print Subsystems

You learned earlier on, that Samba in most cases uses its built-in settings for many parameters if it can not find an explicitly stated one in its configuration file. The same is true for the "print command ". The default print command varies depending on the "printing =..." parameter setting. You will notice some funny "%<LETTER>" notions in all the commands beneath. These stand for "printername", "spoolfile" and "job ID". They are explained in more detail further below. Here is an overview (excluding the special case CUPS, which is discussed in the next chapter):

We excluded the special CUPS case here, because it is discussed in the next chapter. Just a short summary. For printing = CUPS: If SAMBA is compiled against libcups, it uses the CUPS API to submit jobs, etc. (Please set also "printcap = cups" in case your cupsd.conf is set to write its autogenerated printcap file to an unusual place). Otherwise it maps to the System V commands with the -oraw option for printing, i.e. it uses

lp -c -d%p -oraw; rm
%s

. With printing = cups , and if SAMBA is compiled against libcups, any manually set print command will be ignored!

Having listed the above mappings here, you should note that there used to be a bug in recent 2.2.x versions which prevented the mapping from taking effect. It lead to the "bsd|aix|lprng|plp" settings to take effect for all other systems, for the most important commands (the print command, the lpq command and the lprm command). The lppause command and the lpresume command remained empty. (Of course, these commands worked on bsd|aix|lprng|plp -- but they didn't work on sysv|hpux|qnx systems.) To work around this bug, you need to explicitly set the commands. Use "testparm -v" to check which command takes effect. Then check, if this command is adaequate and actually works for your installed print subsystem. It is always a good idea to explicitly set configuration files up the way you want them to work and not rely on any built-in defaults.

6.5.6. Setting up your own Print Commands

After a print job has finished spooling to a service, the print command will be used by Samba via a system() call to process the spool file. Usually the command specified will submit the spool file to the host's printing subsystem. But there is no requirement at all that this must be the case. The print subsystem will probably not remove the spool file on its own. So whatever command you specify on your own -- you should think to delete the spool file when it has been processed.

Using your own customized print commands is no problem with the traditional printing systems. However, if you don't bother to "roll your own", you should know which are the default built-in commands Samba uses for each printing subsystem (see table above). In all the commands listed in the last paragraphs you see these funny "%<LETTER>" notions. These are macros, or shortcuts, used as place holders for the names of real objects. At the time of running a command with such a placeholder, Samba will insert the appropriate value automatically. Print commands can handle all Samba macro substitutions. In regard to printing, the following ones do have special relevance:

The print command MUST contain at least one occurrence of %s or %f. -- The %p is optional. If no printer name is supplied, the %p will be silently removed from the print command. In this case the job is sent to the default printer.

If specified in the [global] section, the print command given will be used for any printable service that does not have its own print command specified. If there is neither a specified print command for a printable service nor a global print command, spool files will be created but not processed! And (most importantly): print files will not be removed, so they will start filling your Samba hard disk.

Note that printing may fail on some UNIXes from the "nobody" account. If this happens: create an alternative guest account and supply it with the privilege to print; set up this guest account in the [global] section with the "guest account" parameter.

You can form quite complex print commands. You need to realize that print commands are just passed to a UNIX shell. The shell is able to expand the included environment variables as usual. (The syntax to include a UNIX environment variable $variable in smb.conf or in the Samba print command is "%$variable ".) To give you a working "print command" example, the following will log a print job to "/tmp/print.log", print the file, then remove it. Note that ';' is the usual separator for commands in shell scripts:

You may have to vary your own command considerably from this example depending on how you normally print files on your system. The default for the "print command" parameter varies depending on the setting of the "printing" parameter. -- Another example

6.6. Innovations in Samba Printing since 2.2

Before version 2.2.0, Samba's print server support for Windows clients was limited to the level of "LanMan" printing calls. This is the same protocol level as Windows 9x PCs offer when they share printers. Beginning with the 2.2.0 release, Samba started to support the native Windows NT printing mechanisms. These are implemented via MS-RPC (RPC = Remote Procedure Calls). MS-RPCs use the SPOOLSS named pipe for all printing.

One other benefit of an update is this: Samba 3.0 is able to publish all its printers in Active Directory (or LDAP)!

One slight difference is here: it is possible on a Windows NT print server to have printers listed in the Printers folder which are not shared. Samba does not make this distinction. By definition, the only printers of which Samba is aware are those which are specified as shares in smb.conf. The reason is that Windows NT/2k/XPprof clients do normally not need and use the standard SMB printer share; they rather print directly to any printer on another Windows NT host using MS-RPC. This of course assumes that the printing client has the necessary privileges on the remote host serving the printer. The default permissions assigned by Windows NT to a printer gives the "Print" permissions to the well-known "Everyone" group. (The older clients of type Win9x can only print to "shared" printers).

6.6.1. Client Drivers on Samba Server for Point'n'Print

There is still confusion about what all this means: Is it or is it not a requirement for printer drivers to be installed on a Samba host in order to support printing from Windows clients? The answer is this: No, it is not a *requirement*. Windows NT/2000 clients can, of course, also run their APW to installing drivers locally (which then connect to a Samba served print queue). This is the same method as used by Windows 9x clients. (However, a bug existed in Samba 2.2.0 which made Windows NT/2000 clients require that the Samba server possess a valid driver for the printer. This was fixed in Samba 2.2.1...).

But it is a new *option* to install the printer drivers into the [print$] share of the Samba server, and a big convenience too. Then all clients (including 95/98/ME) get the driver installed when they first connect to this printer share. The uploading or depositing of the driver into this [print$] share, and the following binding of this driver to an existing Samba printer share can be achieved by different means:

Please take additional note of the following fact: Samba does not use these uploaded drivers in any way to process spooled files. Drivers are utilized entirely by the clients, who download and install them via the "Point 'n'Print" mechanism supported by Samba. The clients use these driver to generate print files in the format the printer (or the Unix print system) requires. Print files received by Samba are handed over to the Unix printing system, which is responsible for all further processing, if needed.

6.6.2. [printer$] Section is removed

6.6.3. Creating [print$]

In order to support the up- and downloading of printer driver files, you must first configure a file share named [print$]. The "public" name of this share is hard coded in Samba's internals (because it is hardcoded in the MS Windows clients too). It can't be renamed since Windows clients are programmed to search for a service of exactly this name if they want to retrieve printer driver files.

You should modify the server's smb.conf file to add the global parameters and create the [print$] file share (of course, some of the parameter values, such as 'path' are arbitrary and should be replaced with appropriate values for your site):

Of course, you also need to ensure that the directory named by the "path" parameter exists on the Unix file system.

6.6.4. Parameters in the [print$] Section

[print$] is a special section in smb.conf. It contains settings relevant to potential printer driver download and local installation by clients.

6.6.5. Subdirectory Structure in [print$]

In order for a Windows NT print server to support the downloading of driver files by multiple client architectures, you must create several subdirectories within the [print$] service (i.e. the Unix directory named by the "path" parameter). These correspond to each of the supported client architectures. Samba follows this model as well. Just like the name of the [print$] share itself, the subdirectories *must* be exactly the names listed below. (You may leave out the subdirs of architectures you don't want to support).

Therefore, create a directory tree below the [print$] share for each architecture you wish to support.

Once you have created the required [print$] service and associated subdirectories, go to a Windows NT 4.0/2k/XP client workstation. Open "Network Neighbourhood" or "My Network Places" and browse for the Samba host. Once you have located the server, navigate to its "Printers and Faxes" folder. You should see an initial listing of printers that matches the printer shares defined on your Samba host.

6.7. Installing Drivers into [print$]

You have successfully created the [print$] share in smb.conf? And Samba has re-read its configuration? Good. But you are not yet ready to take off. The driver files need to be present in this share, too! So far it is still an empty share. Unfortunatly, it is not enough to just copy the driver files over. They need to be set up too. And that is a bit tricky, to say the least. We will now discuss two alternative ways to install the drivers into [print$]:

The latter option is probably the easier one (even if the only entrance to this realm seems a little bit weird at first).

6.7.1. Setting Drivers for existing Printers with a Client GUI

The initial listing of printers in the Samba host's " Printers" folder accessed from a client's Explorer will have no real printer driver assigned to them. By default, in Samba 3.0 (as in 2.2.1 and later) this driver name is set to a NULL string. This must be changed now. the local Add Printer Wizard, run from NT/2000/XP clients, will help us in this task.

However, the job to set a valid driver for the printer is not a straightforward one: You must attempt to view the printer properties for the printer you want the driver assign to. Open the Windows Explorer, open Network Neighbourhood, browse to the Samba host, open Samba's "Printers" folder, right-click the printer icon and select "Properties...". You are now trying to view printer and driver properties for a queue which has this default "NULL" driver assigned. This will result in an error message (this is "normal" here):

Don't click "Yes"! Instead, click "No" in the error dialog. Only now you will be presented with the printer properties window. From here, the way to assign a driver to a printer is open to us. You have now the choice. Either

Once the APW is started, the procedure is exactly the same you are used to from Wiindows. We assume here that you are familiar with the printer driver installations procedure on Windows NT. Make sure your connection is setup in fact as a user with printer admin privileges (if in doubt, use "smbstatus" to check for this). If you wish to install printer drivers for client operating systems other than "Windows NT x86", you will need to use the "Sharing" tab of the printer properties dialog.

Assuming you have connected with an administrative (or root) account (as named by the "printer admin" parameter), you will also be able to modify other printer properties such as ACLs and default device settings using this dialog. (For the default device settings, please consider the advice given further below). [ FIXME: This section should sometime in the near future be updated and enhanced and include some screenshots from the process. FIXME]

6.7.2. Setting Drivers for existing Printers with rpcclient

The second way to install printer drivers into [print$] and set them up in a valid way can be done from the UNIX command line. This involves three (or four, if you count "zero" too ;-) distinct steps:

We will provide detailed hints for each of these steps in the next few paragraphs.

6.7.2.1. Identifying the Driver Files

To find out about the driver files, you have two options: you could investigate the driver CD which comes with your printer. Study the *.inf file on the CD, if it is contained. This may not be the possible, since the *.inf file might be missing. Unfortunately, many vendors have now started to use their own installation programs. These installations packages are often some sort of Windows platform archive format, plus, the files may get re-named during the installation process. This makes it extremely difficult to identify the driver files you need.

Then you only have the second option: install the driver first on a Windows client *locally* and investigate which file names and paths it uses after they are installed. (Note, that you need to repeat this procedure for every client platform you want to support. We are going to show it here for the "W32X86" platform only, a name used by Microsoft for all WinNT/2k/XP clients...)

A good method to recognize the driver files this is to print the test page from the driver's Properties Dialog (General tab). Then look at the list of driver files named on the printout. You'll need to recognize what Windows (and Samba) are calling the "Driver File", the "Data File", the "Config File", the "Help File" and (optionally) the "Dependent Driver Files" (this may vary slightly for Windows NT). ( FIXME: Attention -- I've translated this back from German: please someone verify the exact names of these file categories on an English version of Windows...FIXME). You need to remember all names (or better take a note) for the next steps.

Another method to quickly test the driver filenames and related paths is provided by the rpcclient utility. Run it with the "enumdrivers" or with the "getdriver" subcommand, each in the "3" level. In the following example, TURBO_XP is the name of the Windows PC (in this case it was a Windows XP Professional laptop, BTW). I had installed the driver locally to TURBO_XP. kde-bitshop is the name of the Linux host from which I am working. We could run an interactive rpcclient session; then we'd get an rpcclient> prompt and would type the subcommands at this prompt. This is left as a good exercise to the reader. For now we use rpcclient with the "-c" parameter to execute a single subcommand line and exit again. This is the method you would use if you want to create scripts to automate the procedure for a large number of printers and drivers. Note the different quotes used to overcome the different spaces in between words:

You may notice, that this driver has quite a big number of "Dependentfiles" (I know worse cases however). Also, strangely, the "Driver File" is here tagged as "Driver Path".... oh, well. Here we don't have yet support for the so-called "WIN40" architecture installed. This name is used by Microsoft for the Win95/98/ME platforms. If we want to support these, we need to install the Win95/98/ME driver files in addition to those for W32X86 (i.e. the WinNT72000/XP clients) onto a Windows PC. This PC can also host the Win9x drivers, even if itself runs on Windows NT, 2000 or XP.

Since the "print$" share is usually accessible through the Network Neighbourhood, you can also use the UNC notation from Windows Explorer to poke at it. The Win9x driver files will end up in subdirectory "0" of the "WIN40" directory. The full path to access them will be "\\WINDOWSHOST\print$\WIN40\0\".

6.7.2.2. Collecting the Driver Files from a Windows Host's [print$] Share

Now we need to collect all the driver files we identified. in our previous step. Where do we get them from? Well, why not retrieve them from the very PC and the same [print$] share which we investigated in our last step to identify the files? We can use smbclient to do this. We will use the paths and names which were leaked to us by "getdriver". The listing is edited to include linebreaks for readability:

After this command is complete, the files are in our current local directory. You probably have noticed that this time we passed several commands to the "-c" parameter, separated by semi-colons. This effects that all commands are executed in sequence on the remote Windows server before smbclient exits again.

Don't forget to repeat the procedure for the "WIN40" architecture should you need to support Win95/98/XP clients. Remember, the files for these architectures are in the WIN40/0/ subdir. Once we are complete, we can run "smbclient ... put" to store the collected files on the Samba server's [print$] share.

6.7.2.3. Depositing the Driver Files into [print$]

So, now we are going to put the driver files into the [print$] share. Remember, the UNIX path to this share has been defined previously in your smb.conf. You also have created subdirectories for the different Windows client types you want to support. Supposing your [print$] share maps to the UNIX path /etc/samba/drivers/, your driver files should now go here:

We again use smbclient to transfer the driver files across the network. We specify the same files and paths as were leaked to us by running "getdriver" against the original Windows install. However, now we are going to store the files into a Samba /UNIX print server's [print$] share...

Phewww -- that was a lot of typing! Most drivers are a lot smaller -- many only having 3 generic PostScript driver files plus 1 PPD. Note, that while we did retrieve the files from the "2" subdirectory of the "W32X86" directory from the Windows box, we *don't* put them (for now) in this same subdirectory of the Samba box! This re-location will automatically be done by the "adddriver" command which we will run shortly. (And don't forget to also put the files for the Win95/98/ME architecture into the WIN40/ subdirectory should you need them....).

6.7.2.4. Check if the Driver Files are there (with smbclient)

For now we verify that our files are there. This can be done with smbclient too (but of course you can log in via SSH also and do this through a standard UNIX shell access too):

Notice that there are already driver files present in the "2" subdir (probably from a previous installation). Once the files for the new driver are there too, you are still a few steps away from being able to use them on the clients. The only thing you could do *now* is to retrieve them from a client just like you retrieve ordinary files from a file share, by opening print$ in Windows Explorer. But that wouldn't install them per Point'n'Print. The reason is: Samba doesn't know yet that these files are something special, namely printer driver files and it doesn't know yet to which print queue(s) these driver files belong....

6.7.2.5. Running rpcclient with adddriver

So, next you must tell Samba about the special category of the files you just uploaded into the [print$] share. This is done by the "adddriver" command. It will prompt Samba to register the driver files into its internal TDB database files. The following command and its output has been edited, again, for readability:

After this step the driver should be recognized by Samba on the print server. You need to be very carefull when typing the command. Don't exchange the order of the fields. Some changes would lead to a "NT_STATUS_UNSUCCESSFUL" error message. These become obvious. Other changes might install the driver files successfully, but render the driver unworkable. So take care! Hints about the syntax of the adddriver command are in the man page. The CUPS printing chapter of this HOWTO collection provides a more detailed description, if you should need it.

6.7.2.6. Check how Driver Files have been moved after adddriver finished

One indication for Samba's recognition of the files as driver files is the "successfully installed" message. Another one is the fact, that our files have been moved by the adddriver command into the "2" subdirectory. You can check this again with smbclient:

Another verification is that the timestamp of the printing TDB files is now updated (and possibly their filesize has increased).

6.7.2.7. Check if the Driver is recognized by Samba

Now the driver should be registered with Samba. We can easily verify this, and will do so in a moment. However, this driver is *not yet* associated with a particular printer. We may check the driver status of the files by at least three methods:

6.7.2.8. A Sidenote: you are not bound to specific Driver Names

You can name the driver as you like. If you repeat the "adddriver" step, with the same files as before, but with a different driver name, it will work the same:

6.7.2.9. Le Finale Grande: Running rpcclient with setdriver

Samba still needs to know *which* printer's driver this is. It needs to create a mapping of the driver to a printer, and store this info in its "memory", the TDB files. The rpcclient setdriver command achieves exactly this:

6.8. "The Proof for the Pudding lies in the Eating" (Client Driver Insta Procedure)

A famous philosopher said once: "The Proof for the Pudding lies in the Eating". The proof for our setup lies in the printing. So let's install the printer driver onto the client PCs. This is not as straightforward as it may seem. Read on.

6.8.1. The first Client Driver Installation

Especially important is the installation onto the first client PC (for each architectural platform separately). Once this is done right, all further clients are easy and shouldn't need further attention. What follows is a description for the recommended first procedure. You work now from a client workstation. First you should guarantee that your connection is not unwittingly mapped to bad user "nobody". In a DOS box type:

Replace root, if needed, by another valid 'printer admin' user as of smb.conf definition. Should you already be connected as a different user, you'll get an error message. There is no easy way to get rid of that connection, because Windows doesn't seem to know a concept of "logging off" from a share connection (don't confuse this with logging off from the local workstation; that is a different matter). You can try to close *all* Windows file explorer and Internet Explorer windows. As a last resort, you may have to reboot. Make sure there is no automatic re-connection set up. (It may be easier to go to a different workstation and try from there...). After you made sure you are connected as a printer admin user (you can check this with the "smbstatus" command on Samba), do this from the Windows workstation:

A new printer (named "printername on samba-server ") should now have appeared in your *local* Printer folder (Start --> Settings --> Control Panel --> Printers and Faxes). ( FIXME: this was translated from German. Someone please tell me the correct words. FIXME ) --

Most likely you are now tempted to try and print a test page. After all, you now can open the printer properties and on the "General" tab, there is a button offering to do just that. But chances are that you get an error message saying "Unable to print Test Page." The reason might be that there is not yet a valid Device Mode set for the driver, or that the "Printer Driver Data" set is still incomplete.

You must now make sure that a valid "Device Mode" is set for the driver. Don't fear -- we will explain now what that means.

6.8.2. IMPORTANT! Setting Device Modes on new Printers

In order for a printer to be truly usable by a Windows NT/2K/XP client, it must possess:

If either one of these is incomplete, the clients can produce less than optimal output at best. In the worst cases, unreadable garbage or nothing at all comes from the printer or they only harvest error messages when attempting to print. Samba stores the named values and all printing related info in its internal TDB database files (ntprinters.tdb, ntdrivers.tdb, printing.tdb and ntforms.tdb).

What do these two words stand for? Basically, the Device Mode and the set of Printer Driver Data is a collection of settings for all print queue properties, initialized in a sensible way. Device Modes and PrinterDriverData should initially be set on the print server (that is here: the Samba host) to healthy values so that the clients can start to use them immediately. How do we set these initial healthy values? This can be achieved by accessing the drivers remotely from an NT (or 2k/XP) client, as is discussed in the next paragraphs.

Be aware, that a valid Device Mode can only be initiated by a "printer admin", or root (the reason should be obvious). Device Modes can only correctly be set by executing the printer driver program itself. Since Samba can not execute this Win32 platform driver code, it sets this field initially to NULL (which is not a valid setting for clients to use). Fortunately, most drivers generate themselves the PrinterDriverData that is needed, when they are uploaded to the [print$] share with the help of the APW or rpcclient.

The generation and setting of a first valid Device Mode however requires some "tickling" from a client, to set it on the Samba server. The easiest means of doing so is to simply change the page orientation on the server's printer. This "executes" enough of the printer driver program on the client for the desired effect to happen, and feeds back the new DeviceMode to our Sanba server. You can use the native Windows NT/2K/XP printer properties page from a Window client for this:

This procedure has executed the printer driver program on the client platform and fed back the correct Device Mode to Samba, which now stored it in its TDB files. (Once the driver is installed on the client, you can follow the analogous steps by accessing the *local* "Printers" folder too if you are a Samba printer admin user.) From now on printing should work as expected.

Samba also includes a service level parameter name default devmode for generating a default Device Mode for a printer. Some driver will function fine with Samba's default set of properties. Others may crash the client's spooler service. So use this parameter with caution. It is always better to have the client generate a valid device mode for the printer and store it on the server for you.

6.8.3. Further Client Driver Insta Procedures

Every further driver may be done by any user, along the lines described above: Browse network, open printers folder on Samba server, right-click printer and choose "Connect...". Once this completes (should be not more than a few seconds, but could also take a minute, depending on network conditions), you should find the new printer in your client workstation local "Printers and Faxes" folder.

You can also open your local "Printers and Faxes" folder by using this command on Windows 2000 and Windows XP Professional workstations:

You can enter the commands either inside a "DOS box" window or in the "Run command..." field from the "Start" menu.

6.8.4. Always make first Client Connection as root or "printer admin"

After you installed the driver on the Samba server (in its [print$] share, you should always make sure that your first client installation goes OK. Make it a habbit for yourself to build that the very first connection from a client as "printer admin". This is to make sure that

Do this by changing the orientation to landscape, " Apply" and change it back. Then set up the other things. (You don't want the default media size set to Letter, when you are all using A4, right? You may want to set the thing do duplex as the default; etc.). --

To connect as root to a Samba printer, try this command from a Windows 2K/XP DOS box command prompt:

You are prompted for root's Samba-password; type it, wait a few seconds and click on "Printing Defaults..." and proceed to set the job options as should be used as defaults by all clients. -- Alternatively, instead of root you can name one other member of the printer admins from the smb.conf setting.

Now all the other users downloading and installing the driver the same way (called "Point'n'Print") will have the same defaults set for them. If you miss this step you'll get a lot of helpdesk calls from your users. But maybe you like to talk to people.... ;-)

6.9. Other Gotchas

Your driver is installed. It is ready for " Point'n'Print" installation by the clients now. You may have tried to download and use it onto your first client machine now. But wait... let's make you acquainted first with a few tips and tricks you may find useful. For example, you didn't manage to "set the defaults" on the printer, as adviced in the preceeding paragraphs? And your users complain about various issues ? (like "We need to set the paper size for each job from Letter to A4 and it won't store it!")

6.9.1. Setting default Print Options for the Client Drivers

The last sentence might by seen with mixed feelings by some users and admins. They have struggled for hours and hours and couldn't arrive at a point were their settings seemed to be saved. It is not their fault. The confusing thing is this: in the multi-tabbed dialog popping up when you right-click the printer name and select " Properties...", you can arrive at two identically looking dialogs, pretending that they help you to set printer options, in three different ways. Here is the definite answer to the "Samba Default Driver Setting FAQ":

6.9.2. Installing large Numbers of Printers

One issue that has arisen during the recent development phase of Samba is the need to support driver downloads for 100's of printers. Using Windows NT APW here is somewhat awkward (to say the least). If you don't want to acquire RSS pains from such the printer installation clicking orgy alone, you need to think about a non-interactive script.

If more than one printer are using the same driver, the rpcclient setdriver command can be used to set the driver associated with an installed queue. If the driver is uploaded to [print$] once and registred with the printing TDBs, it can be used by multiple print queues. In this case you just need to repeat the setprinter subcommand of rpcclient for every queue (without the need to conduct the adddriver again and again). The following is an example of how this could be accomplished. Of course you could mould this into a complete script, automating everything:

The 'enumprinters' command lists all shared printers known to Samba (and tagged as "browseable" in smb.conf!). Note that the description field would show the driver name, in the field where we see here only two commas...

The 'enumdrivers' command lists all drivers installed in the [print$] share. These drivers are there, left over from previous installations.

The 'setdriver' command sets one of the previously listed drivers to be associated with the "dm9110" printer. Note how upper- or lower case is irrelevant to the host name.

Again, the 'setdriver' command has set the printqueue with the new driver, as is indicated in the "description" field....

This command installs 5 printers into CUPS. Note that these are "raw" printers for CUPS, since we don't specify a PPD.... (The stopping and starting of Samba should not be necessary -- but an insistent bug in recent versions of Samba prevented the automatic update of the printer list. The 3.0 release should see this bug finally squashed...)

Here we use 'enumprinters' to query for Samba's sight of things. Note that Samba doesn't list a driver for these newly installed CUPS printers.

Here we use 'setdriver' to associate the 5 new print queues with a previously installed driver (as listed previously by 'enumdrivers'.) Of course, this driver needs to be choosen so that it is fitting the model for the Windows clients to download and use..

Now the 'enumprinters' command shows the drivername in the "description" field. Note, that the printers to CUPS still represent "raw" printqueues -- the driver listed here (the same one for each queue) is only usable for Samba's Windows clients to download, install and format the printjobs, which will be spooled as "raw" by CUPS....

It may be not easy to recognize: but the first call to "enumprinters" showed the "dm9110" printer with an empty string where the driver should have been listed (between the 2 commas in the "description" field). After the "setdriver" command succeeded, all is well. (The CUPS Printing chapter has more info about the installation of printer drivers with the help of rpccclient).

6.9.3. Adding new Printers with the Windows NT APW

By default, Samba exhibits all printer shares defined in smb.conf in the "Printers..." folder. Also located in this folder is the Windows NT Add Printer Wizard icon. The APW will be shown only if...

The last one (add a new printer) requires more effort than the previous ones. In order to use the APW to successfully add a printer to a Samba server, the add printer command must have a defined value. The program hook must successfully add the printer to the Unix print system (i.e. to /etc/printcap, /etc/cups/printers.conf or other appropriate files) and to smb.conf if necessary.

When using the APW from a client, if the named printer share does not exist, smbd will execute the " add printer command" and reparse to the smb.conf to attempt to locate the new printer share. If the share is still not defined, an error of "Access Denied" is returned to the client. Note that the "add printer command" is executed under the context of the connected user, not necessarily a root account. A "map to guest = bad user" may have connected you unwittingly under the wrong privilege -- check it by using the "smbstatus" command.

6.9.4. Weird Error Message "Can not connect under a different Name"

Once you are connected with the wrong credentials, there is no chance to correct that other than close all Explorer windows, and maybe reboot.

So you close all connections. You try again. You get the same message. You check from the Samba side, using "smbstatus". Yes, there are some more connections. You kill them all. The client still gives you the same error message. You watch the smbd.log file on a very high debug level and try re-connect. Same error message, but not a single line in the log. You start to wonder if there was a connection attempt at all. You run ethereal and tcpdump while you try to connect. Result: not a single byte goes on the wire. Windows still gives the errror message. You close all Explorere Windows and start it again. You try to connect -- and this times it works! Windows seems to cache connection info somewhere and doesn't keep it up to date. (In unlucky cases you might need to reboot to get rid of the error message.)

6.9.5. Be careful when assembling Driver Files

You need to be very careful when you take notes about the files and belonging to a particular driver. Don't confuse the files for driver version "0" (for Win95/98/ME, going into [print$]/WIN/0/), driver version "2" (Kernel Mode driver for WinNT, going into [print$]/W32X86/2/ -- may be used on Win2K/XP too), and driver version "3" (non-Kernel Mode driver going into [print$]/W32X86/3/ -- can not be used on WinNT). Very often these different driver versions contain files carrying the same name -- but still the files are very different! Also, if you look at them from the Windows Explorer (they reside in "%WINDOWS%\system32\spool\drivers\W32X86\") you will probably see names in capital letters, while an "enumdrivers" command from Samba would show mixed or lower case letters. So it is easily possible to confuse them. If you install them manually using "rpcclient" and subcommands, you may even succeed without an error message. Only later, when you try install on a client, you will encounter error messages like "This server has no appropriate driver for the printer..."

Here is an example. You are invited to look very closely at the various files, compare their names and their spelling, and discover the differences in the composition of the version-2 and -3 sets (BTW, the version-0 set contained 40 (!) Dependentfiles, so I left it out for space reasons):

If we write the "version 2" files and the "version 3" files into different text files and compare the result, we see this picture:

Don't get fooled though! Driver files for each version with identical names may be different in their content, as you can see from this size comparison:

In my example were even more differences than shown here. Conclusion: you must be very careful to select the correct driver files for each driver version. Don't rely on the names alone. Don't interchange files belonging to different driver versions.

6.9.6. Samba and Printer Ports

Windows NT/2000 print servers associate a port with each printer. These normally take the form of LPT1:, COM1:, FILE:, etc... Samba must also support the concept of ports associated with a printer. By default, only one printer port, named "Samba Printer Port", exists on a system. Samba does not really need such a "port" in order to print; it rather is a requirement of Windows clients. They insist to get told about an available port when they request this info, otherwise theyw and error message at you. So Samba fakes the port info to keep the Windows clients happy..

Note that Samba does not support the concept of "Printer Pooling" internally either. Printer Pooling assigns a logical printer to multiple ports as a form of load balancing or fail over.

If you require that multiple ports be defined for some reason or another ("My users and my Boss should not know that they are working with Samba"), smb.conf possesses a enumports command which can be used to define an external program that generates a listing of ports on a system.

6.9.7. Avoiding the most common Misconfigurations of the Client Driver

Soooo -- printing works, but there are still problems. Most jobs print well, some don't at all. Some jobs have problems with fonts, which don't look good at all. Some jobs print fast, and some are dead-slow. We can't cover it all -- but we want to encourage you to read the little paragraph about "Avoiding the wrong PostScript Driver Settings" in the CUPS Printing part of this document.

6.10. The Imprints Toolset

The Imprints tool set provides a UNIX equivalent of the Windows NT Add Printer Wizard. For complete information, please refer to the Imprints web site at http://imprints.sourceforge.net/ as well as the documentation included with the imprints source distribution. This section will only provide a brief introduction to the features of Imprints.

6.10.1. What is Imprints?

6.11.2. Creating Printer Driver Packages

The process of creating printer driver packages is beyond the scope of this document (refer to Imprints.txt also included with the Samba distribution for more information). In short, an Imprints driver package is a gzipped tarball containing the driver files, related INF files, and a control file needed by the installation client.

6.12.3. The Imprints Server

The Imprints server is really a database server that may be queried via standard HTTP mechanisms. Each printer entry in the database has an associated URL for the actual downloading of the package. Each package is digitally signed via GnuPG which can be used to verify that package downloaded is actually the one referred in the Imprints database. It is not recommended that this security check be disabled.

6.13.4. The Installation Client

More information regarding the Imprints installation client is available in the Imprints-Client-HOWTO.ps file included with the imprints source package.

The installation client (in both forms) provides a means of querying the Imprints database server for a matching list of known printer model names as well as a means to download and install the drivers on remote Samba and Windows NT print servers.

The basic installation process is in four steps and perl code is wrapped around smbclient and rpcclient

One of the problems encountered when implementing the Imprints tool set was the name space issues between various supported client architectures. For example, Windows NT includes a driver named "Apple LaserWriter II NTX v51.8" and Windows 95 calls its version of this driver "Apple LaserWriter II NTX"

The problem is how to know what client drivers have been uploaded for a printer. An astute reader will remember that the Windows NT Printer Properties dialog only includes space for one printer driver name. A quick look in the Windows NT 4.0 system registry at

will reveal that Windows NT always uses the NT driver name. This is ok as Windows NT always requires that at least the Windows NT version of the printer driver is present. However, Samba does not have the requirement internally. Therefore, how can you use the NT driver name if is has not already been installed?

The way of sidestepping this limitation is to require that all Imprints printer driver packages include both the Intel Windows NT and 95/98 printer drivers and that NT driver is installed first.

6.11. Add Network Printers at Logon without User Interaction

The following MS Knowledge Base article may be of some help if you need to handle Windows 2000 clients: How to Add Printers with No User Interaction in Windows 2000. ( http://support.microsoft.com/default.aspx?scid=kb;en-us;189105). It also applies to Windows XP Professional clients.

The ideas sketched out below are inspired by this article. It describes a commandline method which can be applied to install network and local printers and their drivers. This is most useful if integrated in Logon Scripts. You can see what options are available by typing in a command prompt ("DOS box") this:

A window pops up which shows you all of the commandline switches available. An extensive list of examples is also provided. This is only for Win 2k/XP. (It doesn't work on WinNT. WinNT has probably some other tools in the respective Resource Kit.) Here's a suggestion what a possible client logon script could contain, with a short explanation of what the lines actually do (it works if 2k/XP Windows clients access printers via Samba, but works for Windows-based print servers too):

I have tested this with a Samba 2.2.7a and a Samba 3.0alpha24 installation and Windows XP Professional clients. Note that this specific command set works with network print queues. (Installing local print queues requires different parameters, but this is of no interest here.)

Note that the second line only works if the printer "infotec2105-PS" is an already working printqueue on "sambacupsserver", and if the printer drivers have sucessfully been uploaded (via APW , smbclient/rpcclient or cupsaddsmb) into the [print$] driver repository of Samba. Also, some previous Samba versions required a re-start of smbd after the printer install and the driver upload, otherwise the script (or any other client driver download) would fail.

Since there no easy way to test for the existence of an installed network printer from the logon script, the suggestion is: don't bother checking and just allow the deinstallation/reinstallation every time a user logs in -- it's really quick anyway (1 to 2 seconds).

Since network printers are installed per user this makes for an easy up-to-date keeping. The extra few seconds at logon time will not really be noticeable. Printers can be centrally added, changed, and deleted at will on the server with no user intervention required on the clients. (You just need to keep the logon scripts up to date.).

6.12. The "addprinter command"

The "addprinter command" can be configured to be a shell script or program executed by Samba. It is triggered by running the APW from a client against the Samba print server. The APW asks the user to fill in several fields (like printer name, driver to be used, comment, port monitor, etc.). These parameters are passed on to Samba by the APW. If the addprinter command is designed in a way that it can create a new printer (through writing correct printcap entries on legacy systems, or execute the lpadmin command on more modern systems) and create the associated share in smb.conf, then the APW will in effect really create a new printer on Samba and the UNIX print subsystem!

( FIXME: this has to be more elaborated. A working expample script should be provided. It should be tested too. FIXME],

6.13. Migration of "Classical" printing to Samba 3.0

"NT-style" printer driver management has not changed considerably in 3.0 over the 2.2.x releases (apart from many improvements). Here migration should be quite easy, especially if you followed previous advice to stop using deprecated parameters in your setup. For migrations from an existing 2.0.x setup, or if you continued "Win9x-style" printing in your Samba 2.2 installations, it is more of an effort. Please read the appropriate release notes and the HOWTO Collection for 2.2. You can follow several paths. Here are possible scenarios for migration:

6.14. Publishing Printer Information in Active Directory or LDAP

6.15. Common Errors and Problems

Here are a few typical errors and problems people have encountered. You can avoid them. Read on.

6.15.1. I give my root password but I don't get access

Don't confuse the root password which is valid for the Unix system (and in most cases stored in the form of a one-way hash in a file named "/etc/shadow") with the password used to authenticate against Samba!. Samba doesn't know the UNIX password; for root to access Samba resources via Samba-type access, a Samba account for root must be created first. This is often done with the "smbpasswd" command.

6.15.2. My printjobs get spooled into the spooling directory, but then get lost

Don't use the existing Unix print system directory for Samba too. It may seem convenient and saving space, but it only leads to problems. The two must be separate.

Chapter 7: CUPS Printing Support in Samba 3.0

7.1. Features and Benefits

The Common Unix Print System ( CUPS) has become very popular. All big Linux distributions now ship it as their default printing system. But to many it is still a very mystical tool. Normally "It Just Works" (TM). People tend to regard it as a sort of "black box", which they don't want to look into, as long as it works OK. But once there is a little problem, they are in trouble to find out where to start debugging it. Also, even the most recent and otherwise excellent printed Samba documentation deals quite negligent with CUPS printing, leaving out important pieces or even writing plain wrong things about it. This demands rectification. But before you dive into this chapter, make sure that you don't forget to refer to the "Classical Printing" chapter also -- it contains a lot of stuff that is relevant for CUPS too.

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 start understand CUPS from the beginning. This documentation will lead you here to a complete understanding of CUPS, if you study all of the material contained. But lets start with the most basic things first. Maybe this is all you need for now. Then you can skip most of the other paragraphs.

7.1.1. Overview

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). In addition it has the traditional commandline 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.

7.2. Basic Configuration of CUPS support

Printing with CUPS in the most basic smb.conf setup in Samba 3.0 (as was true for 2.2.x) only needs two settings: printing = cups and printcap = cups . CUPS itself doesn't need a printcap file anymore. However, thecupsd.conf configuration file knows two related directives: they control if such a file should be automatically created and maintained by CUPS for the convenience of third party applications (example: Printcap /etc/printcap and PrintcapFormat BSD). These legacy programs often insist to find a "printcap" file containing printernames -- or they will refuse to print. Make sure CUPS is set to generate and maintain a printcap! For details see "man cupsd.conf" and other CUPS-related documentation, like the wealth of documents on your CUPS server itself: http://localhost:631/documentation.html.

7.2.1. Linking of smbd with libcups.so

Samba has a very special relationship to CUPS. The reason is: Samba can be compiled with CUPS library support. Most recent installations have this support enabled, and 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.

If SAMBA is compiled against libcups, then 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):

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!

7.2.2. Simple smb.conf Settings for CUPS

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, nost of your Windows users would not know how to send this kind of files to print without opening a GUI application. Windows clients tend to have local printer drivers installed. And the GUI applecation'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.

7.2.3. More complex smb.conf Settings for CUPS

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 my testing purposes. It doesn't even write the printjob 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't announced in Network Neighbourhood (so you need to know it is there), and it is only allowing access from 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".

7.3. Advanced Configuration

Before we dive into further configuration options and setup details, let's clarify one point: Network printing needs to be organized and setup properly!. Often this is not done right. Legacy systems or small LANs in business environments often lack a clear design and good housekeeping.

7.3.1. Central spooling vs. "Peer-to-Peer" printing

Many small office or home networks, as well as badly organized larger environments, allow each client a direct access to available network printers. Generally, this is 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.

7.3.2. CUPS/Samba as a "spooling-only" Print Server -- "raw" printing with Vendor Drivers on Windows Clients

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 printjob file in such a way that it beame fit to be fed 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.

Of course you can setup CUPS, Samba and your Windows clients in the same, traditional and simple way. When CUPS printers are configured for RAW print-gh 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.

7.3.3. Driver Installation Methods on Windows Clients

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

7.3.4. Explicitly enable "raw" printing for application/octet-stream!

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:

Note: editing the "mime.convs" and the "mime.types" file does not *enforce* "raw" printing, it only *allows* it.

Background: CUPS being a more security-aware printing system than traditional ones does not by default allow 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: 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 info about more advanced CUPS/Samba printing, simply skip the remaining sections of this chapter.

7.3.5. Three familiar Methods for Driver Upload plus a new one

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

7.4. Using CUPS/Samba in an advanced Way -- intelligent printing with PostScript Driver Download

Still reading on? Good. Let's go into more detail then. We now know how to set up a "dump" printserver -- a server which is spooling printjobs "raw", leaving the print data untouched.

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

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

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

7.4.1. GDI on Windows -- PostScript on Unix

Network printing is one of the most complicated and error-prone day-to-day tasks any user or 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 justw them towards printers and they get printed. There needs to be a file format conversion in between. The mess 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 extend 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 there own" (their reasons may be unacceptable license fees for using printer-embedded PostScript interpreters, etc.).

7.4.2. Windows Drivers, GDI and EMF

In Windows OS, the format conversion job is done by the printers 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). Therefor 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 both, 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.

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

7.4.3. Unix Printfile Conversion and GUI Basics

In Unix and Linux, there is no comparable layer built into the OS kernel(s) or the X (screen display) server. Every application is responsible for itself to create its print output. Fortunately, most use PostScript. 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". (There is now, already for a few years, the "Xprint" project going on; it tries 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 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...

7.4.4. PostScript and Ghostscript

So, Unix is lacking one common ground for printing on paper and displaying on screen. Despite of 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 PostScript language "interpreter", also called a Raster Image Processor (RIP), built-in (which makes them more expensive than other types of printers);w PostScript towards them, and they will spit out your prints. 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 difference to PostScript printing of a file from a Windows origin.

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

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.

7.4.5. Ghostscript -- the Software RIP for non-PostScript Printers

Here is where Ghostscript kicks in. Ghostscript is the traditional (and quite powerful) PostScript interpreter used on Unix platforms. It is a RIP in software, capable 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.

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

7.4.6. PostScript Printer Description (PPD) Specification

While PostScript in essence is a Page Description Language (PDL) to represent the page layout in a device independent way, real world print jobs are always ending up 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.

Info from these PPDs is meant to be taken into account by the printer drivers. Therefor, 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

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

7.4.7. CUPS can use all Windows-formatted Vendor PPDs

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 favorable OS in his manuals and brochures -- you can safely trust on this: if you get hold of the Windows NT version of the PPD, you can use it unchanged in CUPS and thusly access the full power of your printer just like a Windows NT user could!

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

Warning: For real PostScript printers don't use the "Foomatic" or "cupsomatic" PPDs from Linuxprinting.org. With these devices the original vendor-provided PPDs are always the first choice!

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

7.4.8. CUPS also uses PPDs for non-PostScript Printers...

CUPS uses specially crafted PPDs to handle non-PostScript printers too. 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.

7.5. The CUPS Filtering Architecture

The core of the CUPS filtering system is based on Ghostscript. In addition to Ghostscript, CUPS uses some other filters of its own. You (or your OS vendor) may have plugged in even more filters. CUPS handles all data file formats under the label of various "MIME types". Every incoming printfile is subjected to an initial "auto-typing". The auto-typing determines its given MIME type. A given MIME type implies one or more (or none) possible filtering chain regarding the selected target printer. This section discusses how MIME types recognition and conversion rules interact. They are used by CUPS to automatically setup a working filtering chain for any given input data format.

If CUPS rasterizes a PostScript file natively to a bitmap, this is done in 2 stages:

Make sure your Ghostscript version has the "cups" device compiled in (check with "gs -h | grep cups"). Otherwise you may encounter the dreaded "Unable to convert file 0" in your CUPS error_log file. To have "cups" as a device in your Ghostscript, you either need to patch GNU Ghostscript and re-compile, or use "ESP Ghostscript" . The superior alternative is ESP Ghostscript: it supports not just CUPS, but also 300 other devices (while GNU Ghostscript supports only ~180). Because of this broad output device support, ESP Ghostscript is the first choice for non-CUPS spoolers too. It is now recommended by Linuxprinting.org for all spoolers.

CUPS printers may be setup to use external rendering paths. One of the most common ones is provided by the "Foomatic/cupsomatic" concept, from Linuxprinting.org. This uses the classical Ghostscript approach, doing everything in one step. It doesn't use the "cups" device, but one of the many others. However, even for Foomatic/cupsomatic usage, best results and broadest printer model support is provided by ESP Ghostscript (more about cupsomatic/Foomatic -- especially the new version called now "foomatic-rip" -- follows below).

7.5.1. MIME types and CUPS Filters

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:

It 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:

Note: there is a very important difference between two similar MIME type in CUPS: one is "application/postscript", the other is "application/vnd.cups-postscript". While "application/postscript" is meant to be device independent (job options for the file are still outside the PS file content, embedded in commandline or environment variables by CUPS), "application/vnd.cups-postscript" may have the job options inserted into the PostScript data itself (were applicable). The transformation of the generic PostScript (application/postscript) to the device-specific version (application/vnd.cups-postscript) is the responsibility of the CUPS pstops filter. pstops uses information contained in the PPD to do the transformation.

Hint: Don't confuse any other "mime.types" file your system might be using with the one in the "/etc/cups/" directory.

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.

7.5.2. MIME type Conversion Rules

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:

It 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-$:

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").

7.5.3. Filter Requirements

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!

Hint: the mentioned "CUPS requirements" for filters are simple. Take filenames or stdin as input and write to stdout. They should take these 5 or 6 arguments:

printer
job user title copies options [filename]

* printer - The name of the printer queue (normally this is the name of the filter being run)
* job - The numeric job ID for the job being printed
* user - The string from the originating-user-name attribute
* title - The string from the job-name attribute
* copies - The numeric value from the number-copies attribute
* options - The job options
* filename - (Optionally) The print request file (if missing, filters expected data fed thru stdin)
In most cases it is very easy to write a simple wrapper script around existing filters to make them work with CUPS.

7.5.4. Prefilters

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.

7.5.5. pstops

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.

7.5.6. pstoraster

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, who are able to generate device-specific printer data.

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 1st 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).

CUPS versions before 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 1.1.15, this has changed. The functions for this has been integrated back into Ghostscript (now based on GNU Ghostscript 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!

7.5.7. imagetops and imagetoraster

Above, in the section about prefilters we mentioned the prefilter which generates PostScript from image formats. The imagetoraster filter is used to directly go 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:

7.5.8. rasterto[printerspecific]

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

7.5.9. CUPS Backends

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-wided default deletes the job and sends a polite mail back to the $USER asking him to alsways specifiy 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 paralmeter, it lists all available backends:

7.5.10. cupsomatic/Foomatic -- how do they fit into the Picture?

"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.

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 and 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:

7.5.11. The complete Picture

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.

7.5.12. mime.convs

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.

Hint: The setting of " FilterLimit 1000" in cupsd.conf will not allow more filters to concurrently run than to consume a total of 1000 virtual filter cost. This is a very efficient way to limit the load of any CUPS server by setting an appropriate "FilterLimit" value. A FilterLimit of 200 allows roughly 1 job at a time, while a FilterLimit of 1000 allows approximately 5 jobs maximum at a time.

7.5.13. "Raw" printing

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

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.

7.5.14. "application/octet-stream" printing

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:

Note: editing the "mime.convs" and the "mime.types" file does not *enforce* "raw" printing, it only *allows* it.

Background: CUPS being a more security-aware printing system than traditional ones does not by default allow 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.

7.5.15. PostScript Printer Descriptions (PPDs) for non-PS Printers

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:

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. Therefor 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):
* deskjet.ppd, older HP inkjet printers and compatible
* deskjet2.ppd, newer HP inkjet printers and compatible
* dymo.ppd, label printers
* epson9.ppd, Epson 24pin impact printers and compatible
* epson24.ppd, Epson 24pin impact printers and compatible
* okidata9.ppd, Okidata 9pin impact printers and compatible
* okidat24.ppd, Okidata 24pin impact printers and compatible
* stcolor.ppd, older Epson Stylus Color printers
* stcolor2.ppd, newer Epson Stylus Color printers
* stphoto.ppd, older Epson Stylus Photo printers
* stphoto2.ppd, newer Epson Stylus Photo printers
* laserjet.ppd, all PCL printers
Further below is a discussion of several other driver/PPD-packages suitable fur use with CUPS.

7.5.16. Difference: "cupsomatic/foomatic-rip" and "native CUPS" printing

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

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

foomatic-rip "kidnaps" the printfile after the "application/vnd.cups-postscript" stage and deviates it through the CUPS-external, systemwide Ghostscript installation: Therefore the printfile bypasses the "pstoraster" filter (and thus also bypasses the CUPS-raster-drivers "rastertosomething "). After Ghostscript finished its rasterization, foomatic-rip hands the rendered file directly to the CUPS backend... The flowchart above illustrates the difference between native CUPS rendering and the foomatic-rip method.

7.5.17. Examples for filtering Chains

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":

Assume you want to print the same file 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 pdftops --> pstops --> pstoraster --> rastertoepson --> usb.

7.5.18. Sources of CUPS drivers / PPDs

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

NOTE: the cupsomatic/foomatic-rip trick from Linuxprinting.org is working different from the other drivers. This is explained elsewhere in this document.

7.5.19. Printing with Interface Scripts

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:

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 info about the traditional usage of interface scripts is to be found at http://playground.sun.com/printing/documentation/interface.html.

7.6. Network printing (purely Windows)

Network printing covers a lot of ground. To understand what exactly goes on with Samba when it is printing on behalf of its Windows clients, let's first look at a "purely Windows" setup: Windows clients with a Windows NT print server.

7.6.1. From Windows Clients to an NT Print Server

7.6.2. Driver Execution on the Client

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.

7.6.3. Driver Execution on the Server

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.

7.7. Network Printing (Windows clients -- UNIX/Samba Print Servers)

Since UNIX print servers can *not* execute the Win32 program code on their platform, the picture is somewhat different. However, this doesn't deprecate you in your options much. In the contrary, you may have a way here to implement printing features which are not possible otherwise.

7.7.1. From Windows Clients to a CUPS/Samba Print Server

Here is a simple recipe 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 [globals] 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 gh. (If you want your own defined print commands to work with a Samba that has CUPS support compiled in, simply use "printing = sysv "...)

7.7.2. Samba receiving Jobfiles and passing them to CUPS

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.

7.8. Network PostScript RIP: CUPS Filters on Server -- clients use PostScript Driver with CUPS-PPDs

PPDs can control all print device options. They are usually provided by the manufacturer -- if you own a PostScript printer, that is. PPD files (PostScript Printer Descriptions) are always a component of PostScript printer drivers on MS Windows or Apple Mac OS systems. They are ASCII files containing user-selectable print options, mapped to appropriate PostScript, PCL or PJL commands for the target printer. Printer driver GUI dialogs translate these options "on-the-fly" into buttons and drop-down lists for the user to select.

CUPS can load, without any conversions, the PPD file from any Windows (NT is recommended) PostScript driver and handle the options. There is a web browser interface to the print options (select http://localhost:631/printers/ and click on one "Configure Printer" button to see it), a commandline interface (see man lpoptions or see if you have lphelp on your system) plus some different GUI frontends on Linux/UNIX, which can present PPD options to users. PPD options are normally meant to become evaluated by the PostScript RIP on the real PostScript printer.

7.8.1. PPDs for non-PS Printers on UNIX

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 gh 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.

7.8.2. PPDs for non-PS Printers on Windows

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.

7.9. Windows Terminal Servers (WTS) as CUPS Clients

This setup may be of special interest to people experiencing major problems in WTS environments. WTS need often a multitude of non-PostScript drivers installed to run their clients' variety of different printer models. This often imposes the price of much increased instability.

7.9.1. Printer Drivers running in "Kernel Mode" cause many Problems

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 "Blues 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.

7.9.2. Workarounds impose heavy Limitations

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 then simplex prints from one standard paper tray, while their devices could do much better, if driven by a different driver! )

7.9.3. CUPS -- a "Magical Stone"?

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

7.9.4. PostScript Drivers with no major problems -- even in Kernel Mode

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 ini Kernel mode. (You can roughly tell 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.

7.10. Setting up CUPS for driver Download

We have said before: all previously known methods to prepare client printer drivers on the Samba server for download and Point'n'Print convenience of Windows workstations are working with CUPS too. These methods were described in the previous chapter. (In reality, this is a pure Samba business, and only a matters the Samba/Win client relationship.)

7.10.1. cupsaddsmb -- the unknown Utility

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 prefered 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 have to get the respective part of Adobe driver too if you need to support Windows 95, 98, and ME clients.

7.10.2. Prepare your smb.conf for cupsaddsmb

7.10.3. CUPS Package of "PostScript Driver for WinNT/2k/XP"

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:

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:

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

ATTENTION: due to a bug, one recent CUPS release puts the cups.hlp driver file into /usr/share/drivers/ instead of /usr/share/cups/drivers/. To work around this, copy/move the file (after running the " ./cups-samba.install" script) manually to the right place

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.

7.10.4. Recognize the different Driver Files

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

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.

Note: if both, the Adobe driver files and the CUPS driver files for the support of WinNT/2k/XP are present in , the Adobe ones will be ignored and the CUPS ones will be used. If you prefer -- for whatever reason -- to use Adobe-only drivers, move away the 3 CUPS driver files. The Win95/98/ME clients use the Adobe drivers in any case.

7.10.5. Acquiring the Adobe Driver Files

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

7.10.6. ESP Print Pro Package of "PostScript Driver for WinNT/2k/XP"

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.

7.10.7. Caveats to be considered...

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). [Hint: You may need to put root into the smbpasswd file by running "smbpasswd"; this is especially important if you should run this whole procedure for the first time, and are not working in an environment where everything is configured for "Single Sign On" to a Windows Domain Controller.]

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.

NOTE 1: Win 9x/ME clients won't work with the CUPS PostScript driver. For these you'd still need to use the ADOBE*.* drivers as previously.

NOTE 2: It is not harming if you've still the ADOBE*.* driver files from previous installations in the "/usr/share/cups/drivers/" directory. The new cupsaddsmb (from 1.1.16) will automatically prefer "its own" drivers if it finds both.

NOTE 3: Should your Win clients have had the old ADOBE*.* files for the Adobe PostScript driver installed, the download and installation of the new CUPS PostScript driver for Windows NT/2k/XP will fail at first. You need to wipe the old driver from the clients first. It is not enough to "delete" the printer as the driver files will still be kept by the clients and re-used if you try to re-install the printer. To really get rid of the Adobe driver files on the clients, open the "Printers" folder (possibly via "Start --> Settings --> Control Panel --> Printers"), right-click onto the folder background and select "Server Properties". A new dialog opens; select the "Drivers" tab; on the list select the driver you want to delete and click on the "Delete" button. (This will only work if there is not a single printer left which uses that particular driver -- you need to "delete" all printers using this driver in the "Printers" folder first.) You need Administrator privileges to do this.

NOTE 4: Once you have successfully downloaded the CUPS PostScript driver to a client, you can easily switch all printers to this one by proceeding as described elsewhere in the "Samba HOWTO Collection": either change a driver for an existing printer by running the "Printer Properties" dialog, or use "rpcclient" with the "setdriver" sub-command.

7.10.9. Run "cupsaddsmb" (quiet Mode)

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 and 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"). Probably your root has already a Samba account. Otherwise, create it now, using "smbpasswd":

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.)

7.10.10. Run "cupsaddsmb" with verbose Output

Probably you want to see what's going on. Use the -v parameter to get a more verbose output (Attention -- you will see the root password for the Samba account printed on screen. If you use remote access, the password will go over the wire unencrypted!) 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:

If you look closely, you'll discover your root password was transfered 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.

7.10.11. Understanding cupsaddsmb

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):

7.10.12. How to recognize if cupsaddsm completed successfully

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.

Note, that it is impossible to see any diagnostic output if you don't run cupsaddsmb in verbose mode. Therefore we strongly recommend to not use the default quiet mode. It will hide any problems from you which might occur.

7.10.13. cupsaddsmb with a Samba PDC

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:

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

7.10.14. cupsaddsmb Flowchart

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!)

7.10.15. Installing the PostScript Driver on a Client

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, there the new printer appears in a "\\SambaServer\PrinterName" notation in the dropdown list of available printers.

NOTE: cupsaddsmb will only reliably work with CUPS version 1.1.15 or higher and Samba from 2.2.4. If it doesn't work, or if the automatic printer driver download to the clients doesn't succeed, you can still manually install the CUPS printer PPD on top of the Adobe PostScript driver on clients. Then point the client's printer queue to the Samba printer share for a UNC type of connection:

7.10.16. Avoiding critical PostScript Driver Settings on the Client

Soooo -- printing works, but there are still problems. Most jobs print well, some don't 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:

7.11. Installing PostScript Driver Files manually (using rpcclient)

Of course you can run all the commands which are embedded into the cupsaddsmb convenience utility yourself, one by one, and hereby upload and prepare the driver files for future client downloads.

We are going to do this now. First, read the man page on "rpcclient" to get a first idea. Look at all the printing related sub-commands. "enumprinters", "enumdrivers", " enumports", "adddriver", "setdriver" are amongst the most interesting ones. rpcclient implements an important part of the MS-RPC protocol. You can use it to query (and command) a Win NT (or 2K/XP) PC too. MS-RPC is used by Windows clients, amongst other things, to benefit from the "Point'n' Print" features. Samba can now mimic this too.

7.11.1. A Check for the man Page

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

7.11.2. Understanding the man Page

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:

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 doI 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.

7.11.3. Producing an Example by querying a Windows Box

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:

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

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.

7.11.4. What is required for adddriver and setdriver to succeed

From the manpage (and from the quoted output of cupsaddsmb, above) it becomes clear, that you need to have the 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:

7.11.5. Manual Commandline Driver Installation in 15 little Steps

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.

7.11.6.1. First Step: Install the Printer on CUPS

This installs printer with the name "mysmbtstprn" to the CUPS system. The printer is accessed via a socket (a.k.a. JetDirect or Direct TCP/IP) connection. You need to be root for this step

7.11.6.2. Second Step (optional): Check if the Printer is recognized by Samba

This should show the printer in the list. If not, stop and re-start the Samba daemon (smbd), or send a HUP signal: " kill -HUP `pidof smbd`". Check again. Troubleshoot + repeat until success. (Note the "empty" field between the two commas in the "description" line. Here would the driver name appear if there was one already) You need to know root's Samba password (as set by the "smbpasswd" command) for this step and most of the following steps (alternatively you can authenticate as one of the users from the "write list" as defined in smb.conf for [print$].)

7.11.6.3. Third Step (optional): Check if Samba knows a Driver for the Printer

Neither method of the 3 shown above should show a driver. This step is just to teach you the sight of that condition. An attempt to connect to the printer at this stage will prompt the message along the lines: "The server has not the required printer driver installed..."

7.11.6.4. Fourth Step: Put all required Driver Files into Samba's [print$]

(Note that this command should be entered in one long single line. Line-breaks and the line-end indicating "\" has been inserted for readability reasons.) This step is *required* for the next one to succeed. It makes the driver files physically present in the [print$] share. However, clients would still not be able to install them, because Samba does not yet treat them as driver files. A client asking for the driver would still be presented with a "not installed here" message.

7.11.6.5. Fifth Step: Verify where the Driver Files are now

7.11.6.6. Sixth Step: Tell Samba that these are *Driver* Files ("adddriver")

Note that your can not repeat this step if it fails. (It could fail because of a simple typo). It will most likely have moved a part of the driver files into the "2" subdirectory. If this step fails, you need to go back to the fourth step and repeat it, before you can try this one again. In this step you need to choose a name for your driver. It is normally a good idea to use the same name as is used for the printername; however, in big installations you may use this driver for a number of printers which have obviously different names. So the name of the driver is not fixed...

7.11.6.7. Seventh Step: Verify where the Driver Files are now

Notice how step 6 did also move the driver files to the appropriate subdirectory. (Compare with the situation after step 5).

7.11.6.8. Eighth Step (optional): Verify if Samba now recognizes the Driver

Remember, this command greps for the name you did choose for the driver in step Six. This command must succeed before you can proceed.

7.11.6.9. Ninth Step: Tell Samba which Printer should use these Driver Files ("setdriver")

Since you can bind any printername (==printqueue) to any driver, this is a very convenient way to setup many queues which use the same driver. You don't need to repeat all the previous steps for the setdriver command to succeed. The only pre-conditions are: "enumdrivers" must find the driver and "enumprinters" must find the printer.

7.11.6.10. Tenth Step (optional): Verify if Samba has this Association recognized

Compare these results with the ones from steps 2 and 3. Note that every single of these commands show the driver is installed. (Even the "enumprinters" command now lists the driver on the "description" line.)

7.11.6.11. Eleventh Step (optional): Tickle the Driver into a correct Device Mode

You certainly know how to install the driver on the client. In case you are not som familiar with Windows, here is a short recipe: browse the ntework neighbourhood, go to the Samba server, look for the shares. You should see all shared Samba printers. Double-click on the one in question, and the driver should get installed, and the network connection set up. An alternative way is to open the "Printers (and Faxes)" folder, right-click on the printer in question and select "Connect" or "Install". As a result, a new printer should have appeared in your client's local "Printers (and Faxes)" folder, named s.th. like "printersharename on Sambahostnam".

It is important that you execute this step as a Samba printer admin (as defined in smb.conf). Here is another method to do this on Windows XP. It uses a commandline, which you may type into the "DOS box" (type root's smbpassword when prompted):

Change any printer setting once (like "portrait" --> "landscape"), click "Apply"; change the setting back.

7.11.6.12. Twelveth Step: Install the Printer on a Client ("Point'n'Print")

7.11.6.13. Thirteenth Step (optional): Print a Test Page

Then hit [TAB] 5 times, [ENTER] twice, [TAB] once and [ENTER] again and march to the printer. (YMMV... ;-)

7.11.6.14. Fourteenth Step (recommended): Study the Test Page

Hmmm.... just kidding! By now you know everything about printer installations and you don't need to read a word. Just put it in a frame and bolt it to the wall with the heading "MY FIRST RPCCLIENT-INSTALLED PRINTER". Or throw it away, will ya?

7.11.6.15. Fifteenth Step (obligatory): Enjoy. Jump. Celebrate your Success

7.11.7. Troubleshooting revisited

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

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

7.12. The printing *.tdb Files

Some mystery is associated with the series of files with a *.tdb-suffix appearing in every Samba installation. They are " connections.tdb", "printing.tdb", "share_info.tdb ", "ntdrivers.tdb", "unexpected.tdb", "brlock.tdb ", "locking.tdb", "ntforms.tdb", "messages.tdb ", "ntprinters.tdb", "sessionid.tdb" and " secrets.tdb". What is their purpose?

7.12.1. Trivial DataBase Files

A Windows NT (Print) Server keeps track of all info 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 info 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.

7.12.2. Binary Format

*.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.

7.12.3. Loosing *.tdb 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 *.tdbs in time...

7.12.4. Using tdbbackup

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:

7.13. CUPS Print Drivers from Linuxprinting.org

CUPS ships with good support for HP LaserJet type printers. You can install the generic driver as follows:

(The "-m" switch will retrieve the "laserjet.ppd" from the standard repository for not-yet-installed-PPDs, which CUPS typically stores in /usr/share/cups/model. Alternatively, you may use "-P /path/to/your.ppd").

The generic laserjet.ppd however does not support every special option for every LaserJet-compatible model. It constitutes a sort of "least denominator" of all the models. If for some reason it is ruled out to you to pay for the commercially available ESP Print Pro drivers, your first move should be to consult the database on http://www.linuxprinting.org/printer_list.cgi. Linuxprinting.org has excellent recommendations about which driver is best used for each printer. Its database is kept current by the tireless work of Till Kamppeter from MandrakeSoft, who is also the principal author of the foomatic-rip utility.

NOTE, that the former "cupsomatic" concept is now be replaced by the new, much more powerful "foomatic-rip". foomatic-rip is the successor of cupsomatic. cupsomatic is not longer maintained. Here is the new URL to the Foomatic-3.0 database: http://www.linuxprinting.org/driver_list.cgi. If you upgrade to foomatic-rip, don't forget to also upgrade to the new-style PPDs for your foomatic-driven printers. foomatic-rip will not work with PPDs generated for the old cupsomatic. The new-style PPDs are 100% compliant to the Adobe PPD specification. They are intended to be used by Samba and the cupsaddsmb utility also, to provide the driver files for the Windows clients also!

7.13.1. foomatic-rip and Foomatic explained

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 operatings systems and all package formats (because there is none). Its history goes back a few years.

They recently have 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!

7.13.1.1. 690 "perfect" Printers

At present there are 690 devices dubbed as working "perfectly", 181 "mostly", 96 "partially" and 46 are "Paperweights". Keeping in mind that most of these are non-PostScript models (PostScript printers are automatically supported supported by CUPS in perfection, by using the manufacturer-provided Windows-PPD...), and that a multifunctional device never qualifies for "perfectly" if it doesn't also scan and copy and fax under GNU/Linux -- then this is a truely astonishing achievement. 3 years ago the number was not more than 500 -- and Linux or UNIX "printing" at the time wasn't anywhere near the quality it is today!

7.13.1.2. How the "Printing HOWTO" started it all...

A few years ago Grant Taylor started it all. The roots of today's Linuxprinting.org are in the first "Linux Printing HOWTO" which he authored. As a side-project to this document, which served many Linux users and admins to guide their first steps in this complicated and delicate setup (printing to a scientist is "applying a structured deposition of distinct patterns of ink or toner particles on paper substrates" ;-), he started to build in a little Postgres database with info about the hardware and driver zoo that made up Linux printing of the time. This database became the core component of today's Foomatic collection of tools and data. In the meantime it has moved to an XML representation of the data blobs.

7.13.1.3. Foomatic's strange Name

"Why the funny name?", you ask. When it really took off, around spring 2000, CUPS was far less popular than today, and most systems used LPD, LPRng or even PDQ to print. CUPS shipped with a few generic "drivers" (good for a few hundred different printer models). These didn't support many device-specific options. CUPS also shipped with its own built-in rasterization filter ("pstoraster", derived from Ghostscript). On the other hand, CUPS had this brilliant support for controlling all printer options through standardized and well-defined "PPD files" (PostScript Printers Description files). Plus, CUPS was designed to be easily extensible.

Grant had in his database already a respectable compilation of facts about a lot more printers, and the Ghostscript "drivers" they run with. His idea, to generate PPDs from the database info and use them to make standard Ghostscript filters work within CUPS, proofed to work very well. It also "killed several birds with one stone":

7.13.1.4. cupsomatic, pdqomatic, lpdomatic, directomatic....

It worked through a quickly-hacked up filter script named "cupsomatic". cupsomatic was running the printfile through Ghostscript, constructing automatically the rather complicated command line needed. It just required to be copied into the CUPS system to make it work. To "configure" the way cupsomatic controls the Ghostscript rendering process, it needs a CUPS-PPD. This PPD is generated directly from the contents of the database. For CUPS and the respective printer/filter combo another Perl script named "CUPS-O-Matic" did the PPD generation. After that was working, Grant implemented within a few days a similar thing for two other spoolers. Names chosen for the config-generator scripts were PDQ-O-Matic (for PDQ) and LPD-O-Matic (for -- you guessed it -- LPD); the configuration here didn't use PPDs but other spooler-specific files.

From late summer of that year, Till Kamppeter started to put work into the database. Till had been newly employed by MandrakeSoft to convert their printing system over to CUPS, after they had seen his FLTK-based XPP (a GUI frontend to the CUPS lp-command). He added a huge amount of new info and new printers. He also developed the support for other spoolers, like PPR (via ppromatic), GNUlpr and LPRng (both via an extended lpdomatic) and "spoolerless" printing (directomatic)....

Soooo, to answer your question: "Foomatic" is the general name for all the overlapping code and data behind the "*omatic" scripts.... -- Foomatic up to versions 2.0.x required (ugly) Perl data structures attached the Linuxprinting.org PPDs for CUPS. It had a different "*omatic" script for every spooler, as well as different printer configuration files..

7.13.1.5.The Grand Unification achieved...

This all has changed in Foomatic versions 2.9 (Beta) and now released "stable" 3.0. There is now the convergence of all *omatic scripts achieved: it is called the "foomatic-rip". This single one script is the unification of the previously different spooler-specific *omatic scripts. foomatic-rip is used by all the different spoolers alike. Because foomatic-rip can read PPDs (both, original PostScript printer PPDs and Linuxprinting.org-generated ones), all of a sudden all supported spoolers will have the power of PPDs at their disposal; users only need to plug "foomatic-rip" into their system.... For users there is improved media type and source support -- paper sizes and trays are easier to configure.

Also, the New Generation of Linuxprinting.org PPDs doesn't contain Perl data structures any more. If you are a distro maintainer and have used the previous version of Foomatic, you may want to give the new one a spin -- but don't forget to generate a new-version set of PPDs, via the new "foomatic-db-engine"! (Individual users just need to generate a single new PPD specific to their model by following the steps outlined in the Foomatic tutorial or further below...) This new development is truly amazing.

foomatic-rip is a very clever wrapper around the need to run Ghostscript with a different syntax, different options, different device selections and/or different filters for each different printer or different spooler. At the same time it can read the PPD associated with a print queue and modify the print job according to the user selections. Together with this comes the 100% compliance of the new Foomatic PPDs with the Adobe spec. Some really innovative features of the Foomatic concept is out for surprise to users: it will support custom paper sizes for many printers -- and it will support the printing on media drawn from different paper trays within the same job (in both cases: even where there is no support for this from Windows-based vendor printer drivers).

7.13.1.6. Driver Development outside

Most driver development itself does not happen on Linuxprinting.org. Drivers are done by independent maintainers. Linuxprinting.org just pools all the info, and stores it in its database. In addition, it also provides the Foomatic glue to integrate the many drivers into any modern (or legacy) printing system known to the world.

Speaking of the different driver development groups: most of the work is currently done in three projects. These are:

7.13.1.7. Forums, Downloads, Tutorials, Howtos -- also for Mac OS X and commercial Unix

Linuxprinting.org today is the one-stop "shop" to download printer drivers, look for printer info and tutorials or solve printing problems in its popular forums. But it's not just GNU/Linux: also users and admins of commercial UNIX systems are going there, and the relatively new Mac OS X forum has turned out to be one of the most frequented ones after only a few weeks.

Linuxprinting.org and the Foomatic driver wrappers around Ghostscript are now a standard toolchain for printing on all the important distros. Most of them also have CUPS underneath. While in recent years most printer data had been added by Till (who works at Mandrake), many additional contributions came from engineers with SuSE, RedHat, Connectiva, Debian and others. Vendor-neutrality is an important goal of the Foomaticproject.

7.13.1.8. Foomatic Database generates PPDs

The Foomatic database is an amazing piece of ingenuity in itself. Not only does it keep the printer and driver info. It is organized in a way that it can generate "PPD" files "on the fly" from its internal XML-based datasets. While these PPDs are modelled to the Adobe specification of "PostScript Printer Descriptions" (PPDs) -- the Linuxprinting.org/Foomatic-PPDs don't normally drive PostScript printers: they are used to describe all the bells and whistles you could ring or blow on an Epson Stylus inkjet, or a HP Photosmart or what-have-you. The main "trick" is one little additional line, not envisaged by the PPD specification, starting with the "*cupsFilter" keyword: it tells the CUPS daemon how to proceed with the PostScript print file. (Old-styple Foomatic-PPDs named the cupsomatic filter script, new-styple PPDs now call the foomatic-rip.). This filter script calls Ghostscript on the host system (the recommended variant is ESP Ghostscript) to do the rendering work. foomatic-rip knows which filter or internal device setting it should ask from Ghostscript to convert the PostScript printjob into a raster format ready for the target device. This usage of PPDs to describe the options of non-PS printers was the invention of the CUPS developers. The rest is easy: GUI tools (like KDE's marvellous "kprinter", or the GNOME "gtklp", "xpp" and the CUPS web interface) read the PPD too and use this info to present the available settings to the user as an intuitive menu selection.

7.13.2. foomatic-rip and Foomatic-PPD Download and Installation

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

7.14. Page Accounting with CUPS

Often there are questions regarding "print quotas": Samba users (=Windows clients) should not be able to print beyond a certain amount of pages or data volume per day, week or month. This feature is dependent on the real print subsystem you're using. Samba's part is always to receive the job files from the clients (filtered *or* unfiltered) and hand it over to this printing subsystem.

Of course one could "hack" things with one's own scripts....But there is CUPS (Common Unix Printing System). CUPS supports "quotas". Quotas can be based on sizes of jobs or on the number of pages or both, and are spanning any time period you want.

7.14.1. Setting up Quotas

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

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).

7.14.2. Correct and incorrect Accounting

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, proprietary drivers for the target printer running on the client computers and CUPS/Samba then spooling 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) for having 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 ~1.000 different printer models, see
http://www.linuxprinting.org/printer_list.cgi

7.14.3. Adobe and CUPS PostScript Drivers for Windows Clients

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 therefor was not counted correctly (the reason is that it often --- depending on the "PPD" being used --- did write a "PJL"-header in front of the real PostScript which made CUPS to skip the 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" (it is tagged in the download area of http://www.cups.org/ as the "cups-samba-1.1.16.tar.gz" package). It is *not* working for Win9x/ME clients. But it:

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

7.14.4. The page_log File Syntax

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:

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"

7.14.5. Possible Shortcomings

7.14.6. Future Developments

But this is the best system out there currently. And there are huge improvements under development for CUPS 1.2:

7.14.7. Other Accounting Tools

PrintAnalyzer, pyKota, printbill, LogReport... (FIXME: There need to go a few sentences in here... FIXME)

more collected material...

CUPS is widely configurable and flexible, even regarding its filtering mechanism. Another workaround in some situations would be to have in "/etc/cups/mime.types" entries as follows:

and would effectively send *all* files to the backend without further processing.

CUPS can handle "-o job-hold-until=indefinite ". This keeps the job in the queue "on hold". It will only be printed upon manual release by the printer operator. This is a requirement in many "central reproduction departments", where a few operators manage the jobs of hundreds of users on some big machine, where no user is allowed to have direct access. (The operators often need to load the proper paper type before running the 10.000 page job requested by marketing for the mailing, etc.).

7.15. Auto-Deletion or Preservation of CUPS Spool Files

Samba print files pass through two "spool" directories. One is the incoming directory managed by Samba, (set in the "path = /var/spool/samba" directive in the [printers] section of "smb.conf"). The other is the spool directory of your UNIX print subsystem. For CUPS it is normally "/var/spool/cups/", as set by the cupsd.conf directive "RequestRoot /var/spool/cups ".

7.15.1. Configuration Settings Docu

I am not sure, which one of your directories keeps the files. From what you say, it is most likely the Samba part.

There are the settings described for your CUPS daemon, which could lead to completed job files not being deleted.

7.15.2. Configuration Settings explained

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

7.15.3. Pre-conditions

7.15.4. Manual Configuration

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.

7.16. When not to use Samba to print to CUPS

7.17. In Case of Trouble.....

If you have more problems, post the output of these commands to the CUPS or Samba mailing lists (choose the one which seems more relevant to your problem):

(adapt paths as needed). These commands leave out the empty lines and lines with comments, providing the "naked settings" in a compact way. Don't forget to name the CUPS and Samba versions you are using! This safes bandwidth and makes for easier readability for experts (and you are expecting experts to read them, right? ;-)

7.17.1. Where to find Documentation

7.17.2. How to ask for Help

7.17.3. Where to find Help

Chapter 8: APPENDIX

8.1. Trouble Shooting Guidelines to fix typical Samba printing Problems

This is a short description of how to debug printing problems with Samba. This describes how to debug problems with printing from a SMB client to a Samba server, not the other way around. For the reverse see the examples/printing directory.

8.2. Printing from CUPS to Windows attached Printers

From time to time the question arises, how you can print to a Windows attached printer from Samba. Normally the local connection "Windows host <--> printer" would be done by USB or parallel cable. But this doesn't matter to Samba. From here only a SMB connection needs to be opened to the Windows host. Of course, this printer must be "shared" first. As you have learned by now, CUPS uses "backends" to talk to printers and other servers. To talk to Windows shared printers you need to use the "smb" (surprise, surprise!) backend. Check if this is in the CUPS backend directory. This resides usually in /usr/lib/cups/backend/. You need to find a "smb" file there. It should be a symlink to smbspool . And this smbspool must exist and be executable:

 kde-bitshop:~# ls -l /usr/lib/cups/backend/   
 total 253
 drwxr-xr-x    3 root     root          720 Apr 30 19:04 .
 drwxr-xr-x    6 root     root          125 Dec 19 17:13 ..
 -rwxr-xr-x    1 root     root        10692 Feb 16 21:29 canon
 -rwxr-xr-x    1 root     root        10692 Feb 16 21:29 epson
 lrwxrwxrwx    1 root     root            3 Apr 17 22:50 http -> ipp
 -rwxr-xr-x    1 root     root        17316 Apr 17 22:50 ipp
 -rwxr-xr-x    1 root     root        15420 Apr 20 17:01 lpd
 -rwxr-xr-x    1 root     root         8656 Apr 20 17:01 parallel
 -rwxr-xr-x    1 root     root         2162 Mar 31 23:15 pdfdistiller
 lrwxrwxrwx    1 root     root           25 Apr 30 19:04 ptal -> /usr/local/sbin/ptal-cups
 -rwxr-xr-x    1 root     root         6284 Apr 20 17:01 scsi
 lrwxrwxrwx    1 root     root           17 Apr  2 03:11 smb -> /usr/bin/smbspool
 -rwxr-xr-x    1 root     root         7912 Apr 20 17:01 socket
 -rwxr-xr-x    1 root     root         9012 Apr 20 17:01 usb

 kde-bitshop:/etc/samba/tmp # ls -l `which smbspool`
 -rwxr-xr-x    1 root     root       563245 Dec 28 14:49 /usr/bin/smbspool

If this symlink doesn't exist, create it:

 kde-bitshop:~# ln -s `which smbspool` /usr/lib/cups/backend/smb

smbspool has been written by Mike Sweet from the CUPS folks. It is included and ships with Samba. (It may also be used with other print subsystems than CUPS, to spool jobs to Windows printer shares.). To set up printer "winprinter" on CUPS, you need to have a "driver" for it. Essentially this means to convert the print data on the CUPS/Samba host to such a format the printer can digest. (The Windows host is unable to convert any files you may send.) This also means you should be able to print to the printer if it where hooked directly at your Samba/CUPS host. (For troubleshooting purposes, this is what you should do, to determine if that part of the process chain is in order. Then proceed to fix the network connection/authentication to the Windows host, etc.).

To install a printer with the smb backend on CUPS, use this command:

 kde-bitshop:~# lpadmin -p winprinter -v smb://WINDOWSNETBIOSNAME/printersharename -P /path/to/PPD

The "PPD" must be fit to direct CUPS to generate the print data for the target model. (For PostScript printers just use the PPD that would be used with the Windows NT PostScript driver). But what to do, if the printer is only accessible with a password? Or if the printer's host is part of another workgroup? This is provided for: then you can include the required parameters as part of the "smb://" device-URI. Like this:

 smb://WORKGROUP/WINDOWSNETBIOSNAME/printersharename 
 smb://username:password@WORKGROUP/WINDOWSNETBIOSNAME/printersharename
 smb://username:password@WINDOWSNETBIOSNAME/printersharename

Note that the device-URI will be visible in the process list of the Samba server (f.e. when someone uses the "ps -aux" command on Linux), even if the username and passwords are sanitized before they get written into the log files. So this is an inherently insecure option. It is the only one. Don't use it if you want to protect your passwords. Better share the printer in a way that doesn't require a password! Printing will only work if you have a working netbios name resolution up and running. (You don't necessarily need to have smbd running -- but who wants that? :-)

8.3. More CUPS filtering Chains

The following diagrams reveal how CUPS handles print jobs.

#########################################################################
#
# CUPS in and of itself has this (general) filter chain (CAPITAL
# letters are FILE-FORMATS or MIME types, other are filters (this is
# true for pre-1.1.15 of pre-4.3 versions of CUPS and ESP PrintPro):
#
# SOMETHNG-FILEFORMAT
#      |
#      V
#     somethingtops
#      |
#      V
# APPLICATION/POSTSCRIPT
#      |
#      V
#     pstops
#      |
#      V
# APPLICATION/VND.CUPS-POSTSCRIPT
#      |
#      V
#     pstoraster   # as shipped with CUPS, independent from any Ghostscipt
#      |           # installation on the system
#      |  (= "postscipt interpreter")
#      V
# APPLICATION/VND.CUPS-RASTER
#      |
#      V
#     rastertosomething  (f.e. Gimp-Print filters may be plugged in here)
#      |   (= "raster driver")
#      V
# SOMETHING-DEVICE-SPECIFIC
#      |
#      V
#     backend
#
#
# ESP PrintPro has some enhanced "rastertosomething" filters as compared to
# CUPS, and also a somewhat improved "pstoraster" filter.
#
# NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
#       CUPS and ESP PrintPro plug-in where rastertosomething is noted.
#
#########################################################################

#########################################################################
#
# This is how "cupsomatic" comes into play:
# =========================================
#
# SOMETHNG-FILEFORMAT
#      |
#      V
#    somethingtops
#      |
#      V
# APPLICATION/POSTSCRIPT
#      |
#      V
#    pstops
#      |
#      V
# APPLICATION/VND.CUPS-POSTSCRIPT ----------------+
#      |                                          V
#      V                                         cupsomatic
#    pstoraster                                  (constructs complicated
#      |  (= "postscipt interpreter")            Ghostscript commandline
#      |                                         to let the file be
#      V                                         processed by a
# APPLICATION/VND.CUPS-RASTER                    "-sDEVICE=s.th."
#      |                                         call...)
#      V                                          |
#    rastertosomething                            V
#      |    (= "raster driver")     +-------------------------+
#      |                            | Ghostscript at work.... |
#      V                            |                         |
# SOMETHING-DEVICE-SPECIFIC         *-------------------------+
#      |                                          |
#      V                                          |
#    backend <------------------------------------+
#      |
#      V
#    THE PRINTER
#
#
# Note, that cupsomatic "kidnaps" the printfile after the
# "APPLICATION/VND.CUPS-POSTSCRPT" stage and deviates it gh
# the CUPS-external, systemwide Ghostscript installation, bypassing the
# "pstoraster" filter (therefor also bypassing the CUPS-raster-drivers
# "rastertosomething", and hands the rasterized file directly to the CUPS
# backend...
#
# 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)
#
# NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
#       CUPS and ESP PrintPro plug-in where rastertosomething is noted.
#
#########################################################################

#########################################################################
#
# And this is how it works for ESP PrintPro from 4.3:
# ===================================================
#
# SOMETHNG-FILEFORMAT
#      |
#      V
#     somethingtops
#      |
#      V
# APPLICATION/POSTSCRIPT
#      |
#      V
#     pstops
#      |
#      V
# APPLICATION/VND.CUPS-POSTSCRIPT
#      |
#      V
#     gsrip
#      |  (= "postscipt interpreter")
#      V
# APPLICATION/VND.CUPS-RASTER
#      |
#      V
#     rastertosomething  (f.e. Gimp-Print filters may be plugged in here)
#      |   (= "raster driver")
#      V
# SOMETHING-DEVICE-SPECIFIC
#      |
#      V
#     backend
#
# NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
#       CUPS and ESP PrintPro plug-in where rastertosomething is noted.
#
#########################################################################

#########################################################################
#
# This is how "cupsomatic" would come into play with ESP PrintPro:
# ================================================================
#
#
# SOMETHNG-FILEFORMAT
#      |
#      V
#    somethingtops
#      |
#      V
# APPLICATION/POSTSCRIPT
#      |
#      V
#    pstops
#      |
#      V
# APPLICATION/VND.CUPS-POSTSCRIPT ----------------+
#      |                                          V
#      V                                         cupsomatic
#    gsrip                                       (constructs complicated
#      |  (= "postscipt interpreter")            Ghostscript commandline
#      |                                         to let the file be
#      V                                         processed by a
# APPLICATION/VND.CUPS-RASTER                    "-sDEVICE=s.th."
#      |                                         call...)
#      V                                          |
#    rastertosomething                            V
#      |   (= "raster driver")      +-------------------------+
#      |                            | Ghostscript at work.... |
#      V                            |                         |
# SOMETHING-DEVICE-SPECIFIC         *-------------------------+
#      |                                          |
#      V                                          |
#    backend <------------------------------------+
#      |
#      V
#    THE PRINTER
#
# NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
#       CUPS and ESP PrintPro plug-in where rastertosomething is noted.
#
#########################################################################

#########################################################################
#
# And this is how it works for CUPS from 1.1.15:
# ==============================================
#
# SOMETHNG-FILEFORMAT
#      |
#      V
#     somethingtops
#      |
#      V
# APPLICATION/POSTSCRIPT
#      |
#      V
#     pstops
#      |
#      V
# APPLICATION/VND.CUPS-POSTSCRIPT-----+
#                  +------------------v------------------------------+
#                  | Ghostscript                                     |
#                  | at work...                                      |
#                  | (with                                           |
#                  | "-sDEVICE=cups")                                |
#                  |                                                 |
#                  |         (= "postscipt interpreter")             |
#                  |                                                 |
#                  +------------------v------------------------------+
#                                     |
# APPLICATION/VND.CUPS-RASTER >-------+
#      |
#      V
#     rastertosomething
#      |   (= "raster driver")
#      V
# SOMETHING-DEVICE-SPECIFIC
#      |
#      V
#     backend
#
#
# NOTE: since version 1.1.15 CUPS "outsourced" the pstoraster process to
#       Ghostscript. GNU Ghostscript needs to be patched to handle the
#       CUPS requirement; ESP Ghostscript has this builtin. In any case,
#       "gs -h" needs to show up a "cups" device. pstoraster is now a
#       calling an appropriate "gs -sDEVICE=cups..." commandline to do
#       the job. It will output "application/vnd.cup-raster", which will
#       be finally processed by a CUPS raster driver "rastertosomething"
#       Note the difference to "cupsomatic", which will *not* output
#       CUPS-raster, but a final version of the printfile, ready to be
#       sent to the printer. cupsomatic also doesn't use the "cups"
#       devicemode in Ghostscript, but one of the classical devicemodes....
#
# NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
#       CUPS and ESP PrintPro plug-in where rastertosomething is noted.
#
#########################################################################

#########################################################################
#
# And this is how it works for CUPS from 1.1.15, with cupsomatic included:
# ========================================================================
#
# SOMETHNG-FILEFORMAT
#      |
#      V
#     somethingtops
#      |
#      V
# APPLICATION/POSTSCRIPT
#      |
#      V
#     pstops
#      |
#      V
# APPLICATION/VND.CUPS-POSTSCRIPT-----+
#                  +------------------v------------------------------+
#                  | Ghostscript        . Ghostscript at work....    |
#                  | at work...         . (with "-sDEVICE=           |
#                  | (with              .            s.th."          |
#                  | "-sDEVICE=cups")   .                            |
#                  |                    .                            |
#                  | (CUPS standard)    .      (cupsomatic)          |
#                  |                    .                            |
#                  |          (= "postscript interpreter")           |
#                  |                    .                            |
#                  +------------------v--------------v---------------+
#                                     |              |
# APPLICATION/VND.CUPS-RASTER >-------+              |
#      |                                             |
#      V                                             |
#     rastertosomething                              |
#      |   (= "raster driver")                       |
#      V                                             |
# SOMETHING-DEVICE-SPECIFIC >------------------------+
#      |
#      V
#     backend
#
#
# NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
#       CUPS and ESP PrintPro plug-in where rastertosomething is noted.
#
##########################################################################

8.4. my TO-BO-DONE list...

Replace the ASCII art flowcharts by properly drawn PNG ones (any volunteers?)

Examples for customized filters/backends...

Where to find help...

Hacking CUPS (a "PDF Distilling Service" for all network clients -- customized backends and filters -- customized web interface -- an "add printer command" --...)

Caveats for the PostScript Driver Settings on the Win clients

Document the "3" subdir in [print$]/W32X86/

A "FAQ"?

Screenshots were applicable

Other printing protocols between Windows and UNIX

##############################################################################

8.5. Troubleshooting Tips

Win9x client can't install driver

For Win9x clients keep the printer names at 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....

testparm

Run "testparm": It will tell you if smb.conf parameters are in the wrong section. Many people have had the "printer admin" parameter in the [printers] section and experienced problems. "testparm" will tell you if it sees this...

"cupsaddsmb" keeps asking for a root password in a neverending loop

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).

"cupsaddsmb" gives "No PPD file for printer..." message (but I swear there is one!)

*--> 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?

I can't connect client to Samba printer.

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?

I can't reconnect to Samba under a new account from Win2K/XP

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: \\SAMBAHOST\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..."

Prevent to be connected to the Samba server as the "wrong" user

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.

Upgrading to CUPS drivers from Adobe drivers on NT/2K/XP clients gives problems

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).

I can't use "cupsaddsmb"on a Samba server which is a PDC

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).

I deleted a printer on Win2K -- but I still see its driver

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 driver 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.

Win2K/XP "Local Security Policies

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

WinXP clients -- Administrator can not install printers for all local users

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.... (probably a "logon script" could automatically install printers for all users?).

"Print Change Notify" functions on NT-clients

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

WinXP-SP1 introduced this "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...

I can't set and save default print options for all users on Win2K/XP

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 it for all users)
Here is how I do in on XP (my interface is German -- my re-translation into English might not be accurate):
A. the first "wrong" way:

1. Open the "Printers" folder.
2. Right-click on the printer ("remoteprinter on cupshost") and select in context menu "Print Settings..."
3. Look at this dialog closely and remember how it looks like.

B. the second, another "wrong" way:

1. Open the "Printers" folder.
2 Right-click on the printer ("remoteprinter on cupshost") and select in context menu "Properties"
3. Click on the "General" tab
4. Click on the button "Print Settings..."
5. A new dialog opens. Keep this dialog open and go back to the parent dialog.

C. the third, the "correct" way:
(Should you do it from the beginning, just do steps 1. + 2. from above "B.")

3. Click on the "Advanced" tab.
4. Click on the "Standard Settings..." (maybe "Printing Defaults...") button. (*)
5. On any of the two new tabs, click on the "Advanced..." (maybe "More..."?) button. (*)
6. A new dialog opens. Compare this one to the other, identical looking one from "B.5" or A.3".

Do you see any difference? I don't either... However, only the last one, which you arrived at with steps "C.1.-6." will safe any settings to become permanent 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...)
[ (*) Could someone with an English version of Win2K/XP please verify my translations and post corrections? Thanks. -kp- ]

What are the most common blunders in driver settings on Windows clients?

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.

I can't make "cupsaddsmb" work with newly installed printer

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.

My permissions on /var/spool/samba/ get reset after each reboot

Have you by accident set the CUPS spool directory to the same location?? ("RequestRoot /var/spool/samba/" -- or the other way round: "/var/spool/cups/" is set as "path" in the [printers] section). These *must* be different. Set RequestRoot in cupsd.conf to /var/spool/cups/ 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.

My printers work fine -- just the printer "lp" does intermittently swallows jobs and spits out completely different ones

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.

How do I "watch" my Samba server?

You can use "tail -f /var/log/samba/log.smbd" (you may need a different path) to see a live scrolling of all log messages. " smbcontrol smbd debuglevel" tells you which verbosity goes into the logs. "smbcontrol smbd debug 3" sets the verbosity to a quite high level (you can choose from 0 to 10 or 100). This works "on the fly", without the need to restart the smbd daemon. Don't use more than 3 initially -- or you'll drown in an ocean of messages.

I can't use Samba from my WinXP Home box, while access from WinXP Prof works flawlessly

You have our condolences! WinXP home has been completely neutered by Microsoft as compared to WinXP Prof: you can not log into a WinNT domain. It cannot join a Win NT domain as a member server. While it is possible to access domain resources, users don't have "single sign-on". They need to supply username and password each time they connect to a resource. Logon scripts and roaming profiles are not supported. It can server file and print shares -- but only in "share-mode security" level. It can not use "user-mode security" (what Windows 95/98/ME still can do).

Where do I find the Adobe PostScript driver files I need for "cupsaddsmb"?

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.

a_big.png: CUPS-Filtering-Flowchart-Complete