diff options
Diffstat (limited to 'docs/htmldocs/CUPS-printing.html')
-rw-r--r-- | docs/htmldocs/CUPS-printing.html | 3311 |
1 files changed, 3311 insertions, 0 deletions
diff --git a/docs/htmldocs/CUPS-printing.html b/docs/htmldocs/CUPS-printing.html new file mode 100644 index 0000000000..19c9d7a021 --- /dev/null +++ b/docs/htmldocs/CUPS-printing.html @@ -0,0 +1,3311 @@ +<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 19. CUPS Printing Support</title><link rel="stylesheet" href="samba.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.60.1"><link rel="home" href="index.html" title="SAMBA Project Documentation"><link rel="up" href="optional.html" title="Part III. Advanced Configuration"><link rel="previous" href="printing.html" title="Chapter 18. Classical Printing Support"><link rel="next" href="VFS.html" title="Chapter 20. Stackable VFS modules"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 19. CUPS Printing Support</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="printing.html">Prev</a> </td><th width="60%" align="center">Part III. Advanced Configuration</th><td width="20%" align="right"> <a accesskey="n" href="VFS.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="CUPS-printing"></a>Chapter 19. CUPS Printing Support</h2></div><div><div class="author"><h3 class="author"><span class="firstname">Kurt</span> <span class="surname">Pfeifle</span></h3><div class="affiliation"><span class="orgname">Danka Deutschland GmbH <br></span><div class="address"><p><tt class="email"><<a href="mailto:kpfeifle@danka.de">kpfeifle@danka.de</a>></tt></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Ciprian</span> <span class="surname">Vizitiu</span></h3><span class="contrib">drawings</span><div class="affiliation"><div class="address"><p><tt class="email"><<a href="mailto:CVizitiu@gbif.org">CVizitiu@gbif.org</a>></tt></p></div></div></div></div><div><div class="author"><h3 class="author"><span class="firstname">Jelmer</span> <span class="othername">R.</span> <span class="surname">Vernooij</span></h3><span class="contrib">drawings</span><div class="affiliation"><span class="orgname">The Samba Team<br></span><div class="address"><p><tt class="email"><<a href="mailto:jelmer@samba.org">jelmer@samba.org</a>></tt></p></div></div></div></div><div><p class="pubdate"> (3 June 2003) </p></div></div><div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><a href="CUPS-printing.html#id2931072">Introduction</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2931079">Features and Benefits</a></dt><dt><a href="CUPS-printing.html#id2931130">Overview</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2931182">Basic CUPS Support Configuration</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2931276">Linking smbd with libcups.so</a></dt><dt><a href="CUPS-printing.html#id2931526">Simple smb.conf Settings for CUPS</a></dt><dt><a href="CUPS-printing.html#id2931722">More Complex CUPS smb.conf Settings</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2932089">Advanced Configuration</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2932110">Central Spooling vs. Peer-to-Peer Printing</a></dt><dt><a href="CUPS-printing.html#id2932163">Raw Print Serving Vendor Drivers on Windows Clients</a></dt><dt><a href="CUPS-printing.html#id2932223">Installation of Windows Client Drivers</a></dt><dt><a href="CUPS-printing.html#cups-raw">Explicitly Enable raw Printing for application/octet-stream</a></dt><dt><a href="CUPS-printing.html#id2932552">Driver Upload Methods</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2932699">Advanced Intelligent Printing with PostScript Driver Download</a></dt><dd><dl><dt><a href="CUPS-printing.html#gdipost">GDI on Windows -- PostScript on UNIX</a></dt><dt><a href="CUPS-printing.html#id2932876">Windows Drivers, GDI and EMF</a></dt><dt><a href="CUPS-printing.html#id2933049">UNIX Printfile Conversion and GUI Basics</a></dt><dt><a href="CUPS-printing.html#post-and-ghost">PostScript and Ghostscript</a></dt><dt><a href="CUPS-printing.html#id2933354">Ghostscript the Software RIP for Non-PostScript Printers</a></dt><dt><a href="CUPS-printing.html#id2933497">PostScript Printer Description (PPD) Specification</a></dt><dt><a href="CUPS-printing.html#id2933573">Using Windows-Formatted Vendor PPDs</a></dt><dt><a href="CUPS-printing.html#id2933679">CUPS Also Uses PPDs for Non-PostScript Printers</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2933709">The CUPS Filtering Architecture</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2933883">MIME Types and CUPS Filters</a></dt><dt><a href="CUPS-printing.html#id2934118">MIME Type Conversion Rules</a></dt><dt><a href="CUPS-printing.html#id2934287">Filtering Overview</a></dt><dt><a href="CUPS-printing.html#id2934481">Prefilters</a></dt><dt><a href="CUPS-printing.html#id2934591">pstops</a></dt><dt><a href="CUPS-printing.html#id2934715">pstoraster</a></dt><dt><a href="CUPS-printing.html#id2934912">imagetops and imagetoraster</a></dt><dt><a href="CUPS-printing.html#id2934991">rasterto [printers specific]</a></dt><dt><a href="CUPS-printing.html#id2935143">CUPS Backends</a></dt><dt><a href="CUPS-printing.html#id2935508">The Role of cupsomatic/foomatic</a></dt><dt><a href="CUPS-printing.html#id2935673">The Complete Picture</a></dt><dt><a href="CUPS-printing.html#id2935688">mime.convs</a></dt><dt><a href="CUPS-printing.html#id2935752">Raw Printing</a></dt><dt><a href="CUPS-printing.html#id2935861">application/octet-stream Printing</a></dt><dt><a href="CUPS-printing.html#id2936129">PostScript Printer Descriptions (PPDs) for Non-PS Printers</a></dt><dt><a href="CUPS-printing.html#id2936430">cupsomatic/foomatic-rip Versus native CUPS Printing</a></dt><dt><a href="CUPS-printing.html#id2936743">Examples for Filtering Chains</a></dt><dt><a href="CUPS-printing.html#id2937128">Sources of CUPS Drivers/PPDs</a></dt><dt><a href="CUPS-printing.html#id2937265">Printing with Interface Scripts</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2937358">Network Printing (Purely Windows)</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2937377">From Windows Clients to an NT Print Server</a></dt><dt><a href="CUPS-printing.html#id2937434">Driver Execution on the Client</a></dt><dt><a href="CUPS-printing.html#id2937506">Driver Execution on the Server</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2937618">Network Printing (Windows Clients UNIX/Samba Print +Servers)</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2937639">From Windows Clients to a CUPS/Samba Print Server</a></dt><dt><a href="CUPS-printing.html#id2937834">Samba Receiving Jobfiles and Passing Them to CUPS</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2937924">Network PostScript RIP</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2938025">PPDs for Non-PS Printers on UNIX</a></dt><dt><a href="CUPS-printing.html#id2938085">PPDs for Non-PS Printers on Windows</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2938166">Windows Terminal Servers (WTS) as CUPS Clients</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2938184">Printer Drivers Running in Kernel Mode Cause Many +Problems</a></dt><dt><a href="CUPS-printing.html#id2938229">Workarounds Impose Heavy Limitations</a></dt><dt><a href="CUPS-printing.html#id2938250">CUPS: A Magical Stone?</a></dt><dt><a href="CUPS-printing.html#id2938313">PostScript Drivers with No Major Problems Even in Kernel +Mode</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2938378">Configuring CUPS for Driver Download</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2938397">cupsaddsmb: The Unknown Utility</a></dt><dt><a href="CUPS-printing.html#id2938514">Prepare Your smb.conf for cupsaddsmb</a></dt><dt><a href="CUPS-printing.html#id2938755">CUPS PostScript Driver for Windows NT/200x/XP</a></dt><dt><a href="CUPS-printing.html#id2939044">Recognizing Different Driver Files</a></dt><dt><a href="CUPS-printing.html#id2939174">Acquiring the Adobe Driver Files</a></dt><dt><a href="CUPS-printing.html#id2939204">ESP Print Pro PostScript Driver for Windows NT/200x/XP</a></dt><dt><a href="CUPS-printing.html#id2939274">Caveats to be Considered</a></dt><dt><a href="CUPS-printing.html#id2939571">Windows CUPS PostScript Driver Versus Adobe Driver</a></dt><dt><a href="CUPS-printing.html#id2939801">Run cupsaddsmb (Quiet Mode)</a></dt><dt><a href="CUPS-printing.html#id2939946">Run cupsaddsmb with Verbose Output</a></dt><dt><a href="CUPS-printing.html#id2940175">Understanding cupsaddsmb</a></dt><dt><a href="CUPS-printing.html#id2940352">How to Recognize If cupsaddsmb Completed Successfully</a></dt><dt><a href="CUPS-printing.html#id2940450">cupsaddsmb with a Samba PDC</a></dt><dt><a href="CUPS-printing.html#id2940538">cupsaddsmb Flowchart</a></dt><dt><a href="CUPS-printing.html#id2940621">Installing the PostScript Driver on a Client</a></dt><dt><a href="CUPS-printing.html#id2940801">Avoiding Critical PostScript Driver Settings on the Client</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2940875">Installing PostScript Driver Files Manually Using rpcclient</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2941083">A Check of the rpcclient man Page</a></dt><dt><a href="CUPS-printing.html#id2941229">Understanding the rpcclient man Page</a></dt><dt><a href="CUPS-printing.html#id2941358">Producing an Example by Querying a Windows Box</a></dt><dt><a href="CUPS-printing.html#id2941534">Requirements for adddriver and setdriver to Succeed</a></dt><dt><a href="CUPS-printing.html#id2941782">Manual Driver Installation in 15 Steps</a></dt><dt><a href="CUPS-printing.html#id2942909">Troubleshooting Revisited</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2943077">The Printing *.tdb Files</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2943322">Trivial Database Files</a></dt><dt><a href="CUPS-printing.html#id2943400">Binary Format</a></dt><dt><a href="CUPS-printing.html#id2943470">Losing *.tdb Files</a></dt><dt><a href="CUPS-printing.html#id2943528">Using tdbbackup</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2943673">CUPS Print Drivers from Linuxprinting.org</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2943860">foomatic-rip and Foomatic Explained</a></dt><dt><a href="CUPS-printing.html#id2944657">foomatic-rip and Foomatic-PPD Download and Installation</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2945207">Page Accounting with CUPS</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2945248">Setting Up Quotas</a></dt><dt><a href="CUPS-printing.html#id2945318">Correct and Incorrect Accounting</a></dt><dt><a href="CUPS-printing.html#id2945366">Adobe and CUPS PostScript Drivers for Windows Clients</a></dt><dt><a href="CUPS-printing.html#id2945495">The page_log File Syntax</a></dt><dt><a href="CUPS-printing.html#id2945665">Possible Shortcomings</a></dt><dt><a href="CUPS-printing.html#id2945745">Future Developments</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2945799">Additional Material</a></dt><dt><a href="CUPS-printing.html#id2946030">Auto-Deletion or Preservation of CUPS Spool Files</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2946094">CUPS Configuration Settings Explained</a></dt><dt><a href="CUPS-printing.html#id2946198">Pre-Conditions</a></dt><dt><a href="CUPS-printing.html#id2946367">Manual Configuration</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2946425">Printing from CUPS to Windows Attached Printers</a></dt><dt><a href="CUPS-printing.html#id2946721">More CUPS-Filtering Chains</a></dt><dt><a href="CUPS-printing.html#id2946814">Common Errors</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2946820">Windows 9x/ME Client Can't Install Driver</a></dt><dt><a href="CUPS-printing.html#id2946839">cupsaddsmb Keeps Asking for Root Password in Never-ending Loop</a></dt><dt><a href="CUPS-printing.html#id2946889">cupsaddsmb Errors</a></dt><dt><a href="CUPS-printing.html#id2946973">Client Can't Connect to Samba Printer</a></dt><dt><a href="CUPS-printing.html#id2947002">New Account Reconnection from Windows 200x/XP Troubles</a></dt><dt><a href="CUPS-printing.html#id2947106">Avoid Being Connected to the Samba Server as the Wrong User</a></dt><dt><a href="CUPS-printing.html#id2947158">Upgrading to CUPS Drivers from Adobe Drivers</a></dt><dt><a href="CUPS-printing.html#id2947200">Can't Use cupsaddsmb on Samba Server Which Is a PDC</a></dt><dt><a href="CUPS-printing.html#id2947239">Deleted Windows 200x Printer Driver Is Still Shown</a></dt><dt><a href="CUPS-printing.html#id2947278">Windows 200x/XP "Local Security Policies"</a></dt><dt><a href="CUPS-printing.html#id2947293">Administrator Cannot Install Printers for All Local Users</a></dt><dt><a href="CUPS-printing.html#id2947323">Print Change Notify Functions on NT-clients</a></dt><dt><a href="CUPS-printing.html#id2947350">WinXP-SP1</a></dt><dt><a href="CUPS-printing.html#id2947402">Print Options for All Users Can't Be Set on Windows 200x/XP</a></dt><dt><a href="CUPS-printing.html#id2947717">Most Common Blunders in Driver Settings on Windows Clients</a></dt><dt><a href="CUPS-printing.html#id2947779">cupsaddsmb Does Not Work with Newly Installed Printer</a></dt><dt><a href="CUPS-printing.html#id2947835">Permissions on /var/spool/samba/ Get Reset After Each Reboot</a></dt><dt><a href="CUPS-printing.html#id2947951">Print Queue Called lp Mis-handles Print Jobs</a></dt><dt><a href="CUPS-printing.html#id2948008">Location of Adobe PostScript Driver Files for cupsaddsmb</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2948065">Overview of the CUPS Printing Processes</a></dt></dl></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2931072"></a>Introduction</h2></div></div><div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2931079"></a>Features and Benefits</h3></div></div><div></div></div><p> + The Common UNIX Print System (<ulink url="http://www.cups.org/">CUPS</ulink>) + has become quite popular. All major Linux distributions now ship it as their default printing + system. To many, it is still a mystical tool. Mostly, it just works. + People tend to regard it as a “<span class="quote">black box</span>” + that they do not want to look into as long as it works. But once + there is a little problem, they are in trouble to find out where to + start debugging it. Refer to the chapter “<span class="quote">Classical Printing</span>” that + contains a lot of information that is relevant for CUPS. + </p><p> + 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 not to try and apply any prior knowledge about + printing to this new system. Rather, try to understand CUPS + from the beginning. This documentation will lead you to a + complete understanding of CUPS. Let's start with the most basic + things first. + </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2931130"></a>Overview</h3></div></div><div></div></div><p> + CUPS is more than just a print spooling system. It is a complete + printer management system that complies with the new + Internet Printing Protocol (IPP). IPP is an industry + and Internet Engineering Task Force (IETF) + standard for network printing. Many of its functions can be managed + remotely (or locally) via a Web browser (giving you a + platform-independent access to the CUPS print server). Additionally, it + has the traditional command line and several more modern GUI interfaces + (GUI interfaces developed by third parties, like KDE's + overwhelming <ulink url="http://printing.kde.org/">KDEPrint</ulink>). + </p><p> + CUPS allows creation of “<span class="quote">raw</span>” printers (i.e., no print file + format translation) as well as “<span class="quote">smart</span>” 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. + </p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2931182"></a>Basic CUPS Support Configuration</h2></div></div><div></div></div><p> + Printing with CUPS in the most basic <tt class="filename">smb.conf</tt> setup in Samba-3.0 (as was true for 2.2.x) only needs two + settings: <a class="indexterm" name="id2931202"></a><i class="parameter"><tt>printing</tt></i> = cups and + <a class="indexterm" name="id2931216"></a><i class="parameter"><tt>printcap</tt></i> = cups. CUPS does not need a printcap file. + However, the <tt class="filename">cupsd.conf</tt> configuration file knows of two related directives that control + how such a file will be automatically created and maintained by CUPS for the convenience of third-party + applications (example: <i class="parameter"><tt>Printcap /etc/printcap</tt></i> and <i class="parameter"><tt>PrintcapFormat BSD</tt></i>). + Legacy programs often require the existence of a printcap file containing printer names or they will refuse to + print. Make sure CUPS is set to generate and maintain a printcap file. For details, see + <b class="command">man cupsd.conf</b> and other CUPS-related documentation, like the wealth of documents on your CUPS server + itself: <ulink url="http://localhost:631/documentation.html">http://localhost:631/documentation.html</ulink>. + </p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2931276"></a>Linking smbd with libcups.so</h3></div></div><div></div></div><p> + Samba has a special relationship to CUPS. Samba can be compiled with CUPS library support. + Most recent installations have this support enabled. Per default, CUPS linking is compiled + into smbd and other Samba binaries. Of course, you can use CUPS even + if Samba is not linked against <tt class="filename">libcups.so</tt> but + there are some differences in required or supported configuration. + </p><p> + When Samba is compiled against <tt class="filename">libcups</tt>, <a class="indexterm" name="id2931315"></a><i class="parameter"><tt>printcap</tt></i> = cups + uses the CUPS API to list printers, submit jobs, query queues, and so on. Otherwise it maps to the System V + commands with an additional <b class="command">-oraw</b> option for printing. On a Linux + system, you can use the <b class="command">ldd</b> utility to find out details (ldd may not be present on + other OS platforms, or its function may be embodied by a different command): + </p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>ldd `which smbd`</tt></b> +libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x4002d000) +libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x4005a000) +libcups.so.2 => /usr/lib/libcups.so.2 (0x40123000) +[....] +</pre><p> + The line <tt class="computeroutput">libcups.so.2 => /usr/lib/libcups.so.2 (0x40123000)</tt> shows + there is CUPS support compiled into this version of Samba. If this is the case, and printing = cups + is set, then <span class="emphasis"><em>any otherwise manually set print command in <tt class="filename">smb.conf</tt> is ignored</em></span>. + This is an important point to remember! + </p><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p> Should it be necessary, for any reason, to set your own print commands, you can do this by setting + <a class="indexterm" name="id2931409"></a><i class="parameter"><tt>printing</tt></i> = sysv. However, you will loose all the benefits + of tight CUPS/Samba integration. When you do this you must manually configure the printing system commands + (most important: + <a class="indexterm" name="id2931426"></a><i class="parameter"><tt>print command</tt></i>; other commands are + <a class="indexterm" name="id2931440"></a><i class="parameter"><tt>lppause command</tt></i>, + <a class="indexterm" name="id2931454"></a><i class="parameter"><tt>lpresume command</tt></i>, + <a class="indexterm" name="id2931468"></a><i class="parameter"><tt>lpq command</tt></i>, + <a class="indexterm" name="id2931482"></a><i class="parameter"><tt>lprm command</tt></i>, + <a class="indexterm" name="id2931496"></a><i class="parameter"><tt>queuepause command</tt></i> and + <a class="indexterm" name="id2931510"></a><i class="parameter"><tt>queue resume command</tt></i>).</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2931526"></a>Simple <tt class="filename">smb.conf</tt> Settings for CUPS</h3></div></div><div></div></div><p> + To summarize, <link linkend="cups-exam-simple"> shows simplest printing-related setup for <tt class="filename">smb.conf</tt> to enable basic CUPS support: + </p><div class="example"><a name="cups-exam-simple"></a><p class="title"><b>Example 19.1. Simplest printing-related smb.conf</b></p><table class="simplelist" border="0" summary="Simple list"><tr><td> </td></tr><tr><td><i class="parameter"><tt>[global]</tt></i></td></tr><tr><td><i class="parameter"><tt>load printers = yes</tt></i></td></tr><tr><td><i class="parameter"><tt>printing = cups</tt></i></td></tr><tr><td><i class="parameter"><tt>printcap name = cups</tt></i></td></tr><tr><td> </td></tr><tr><td><i class="parameter"><tt>[printers]</tt></i></td></tr><tr><td><i class="parameter"><tt>comment = All Printers</tt></i></td></tr><tr><td><i class="parameter"><tt>path = /var/spool/samba</tt></i></td></tr><tr><td><i class="parameter"><tt>browseable = no</tt></i></td></tr><tr><td><i class="parameter"><tt>public = yes</tt></i></td></tr><tr><td><i class="parameter"><tt>guest ok = yes</tt></i></td></tr><tr><td><i class="parameter"><tt>writable = no</tt></i></td></tr><tr><td><i class="parameter"><tt>printable = yes</tt></i></td></tr><tr><td><i class="parameter"><tt>printer admin = root, @ntadmins</tt></i></td></tr></table></div><p> + This is all you need for basic printing setup for CUPS. It will print + all graphic, text, PDF, and PostScript files submitted from Windows + clients. However, most of your Windows users would not know how to + send these kinds of files to print without opening a GUI + application. Windows clients tend to have local printer drivers + installed, and the GUI application's print buttons start a printer + driver. Your users also rarely send files from the command + line. Unlike UNIX clients, they hardly submit graphic, text or PDF + formatted files directly to the spooler. They nearly exclusively print + from GUI applications with a “<span class="quote">printer driver</span>” hooked in between the + application's native format and the print-data-stream. If the backend + printer is not a PostScript device, the print data stream is “<span class="quote">binary,</span>” + sensible only for the target printer. Read on to learn which problem + this may cause and how to avoid it. + </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2931722"></a>More Complex CUPS <tt class="filename">smb.conf</tt> Settings</h3></div></div><div></div></div><p> + <link linkend="overridesettings"> is a slightly more complex printing-related setup + for <tt class="filename">smb.conf</tt>. It enables general CUPS printing + support for all printers, but defines one printer share, which is set + up differently. + </p><div class="example"><a name="overridesettings"></a><p class="title"><b>Example 19.2. Overriding global CUPS settings for one printer</b></p><table class="simplelist" border="0" summary="Simple list"><tr><td> </td></tr><tr><td><i class="parameter"><tt>[global]</tt></i></td></tr><tr><td><i class="parameter"><tt>printing = cups</tt></i></td></tr><tr><td><i class="parameter"><tt>printcap name = cups</tt></i></td></tr><tr><td><i class="parameter"><tt>load printers = yes</tt></i></td></tr><tr><td> </td></tr><tr><td><i class="parameter"><tt>[printers]</tt></i></td></tr><tr><td><i class="parameter"><tt>comment = All Printers</tt></i></td></tr><tr><td><i class="parameter"><tt>path = /var/spool/samba</tt></i></td></tr><tr><td><i class="parameter"><tt>public = yes</tt></i></td></tr><tr><td><i class="parameter"><tt>guest ok = yes</tt></i></td></tr><tr><td><i class="parameter"><tt>writable = no</tt></i></td></tr><tr><td><i class="parameter"><tt>printable = yes</tt></i></td></tr><tr><td><i class="parameter"><tt>printer admin = root, @ntadmins</tt></i></td></tr><tr><td> </td></tr><tr><td><i class="parameter"><tt>[special_printer]</tt></i></td></tr><tr><td><i class="parameter"><tt>comment = A special printer with his own settings</tt></i></td></tr><tr><td><i class="parameter"><tt>path = /var/spool/samba-special</tt></i></td></tr><tr><td><i class="parameter"><tt>printing = sysv</tt></i></td></tr><tr><td><i class="parameter"><tt>printcap = lpstat</tt></i></td></tr><tr><td><i class="parameter"><tt>print command = echo "NEW: `date`: printfile %f" >> /tmp/smbprn.log ; \</tt></i></td></tr><tr><td><i class="parameter"><tt>echo " `date`: p-%p s-%s f-%f" >> /tmp/smbprn.log ; \</tt></i></td></tr><tr><td><i class="parameter"><tt>echo " `date`: j-%j J-%J z-%z c-%c" >> /tmp/smbprn.log : rm %f</tt></i></td></tr><tr><td><i class="parameter"><tt>public = no</tt></i></td></tr><tr><td><i class="parameter"><tt>guest ok = no</tt></i></td></tr><tr><td><i class="parameter"><tt>writeable = no</tt></i></td></tr><tr><td><i class="parameter"><tt>printable = yes</tt></i></td></tr><tr><td><i class="parameter"><tt>printer admin = kurt</tt></i></td></tr><tr><td><i class="parameter"><tt>hosts deny = 0.0.0.0</tt></i></td></tr><tr><td><i class="parameter"><tt>hosts allow = turbo_xp, 10.160.50.23, 10.160.51.60</tt></i></td></tr></table></div><p> + This special share is only there for testing purposes. It does not write the print job to a file. It just logs the job parameters + known to Samba into the <tt class="filename">/tmp/smbprn.log</tt> file and deletes the jobfile. Moreover, the + <a class="indexterm" name="id2932031"></a><i class="parameter"><tt>printer admin</tt></i> of this share is “<span class="quote">kurt</span>” (not the “<span class="quote">@ntadmins</span>” group), + guest access is not allowed, the share isn't published to the Network Neighborhood (so you need to know it is there), and it only + allows access from only three hosts. To prevent CUPS kicking in and taking over the print jobs for that share, we need to set + <a class="indexterm" name="id2932058"></a><i class="parameter"><tt>printing</tt></i> = sysv and + <a class="indexterm" name="id2932072"></a><i class="parameter"><tt>printcap</tt></i> = lpstat. + </p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2932089"></a>Advanced Configuration</h2></div></div><div></div></div><p> + Before we delve into all the configuration options, let us clarify a few + points. <span class="emphasis"><em>Network printing needs to be organized and setup + correctly</em></span>. This frequently doesn't happen. Legacy systems + or small business LAN environments often lack design and good housekeeping. + </p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2932110"></a>Central Spooling vs. “<span class="quote">Peer-to-Peer</span>” Printing</h3></div></div><div></div></div><p> +<a class="indexterm" name="id2932125"></a> +<a class="indexterm" name="id2932136"></a> + Many small office or home networks, as well as badly organized larger + environments, allow each client a direct access to available network + printers. This is generally a bad idea. It often blocks one client's + access to the printer when another client's job is printing. It might + freeze the first client's application while it is waiting to get + rid of the job. Also, there are frequent complaints about various jobs + being printed with their pages mixed with each other. A better concept + is the 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. + </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2932163"></a>Raw Print Serving Vendor Drivers on Windows Clients</h3></div></div><div></div></div><p> + <a class="indexterm" name="id2932178"></a> + <a class="indexterm" name="id2932186"></a> + 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 “<span class="quote">raw</span>” spooling of all jobs handed to them by + Samba. This approach meant that the Windows clients were expected to + prepare the print job file that its ready to be sent to the printing + device. Here is a native (vendor-supplied) Windows printer + driver for the target device needed to be installed on each and every + client. + </p><p> + It is possible to configure CUPS, Samba and your Windows clients in the + same traditional and simple way. When CUPS printers are configured + for RAW print-through mode operation, it is the responsibility of the + Samba client to fully render the print job (file). The file must be + sent in a format that is suitable for direct delivery to the + printer. Clients need to run the vendor-provided drivers to do + this. In this case, CUPS will not do any print file format conversion + work. + </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2932223"></a>Installation of Windows Client Drivers</h3></div></div><div></div></div><p> + The printer drivers on the Windows clients may be installed + in two functionally different ways: + </p><div class="itemizedlist"><ul type="disc"><li><p>Manually install the drivers locally on each client, + one by one; this yields the old <span class="emphasis"><em>LanMan</em></span> style + printing and uses a <tt class="filename">\\sambaserver\printershare</tt> + type of connection.</p></li><li><p> + <a class="indexterm" name="id2932265"></a> + Deposit and prepare the drivers (for later download) on + the print server (Samba); this enables the clients to use + “<span class="quote">Point'n'Print</span>” to get drivers semi-automatically installed the + first time they access the printer; with this method NT/200x/XP + clients use the <span class="emphasis"><em>SPOOLSS/MS-RPC</em></span> + type printing calls.</p></li></ul></div><p> + The second method is recommended for use over the first. + </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="cups-raw"></a>Explicitly Enable “<span class="quote">raw</span>” Printing for <span class="emphasis"><em>application/octet-stream</em></span></h3></div></div><div></div></div><p> + <a class="indexterm" name="id2932317"></a> + <a class="indexterm" name="id2932325"></a> + <a class="indexterm" name="id2932334"></a> + 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 “<span class="quote">raw</span>” printing of deliberate (binary) file + formats. The CUPS files that need to be correctly set for RAW mode + printers to work are: + </p><div class="itemizedlist"><ul type="disc"><li><p><tt class="filename">/etc/cups/mime.types</tt></p></li><li><p><tt class="filename">/etc/cups/mime.convs</tt></p></li></ul></div><p> + Both contain entries (at the end of the respective files) which must + be uncommented to allow RAW mode operation. + In <tt class="filename">/etc/cups/mime.types</tt>, make sure this line is + present: + + </p><pre class="programlisting"> + application/octet-stream + </pre><p> + + <a class="indexterm" name="id2932400"></a> + <a class="indexterm" name="id2932408"></a> + + In <tt class="filename">/etc/cups/mime.convs</tt>, + have this line: + + <a class="indexterm" name="id2932425"></a> + + </p><pre class="programlisting"> + application/octet-stream application/vnd.cups-raw 0 - + </pre><p> + + If these two files are not set up correctly for raw Windows client + printing, you may encounter the dreaded <tt class="computeroutput">Unable to + convert file 0</tt> in your CUPS error_log file. + </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Editing the <tt class="filename">mime.convs</tt> and the + <tt class="filename">mime.types</tt> file does not + <span class="emphasis"><em>enforce</em></span> “<span class="quote">raw</span>” printing, it only + <span class="emphasis"><em>allows</em></span> it. + </p></div><p><b>Background. </b> + <a class="indexterm" name="id2932493"></a> + CUPS being a more security-aware printing system than traditional ones + does not by default allow a user to send deliberate (possibly binary) + data to printing devices. This could be easily abused to launch a + “<span class="quote">Denial of Service</span>” attack on your printer(s), causing at least + the loss of a lot of paper and ink. “<span class="quote">Unknown</span>” data are tagged by CUPS + as <i class="parameter"><tt>MIME type: application/octet-stream</tt></i> and not + allowed to go to the printer. By default, you can only send other + (known) MIME types “<span class="quote">raw</span>”. Sending data “<span class="quote">raw</span>” means that CUPS does not + try to convert them and passes them to the printer untouched (see the next + chapter for even more background explanations). + </p><p> + This is all you need to know to get the CUPS/Samba combo printing + “<span class="quote">raw</span>” files prepared by Windows clients, which have vendor drivers + locally installed. If you are not interested in background information about + more advanced CUPS/Samba printing, simply skip the remaining sections + of this chapter. + </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2932552"></a>Driver Upload Methods</h3></div></div><div></div></div><p> + This section describes three familiar methods, plus one new one, by which + printer drivers may be uploaded. + </p><p> + <a class="indexterm" name="id2932570"></a> + If you want to use the MS-RPC type printing, you must upload the + drivers onto the Samba server first (<i class="parameter"><tt>[print$]</tt></i> + share). For a discussion on how to deposit printer drivers on the + Samba host (so the Windows clients can download and use them via + “<span class="quote">Point'n'Print</span>”), please refer to the previous chapter of this + HOWTO Collection. There you will find a description or reference to + three methods of preparing the client drivers on the Samba server: + </p><div class="itemizedlist"><ul type="disc"><li><p> + <a class="indexterm" name="id2932606"></a> + The GUI, “<span class="quote">Add Printer Wizard</span>” + <span class="emphasis"><em>upload-from-a-Windows-client</em></span> + method.</p></li><li><p>The command line, “<span class="quote">smbclient/rpcclient</span>” + upload-from-a-UNIX-workstation method.</p></li><li><p> + <a class="indexterm" name="id2932640"></a> + The Imprints Toolset + method.</p></li></ul></div><p> + These three methods apply to CUPS all the same. A new and more + convenient way to load the Windows drivers into Samba is provided + if you use CUPS: + </p><div class="itemizedlist"><ul type="disc"><li><p> + <a class="indexterm" name="id2932666"></a> + the <i class="parameter"><tt>cupsaddsmb</tt></i> + utility.</p></li></ul></div><p> + <b class="command">cupsaddsmb</b> is discussed in much detail further below. But we first + explore the CUPS filtering system and compare the Windows and UNIX printing architectures. + </p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2932699"></a>Advanced Intelligent Printing with PostScript Driver Download</h2></div></div><div></div></div><p> + <a class="indexterm" name="id2932710"></a> + We now know + how to set up a “<span class="quote">dump</span>” printserver, that is, a server which is spooling + printjobs “<span class="quote">raw</span>”, leaving the print data untouched. + </p><p> + Possibly you need to setup CUPS in a smarter way. The reasons could + be manifold: + </p><div class="itemizedlist"><ul type="disc"><li><p>Maybe your boss wants to get monthly statistics: Which + printer did how many pages? What was the average data size of a job? + What was the average print run per day? What are the typical hourly + peaks in printing? Which department prints how much?</p></li><li><p>Maybe you are asked to setup a print quota system: + Users should not be able to print more jobs, once they have surpassed + a given limit per period.</p></li><li><p>Maybe your previous network printing setup is a mess + and must be re-organized from a clean beginning.</p></li><li><p>Maybe you have experiencing too many “<span class="quote">blue screens</span>” + originating from poorly debugged printer drivers running in NT “<span class="quote">kernel mode</span>”?</p></li></ul></div><p> + These goals cannot be achieved by a raw print server. To build a + server meeting these requirements, you'll first need to learn about + how CUPS works and how you can enable its features. + </p><p> + What follows is the comparison of some fundamental concepts for + Windows and UNIX printing; then follows a description of the + CUPS filtering system, how it works and how you can tweak it. + </p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="gdipost"></a>GDI on Windows -- PostScript on UNIX</h3></div></div><div></div></div><p> + <a class="indexterm" name="id2932814"></a> + <a class="indexterm" name="id2932822"></a> + Network printing is one of the most complicated and error-prone + day-to-day tasks any user or administrator may encounter. This is + true for all OS platforms. And there are reasons for this. + </p><p> + <a class="indexterm" name="id2932838"></a> + <a class="indexterm" name="id2932846"></a> + You can't expect most file formats to just throw them toward + printers and they get printed. There needs to be a file format + conversion in between. The problem is that there is no common standard for + print file formats across all manufacturers and printer types. While + PostScript (trademark held by Adobe) and, to an + extent, PCL (trademark held by HP) have developed + into semi-official “<span class="quote">standards</span>” by being the most widely used PDLs + Page Description Languages (PDLs), there are still + many manufacturers who “<span class="quote">roll their own</span>” (their reasons may be + unacceptable license fees for using printer-embedded PostScript + interpreters, and so on). + </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2932876"></a>Windows Drivers, GDI and EMF</h3></div></div><div></div></div><p> + <a class="indexterm" name="id2932888"></a> + <a class="indexterm" name="id2932896"></a> + <a class="indexterm" name="id2932904"></a> + In Windows OS, the format conversion job is done by the printer + drivers. On MS Windows OS platforms all application programmers have + at their disposal a built-in API, the Graphical Device + Interface (GDI), as part and parcel of the OS itself to base + themselves on. This GDI core is used as one common unified ground for + all Windows programs to draw pictures, fonts and documents + <span class="emphasis"><em>on screen</em></span> as well as <span class="emphasis"><em>on + paper</em></span> (print). Therefore, printer driver developers can + standardize on a well-defined GDI output for their own driver + input. Achieving WYSIWYG (“<span class="quote">What You See Is What You Get</span>”) is + relatively easy, because the on-screen graphic primitives, as well as + the on-paper drawn objects, come from one common source. This source, + the GDI, often produces a file format called Enhanced + MetaFile (EMF). The EMF is processed by the printer driver and + converted to the printer-specific file format. + </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> + <a class="indexterm" name="id2932947"></a> + 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 + <a class="indexterm" name="id2932959"></a> + <a class="indexterm" name="id2932967"></a> + <a class="indexterm" name="id2932976"></a> + <a class="indexterm" name="id2932984"></a> + Systems. Their <span class="emphasis"><em>Core Graphic Engine</em></span> uses a + <span class="emphasis"><em>PDF</em></span> derivative for all display work. + </p></div><p> + + </p><div class="figure"><a name="1small"></a><p class="title"><b>Figure 19.1. Windows printing to a local printer.</b></p><div class="mediaobject"><img src="projdoc/imagefiles/1small.png" width="270" alt="Windows printing to a local printer."></div></div><p> + </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2933049"></a>UNIX Printfile Conversion and GUI Basics</h3></div></div><div></div></div><p> + <a class="indexterm" name="id2933059"></a> + <a class="indexterm" name="id2933067"></a> + <a class="indexterm" name="id2933075"></a> + <a class="indexterm" name="id2933084"></a> + In UNIX and Linux, there is no comparable layer built into the OS + kernel(s) or the X (screen display) server. Every application is + responsible for itself to create its print output. Fortunately, most + use PostScript and that at least gives some common ground. Unfortunately, + there are many different levels of quality for this PostScript. And + worse, there is a huge difference (and no common root) in the way + the same document is displayed on screen and how it is presented on + paper. WYSIWYG is more difficult to achieve. This goes back to the + time, decades ago, when the predecessors of X.org, + designing the UNIX foundations and protocols for Graphical User + Interfaces, refused to take responsibility for “<span class="quote">paper output</span>” + also, as some had demanded at the time, and restricted itself to + “<span class="quote">on-screen only.</span>” (For some years now, the “<span class="quote">Xprint</span>” project has been + under development, attempting to build printing support into the X + framework, including a PostScript and a PCL driver, but it is not yet + ready for prime time.) You can see this unfavorable inheritance up to + the present day by looking into the various “<span class="quote">font</span>” directories on your + system; there are separate ones for fonts used for X display and fonts + to be used on paper. + </p><p><b>Background. </b> + <a class="indexterm" name="id2933141"></a> + The PostScript programming language is an “<span class="quote">invention</span>” by Adobe Inc., + but its specifications have been published to the full. Its strength + lies in its powerful abilities to describe graphical objects (fonts, + shapes, patterns, lines, curves, and dots), their attributes (color, + linewidth) and the way to manipulate (scale, distort, rotate, + shift) them. Because of its open specification, anybody with the + skill can start writing his own implementation of a PostScript + interpreter and use it to display PostScript files on screen or on + paper. Most graphical output devices are based on the concept of + “<span class="quote">raster images</span>” or “<span class="quote">pixels</span>” (one notable exception is pen + plotters). Of course, you can look at a PostScript file in its textual + form and you will be reading its PostScript code, the language + instructions which need to be interpreted by a rasterizer. Rasterizers + produce pixel images, which may be displayed on screen by a viewer + program or on paper by a printer. + </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="post-and-ghost"></a>PostScript and Ghostscript</h3></div></div><div></div></div><p> + <a class="indexterm" name="id2933199"></a> + <a class="indexterm" name="id2933207"></a> + <a class="indexterm" name="id2933218"></a> + So, UNIX is lacking a common ground for printing on paper and + displaying on screen. Despite this unfavorable legacy for UNIX, basic + printing is fairly easy if you have PostScript printers at your + disposal. The reason is these devices have a built-in PostScript + language “<span class="quote">interpreter,</span>” also called a Raster Image + Processor (RIP) (which makes them more expensive than + other types of printers); throw PostScript toward them, and they will + spit out your printed pages. Their RIP is doing all the hard work of + converting the PostScript drawing commands into a bitmap picture as + you see it on paper, in a resolution as done by your printer. This is + no different to PostScript printing a file from a Windows origin. + </p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> + <a class="indexterm" name="id2933261"></a> + Traditional UNIX programs and printing systems while + using PostScript are largely not PPD-aware. PPDs are “<span class="quote">PostScript + Printer Description</span>” files. They enable you to specify and control all + options a printer supports: duplexing, stapling and punching. Therefore, + UNIX users for a long time couldn't choose many of the supported + device and job options, unlike Windows or Apple users. But now there + is CUPS. + </p></div><p> + </p><div class="figure"><a name="2small"></a><p class="title"><b>Figure 19.2. Printing to a PostScript printer.</b></p><div class="mediaobject"><img src="projdoc/imagefiles/2small.png" width="270" alt="Printing to a PostScript printer."></div></div><p> + </p><p> + <a class="indexterm" name="id2933337"></a> + However, there are other types of printers out there. These do not know + how to print PostScript. They use their own Page Description + Language (PDL, often proprietary). To print to them is much + more demanding. Since your UNIX applications mostly produce + PostScript, and since these devices do not understand PostScript, you + need to convert the printfiles to a format suitable for your printer + on the host before you can send it away. + </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2933354"></a>Ghostscript the Software RIP for Non-PostScript Printers</h3></div></div><div></div></div><p> + <a class="indexterm" name="id2933369"></a> + Here is where Ghostscript kicks in. Ghostscript is + the traditional (and quite powerful) PostScript interpreter used on + UNIX platforms. It is a RIP in software, capable of doing a + <span class="emphasis"><em>lot</em></span> of file format conversions for a very broad + spectrum of hardware devices as well as software file formats. + Ghostscript technology and drivers are what enable PostScript printing + to non-PostScript hardware. + </p><p> + </p><div class="figure"><a name="3small"></a><p class="title"><b>Figure 19.3. Ghostscript as a RIP for non-postscript printers.</b></p><div class="mediaobject"><img src="projdoc/imagefiles/3small.png" width="270" alt="Ghostscript as a RIP for non-postscript printers."></div></div><p> + </p><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p> + Use the “<span class="quote">gs -h</span>” command to check for all built-in “<span class="quote">devices</span>” + of your Ghostscript version. If you specify a parameter of + <i class="parameter"><tt>-sDEVICE=png256</tt></i> on your Ghostscript command + line, you are asking Ghostscript to convert the input into a PNG + file. Naming a “<span class="quote">device</span>” on the command line is the most important + single parameter to tell Ghostscript exactly how it should render the + input. New Ghostscript versions are released at fairly regular + intervals, now by artofcode LLC. They are initially put under the + “<span class="quote">AFPL</span>” license, but re-released under the GNU GPL as soon as the next + AFPL version appears. GNU Ghostscript is probably the version + installed on most Samba systems. But it has some deficiencies. + <a class="indexterm" name="id2933472"></a> + 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 “<span class="quote">cups</span>” device (essential to print to non-PS printers from CUPS). + </p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2933497"></a>PostScript Printer Description (PPD) Specification</h3></div></div><div></div></div><p> + <a class="indexterm" name="id2933509"></a> + While PostScript in essence is a Page Description + Language (PDL) to represent the page layout in a + device-independent way, real-world print jobs are + always ending up being output on hardware with device-specific + features. To take care of all the differences in hardware and to + allow for innovations, Adobe has specified a syntax and file format + for PostScript Printer Description (PPD) + files. Every PostScript printer ships with one of these files. + </p><p> + PPDs contain all the information about general and special features of the + given printer model: Which different resolutions can it handle? Does + it have a Duplexing Unit? How many paper trays are there? What media + types and sizes does it take? For each item, it also names the special + command string to be sent to the printer (mostly inside the PostScript + file) in order to enable it. + </p><p> + Information from these PPDs is meant to be taken into account by the + printer drivers. Therefore, installed as part of the Windows + PostScript driver for a given printer is the printer's PPD. Where it + makes sense, the PPD features are presented in the drivers' UI dialogs + to display to the user a choice of print options. In the end, the + user selections are somehow written (in the form of special + PostScript, PJL, JCL or vendor-dependent commands) into the PostScript + file created by the driver. + </p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p> + <a class="indexterm" name="id2933556"></a> + A PostScript file that was created to contain device-specific commands + for achieving a certain print job output (e.g., duplexed, stapled and + punched) on a specific target machine, may not print as expected, or + may not be printable at all on other models; it also may not be fit + for further processing by software (e.g., by a PDF distilling program). + </p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2933573"></a>Using Windows-Formatted Vendor PPDs</h3></div></div><div></div></div><p> + CUPS can handle all spec-compliant PPDs as supplied by the + manufacturers for their PostScript models. Even if a + vendor might not have mentioned our favorite + OS in his manuals and brochures, you can safely trust this: + <span class="emphasis"><em>If you get the Windows NT version of the PPD, you + can use it unchanged in CUPS</em></span> and thus access the full + power of your printer just like a Windows NT user could! + </p><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p> + To check the spec compliance of any PPD online, go to <ulink url="http://www.cups.org/testppd.php">http://www.cups.org/testppd.php</ulink> + 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. + </p></div><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p> + <a class="indexterm" name="id2933620"></a> + <a class="indexterm" name="id2933629"></a> + For real PostScript printers, <span class="emphasis"><em>do not</em></span> use the + <span class="emphasis"><em>Foomatic</em></span> or <span class="emphasis"><em>cupsomatic</em></span> + PPDs from Linuxprinting.org. With these devices, the original + vendor-provided PPDs are always the first choice! + </p></div><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p> + If you are looking for an original vendor-provided PPD of a specific + device, and you know that an NT4 box (or any other Windows box) on + your LAN has the PostScript driver installed, just use + <b class="command">smbclient //NT4-box/print\$ -U username</b> to + access the Windows directory where all printer driver files are + stored. First look in the <tt class="filename">W32X86/2</tt> subdir for + the PPD you are seeking. + </p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2933679"></a>CUPS Also Uses PPDs for Non-PostScript Printers</h3></div></div><div></div></div><p> + CUPS also uses specially crafted PPDs to handle non-PostScript + printers. These PPDs are usually not available from the vendors (and + no, you can't just take the PPD of a PostScript printer with the same + model name and hope it works for the non-PostScript version too). To + understand how these PPDs work for non-PS printers, we first need to + dive deeply into the CUPS filtering and file format conversion + architecture. Stay tuned. + </p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2933709"></a>The CUPS Filtering Architecture</h2></div></div><div></div></div><p> +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 zero or more possible filtering +chains relevant to 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. +</p><p> +If CUPS rasterizes a PostScript file natively to +a bitmap, this is done in two stages: +</p><div class="itemizedlist"><ul type="disc"><li><p>The first stage uses a Ghostscript device named “<span class="quote">cups</span>” +(this is since version 1.1.15) and produces a generic raster format +called “<span class="quote">CUPS raster</span>”. +</p></li><li><p>The second stage uses a “<span class="quote">raster driver</span>” that converts + the generic CUPS raster to a device-specific raster.</p></li></ul></div><p> +Make sure your Ghostscript version has the “<span class="quote">cups</span>” device compiled in +(check with <b class="command">gs -h | grep cups</b>). Otherwise you +may encounter the dreaded <tt class="computeroutput">Unable to convert file +0</tt> in your CUPS error_log file. To have “<span class="quote">cups</span>” as a +device in your Ghostscript, you either need to patch GNU +Ghostscript and re-compile, or use <a class="indexterm" name="id2933802"></a><ulink url="http://www.cups.org/ghostscript.php">ESP Ghostscript</ulink>. The +superior alternative is ESP Ghostscript. It supports not just CUPS, +but 300 other devices too (while GNU Ghostscript supports only about +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. +</p><p> +<a class="indexterm" name="id2933830"></a> +<a class="indexterm" name="id2933839"></a> +CUPS printers may be setup to use external +rendering paths. One of the most common is provided by the +Foomatic/cupsomatic concept from <ulink url="http://www.linuxprinting.org/">Linuxprinting.org.</ulink> This +uses the classical Ghostscript approach, doing everything in one +step. It does not use the “<span class="quote">cups</span>” device, but one of the many +others. However, even for Foomatic/cupsomatic usage, best results and +<a class="indexterm" name="id2933864"></a> +broadest printer model support is provided by ESP Ghostscript (more +about cupsomatic/Foomatic, particularly the new version called now +<span class="emphasis"><em>foomatic-rip</em></span>, follows below). +</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2933883"></a>MIME Types and CUPS Filters</h3></div></div><div></div></div><p> +<a class="indexterm" name="id2933894"></a> + <a class="indexterm" name="id2933905"></a> +CUPS reads the file <tt class="filename">/etc/cups/mime.types</tt> +(and all other files carrying a <tt class="filename">*.types</tt> suffix +in the same directory) upon startup. These files contain the MIME +type recognition rules that are applied when CUPS runs its +auto-typing routines. The rule syntax is explained in the man page +for <tt class="filename">mime.types</tt> and in the comments section of the +<tt class="filename">mime.types</tt> file itself. A simple rule reads +like this: + +<a class="indexterm" name="id2933946"></a> +</p><pre class="programlisting"> + application/pdf pdf string(0,%PDF) +</pre><p> + +This means if a filename has either a +<tt class="filename">.pdf</tt> suffix or if the magic +string <span class="emphasis"><em>%PDF</em></span> is right at the +beginning of the file itself (offset 0 from the start), then it is +a PDF file (<i class="parameter"><tt>application/pdf</tt></i>). +Another rule is this: + +</p><pre class="programlisting"> + application/postscript ai eps ps string(0,%!) string(0,<04>%!) +</pre><p> + +If the filename has one of the suffixes +<tt class="filename">.ai</tt>, <tt class="filename">.eps</tt>, +<tt class="filename">.ps</tt> or if the file itself starts with one of the +strings <span class="emphasis"><em>%!</em></span> or <span class="emphasis"><em><04>%!</em></span>, it +is a generic PostScript file +(<i class="parameter"><tt>application/postscript</tt></i>). +</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p> +Don't confuse the other mime.types files your system might be using +with the one in the <tt class="filename">/etc/cups/</tt> directory. +</p></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> +There is an important difference between two similar MIME types in +CUPS: one is <i class="parameter"><tt>application/postscript</tt></i>, the other is +<i class="parameter"><tt>application/vnd.cups-postscript</tt></i>. While +<i class="parameter"><tt>application/postscript</tt></i> is meant to be device +independent (job options for the file are still outside the PS file +content, embedded in command line or environment variables by CUPS), +<i class="parameter"><tt>application/vnd.cups-postscript</tt></i> may have the job +options inserted into the PostScript data itself (where +applicable). The transformation of the generic PostScript +(<i class="parameter"><tt>application/postscript</tt></i>) to the device-specific version +(<i class="parameter"><tt>application/vnd.cups-postscript</tt></i>) is the responsibility of the +CUPS <i class="parameter"><tt>pstops</tt></i> filter. pstops uses information +contained in the PPD to do the transformation. +</p></div><p> +CUPS can handle ASCII text, HP-GL, PDF, PostScript, DVI, and +many image formats (GIF. PNG, TIFF, JPEG, Photo-CD, SUN-Raster, +PNM, PBM, SGI-RGB, and more) and their associated MIME types +with its filters. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2934118"></a>MIME Type Conversion Rules</h3></div></div><div></div></div><p> +<a class="indexterm" name="id2934130"></a> +<a class="indexterm" name="id2934138"></a> +CUPS reads the file <tt class="filename">/etc/cups/mime.convs</tt> +(and all other files named with a <tt class="filename">*.convs</tt> +suffix in the same directory) upon startup. These files contain +lines naming an input MIME type, an output MIME type, a format +conversion filter that can produce the output from the input type +and virtual costs associated with this conversion. One example line +reads like this: + +</p><pre class="programlisting"> + application/pdf application/postscript 33 pdftops +</pre><p> + +This means that the <i class="parameter"><tt>pdftops</tt></i> filter will take +<i class="parameter"><tt>application/pdf</tt></i> as input and produce +<i class="parameter"><tt>application/postscript</tt></i> as output; the virtual +cost of this operation is 33 CUPS-$. The next filter is more +expensive, costing 66 CUPS-$: + +<a class="indexterm" name="id2934198"></a> + +</p><pre class="programlisting"> + application/vnd.hp-HPGL application/postscript 66 hpgltops +</pre><p> + +This is the <i class="parameter"><tt>hpgltops</tt></i>, which processes HP-GL +plotter files to PostScript. + +<a class="indexterm" name="id2934222"></a> + +</p><pre class="programlisting"> + application/octet-stream +</pre><p> + +Here are two more examples: + +<a class="indexterm" name="id2934239"></a> + +</p><pre class="programlisting"> + application/x-shell application/postscript 33 texttops + text/plain application/postscript 33 texttops +</pre><p> + +The last two examples name the <i class="parameter"><tt>texttops</tt></i> filter +to work on <i class="parameter"><tt>text/plain</tt></i> as well as on <i class="parameter"><tt>application/x-shell</tt></i>. (Hint: +This differentiation is needed for the syntax highlighting feature of +<i class="parameter"><tt>texttops</tt></i>). +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2934287"></a>Filtering Overview</h3></div></div><div></div></div><p> +<a class="indexterm" name="id2934298"></a> +There are many more combinations named in <tt class="filename">mime.convs</tt>. 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 <tt class="filename">mime.types</tt> +and <tt class="filename">mime.convs</tt>, then it will work seamlessly +inside CUPS. +</p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2934336"></a>Filter requirements</h4></div></div><div></div></div><p> +The mentioned “<span class="quote">CUPS requirements</span>” for filters are simple. Take +filenames or <tt class="filename">stdin</tt> as input and write to +<tt class="filename">stdout</tt>. They should take these 5 or 6 arguments: +<span class="emphasis"><em>printer job user title copies options [filename]</em></span> +</p><div class="variablelist"><dl><dt><span class="term">Printer </span></dt><dd><p>The name of the printer queue (normally this is the +name of the filter being run).</p></dd><dt><span class="term">job </span></dt><dd><p>The numeric job ID for the job being +printed.</p></dd><dt><span class="term">user </span></dt><dd><p>The string from the originating-user-name +attribute.</p></dd><dt><span class="term">title </span></dt><dd><p>The string from the job-name attribute.</p></dd><dt><span class="term">copies </span></dt><dd><p>The numeric value from the number-copies +attribute.</p></dd><dt><span class="term">options </span></dt><dd><p>The job options.</p></dd><dt><span class="term">filename </span></dt><dd><p>(Optionally) The print request file (if missing, +filters expected data fed through <tt class="filename">stdin</tt>). In most +cases, it is easy to write a simple wrapper script around existing +filters to make them work with CUPS.</p></dd></dl></div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2934481"></a>Prefilters</h3></div></div><div></div></div><p> +<a class="indexterm" name="id2934492"></a> +As previously stated, PostScript is the central file format to any UNIX-based +printing system. From PostScript, CUPS generates raster data to feed +non-PostScript printers. +</p><p> +But what happens if you send one of the supported non-PS formats +to print? Then CUPS runs “<span class="quote">pre-filters</span>” 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 <i class="parameter"><tt>application/postscript</tt></i> (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 <i class="parameter"><tt>imagetops</tt></i> filter. Its outcome is always of +MIME type <i class="parameter"><tt>application/vnd.cups-postscript</tt></i> +(not application/postscript), meaning it has the +print options already embedded into the file. +</p><p> + </p><div class="figure"><a name="4small"></a><p class="title"><b>Figure 19.4. Pre-filtering in CUPS to form PostScript.</b></p><div class="mediaobject"><img src="projdoc/imagefiles/4small.png" width="270" alt="Pre-filtering in CUPS to form PostScript."></div></div><p> +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2934591"></a>pstops</h3></div></div><div></div></div><p> +<span class="emphasis"><em>pstops</em></span> is the filter to convert +<i class="parameter"><tt>application/postscript</tt></i> to +<i class="parameter"><tt>application/vnd.cups-postscript</tt></i>. 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 and punching it, and so on) into the PostScript file. +</p><p> + </p><div class="figure"><a name="5small"></a><p class="title"><b>Figure 19.5. Adding device-specific print options.</b></p><div class="mediaobject"><img src="projdoc/imagefiles/5small.png" width="270" alt="Adding device-specific print options."></div></div><p> +</p><p> +This is not all. Other tasks performed by it are: +</p><div class="itemizedlist"><ul type="disc"><li><p> +Selecting the range of pages to be printed (if you choose to +print only pages “<span class="quote">3, 6, 8-11, 16, 19-21</span>”, or only the odd numbered +ones). +</p></li><li><p> +Putting 2 or more logical pages on one sheet of paper (the +so-called “<span class="quote">number-up</span>” function). +</p></li><li><p>Counting the pages of the job to insert the accounting +information into the <tt class="filename">/var/log/cups/page_log</tt>. +</p></li></ul></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2934715"></a>pstoraster</h3></div></div><div></div></div><p> +<i class="parameter"><tt>pstoraster</tt></i> 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 <span class="emphasis"><em>raster drivers</em></span> +that are able to generate device-specific printer data. +</p><p> + </p><div class="figure"><a name="6small"></a><p class="title"><b>Figure 19.6. PostScript to intermediate raster format.</b></p><div class="mediaobject"><img src="projdoc/imagefiles/6small.png" width="270" alt="PostScript to intermediate raster format."></div></div><p> +</p><p> +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 quite easy and inexpensive for +manufacturers to develop Linux and UNIX raster drivers for their +printer models, should they choose to do so. CUPS always takes care +for the first stage of rasterization so these vendors do not need to care +about Ghostscript complications (in fact, there is currently more +than one vendor financing the development of CUPS raster drivers). +</p><p> + </p><div class="figure"><a name="7small"></a><p class="title"><b>Figure 19.7. CUPS-raster production using Ghostscript.</b></p><div class="mediaobject"><img src="projdoc/imagefiles/7small.png" width="270" alt="CUPS-raster production using Ghostscript."></div></div><p> +</p><p> +CUPS versions before version 1.1.15 were shipping a binary (or source +code) standalone filter, named <i class="parameter"><tt>pstoraster</tt></i>. <i class="parameter"><tt>pstoraster</tt></i> was derived +from GNU Ghostscript 5.50, and could be installed besides and in +addition to any GNU or AFPL Ghostscript package without conflicting. +</p><p> +>From version 1.1.15, this has changed. The functions for this have been +integrated back into Ghostscript (now based on GNU Ghostscript version +7.05). The <i class="parameter"><tt>pstoraster</tt></i> filter is now a simple shell script calling +<b class="command">gs</b> with the <b class="command">-sDEVICE=cups</b> +parameter. If your Ghostscript does not show a success on asking for +<b class="command">gs -h |grep cups</b>, you might not be able to +print. Update your Ghostscript. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2934912"></a>imagetops and imagetoraster</h3></div></div><div></div></div><p> +In the section about pre-filters, we mentioned the pre-filter +that generates PostScript from image formats. The <i class="parameter"><tt>imagetoraster</tt></i> +filter is used to convert directly from image to raster, without the +intermediate PostScript stage. It is used more often than the above +mentioned pre-filters. A summarizing flowchart of image file +filtering is shown in <link linkend="small8">. +</p><p> + </p><div class="figure"><a name="small8"></a><p class="title"><b>Figure 19.8. Image format to CUPS-raster format conversion.</b></p><div class="mediaobject"><img src="projdoc/imagefiles/8small.png" width="270" alt="Image format to CUPS-raster format conversion."></div></div><p> +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2934991"></a>rasterto [printers specific]</h3></div></div><div></div></div><p> +CUPS ships with quite different raster drivers processing CUPS +raster. On my system I find in /usr/lib/cups/filter/ these: +<i class="parameter"><tt>rastertoalps</tt></i>, <i class="parameter"><tt>rastertobj</tt></i>, <i class="parameter"><tt>rastertoepson</tt></i>, <i class="parameter"><tt>rastertoescp</tt></i>, +<i class="parameter"><tt>rastertopcl</tt></i>, <i class="parameter"><tt>rastertoturboprint</tt></i>, <i class="parameter"><tt>rastertoapdk</tt></i>, <i class="parameter"><tt>rastertodymo</tt></i>, +<i class="parameter"><tt>rastertoescp</tt></i>, <i class="parameter"><tt>rastertohp</tt></i>, and +<i class="parameter"><tt>rastertoprinter</tt></i>. Don't worry if you have less +than this; some of these are installed by commercial add-ons to CUPS +(like <i class="parameter"><tt>rastertoturboprint</tt></i>), others (like +<i class="parameter"><tt>rastertoprinter</tt></i>) by third-party driver +development projects (such as Gimp-Print) wanting to cooperate as +closely as possible with CUPS. +</p><p> + </p><div class="figure"><a name="small9"></a><p class="title"><b>Figure 19.9. Raster to printer-specific formats.</b></p><div class="mediaobject"><img src="projdoc/imagefiles/9small.png" width="270" alt="Raster to printer-specific formats."></div></div><p> +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2935143"></a>CUPS Backends</h3></div></div><div></div></div><p> +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 print queue needs to have a CUPS “<span class="quote">device-URI</span>” +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: +</p><div class="variablelist"><dl><dt><span class="term">usb </span></dt><dd><p> + This backend sends printfiles to USB-connected printers. An + example for the CUPS device-URI to use is: + <tt class="filename">usb:/dev/usb/lp0</tt>. + </p></dd><dt><span class="term">serial </span></dt><dd><p> + This backend sends printfiles to serially connected printers. + An example for the CUPS device-URI to use is: + <tt class="filename">serial:/dev/ttyS0?baud=11500</tt>. + </p></dd><dt><span class="term">parallel </span></dt><dd><p> + This backend sends printfiles to printers connected to the + parallel port. An example for the CUPS device-URI to use is: + <tt class="filename">parallel:/dev/lp0</tt>. + </p></dd><dt><span class="term">scsi </span></dt><dd><p> + This backend sends printfiles to printers attached to the + SCSI interface. An example for the CUPS device-URI to use is: + <tt class="filename">scsi:/dev/sr1</tt>. + </p></dd><dt><span class="term">lpd </span></dt><dd><p> + This backend sends printfiles to LPR/LPD connected network + printers. An example for the CUPS device-URI to use is: + <tt class="filename">lpd://remote_host_name/remote_queue_name</tt>. + </p></dd><dt><span class="term">AppSocket/HP JetDirect </span></dt><dd><p> + This backend sends printfiles to AppSocket (a.k.a. "HP + JetDirect") connected network printers. An example for the CUPS + device-URI to use is: + <tt class="filename">socket://10.11.12.13:9100</tt>. + </p></dd><dt><span class="term">ipp </span></dt><dd><p> + This backend sends printfiles to IPP connected network + printers (or to other CUPS servers). Examples for CUPS device-URIs + to use are: + <tt class="filename">ipp:://192.193.194.195/ipp</tt> + (for many HP printers) or + <tt class="filename">ipp://remote_cups_server/printers/remote_printer_name</tt>. + </p></dd><dt><span class="term">http </span></dt><dd><p> + This backend sends printfiles to HTTP connected printers. + (The http:// CUPS backend is only a symlink to the ipp:// backend.) + Examples for the CUPS device-URIs to use are: + <tt class="filename">http:://192.193.194.195:631/ipp</tt> + (for many HP printers) or + <tt class="filename">http://remote_cups_server:631/printers/remote_printer_name</tt>. + </p></dd><dt><span class="term">smb </span></dt><dd><p> + This backend sends printfiles to printers shared by a Windows + host. An example for CUPS device-URIs that may be used includes: + </p><p> + </p><table class="simplelist" border="0" summary="Simple list"><tr><td><tt class="filename">smb://workgroup/server/printersharename</tt></td></tr><tr><td><tt class="filename">smb://server/printersharename</tt></td></tr><tr><td><tt class="filename">smb://username:password@workgroup/server/printersharename</tt></td></tr><tr><td><tt class="filename">smb://username:password@server/printersharename</tt></td></tr></table><p> + </p><p> + The smb:// backend is a symlink to the Samba utility + <i class="parameter"><tt>smbspool</tt></i> (does not ship with CUPS). If the + symlink is not present in your CUPS backend directory, have your + root user create it: <b class="command">ln -s `which smbspool' + /usr/lib/cups/backend/smb</b>. + </p></dd></dl></div><p> +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 “<span class="quote">special</span>” printers that send +the printjobs as email (through a “<span class="quote">mailto:/</span>” backend), convert them to +PDF (through a “<span class="quote">pdfgen:/</span>” backend) or dump them to “<span class="quote">/dev/null</span>”. (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 do not name +a printer. The system-wide default deletes the job and sends a polite +email back to the $USER asking him to always specify the correct +printer name.) +</p><p> +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 <span class="emphasis"><em>lpinfo</em></span> +utility. Used with the <tt class="option">-v</tt> parameter, it lists +all available backends: +</p><pre class="screen"> +<tt class="prompt">$ </tt><b class="userinput"><tt>lpinfo -v</tt></b> +</pre></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2935508"></a>The Role of <i class="parameter"><tt>cupsomatic/foomatic</tt></i></h3></div></div><div></div></div><p> +<a class="indexterm" name="id2935523"></a> +<a class="indexterm" name="id2935532"></a> +<i class="parameter"><tt>cupsomatic</tt></i> 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. <i class="parameter"><tt>cupsomatic</tt></i> uses PPDs that are generated from the Foomatic +Printer & Driver Database at Linuxprinting.org. +</p><p> +You can recognize these PPDs from the line calling the +<i class="parameter"><tt>cupsomatic</tt></i> filter: + +</p><pre class="programlisting"> + *cupsFilter: "application/vnd.cups-postscript 0 cupsomatic" +</pre><p> + +You may find this line among the first 40 or so lines of the PPD +file. If you have such a PPD installed, the printer shows up in the +CUPS Web interface with a <i class="parameter"><tt>foomatic</tt></i> namepart for +the driver description. <i class="parameter"><tt>cupsomatic</tt></i> is a Perl script that runs +Ghostscript with all the complicated command line options +auto-constructed from the selected PPD and command line options give to +the printjob. +</p><p> +<a class="indexterm" name="id2935609"></a> + However, <i class="parameter"><tt>cupsomatic</tt></i> 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 “<span class="quote">Point'n'Print</span>” to Windows clients. A better +and more powerful successor is now in a stable beta-version: it is called <i class="parameter"><tt>foomatic-rip</tt></i>. To use +<i class="parameter"><tt>foomatic-rip</tt></i> as a filter with CUPS, you need the new-type PPDs. These +have a similar but different line: + +</p><pre class="programlisting"> + *cupsFilter: "application/vnd.cups-postscript 0 foomatic-rip" +</pre><p> + +The PPD generating engine at Linuxprinting.org has been revamped. +The new PPDs comply to the Adobe spec. On top, they also provide a +new way to specify different quality levels (hi-res photo, normal +color, grayscale, and draft) with a single click, whereas before you +could have required five or more different selections (media type, +resolution, inktype and dithering algorithm). There is support for +custom-size media built in. There is support to switch +print-options from page to page in the middle of a job. And the +best thing is the new foomatic-rip now works seamlessly with all +legacy spoolers too (like LPRng, BSD-LPD, PDQ, PPR and so on), providing +for them access to use PPDs for their printing. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2935673"></a>The Complete Picture</h3></div></div><div></div></div><p> +If you want to see an overview of all the filters and how they +relate to each other, the complete picture of the puzzle is at the end +of this document. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2935688"></a><tt class="filename">mime.convs</tt></h3></div></div><div></div></div><p> +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 third column of the mime.convs file. They represent virtual costs +assigned to this filter. Every possible filtering chain will sum up to +a total “<span class="quote">filter cost.</span>” CUPS decides for the most “<span class="quote">inexpensive</span>” route. +</p><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p> +The setting of <i class="parameter"><tt>FilterLimit 1000</tt></i> in +<tt class="filename">cupsd.conf</tt> will not allow more filters to +run concurrently than will consume a total of 1000 virtual filter +cost. This is an efficient way to limit the load of any CUPS +server by setting an appropriate “<span class="quote">FilterLimit</span>” value. A FilterLimit of +200 allows roughly one job at a time, while a FilterLimit of 1000 allows +approximately five jobs maximum at a time. +</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2935752"></a>“<span class="quote">Raw</span>” Printing</h3></div></div><div></div></div><p> + You can tell CUPS to print (nearly) any file “<span class="quote">raw</span>”. “<span class="quote">Raw</span>” means it + will not be filtered. CUPS will send the file to the printer “<span class="quote">as is</span>” +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 “<span class="quote"><i class="parameter"><tt>-o raw</tt></i></span>” 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: +</p><pre class="screen"> +<tt class="prompt">$ </tt><b class="userinput"><tt>lpadmin -P rawprinter -v socket://11.12.13.14:9100 -E</tt></b> +</pre><p> + sets up a queue named “<span class="quote">rawprinter</span>”, connected via the “<span class="quote">socket</span>” + protocol (a.k.a. “<span class="quote">HP JetDirect</span>”) to the device at IP address +11.12.1.3.14, using port 9100. (If you had added a PPD with +<b class="command">-P /path/to/PPD</b> to this command line, you would +have installed a “<span class="quote">normal</span>” print queue. +</p><p> +CUPS will automatically treat each job sent to a queue as a “<span class="quote">raw</span>” 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. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2935861"></a>application/octet-stream Printing</h3></div></div><div></div></div><p> +Any MIME type with no rule in the +<tt class="filename">/etc/cups/mime.types</tt> file is regarded as unknown +or <i class="parameter"><tt>application/octet-stream</tt></i> and will not be +sent. Because CUPS refuses to print unknown MIME types per default, +you will probably have experienced the fact that print jobs originating +from Windows clients were not printed. You may have found an error +message in your CUPS logs like: +</p><p><tt class="computeroutput"> + Unable to convert file 0 to printable format for job +</tt></p><p> +To enable the printing of <i class="parameter"><tt>application/octet-stream</tt></i> files, edit +these two files: +</p><div class="itemizedlist"><ul type="disc"><li><p><tt class="filename">/etc/cups/mime.convs</tt></p></li><li><p><tt class="filename">/etc/cups/mime.types</tt></p></li></ul></div><p> +Both contain entries (at the end of the respective files) which must +be uncommented to allow RAW mode operation for +<i class="parameter"><tt>application/octet-stream</tt></i>. In <tt class="filename">/etc/cups/mime.types</tt> +make sure this line is present: + +<a class="indexterm" name="id2935958"></a> + +</p><pre class="programlisting"> +application/octet-stream +</pre><p> + +This line (with no specific auto-typing rule set) makes all files +not otherwise auto-typed a member of <i class="parameter"><tt>application/octet-stream</tt></i>. In +<tt class="filename">/etc/cups/mime.convs</tt>, have this +line: + +</p><pre class="programlisting"> +application/octet-stream application/vnd.cups-raw 0 - +</pre><p> + +<a class="indexterm" name="id2935999"></a> + +This line tells CUPS to use the <span class="emphasis"><em>Null Filter</em></span> +(denoted as “<span class="quote">-</span>”, doing nothing at all) on +<i class="parameter"><tt>application/octet-stream</tt></i>, and tag the result as +<i class="parameter"><tt>application/vnd.cups-raw</tt></i>. This last one is +always a green light to the CUPS scheduler to now hand the file over +to the backend connecting to the printer and sending it over. +</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Editing the <tt class="filename">mime.convs</tt> and the +<tt class="filename">mime.types</tt> file does not +<span class="emphasis"><em>enforce</em></span> “<span class="quote">raw</span>” printing, it only +<span class="emphasis"><em>allows</em></span> it. +</p></div><p><b>Background. </b> +CUPS being a more security-aware printing system than traditional ones +does not by default allow one to send deliberate (possibly binary) +data to printing devices. (This could be easily abused to launch a +Denial of Service attack on your printer(s), causing at least the loss +of a lot of paper and ink...) “<span class="quote">Unknown</span>” data are regarded by CUPS +as <span class="emphasis"><em>MIME type</em></span> +<span class="emphasis"><em>application/octet-stream</em></span>. While you +<span class="emphasis"><em>can</em></span> send data “<span class="quote">raw</span>”, the MIME type for these must +be one that is known to CUPS and an allowed one. The file +<tt class="filename">/etc/cups/mime.types</tt> defines the “<span class="quote">rules</span>” of how CUPS +recognizes MIME types. The file +<tt class="filename">/etc/cups/mime.convs</tt> decides which file +conversion filter(s) may be applied to which MIME types. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2936129"></a>PostScript Printer Descriptions (PPDs) for Non-PS Printers</h3></div></div><div></div></div><p> +<a class="indexterm" name="id2936141"></a> +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 +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. +</p><p> +PPDs for a non-PS printer have a few lines that are unique to +CUPS. The most important one looks similar to this: + +<a class="indexterm" name="id2936166"></a> + +</p><pre class="programlisting"> + *cupsFilter: application/vnd.cups-raster 66 rastertoprinter +</pre><p> + +It is the last piece in the CUPS filtering puzzle. This line tells the +CUPS daemon to use as a last filter <i class="parameter"><tt>rastertoprinter</tt></i>. This filter +should be served as input an <i class="parameter"><tt>application/vnd.cups-raster</tt></i> MIME type +file. Therefore, CUPS should auto-construct a filtering chain, which +delivers as its last output the specified MIME type. This is then +taken as input to the specified <i class="parameter"><tt>rastertoprinter</tt></i> filter. After this +the last filter has done its work (<i class="parameter"><tt>rastertoprinter</tt></i> is a Gimp-Print +filter), the file should go to the backend, which sends it to the +output device. +</p><p> +CUPS by default ships only a few generic PPDs, but they are good for +several hundred printer models. You may not be able to control +different paper trays, or you may get larger margins than your +specific model supports. See <link linkend="cups-ppds"> for summary information. +</p><div class="table"><a name="cups-ppds"></a><p class="title"><b>Table 19.1. PPDs shipped with CUPS</b></p><table summary="PPDs shipped with CUPS" border="1"><colgroup><col align="left"><col align="justify"></colgroup><thead><tr><th align="left">PPD file</th><th align="justify">Printer type</th></tr></thead><tbody><tr><td align="left">deskjet.ppd</td><td align="justify">older HP inkjet printers and compatible</td></tr><tr><td align="left">deskjet2.ppd</td><td align="justify">newer HP inkjet printers and compatible </td></tr><tr><td align="left">dymo.ppd</td><td align="justify">label printers </td></tr><tr><td align="left">epson9.ppd</td><td align="justify">Epson 24pin impact printers and compatible </td></tr><tr><td align="left">epson24.ppd</td><td align="justify">Epson 24pin impact printers and compatible </td></tr><tr><td align="left">okidata9.ppd</td><td align="justify">Okidata 9pin impact printers and compatible </td></tr><tr><td align="left">okidat24.ppd</td><td align="justify">Okidata 24pin impact printers and compatible </td></tr><tr><td align="left">stcolor.ppd</td><td align="justify">older Epson Stylus Color printers </td></tr><tr><td align="left">stcolor2.ppd</td><td align="justify">newer Epson Stylus Color printers </td></tr><tr><td align="left">stphoto.ppd</td><td align="justify">older Epson Stylus Photo printers </td></tr><tr><td align="left">stphoto2.ppd</td><td align="justify">newer Epson Stylus Photo printers </td></tr><tr><td align="left">laserjet.ppd</td><td align="justify">all PCL printers. Further below is a discussion + of several other driver/PPD-packages suitable for use with CUPS. </td></tr></tbody></table></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2936430"></a><span class="emphasis"><em>cupsomatic/foomatic-rip</em></span> Versus <span class="emphasis"><em>native CUPS</em></span> Printing</h3></div></div><div></div></div><p> +<a class="indexterm" name="id2936449"></a> +<a class="indexterm" name="id2936457"></a> +Native CUPS rasterization works in two steps: +</p><div class="itemizedlist"><ul type="disc"><li><p> +First is the <i class="parameter"><tt>pstoraster</tt></i> step. It uses the special CUPS +<a class="indexterm" name="id2936483"></a> +device from ESP Ghostscript 7.05.x as its tool. +</p></li><li><p> +Second comes the <i class="parameter"><tt>rasterdriver</tt></i> step. It uses various +device-specific filters; there are several vendors who provide good +quality filters for this step. Some are free software, some are +shareware/non-free and some are proprietary.</p></li></ul></div><p> +Often this produces better quality (and has several more +advantages) than other methods. +</p><p> + </p><div class="figure"><a name="cupsomatic-dia"></a><p class="title"><b>Figure 19.10. cupsomatic/foomatic Processing versus Native CUPS.</b></p><div class="mediaobject"><img src="projdoc/imagefiles/10small.png" width="270" alt="cupsomatic/foomatic Processing versus Native CUPS."></div></div><p> +</p><p> +One other method is the <i class="parameter"><tt>cupsomatic/foomatic-rip</tt></i> +way. Note that <i class="parameter"><tt>cupsomatic</tt></i> is <span class="emphasis"><em>not</em></span> made by the CUPS +developers. It is an independent contribution to printing development, +made by people from Linuxprinting.org <sup>[<a name="id2936587" href="#ftn.id2936587">4</a>]</sup>. +<i class="parameter"><tt>cupsomatic</tt></i> is no longer developed and maintained and is no longer +supported. It has now been replaced by +<i class="parameter"><tt>foomatic-rip</tt></i>. <i class="parameter"><tt>foomatic-rip</tt></i> is a complete re-write +of the old <i class="parameter"><tt>cupsomatic</tt></i> idea, but very much improved and generalized to +other (non-CUPS) spoolers. An upgrade to foomatic-rip is strongly +advised, especially if you are upgrading to a recent version of CUPS, +too. +</p><p> + <a class="indexterm" name="id2936634"></a> + <a class="indexterm" name="id2936642"></a> +Both the <i class="parameter"><tt>cupsomatic</tt></i> (old) and the <i class="parameter"><tt>foomatic-rip</tt></i> (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 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. +</p><p> +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. +</p><p> +<i class="parameter"><tt>cupsomatic</tt></i> kidnaps the printfile after the +<i class="parameter"><tt>application/vnd.cups-postscript</tt></i> stage and +deviates it through the CUPS-external, system-wide Ghostscript +installation. Therefore the printfile bypasses the <i class="parameter"><tt>pstoraster</tt></i> filter +(and also bypasses the CUPS-raster-drivers +<i class="parameter"><tt>rastertosomething</tt></i>). After Ghostscript finished its rasterization, +<i class="parameter"><tt>cupsomatic</tt></i> hands the rendered file directly to the CUPS backend. The +flowchart in <link linkend="cupsomatic-dia"> illustrates the difference between native CUPS +rendering and the <i class="parameter"><tt>Foomatic/cupsomatic</tt></i> method. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2936743"></a>Examples for Filtering Chains</h3></div></div><div></div></div><p> +Here are a few examples of commonly occurring filtering chains to +illustrate the workings of CUPS. +</p><p> +Assume you want to print a PDF file to an HP JetDirect-connected +PostScript printer, but you want to print the pages 3-5, 7, 11-13 +only, and you want to print them “<span class="quote">two-up</span>” and “<span class="quote">duplex</span>”: +</p><div class="itemizedlist"><ul type="disc"><li><p>Your print options (page selection as required, two-up, +duplex) are passed to CUPS on the command line.</p></li><li><p>The (complete) PDF file is sent to CUPS and autotyped as +<i class="parameter"><tt>application/pdf</tt></i>.</p></li><li><p>The file therefore must first pass the +<i class="parameter"><tt>pdftops</tt></i> pre-filter, which produces PostScript +MIME type <i class="parameter"><tt>application/postscript</tt></i> (a preview here +would still show all pages of the original PDF).</p></li><li><p>The file then passes the <i class="parameter"><tt>pstops</tt></i> +filter that applies the command line options: it selects the pages +2-5, 7 and 11-13, creates an imposed layout “<span class="quote">2 pages on 1 sheet</span>” and +inserts the correct “<span class="quote">duplex</span>” command (as defined in the printer's +PPD) into the new PostScript file; the file is now of PostScript MIME +type +<i class="parameter"><tt>application/vnd.cups-postscript</tt></i>.</p></li><li><p>The file goes to the <i class="parameter"><tt>socket</tt></i> +backend, which transfers the job to the printers.</p></li></ul></div><p> + The resulting filter chain, therefore, is as drawn in <link linkend="pdftosocket">. +</p><div class="figure"><a name="pdftosocket"></a><p class="title"><b>Figure 19.11. PDF to socket chain.</b></p><div class="mediaobject"><img src="projdoc/imagefiles/pdftosocket.png" width="270" alt="PDF to socket chain."></div></div><p> +Assume your want to print the same filter to an USB-connected +Epson Stylus Photo printer installed with the CUPS +<tt class="filename">stphoto2.ppd</tt>. The first few filtering stages +are nearly the same: +</p><div class="itemizedlist"><ul type="disc"><li><p>Your print options (page selection as required, two-up, +duplex) are passed to CUPS on the commandline.</p></li><li><p>The (complete) PDF file is sent to CUPS and autotyped as +<i class="parameter"><tt>application/pdf</tt></i>.</p></li><li><p>The file must first pass the +<i class="parameter"><tt>pdftops</tt></i> pre-filter, which produces PostScript +MIME type <i class="parameter"><tt>application/postscript</tt></i> (a preview here +would still show all pages of the original PDF).</p></li><li><p>The file then passes the “<span class="quote">pstops</span>” filter that applies +the commandline options: it selects the pages 2-5, 7 and 11-13, +creates an imposed layout “<span class="quote">two pages on one sheet</span>” and inserts the +correct “<span class="quote">duplex</span>” command... (Oops this printer and PPD +do not support duplex printing at all so this option will +be ignored) into the new PostScript file; the file is now of PostScript +MIME type +<i class="parameter"><tt>application/vnd.cups-postscript</tt></i>.</p></li><li><p>The file then passes the + +<i class="parameter"><tt>pstoraster</tt></i> stage and becomes MIME type +<i class="parameter"><tt>application/ +cups-raster</tt></i>.</p></li><li><p>Finally, the <i class="parameter"><tt>rastertoepson</tt></i> filter +does its work (as indicated in the printer's PPD), creating the +rinter-specific raster data and embedding any user-selected +print-options into the print data stream.</p></li><li><p>The file goes to the <i class="parameter"><tt>usb</tt></i> backend, +which transfers the job to the printers.</p></li></ul></div><p> + The resulting filter chain therefore is as drawn in <link linkend="pdftoepsonusb">. +</p><div class="figure"><a name="pdftoepsonusb"></a><p class="title"><b>Figure 19.12. PDF to USB chain.</b></p><div class="mediaobject"><img src="projdoc/imagefiles/pdftoepsonusb.png" width="270" alt="PDF to USB chain."></div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2937128"></a>Sources of CUPS Drivers/PPDs</h3></div></div><div></div></div><p> +On the Internet you can now find many thousands of CUPS-PPD files +(with their companion filters), in many national languages +supporting more than thousand non-PostScript models. +</p><div class="itemizedlist"><a class="indexterm" name="id2937144"></a><a class="indexterm" name="id2937154"></a><ul type="disc"><li><p><ulink url="http://wwwl.easysw.com/printpro/">ESP +PrintPro</ulink> (commercial, +non-free) is packaged with more than three thousand PPDs, ready for +successful use “<span class="quote">out of the box</span>” on Linux, Mac OS X, IBM-AIX, +HP-UX, Sun-Solaris, SGI-IRIX, Compaq Tru64, Digital UNIX, and some +more commercial Unices (it is written by the CUPS developers +themselves and its sales help finance the further development of +CUPS, as they feed their creators).</p></li><li><p>The <ulink url="http://gimp-print.sourceforge.net/">Gimp-Print-Project +</ulink> (GPL, free software) +provides around 140 PPDs (supporting nearly 400 printers, many driven +to photo quality output), to be used alongside the Gimp-Print CUPS +filters.</p></li><li><p><ulink url="http://www.turboprint.com/">TurboPrint +</ulink> (shareware, non-free) supports +roughly the same amount of printers in excellent +quality.</p></li><li><p><ulink url="http://www-124.ibm.com/developerworks/oss/linux/projects/omni/">OMNI +</ulink> +(LPGL, free) is a package made by IBM, now containing support for more +than 400 printers, stemming from the inheritance of IBM OS/2 Know-How +ported over to Linux (CUPS support is in a beta-stage at +present).</p></li><li><p><ulink url="http://hpinkjet.sourceforge.net/">HPIJS +</ulink> (BSD-style licenses, free) +supports around 150 of HP's own printers and is also providing +excellent print quality now (currently available only via the Foomatic +path).</p></li><li><p><ulink url="http://www.linuxprinting.org/">Foomatic/cupsomatic +</ulink> (LPGL, free) from +Linuxprinting.org are providing PPDs for practically every Ghostscript +filter known to the world (including Omni, Gimp-Print and +HPIJS).</p></li></ul></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2937265"></a>Printing with Interface Scripts</h3></div></div><div></div></div><p> +CUPS also supports the usage of “<span class="quote">interface scripts</span>” 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 <b class="command">-i</b> option: +</p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>lpadmin -p pclprinter -v socket://11.12.13.14:9100 \ + -i /path/to/interface-script</tt></b> +</pre><p> +Interface scripts might be the “<span class="quote">unknown animal</span>” to many. However, +with CUPS they provide the easiest way to plug in your own +custom-written filtering script or program into one specific print +queue (some information about the traditional usage of interface scripts is +to be found at <ulink url="http://playground.sun.com/printing/documentation/interface.html">http://playground.sun.com/printing/documentation/interface.html</ulink>). +</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2937358"></a>Network Printing (Purely Windows)</h2></div></div><div></div></div><p> +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 “<span class="quote">purely Windows</span>” setup: Windows clients +with a Windows NT print server. +</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2937377"></a>From Windows Clients to an NT Print Server</h3></div></div><div></div></div><p> +Windows clients printing to an NT-based print server have two +options. They may: +<a class="indexterm" name="id2937390"></a> +<a class="indexterm" name="id2937399"></a> +</p><div class="itemizedlist"><ul type="disc"><li><p>Execute the driver locally and render the GDI output + (EMF) into the printer-specific format on their own. + </p></li><li><p>Send the GDI output (EMF) to the server, where the +driver is executed to render the printer specific +output.</p></li></ul></div><p> + Both print paths are shown in the flowcharts in the figures below. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2937434"></a>Driver Execution on the Client</h3></div></div><div></div></div><p> +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 a traditional UNIX-based print server can do too, and +at a better performance and more reliably than an NT print server. This +is what most Samba administrators probably are familiar with. One +advantage of this setup is that this “<span class="quote">spooling-only</span>” 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. +</p><p> + </p><div class="figure"><a name="small11"></a><p class="title"><b>Figure 19.13. Print driver execution on the client.</b></p><div class="mediaobject"><img src="projdoc/imagefiles/11small.png" width="270" alt="Print driver execution on the client."></div></div><p> +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2937506"></a>Driver Execution on the Server</h3></div></div><div></div></div><p> +<a class="indexterm" name="id2937515"></a> +<a class="indexterm" name="id2937523"></a> +<a class="indexterm" name="id2937532"></a> +<a class="indexterm" name="id2937540"></a> +<a class="indexterm" name="id2937548"></a> +The other path executes the printer driver on the server. The client +transfers print files in EMF format to the server. The server uses the +PostScript, PCL, ESC/P or other driver to convert the EMF file into +the printer-specific language. It is not possible for UNIX to do the +same. Currently, there is no program or method to convert a Windows +client's GDI output on a UNIX server into something a printer could +understand. +</p><p> + </p><div class="figure"><a name="small12"></a><p class="title"><b>Figure 19.14. Print driver execution on the server.</b></p><div class="mediaobject"><img src="projdoc/imagefiles/12small.png" width="270" alt="Print driver execution on the server."></div></div><p> +</p><p> +However, there is something similar possible with CUPS. Read on. +</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2937618"></a>Network Printing (Windows Clients UNIX/Samba Print +Servers)</h2></div></div><div></div></div><p> +Since UNIX print servers <span class="emphasis"><em>cannot</em></span> execute the Win32 +program code on their platform, the picture is somewhat +different. However, this does not limit your options all that +much. On the contrary, you may have a way here to implement printing +features that are not possible otherwise. +</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2937639"></a>From Windows Clients to a CUPS/Samba Print Server</h3></div></div><div></div></div><p> +Here is a simple recipe showing how you can take advantage of CUPS' +powerful features for the benefit of your Windows network printing +clients: +</p><div class="itemizedlist"><ul type="disc"><li><p>Let the Windows clients send PostScript to the CUPS +server.</p></li><li><p>Let the CUPS server render the PostScript into device-specific raster format.</p></li></ul></div><p> +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. +</p><p> +First, to enable CUPS-based rinting through Samba the +following options should be set in your <tt class="filename">smb.conf</tt> file [global] +section: +</p><table class="simplelist" border="0" summary="Simple list"><tr><td><i class="parameter"><tt>printing = cups</tt></i></td></tr><tr><td><i class="parameter"><tt>printcap = cups</tt></i></td></tr></table><p> +When these parameters are specified, all manually set print directives +(like <a class="indexterm" name="id2937719"></a><i class="parameter"><tt>print command</tt></i>, or <a class="indexterm" name="id2937734"></a><i class="parameter"><tt>lppause command</tt></i>) in <tt class="filename">smb.conf</tt> (as well as +in Samba itself) will be ignored. Instead, Samba will directly +interface with CUPS through its 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 +<span class="emphasis"><em>System V</em></span> AT&T command set, with the -oraw +option automatically passing through (if you want your own defined +print commands to work with a Samba that has CUPS support compiled in, +simply use <a class="indexterm" name="id2937772"></a><i class="parameter"><tt>printing</tt></i> = sysv). +</p><p> +</p><div class="figure"><a name="13small"></a><p class="title"><b>Figure 19.15. Printing via CUPS/Samba server.</b></p><div class="mediaobject"><img src="projdoc/imagefiles/13small.png" width="270" alt="Printing via CUPS/Samba server."></div></div><p> +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2937834"></a>Samba Receiving Jobfiles and Passing Them to CUPS</h3></div></div><div></div></div><p> +Samba <span class="emphasis"><em>must</em></span> use its own spool directory (it is set +by a line similar to <a class="indexterm" name="id2937848"></a><i class="parameter"><tt>path</tt></i> = /var/spool/samba, +in the <i class="parameter"><tt>[printers]</tt></i> or +<i class="parameter"><tt>[printername]</tt></i> section of +<tt class="filename">smb.conf</tt>). 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 <i class="parameter"><tt>RequestRoot</tt></i> +directive, in a line that defaults to <i class="parameter"><tt>RequestRoot +/var/spool/cups</tt></i>). CUPS checks the access rights of its +spool dir and resets it to healthy values with every restart. We have +seen quite a few people who had used a common spooling space for Samba +and CUPS, and were struggling for weeks with this “<span class="quote">problem.</span>” +</p><p> +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 “<span class="quote">localhost</span>” to print. If they run on different machines, you +need to make sure the Samba host gets access to printing on CUPS. +</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2937924"></a>Network PostScript RIP</h2></div></div><div></div></div><p> +This section discusses the use of CUPS filters on the server configuration where +clients make use of a PostScript driver with CUPS-PPDs. +</p><p> +<a class="indexterm" name="id2937945"></a> +<a class="indexterm" name="id2937953"></a> +<a class="indexterm" name="id2937961"></a> +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 +“<span class="quote">on-the-fly</span>” into buttons and drop-down lists for the user to select. +</p><p> +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 <ulink url="http://localhost:631/printers/">http://localhost:631/printers/</ulink> +and click on one <span class="guibutton">Configure Printer</span> button to see +it), or a command line interface (see <b class="command">man lpoptions</b> +or see if you have <b class="command">lphelp</b> on your system). There are also some +different GUI frontends on Linux/UNIX, which can present PPD options +to users. PPD options are normally meant to be evaluated by the +PostScript RIP on the real PostScript printer. +</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2938025"></a>PPDs for Non-PS Printers on UNIX</h3></div></div><div></div></div><p> +<a class="indexterm" name="id2938037"></a> +CUPS does not limit itself to “<span class="quote">real</span>” PostScript printers in its usage +of PPDs. The CUPS developers have extended the scope of the PPD +concept to also describe available device and driver options for +non-PostScript printers through CUPS-PPDs. +</p><p> +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 +<i class="parameter"><tt>*cupsFilter</tt></i>. 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. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2938085"></a>PPDs for Non-PS Printers on Windows</h3></div></div><div></div></div><p> +<a class="indexterm" name="id2938096"></a> +CUPS-PPDs can also be used on Windows-Clients, on top of a +“<span class="quote">core</span>” PostScript driver (now recommended is the "CUPS PostScript +Driver for WindowsNT/200x/XP"; you can also use the Adobe one, with +limitations). This feature enables CUPS to do a few tricks no other +spooler can do: +</p><div class="itemizedlist"><ul type="disc"><li><p>Act as a networked PostScript RIP (Raster Image +Processor), handling printfiles from all client platforms in a uniform +way.</p></li><li><p>Act as a central accounting and billing server, since +all files are passed through the pstops filter and are, therefore, +logged in the CUPS <tt class="filename">page_log</tt> file. +<span class="emphasis"><em>Note:</em></span> this cannot happen with “<span class="quote">raw</span>” print jobs, +which always remain unfiltered per definition.</p></li><li><p>Enable clients to consolidate on a single PostScript +driver, even for many different target printers.</p></li></ul></div><p> +Using CUPS PPDs on Windows clients enables these to control +all print job settings just as a UNIX client can do. +</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2938166"></a>Windows Terminal Servers (WTS) as CUPS Clients</h2></div></div><div></div></div><p> +This setup may be of special interest to people experiencing major +problems in WTS environments. WTS often need 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. +</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2938184"></a>Printer Drivers Running in “<span class="quote">Kernel Mode</span>” Cause Many +Problems</h3></div></div><div></div></div><p> + In Windows NT printer drivers which run in “<span class="quote">Kernel +Mode</span>”, 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 “<span class="quote">blue screens +of death</span>” on a regular basis? +</p><p> +PostScript drivers are generally well tested. They are not known +to cause any problems, even though they also run in kernel mode. This +might be because there have been so far only two different PostScript +drivers: the ones from Adobe and the one from Microsoft. Both are +well tested and are as stable as you can imagine on +Windows. The CUPS driver is derived from the Microsoft one. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2938229"></a>Workarounds Impose Heavy Limitations</h3></div></div><div></div></div><p> +In many cases, in an attempt to work around this problem, site +administrators have resorted to restricting the allowed drivers installed +on their WTS to one generic PCL and one PostScript driver. This, +however, restricts the clients in the number of printer options +available for them. Often they can't get out more than simplex +prints from one standard paper tray, while their devices could do much +better, if driven by a different driver! +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2938250"></a>CUPS: A “<span class="quote">Magical Stone</span>”?</h3></div></div><div></div></div><p> +<a class="indexterm" name="id2938266"></a> +<a class="indexterm" name="id2938274"></a> +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 three 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 “<span class="quote">raw spooling</span>” device. Plus, this setup is not yet widely tested, +although the first feedbacks look very promising. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2938313"></a>PostScript Drivers with No Major Problems Even in Kernel +Mode</h3></div></div><div></div></div><p> +<a class="indexterm" name="id2938329"></a> +More recent printer drivers on W200x and XP no longer run in kernel mode +(unlike Windows NT). However, both operating systems can still +use the NT drivers, running in kernel mode (you can roughly tell which +is which as the drivers in subdirectory “<span class="quote">2</span>” of “<span class="quote">W32X86</span>” are “<span class="quote">old</span>” +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 Windows 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 does not allow them to publish the whole of the source code. +However, they have released the “<span class="quote">diff</span>” under the GPL, and if you are +the owner of an “<span class="quote">MS DDK for Windows NT,</span>” you can check the driver yourself. +</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2938378"></a>Configuring CUPS for Driver Download</h2></div></div><div></div></div><p> +As 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 relates to the Samba/Windows client +relationship. +</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2938397"></a><span class="emphasis"><em>cupsaddsmb</em></span>: The Unknown Utility</h3></div></div><div></div></div><p> +<a class="indexterm" name="id2938412"></a> +The <b class="command">cupsaddsmb</b> utility (shipped with all current CUPS versions) is an +alternate method to transfer printer drivers into the Samba +<i class="parameter"><tt>[print$]</tt></i> 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 quite easy. <b class="command">cupsaddsmb</b> can use the Adobe PostScript driver as +well as the newly developed CUPS PostScript Driver for +Windows NT/200x/XP. <i class="parameter"><tt>cupsaddsmb</tt></i> does +<span class="emphasis"><em>not</em></span> work with arbitrary vendor printer drivers, +but only with the <span class="emphasis"><em>exact</em></span> driver files that are +named in its man page. +</p><p> +The CUPS printer driver is available from the CUPS download site. Its +package name is <tt class="filename">cups-samba-[version].tar.gz</tt> . It +is preferred over the Adobe drivers since it has a number of +advantages: +</p><div class="itemizedlist"><ul type="disc"><li><p>It supports a much more accurate page +accounting.</p></li><li><p>It supports banner pages, and page labels on all +printers.</p></li><li><p>It supports the setting of a number of job IPP +attributes (such as job-priority, page-label and +job-billing).</p></li></ul></div><p> +However, currently only Windows NT, 2000 and XP are supported by the +CUPS drivers. You will also need to get the respective part of Adobe driver +if you need to support Windows 95, 98 and ME clients. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2938514"></a>Prepare Your <tt class="filename">smb.conf</tt> for <b class="command">cupsaddsmb</b></h3></div></div><div></div></div><p> +Prior to running <b class="command">cupsaddsmb</b>, you need the settings in +<tt class="filename">smb.conf</tt> as shown in <link linkend="cupsadd-ex">: +</p><div class="example"><a name="cupsadd-ex"></a><p class="title"><b>Example 19.3. smb.conf for cupsaddsmb usage</b></p><table class="simplelist" border="0" summary="Simple list"><tr><td> </td></tr><tr><td><i class="parameter"><tt>[global]</tt></i></td></tr><tr><td><i class="parameter"><tt>load printers = yes</tt></i></td></tr><tr><td><i class="parameter"><tt>printing = cups</tt></i></td></tr><tr><td><i class="parameter"><tt>printcap name = cups</tt></i></td></tr><tr><td> </td></tr><tr><td><i class="parameter"><tt>[printers]</tt></i></td></tr><tr><td><i class="parameter"><tt>comment = All Printers</tt></i></td></tr><tr><td><i class="parameter"><tt>path = /var/spool/samba</tt></i></td></tr><tr><td><i class="parameter"><tt>browseable = no</tt></i></td></tr><tr><td><i class="parameter"><tt>public = yes</tt></i></td></tr><tr><td># setting depends on your requirements</td></tr><tr><td><i class="parameter"><tt>guest ok = yes</tt></i></td></tr><tr><td><i class="parameter"><tt>writable = no</tt></i></td></tr><tr><td><i class="parameter"><tt>printable = yes</tt></i></td></tr><tr><td><i class="parameter"><tt>printer admin = root</tt></i></td></tr><tr><td> </td></tr><tr><td><i class="parameter"><tt>[print$]</tt></i></td></tr><tr><td><i class="parameter"><tt>comment = Printer Drivers</tt></i></td></tr><tr><td><i class="parameter"><tt>path = /etc/samba/drivers</tt></i></td></tr><tr><td><i class="parameter"><tt>browseable = yes</tt></i></td></tr><tr><td><i class="parameter"><tt>guest ok = no</tt></i></td></tr><tr><td><i class="parameter"><tt>read only = yes</tt></i></td></tr><tr><td><i class="parameter"><tt>write list = root</tt></i></td></tr></table></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2938755"></a>CUPS “<span class="quote">PostScript Driver for Windows NT/200x/XP</span>”</h3></div></div><div></div></div><p> +<a class="indexterm" name="id2938770"></a> +CUPS users may get the exact same packages from <ulink url="http://www.cups.org/software.html">http://www.cups.org/software.html</ulink>. +It is a separate package from the CUPS base software files, tagged as +CUPS 1.1.x Windows NT/200x/XP Printer Driver for Samba +(tar.gz, 192k). The filename to download is +<tt class="filename">cups-samba-1.1.x.tar.gz</tt>. Upon untar and unzipping, +it will reveal these files: +</p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>tar xvzf cups-samba-1.1.19.tar.gz</tt></b> +cups-samba.install +cups-samba.license +cups-samba.readme +cups-samba.remove +cups-samba.ss +</pre><p> +<a class="indexterm" name="id2938825"></a> +<a class="indexterm" name="id2938836"></a> +These have been packaged with the ESP meta packager software +EPM. The <tt class="filename">*.install</tt> and +<tt class="filename">*.remove</tt> files are simple shell scripts, which +untars the <tt class="filename">*.ss</tt> (the <tt class="filename">*.ss</tt> is +nothing else but a tar-archive, which can be untarred by “<span class="quote">tar</span>” +too). Then it puts the content into +<tt class="filename">/usr/share/cups/drivers/</tt>. This content includes three +files: +</p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>tar tv cups-samba.ss</tt></b> +cupsdrvr.dll +cupsui.dll +cups.hlp +</pre><p> +The <i class="parameter"><tt>cups-samba.install</tt></i> shell scripts are easy to +handle: +</p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>./cups-samba.install</tt></b> +[....] +Installing software... +Updating file permissions... +Running post-install commands... +Installation is complete. +</pre><p> +The script should automatically put the driver files into the +<tt class="filename">/usr/share/cups/drivers/</tt> directory. +</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p> +Due to a bug, one recent CUPS release puts the +<tt class="filename">cups.hlp</tt> driver file +into<tt class="filename">/usr/share/drivers/</tt> instead of +<tt class="filename">/usr/share/cups/drivers/</tt>. To work around this, +copy/move the file (after running the +<b class="command">./cups-samba.install</b> script) manually to the +correct place. +</p></div><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>cp /usr/share/drivers/cups.hlp /usr/share/cups/drivers/</tt></b> +</pre><p> +<a class="indexterm" name="id2939020"></a> +This new CUPS PostScript driver is currently binary-only, but free of +charge. No complete source code is provided (yet). The reason is that +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 “<span class="quote">diff</span>” 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. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2939044"></a>Recognizing Different Driver Files</h3></div></div><div></div></div><p> +The CUPS drivers do not support the older Windows 95/98/Me, but only +the Windows NT/2000/XP client. +</p><p>Windows NT, 2000 and XP are supported by:</p><p> + </p><div class="itemizedlist"><ul type="disc"><li>cups.hlp</li><li>cupsdrvr.dll</li><li>cupsui.dll</li></ul></div><p> +</p><p> +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 from the +different platforms. +</p><p>Windows 95, 98 and ME are supported by:</p><p> + </p><div class="itemizedlist"><ul type="disc"><li>ADFONTS.MFM</li><li>ADOBEPS4.DRV</li><li>ADOBEPS4.HLP</li><li>DEFPRTR2.PPD</li><li>ICONLIB.DLL</li><li>PSMON.DLL</li></ul></div><p> +</p><p>Windows NT, 2000 and XP are supported by:</p><p> +</p><div class="itemizedlist"><ul type="disc"><li>ADOBEPS5.DLL</li><li>ADOBEPSU.DLL</li><li>ADOBEPSU.HLP</li></ul></div><p> + +</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> +If both the Adobe driver files and the CUPS driver files for the +support of Windows NT/200x/XP are present in FIXME, 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 three CUPS driver files. The +Windows 9x/Me clients use the Adobe drivers in any case. +</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2939174"></a>Acquiring the Adobe Driver Files</h3></div></div><div></div></div><p> +Acquiring the Adobe driver files seems to be unexpectedly difficult +for many users. They are not available on the Adobe Web site 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 +<i class="parameter"><tt>[print$]</tt></i> share holds the Adobe files, from +where you can get them with smbclient from the CUPS host. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2939204"></a>ESP Print Pro PostScript Driver for Windows NT/200x/XP</h3></div></div><div></div></div><p> +<a class="indexterm" name="id2939217"></a> +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 <ulink url="http://www.easysw.com/software.html">http://www.easysw.com/software.html</ulink>. +You need to locate the link labelled “<span class="quote">SAMBA</span>” among the +<span class="guilabel">Download Printer Drivers for ESP Print Pro 4.x</span> +area and download the package. Once installed, you can prepare any +driver by simply highlighting the printer in the Printer Manager GUI +and select <span class="guilabel">Export Driver...</span> from the menu. Of +course you need to have prepared Samba beforehand to handle the +driver files; i.e., setup the <i class="parameter"><tt>[print$]</tt></i> +share, and so on. 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. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2939274"></a>Caveats to be Considered</h3></div></div><div></div></div><p> +<a class="indexterm" name="id2939286"></a> +Once you have run the install script (and possibly manually +moved the <tt class="filename">cups.hlp</tt> file to +<tt class="filename">/usr/share/cups/drivers/</tt>), the driver is +ready to be put into Samba's <i class="parameter"><tt>[print$]</tt></i> share (which often maps to +<tt class="filename">/etc/samba/drivers/</tt> and contains a subdirectory +tree with <span class="emphasis"><em>WIN40</em></span> and +<span class="emphasis"><em>W32X86</em></span> branches). You do this by running +<b class="command">cupsaddsmb</b> (see also <b class="command">man cupsaddsmb</b> for +CUPS since release 1.1.16). +</p><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p> +<a class="indexterm" name="id2939354"></a> +You may need to put root into the smbpasswd file by running +<b class="command">smbpasswd</b>; 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 +<span class="emphasis"><em>single sign on</em></span> to a Windows Domain Controller. +</p></div><p> +Once the driver files are in the <i class="parameter"><tt>[print$]</tt></i> share +and are initialized, they are ready to be downloaded and installed by +the Windows NT/200x/XP clients. +</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> +Win 9x/Me clients will not work with the CUPS PostScript driver. For +these you still need to use the <tt class="filename">ADOBE*.*</tt> +drivers as previously stated. +</p></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> +It is not harmful if you still have the +<tt class="filename">ADOBE*.*</tt> driver files from previous +installations in the <tt class="filename">/usr/share/cups/drivers/</tt> +directory. The new <b class="command">cupsaddsmb</b> (from 1.1.16) will +automatically prefer its own drivers if it finds both. +</p></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> +<a class="indexterm" name="id2939442"></a> +Should your Windows clients have had the old <tt class="filename">ADOBE*.*</tt> +files for the Adobe PostScript driver installed, the download and +installation of the new CUPS PostScript driver for Windows NT/200x/XP +will fail at first. You need to wipe the old driver from the clients +first. It is not enough to “<span class="quote">delete</span>” 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 <span class="guilabel">Printers</span> folder (possibly via <span class="guilabel">Start > Settings > Control Panel > Printers</span>), +right-click on the folder background and select <span class="guimenuitem">Server +Properties</span>. When the new dialog opens, select the +<span class="guilabel">Drivers</span> tab. On the list select the driver you +want to delete and click the <span class="guilabel">Delete</span> +button. This will only work if there is not one single printer left +that uses that particular driver. You need to “<span class="quote">delete</span>” all printers +using this driver in the <span class="guilabel">Printers</span> folder first. You will need +Administrator privileges to do this. +</p></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> +<a class="indexterm" name="id2939527"></a> +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 in <link linkend="printing">. Either change +a driver for an existing printer by running the <span class="guilabel">Printer Properties</span> +dialog, or use <b class="command">rpcclient</b> with the +<b class="command">setdriver</b> subcommand. +</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2939571"></a>Windows CUPS PostScript Driver Versus Adobe Driver</h3></div></div><div></div></div><p> +Are you interested in a comparison between the CUPS and the Adobe +PostScript drivers? For our purposes these are the most important +items that weigh in favor of the CUPS ones: +</p><div class="itemizedlist"><ul type="disc"><li><p>No hassle with the Adobe EULA.</p></li><li><p>No hassle with the question “<span class="quote">Where do I +get the ADOBE*.* driver files from?</span>”</p></li><li><p> +<a class="indexterm" name="id2939611"></a> +The Adobe drivers (on request of the printer PPD +associated with them) often put a PJL header in front of the main +PostScript part of the print file. Thus, the printfile starts with +<i class="parameter"><tt><1B >%-12345X</tt></i> or +<i class="parameter"><tt><escape>%-12345X</tt></i> instead +of <i class="parameter"><tt>%!PS</tt></i>). This leads to the +CUPS daemon auto-typing the incoming file as a print-ready file, +not initiating a pass through the <i class="parameter"><tt>pstops</tt></i> filter (to speak more +technically, it is not regarded as the generic MIME-type +<a class="indexterm" name="id2939654"></a> +<i class="parameter"><tt>application/postscript</tt></i>, but as +the more special MIME type +<a class="indexterm" name="id2939671"></a> +<i class="parameter"><tt>application/cups.vnd-postscript</tt></i>), +which therefore also leads to the page accounting in +<i class="parameter"><tt>/var/log/cups/page_log</tt></i> not +receiving the exact number of pages; instead the dummy page number +of “<span class="quote">1</span>” is logged in a standard setup).</p></li><li><p>The Adobe driver has more options to misconfigure the +PostScript generated by it (like setting it inadvertently to +<span class="guilabel">Optimize for Speed</span>, instead of +<span class="guilabel">Optimize for Portability</span>, which +could lead to CUPS being unable to process it).</p></li><li><p>The CUPS PostScript driver output sent by Windows +clients to the CUPS server is guaranteed to auto-type +as the generic MIME type <i class="parameter"><tt>application/postscript</tt></i>, +thus passing through the CUPS <i class="parameter"><tt>pstops</tt></i> filter and logging the +correct number of pages in the <tt class="filename">page_log</tt> for +accounting and quota purposes.</p></li><li><p>The CUPS PostScript driver supports the sending of +additional standard (IPP) print options by Windows NT/200x/XP clients. Such +additional print options are: naming the CUPS standard +<span class="emphasis"><em>banner pages</em></span> (or the custom ones, should they be +installed at the time of driver download), using the CUPS +page-label option, setting a +job-priority, and setting the scheduled +time of printing (with the option to support additional +useful IPP job attributes in the future).</p></li><li><p>The CUPS PostScript driver supports the inclusion of +the new <i class="parameter"><tt>*cupsJobTicket</tt></i> comments at the +beginning of the PostScript file (which could be used in the future +for all sort of beneficial extensions on the CUPS side, but which will +not disturb any other applications as they will regard it as a comment +and simply ignore it).</p></li><li><p>The CUPS PostScript driver will be the heart of the +fully fledged CUPS IPP client for Windows NT/200x/XP to be released soon +(probably alongside the first beta release for CUPS +1.2).</p></li></ul></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2939801"></a>Run cupsaddsmb (Quiet Mode)</h3></div></div><div></div></div><p> +<a class="indexterm" name="id2939812"></a> +<a class="indexterm" name="id2939820"></a> +The <b class="command">cupsaddsmb</b> command copies the needed files into your +<i class="parameter"><tt>[print$]</tt></i> share. Additionally, the PPD +associated with this printer is copied from +<tt class="filename">/etc/cups/ppd/</tt> to +<i class="parameter"><tt>[print$]</tt></i>. There the files wait for convenient +Windows client installations via Point'n'Print. Before we can run the +command successfully, we need to be sure that we can authenticate +toward Samba. If you have a small network, you are probably using user-level +security (<a class="indexterm" name="id2939861"></a><i class="parameter"><tt>security</tt></i> = user). +</p><p> +Here is an example of a successfully run <b class="command">cupsaddsmb</b> command: +</p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>cupsaddsmb -U root infotec_IS2027</tt></b> +Password for root required to access localhost via Samba: <b class="userinput"><tt>['secret']</tt></b> +</pre><p> +To share <span class="emphasis"><em>all</em></span> printers and drivers, use the +<tt class="option">-a</tt> parameter instead of a printer name. Since +<b class="command">cupsaddsmb</b> “<span class="quote">exports</span>” the printer drivers to Samba, it should be +obvious that it only works for queues with a CUPS driver associated. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2939946"></a>Run cupsaddsmb with Verbose Output</h3></div></div><div></div></div><p> +<a class="indexterm" name="id2939957"></a> +Probably you want to see what's going on. Use the +<tt class="option">-v</tt> parameter to get a more verbose output. The +output below was edited for better readability: all “<span class="quote">\</span>” at the end of +a line indicate that I inserted an artificial line break plus some +indentation here: +</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p> +You will see the root password for the Samba account printed on +screen. +</p></div><p> + +<a class="indexterm" name="id2939988"></a> +<a class="indexterm" name="id2939999"></a> + </p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>cupsaddsmb -U root -v infotec_2105</tt></b> +Password for root required to access localhost via GANDALF: +Running command: smbclient //localhost/print\$ -N -U'root%secret' \ + -c 'mkdir W32X86; \ + put /var/spool/cups/tmp/3e98bf2d333b5 W32X86/infotec_2105.ppd; \ + put /usr/share/cups/drivers/cupsdrvr.dll W32X86/cupsdrvr.dll; \ + put /usr/share/cups/drivers/cupsui.dll W32X86/cupsui.dll; \ + put /usr/share/cups/drivers/cups.hlp W32X86/cups.hlp' +added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0 +Domain=[CUPS-PRINT] OS=[UNIX] Server=[Samba 2.2.7a] +NT_STATUS_OBJECT_NAME_COLLISION making remote directory \W32X86 +putting file /var/spool/cups/tmp/3e98bf2d333b5 as \W32X86/infotec_2105.ppd +putting file /usr/share/cups/drivers/cupsdrvr.dll as \W32X86/cupsdrvr.dll +putting file /usr/share/cups/drivers/cupsui.dll as \W32X86/cupsui.dll +putting file /usr/share/cups/drivers/cups.hlp as \W32X86/cups.hlp + +Running command: rpcclient localhost -N -U'root%secret' + -c 'adddriver "Windows NT x86" \ + "infotec_2105:cupsdrvr.dll:infotec_2105.ppd:cupsui.dll:cups.hlp:NULL: \ + RAW:NULL"' +cmd = adddriver "Windows NT x86" \ + "infotec_2105:cupsdrvr.dll:infotec_2105.ppd:cupsui.dll:cups.hlp:NULL: \ + RAW:NULL" +Printer Driver infotec_2105 successfully installed. + +Running command: smbclient //localhost/print\$ -N -U'root%secret' \ +-c 'mkdir WIN40; \ + put /var/spool/cups/tmp/3e98bf2d333b5 WIN40/infotec_2105.PPD; \ + put /usr/share/cups/drivers/ADFONTS.MFM WIN40/ADFONTS.MFM; \ + put /usr/share/cups/drivers/ADOBEPS4.DRV WIN40/ADOBEPS4.DRV; \ + put /usr/share/cups/drivers/ADOBEPS4.HLP WIN40/ADOBEPS4.HLP; \ + put /usr/share/cups/drivers/DEFPRTR2.PPD WIN40/DEFPRTR2.PPD; \ + put /usr/share/cups/drivers/ICONLIB.DLL WIN40/ICONLIB.DLL; \ + put /usr/share/cups/drivers/PSMON.DLL WIN40/PSMON.DLL;' + added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0 + Domain=[CUPS-PRINT] OS=[UNIX] Server=[Samba 2.2.7a] + NT_STATUS_OBJECT_NAME_COLLISION making remote directory \WIN40 + putting file /var/spool/cups/tmp/3e98bf2d333b5 as \WIN40/infotec_2105.PPD + putting file /usr/share/cups/drivers/ADFONTS.MFM as \WIN40/ADFONTS.MFM + putting file /usr/share/cups/drivers/ADOBEPS4.DRV as \WIN40/ADOBEPS4.DRV + putting file /usr/share/cups/drivers/ADOBEPS4.HLP as \WIN40/ADOBEPS4.HLP + putting file /usr/share/cups/drivers/DEFPRTR2.PPD as \WIN40/DEFPRTR2.PPD + putting file /usr/share/cups/drivers/ICONLIB.DLL as \WIN40/ICONLIB.DLL + putting file /usr/share/cups/drivers/PSMON.DLL as \WIN40/PSMON.DLL + + Running command: rpcclient localhost -N -U'root%secret' \ + -c 'adddriver "Windows 4.0" \ + "infotec_2105:ADOBEPS4.DRV:infotec_2105.PPD:NULL:ADOBEPS4.HLP: \ + PSMON.DLL:RAW:ADOBEPS4.DRV,infotec_2105.PPD,ADOBEPS4.HLP,PSMON.DLL, \ + ADFONTS.MFM,DEFPRTR2.PPD,ICONLIB.DLL"' + cmd = adddriver "Windows 4.0" "infotec_2105:ADOBEPS4.DRV:\ + infotec_2105.PPD:NULL:ADOBEPS4.HLP:PSMON.DLL:RAW:ADOBEPS4.DRV,\ + infotec_2105.PPD,ADOBEPS4.HLP,PSMON.DLL,ADFONTS.MFM,DEFPRTR2.PPD,\ + ICONLIB.DLL" + Printer Driver infotec_2105 successfully installed. + + Running command: rpcclient localhost -N -U'root%secret' \ + -c 'setdriver infotec_2105 infotec_2105' + cmd = setdriver infotec_2105 infotec_2105 + Successfully set infotec_2105 to driver infotec_2105. + +</pre><p> +If you look closely, you'll discover your root password was transferred +unencrypted over the wire, so beware! Also, if you look further, +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 <i class="parameter"><tt>[print$]</tt></i> driver download share (from a previous driver installation). They are harmless here. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2940175"></a>Understanding cupsaddsmb</h3></div></div><div></div></div><p> +<a class="indexterm" name="id2940187"></a> +What has happened? What did <b class="command">cupsaddsmb</b> do? There are five stages of +the procedure: +</p><div class="orderedlist"><ol type="1"><li><p> + <a class="indexterm" name="id2940218"></a> + Call the CUPS server via IPP and request the +driver files and the PPD file for the named printer.</p></li><li><p>Store the files temporarily in the local +TEMPDIR (as defined in +<tt class="filename">cupsd.conf</tt>).</p></li><li><p>Connect via smbclient to the Samba server's + <i class="parameter"><tt>[print$]</tt></i> share and put the files into the + share's WIN40 (for Windows 9x/Me) and W32X86/ (for Windows NT/200x/XP) subdirectories.</p></li><li><p> +<a class="indexterm" name="id2940262"></a> + Connect via rpcclient to the Samba server and +execute the <b class="command">adddriver</b> command with the correct +parameters.</p></li><li><p> +<a class="indexterm" name="id2940287"></a> + Connect via rpcclient to the Samba server a second +time and execute the <b class="command">setdriver</b> command.</p></li></ol></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> +You can run the <b class="command">cupsaddsmb</b> 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 to 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): +</p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>cupsaddsmb -H sambaserver -h cupsserver -v printer</tt></b> +</pre></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2940352"></a>How to Recognize If cupsaddsmb Completed Successfully</h3></div></div><div></div></div><p> +You <span class="emphasis"><em>must</em></span> always check if the utility completed +successfully in all fields. You need as a minimum these three messages +among the output: +</p><div class="orderedlist"><ol type="1"><li><p><span class="emphasis"><em>Printer Driver infotec_2105 successfully +installed.</em></span> # (for the W32X86 == Windows NT/200x/XP +architecture).</p></li><li><p><span class="emphasis"><em>Printer Driver infotec_2105 successfully +installed.</em></span> # (for the WIN40 == Windows 9x/Me +architecture).</p></li><li><p><span class="emphasis"><em>Successfully set [printerXPZ] to driver +[printerXYZ].</em></span></p></li></ol></div><p> +These messages are probably not easily recognized in the general +output. If you run <b class="command">cupsaddsmb</b> with the <tt class="option">-a</tt> +parameter (which tries to prepare <span class="emphasis"><em>all</em></span> active CUPS +printer drivers for download), you might miss if individual printers +drivers had problems installing properly. Here a redirection of the +output will help you analyze the results in retrospective. +</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> +It is impossible to see any diagnostic output if you do not run +<b class="command">cupsaddsmb</b> in verbose mode. Therefore, we strongly recommend to not +use the default quiet mode. It will hide any problems from you that +might occur. +</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2940450"></a>cupsaddsmb with a Samba PDC</h3></div></div><div></div></div><p> +<a class="indexterm" name="id2940460"></a> +Can't get the standard <b class="command">cupsaddsmb</b> command to run on a Samba PDC? +Are you 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: +</p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>cupsaddsmb -U MIDEARTH\\root -v printername</tt></b> +<tt class="prompt">root# </tt><b class="userinput"><tt>cupsaddsmb -H SAURON -U MIDEARTH\\root -v printername</tt></b> +<tt class="prompt">root# </tt><b class="userinput"><tt>cupsaddsmb -H SAURON -U MIDEARTH\\root -h cups-server -v printername</tt></b> +</pre><p> +(Note the two backslashes: the first one is required to +“<span class="quote">escape</span>” the second one). +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2940538"></a>cupsaddsmb Flowchart</h3></div></div><div></div></div><p> +<a class="indexterm" name="id2940548"></a> +<link linkend="small14"> shows a chart about the procedures, commandflows and +dataflows of the <b class="command">cupaddsmb</b> command. Note again: cupsaddsmb is +not intended to, and does not work with, raw queues! +</p><p> + </p><div class="figure"><a name="small14"></a><p class="title"><b>Figure 19.16. cupsaddsmb flowchart.</b></p><div class="mediaobject"><img src="projdoc/imagefiles/14small.png" width="270" alt="cupsaddsmb flowchart."></div></div><p> +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2940621"></a>Installing the PostScript Driver on a Client</h3></div></div><div></div></div><p> +<a class="indexterm" name="id2940631"></a> +After <b class="command">cupsaddsmb</b> is 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: +</p><div class="itemizedlist"><ul type="disc"><li><p> +<a class="indexterm" name="id2940659"></a> +Open the <span class="guilabel">Printers</span> +share of Samba in Network Neighborhood.</p></li><li><p>Right-click on the printer in +question.</p></li><li><p>From the opening context-menu select +<span class="guimenuitem">Install...</span> or +<span class="guimenuitem">Connect...</span> (depending on the Windows version you +use).</p></li></ul></div><p> +After a few seconds, there should be a new printer in your +client's <span class="emphasis"><em>local</em></span> <span class="guilabel">Printers</span> folder. On Windows +XP it will follow a naming convention of <span class="emphasis"><em>PrinterName on +SambaServer</em></span>. (In my current case it is "infotec_2105 on +kde-bitshop"). If you want to test it and send your first job from +an application like Winword, the new printer appears in a +<tt class="filename">\\SambaServer\PrinterName</tt> entry in the +drop-down list of available printers. +</p><p> +<a class="indexterm" name="id2940738"></a> +<b class="command">cupsaddsmb</b> will only reliably work with CUPS version 1.1.15 or higher +and Samba from 2.2.4. If it does not work, or if the automatic printer +driver download to the clients does not 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: +</p><pre class="screen"> +<tt class="prompt">C:\> </tt><b class="userinput"><tt>net use lpt1: \\sambaserver\printershare /user:ntadmin</tt></b> +</pre><p> +should you desire to use the CUPS networked PostScript RIP +functions. (Note that user “<span class="quote">ntadmin</span>” needs to be a valid Samba user +with the required privileges to access the printershare.) This +sets up the printer connection in the traditional +<span class="emphasis"><em>LanMan</em></span> way (not using MS-RPC). +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2940801"></a>Avoiding Critical PostScript Driver Settings on the Client</h3></div></div><div></div></div><p> +Printing works, but there are still problems. Most jobs print +well, some do not print at all. Some jobs have problems with fonts, +which do not 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: +</p><div class="itemizedlist"><ul type="disc"><li><p>Avoid the PostScript Output Option: Optimize +for Speed setting. Use the Optimize for +Portability instead (Adobe PostScript +driver).</p></li><li><p>Don't use the Page Independence: +NO setting. Instead, use Page Independence +YES (CUPS PostScript Driver).</p></li><li><p>Recommended is the True Type Font +Downloading Option: Native True Type over +Automatic and Outline; you +should by all means avoid Bitmap (Adobe +PostScript Driver).</p></li><li><p>Choose True Type Font: Download as Softfont +into Printer over the default Replace by Device +Font (for exotic fonts, you may need to change it back to +get a printout at all) (Adobe).</p></li><li><p>Sometimes you can choose PostScript Language +Level: In case of problems try 2 +instead of 3 (the latest ESP Ghostscript package +handles Level 3 PostScript very well) (Adobe).</p></li><li><p>Say Yes to PostScript +Error Handler (Adobe).</p></li></ul></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2940875"></a>Installing PostScript Driver Files Manually Using rpcclient</h2></div></div><div></div></div><p> +Of course, you can run all the commands that are embedded into the +cupsaddsmb convenience utility yourself, one by one, and hereby upload +and prepare the driver files for future client downloads. +</p><div class="orderedlist"><ol type="1"><li><p>Prepare Samba (A CUPS print queue with the name of the +printer should be there. We are providing the driver +now).</p></li><li><p>Copy all files to + <i class="parameter"><tt>[print$]</tt></i>.</p></li><li><p> +<a class="indexterm" name="id2940926"></a> +Run <b class="command">rpcclient adddriver</b> +(for each client architecture you want to support).</p></li><li><p> +<a class="indexterm" name="id2940950"></a> +Run <b class="command">rpcclient +setdriver.</b></p></li></ol></div><p> +<a class="indexterm" name="id2940972"></a> +<a class="indexterm" name="id2940983"></a> +<a class="indexterm" name="id2940994"></a> +<a class="indexterm" name="id2941005"></a> +<a class="indexterm" name="id2941016"></a> +We are going to do this now. First, read the man page on <i class="parameter"><tt>rpcclient</tt></i> +to get a first idea. Look at all the printing related +subcommands. <b class="command">enumprinters</b>, +<b class="command">enumdrivers</b>, <b class="command">enumports</b>, +<b class="command">adddriver</b>, <b class="command">setdriver</b> are among +the most interesting ones. <i class="parameter"><tt>rpcclient</tt></i> implements an important part of +the MS-RPC protocol. You can use it to query (and command) a Windows NT +(or 200x/XP) PC, too. MS-RPC is used by Windows clients, among other +things, to benefit from the Point'n'Print features. Samba can now +mimic this as well. +</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2941083"></a>A Check of the rpcclient man Page</h3></div></div><div></div></div><p> + First let's check the <i class="parameter"><tt>rpcclient</tt></i> man page. Here are +two relevant passages: +</p><p> +<b class="command">adddriver <arch> <config></b> Execute an +<b class="command">AddPrinterDriver()</b> RPC to install the printer driver information on +the server. The driver files should already exist in the +directory returned by <b class="command">getdriverdir</b>. Possible +values for <i class="parameter"><tt>arch</tt></i> are the same as those for the +<b class="command">getdriverdir</b> command. The +<i class="parameter"><tt>config</tt></i> parameter is defined as follows: +</p><pre class="screen"> +Long Printer Name:\ +Driver File Name:\ +Data File Name:\ +Config File Name:\ +Help File Name:\ +Language Monitor Name:\ +Default Data Type:\ +Comma Separated list of Files +</pre><p>Any empty fields should be enter as the string “<span class="quote">NULL</span>”. </p><p>Samba does not need to support the concept of Print Monitors +since these only apply to local printers whose driver can make use of +a bi-directional link for communication. This field should be “<span class="quote">NULL</span>”. +On a remote NT print server, the Print Monitor for a driver must +already be installed prior to adding the driver or else the RPC will +fail. +</p><p> +<b class="command">setdriver <printername> <drivername></b> +Execute a <b class="command">SetPrinter()</b> command to update the +printer driver associated with an installed printer. The printer +driver must already be correctly installed on the print server. +</p><p>See also the <b class="command">enumprinters</b> and <b class="command">enumdrivers</b> commands for +obtaining a list of installed printers and drivers. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2941229"></a>Understanding the rpcclient man Page</h3></div></div><div></div></div><p> +The <span class="emphasis"><em>exact</em></span> 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 “<span class="quote">\</span>”. Usually you would type the +command in one line without the linebreaks: +<a class="indexterm" name="id2941254"></a> +</p><pre class="screen"> + adddriver "Architecture" \ + "LongPrinterName:DriverFile:DataFile:ConfigFile:HelpFile:\ + LanguageMonitorFile:DataType:ListOfFiles,Comma-separated" +</pre><p> +What the man pages denote as a simple <i class="parameter"><tt><config></tt></i> +keyword, in reality consists of eight 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. +What the man pages names the “<span class="quote">LongPrinterName</span>” in +reality should be called the “<span class="quote">Driver Name</span>”. You can name it +anything you want, as long as you use this name later in the +<b class="command">rpcclient ... setdriver</b> command. For +practical reasons, many name the driver the same as the +printer. +</p><p> +It isn't simple at all. I hear you asking: +“<span class="quote">How do I know which files are "Driver +File</span>”, “<span class="quote">Data File</span>”, “<span class="quote">Config File</span>”, “<span class="quote">Help File</span>” and “<span class="quote">Language +Monitor File" in each case?</span>” 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 <b class="command">rpcclient</b> to see what it tells us and +try to understand the man page more clearly that we've read just +now. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2941358"></a>Producing an Example by Querying a Windows Box</h3></div></div><div></div></div><p> + <a class="indexterm" name="id2941369"></a> + <a class="indexterm" name="id2941380"></a> +We could run <b class="command">rpcclient</b> with a +<b class="command">getdriver</b> or a <b class="command">getprinter</b> +subcommand (in level 3 verbosity) against it. Just sit down at a UNIX or +Linux workstation with the Samba utilities installed, then type the +following command: +</p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>rpcclient -U'user%secret' NT-SERVER -c 'getdriver printername 3'</tt></b> +</pre><p> +From the result it should become clear which is which. Here is an example from my installation: +</p><p> +<a class="indexterm" name="id2941447"></a> + </p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>rpcclient -U'Danka%xxxx' W200xSERVER \ + -c'getdriver "DANKA InfoStream Virtual Printer" 3'</tt></b> + cmd = getdriver "DANKA InfoStream Virtual Printer" 3 + + [Windows NT x86] + Printer Driver Info 3: + Version: [2] + Driver Name: [DANKA InfoStream] + Architecture: [Windows NT x86] + Driver Path: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\PSCRIPT.DLL] + Datafile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\INFOSTRM.PPD] + Configfile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\PSCRPTUI.DLL] + Helpfile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\PSCRIPT.HLP] + + Dependentfiles: [] + Dependentfiles: [] + Dependentfiles: [] + Dependentfiles: [] + Dependentfiles: [] + Dependentfiles: [] + Dependentfiles: [] + + Monitorname: [] + Defaultdatatype: [] + +</pre><p> +Some printer drivers list additional files under the label +<i class="parameter"><tt>Dependentfiles</tt></i> and these would go into the last field +<i class="parameter"><tt>ListOfFiles,Comma-separated</tt></i>. For the CUPS +PostScript drivers, we do not need any (nor would we for the Adobe +PostScript driver), therefore, the field will get a “<span class="quote">NULL</span>” entry. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2941534"></a>Requirements for adddriver and setdriver to Succeed</h3></div></div><div></div></div><p> +>From the man page (and from the quoted output +of <b class="command">cupsaddsmb</b> above) it becomes clear that you +need to have certain conditions in order to make the manual uploading +and initializing of the driver files succeed. The two <b class="command">rpcclient</b> +<a class="indexterm" name="id2941564"></a> +subcommands (<b class="command">adddriver</b> and +<b class="command">setdriver</b>) need to encounter the following +preconditions to complete successfully: +</p><div class="itemizedlist"><ul type="disc"><li><p>You are connected as <a class="indexterm" name="id2941599"></a><i class="parameter"><tt>printer admin</tt></i> or root (this is <span class="emphasis"><em>not</em></span> the “<span class="quote">Printer Operators</span>” group in +NT, but the <span class="emphasis"><em>printer admin</em></span> group as defined in +the <i class="parameter"><tt>[global]</tt></i> section of +<tt class="filename">smb.conf</tt>).</p></li><li><p>Copy all required driver files to +<tt class="filename">\\SAMBA\print$\w32x86</tt> and +<tt class="filename">\\SAMBA\print$\win40</tt> as appropriate. They +will end up in the “<span class="quote">0</span>” respective “<span class="quote">2</span>” subdirectories later. For now, +<span class="emphasis"><em>do not</em></span> put them there, they'll be automatically +used by the <b class="command">adddriver</b> subcommand. (If you use +<b class="command">smbclient</b> to put the driver files into the share, note that you need +to escape the “<span class="quote">$</span>”: <b class="command">smbclient //sambaserver/print\$ -U +root.</b>)</p></li><li><p>The user you're connecting as must be able to write to +the <i class="parameter"><tt>[print$]</tt></i> share and create +subdirectories.</p></li><li><p>The printer you are going to setup for the Windows +clients needs to be installed in CUPS already.</p></li><li><p> + <a class="indexterm" name="id2941729"></a> + <a class="indexterm" name="id2941740"></a> + The CUPS printer must be known to Samba, otherwise the +<b class="command">setdriver</b> subcommand fails with an +NT_STATUS_UNSUCCESSFUL error. To check if the printer is known by +Samba, you may use the <b class="command">enumprinters</b> subcommand to +<b class="command">rpcclient</b>. A long-standing bug prevented a proper update of the +printer list until every smbd process had received a SIGHUP or was +restarted. Remember this in case you've created the CUPS printer just +recently and encounter problems: try restarting +Samba.</p></li></ul></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2941782"></a>Manual Driver Installation in 15 Steps</h3></div></div><div></div></div><p> +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. +</p><div class="procedure"><p class="title"><b>Procedure 19.1. Manual Driver Installation</b></p><ol type="1"><li><p class="title"><b>Install the printer on CUPS.</b></p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>lpadmin -p mysmbtstprn -v socket://10.160.51.131:9100 -E \ + -P canonIR85.ppd</tt></b> +</pre><p> +This installs a printer with the name <i class="parameter"><tt>mysmbtstprn</tt></i> +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. +</p></li><li><p class="title"><b>(Optional) Check if the printer is recognized by Samba.</b></p><p> +<a class="indexterm" name="id2941868"></a> +</p><pre class="screen"> + <tt class="prompt">root# </tt><b class="userinput"><tt>rpcclient -Uroot%xxxx -c 'enumprinters' localhost \ + | grep -C2 mysmbtstprn</tt></b> +flags:[0x800000] +name:[\\kde-bitshop\mysmbtstprn] +description:[\\kde-bitshop\mysmbtstprn,,mysmbtstprn] +comment:[mysmbtstprn] +</pre><p> +This should show the printer in the list. If not, stop and restart +the Samba daemon (smbd), or send a HUP signal: +</p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>kill -HUP `pidof smbd`</tt></b> +</pre><p>Check again. Troubleshoot and repeat until +successful. Note the “<span class="quote">empty</span>” field between the two commas in the +“<span class="quote">description</span>” line. The driver name would appear here if there was one already. You need to know root's Samba password (as set by the +<b class="command">smbpasswd</b> command) for this step and most of the +following steps. Alternately, you can authenticate as one of the +users from the “<span class="quote">write list</span>” as defined in <tt class="filename">smb.conf</tt> for +<i class="parameter"><tt>[print$]</tt></i>. +</p></li><li><p class="title"><b>(Optional) Check if Samba knows a driver for the printer.</b></p><p> + <a class="indexterm" name="id2941980"></a> + <a class="indexterm" name="id2941991"></a> + </p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>rpcclient -Uroot%xxxx -c 'getprinter mysmbtstprn 2' localhost \ + | grep driver </tt></b> +drivername:[] + +<tt class="prompt">root# </tt><b class="userinput"><tt>rpcclient -Uroot%xxxx -c 'getprinter mysmbtstprn 2' localhost \ + | grep -C4 driv</tt></b> +servername:[\\kde-bitshop] +printername:[\\kde-bitshop\mysmbtstprn] +sharename:[mysmbtstprn] +portname:[Samba Printer Port] +drivername:[] +comment:[mysmbtstprn] +location:[] +sepfile:[] +printprocessor:[winprint] + +<tt class="prompt">root# </tt><b class="userinput"><tt>rpcclient -U root%xxxx -c 'getdriver mysmbtstprn' localhost</tt></b> + result was WERR_UNKNOWN_PRINTER_DRIVER + +</pre><p> +None of the three commands shown above should show a driver. +This step was done for the purpose of demonstrating this condition. An +attempt to connect to the printer at this stage will prompt the +message along the lines of: “<span class="quote">The server does not have the required printer +driver installed.</span>” +</p></li><li><p class="title"><b>Put all required driver files into Samba's +[print$].</b></p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>smbclient //localhost/print\$ -U 'root%xxxx' \ + -c 'cd W32X86; \ + put /etc/cups/ppd/mysmbtstprn.ppd mysmbtstprn.PPD; \ + put /usr/share/cups/drivers/cupsui.dll cupsui.dll; \ + put /usr/share/cups/drivers/cupsdrvr.dll cupsdrvr.dll; \ + put /usr/share/cups/drivers/cups.hlp cups.hlp'</tt></b> +</pre><p> +(This command should be entered in one long single +line. Line-breaks and the line-end indicated by “<span class="quote">\</span>” have been inserted +for readability reasons.) This step is <span class="emphasis"><em>required</em></span> +for the next one to succeed. It makes the driver files physically +present in the <i class="parameter"><tt>[print$]</tt></i> 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 “<span class="quote">not installed here</span>” message. +</p></li><li><p class="title"><b>Verify where the driver files are now.</b></p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>ls -l /etc/samba/drivers/W32X86/</tt></b> +total 669 +drwxr-sr-x 2 root ntadmin 532 May 25 23:08 2 +drwxr-sr-x 2 root ntadmin 670 May 16 03:15 3 +-rwxr--r-- 1 root ntadmin 14234 May 25 23:21 cups.hlp +-rwxr--r-- 1 root ntadmin 278380 May 25 23:21 cupsdrvr.dll +-rwxr--r-- 1 root ntadmin 215848 May 25 23:21 cupsui.dll +-rwxr--r-- 1 root ntadmin 169458 May 25 23:21 mysmbtstprn.PPD +</pre><p> +The driver files now are in the W32X86 architecture “<span class="quote">root</span>” of +<i class="parameter"><tt>[print$]</tt></i>. +</p></li><li><p class="title"><b>Tell Samba that these are driver files (<b class="command">adddriver</b>).</b></p><p> +<a class="indexterm" name="id2942214"></a> +</p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>rpcclient -Uroot%xxxx -c `adddriver "Windows NT x86" \ + "mydrivername:cupsdrvr.dll:mysmbtstprn.PPD: \ + cupsui.dll:cups.hlp:NULL:RAW:NULL" \ + localhost</tt></b> +Printer Driver mydrivername successfully installed. +</pre><p> +You cannot repeat this step if it fails. It could fail even +as a result of a simple typo. It will most likely have moved a part of +the driver files into the “<span class="quote">2</span>” 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 printer name; however, in big installations you may use this driver +for a number of printers that obviously have different names, so the +name of the driver is not fixed. +</p></li><li><p class="title"><b>Verify where the driver files are now.</b></p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>ls -l /etc/samba/drivers/W32X86/</tt></b> +total 1 +drwxr-sr-x 2 root ntadmin 532 May 25 23:22 2 +drwxr-sr-x 2 root ntadmin 670 May 16 03:15 3 + +<tt class="prompt">root# </tt><b class="userinput"><tt>ls -l /etc/samba/drivers/W32X86/2</tt></b> +total 5039 +[....] +-rwxr--r-- 1 root ntadmin 14234 May 25 23:21 cups.hlp +-rwxr--r-- 1 root ntadmin 278380 May 13 13:53 cupsdrvr.dll +-rwxr--r-- 1 root ntadmin 215848 May 13 13:53 cupsui.dll +-rwxr--r-- 1 root ntadmin 169458 May 25 23:21 mysmbtstprn.PPD +</pre><p> +Notice how step 6 also moved the driver files to the appropriate +subdirectory. Compare this with the situation after step 5. +</p></li><li><p class="title"><b>(Optional) Verify if Samba now recognizes the driver.</b></p><p> +<a class="indexterm" name="id2942341"></a> +</p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>rpcclient -Uroot%xxxx -c 'enumdrivers 3' \ + localhost | grep -B2 -A5 mydrivername</tt></b> +Printer Driver Info 3: +Version: [2] +Driver Name: [mydrivername] +Architecture: [Windows NT x86] +Driver Path: [\\kde-bitshop\print$\W32X86\2\cupsdrvr.dll] +Datafile: [\\kde-bitshop\print$\W32X86\2\mysmbtstprn.PPD] +Configfile: [\\kde-bitshop\print$\W32X86\2\cupsui.dll] +Helpfile: [\\kde-bitshop\print$\W32X86\2\cups.hlp] +</pre><p> +Remember, this command greps for the name you chose for the +driver in step 6. This command must succeed before you can proceed. +</p></li><li><p>Tell Samba which printer should use these driver files (<b class="command">setdriver</b>).</p><p> +<a class="indexterm" name="id2942406"></a> +</p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>rpcclient -Uroot%xxxx -c 'setdriver mysmbtstprn mydrivername' \ + localhost</tt></b> +Successfully set mysmbtstprn to driver mydrivername +</pre><p> +Since you can bind any printername (print queue) to any driver, this +is a convenient way to setup many queues that use the same +driver. You do not need to repeat all the previous steps for the +setdriver command to succeed. The only preconditions are: +<b class="command">enumdrivers</b> must find the driver and +<b class="command">enumprinters</b> must find the printer. +</p></li><li><p class="title"><b>(Optional) Verify if Samba has recognized this association.</b></p><p> +<a class="indexterm" name="id2942476"></a> +<a class="indexterm" name="id2942487"></a> +<a class="indexterm" name="id2942498"></a> +</p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>rpcclient -Uroot%xxxx -c 'getprinter mysmbtstprn 2' localhost \ + | grep driver</tt></b> +drivername:[mydrivername] + +<tt class="prompt">root# </tt><b class="userinput"><tt>rpcclient -Uroot%xxxx -c 'getprinter mysmbtstprn 2' localhost \ + | grep -C4 driv</tt></b> +servername:[\\kde-bitshop] +printername:[\\kde-bitshop\mysmbtstprn] +sharename:[mysmbtstprn] +portname:[Done] +drivername:[mydrivername] +comment:[mysmbtstprn] +location:[] +sepfile:[] +printprocessor:[winprint] + +<tt class="prompt">root# </tt><b class="userinput"><tt>rpcclient -U root%xxxx -c 'getdriver mysmbtstprn' localhost</tt></b> +[Windows NT x86] +Printer Driver Info 3: + Version: [2] + Driver Name: [mydrivername] + Architecture: [Windows NT x86] + Driver Path: [\\kde-bitshop\print$\W32X86\2\cupsdrvr.dll] + Datafile: [\\kde-bitshop\print$\W32X86\2\mysmbtstprn.PPD] + Configfile: [\\kde-bitshop\print$\W32X86\2\cupsui.dll] + Helpfile: [\\kde-bitshop\print$\W32X86\2\cups.hlp] + Monitorname: [] + Defaultdatatype: [RAW] + Monitorname: [] + Defaultdatatype: [RAW] + +<tt class="prompt">root# </tt><b class="userinput"><tt>rpcclient -Uroot%xxxx -c 'enumprinters' localhost \ + | grep mysmbtstprn</tt></b> + name:[\\kde-bitshop\mysmbtstprn] + description:[\\kde-bitshop\mysmbtstprn,mydrivername,mysmbtstprn] + comment:[mysmbtstprn] + +</pre><p> +<a class="indexterm" name="id2942589"></a> +Compare these results with the ones from steps 2 and 3. Every one of these commands show the driver is installed. Even +the <b class="command">enumprinters</b> command now lists the driver +on the “<span class="quote">description</span>” line. +</p></li><li><p class="title"><b>(Optional) Tickle the driver into a correct +device mode.</b></p><p> +<a class="indexterm" name="id2942629"></a> +You certainly know how to install the driver on the client. In case +you are not particularly familiar with Windows, here is a short +recipe: Browse the Network Neighborhood, go to the Samba server, and look +for the shares. You should see all shared Samba printers. +Double-click on the one in question. The driver should get +installed and the network connection set up. An alternate way is to +open the <span class="guilabel">Printers (and Faxes)</span> folder, right-click on the printer in +question and select <span class="guilabel">Connect</span> or <span class="guilabel">Install</span>. As a result, a new printer +should have appeared in your client's local <span class="guilabel">Printers (and Faxes)</span> +folder, named something like <span class="guilabel">printersharename on Sambahostname</span>. +</p><p> +It is important that you execute this step as a Samba printer admin +(as defined in <tt class="filename">smb.conf</tt>). Here is another method +to do this on Windows XP. It uses a command line, which you may type +into the “<span class="quote">DOS box</span>” (type root's smbpassword when prompted): +</p><pre class="screen"> +<tt class="prompt">C:\> </tt><b class="userinput"><tt>runas /netonly /user:root "rundll32 printui.dll,PrintUIEntry \ + /in /n \\sambaserver\mysmbtstprn"</tt></b> +</pre><p> +Change any printer setting once (like changing <span class="emphasis"><em><span class="guilabel">portrait</span> to + <span class="guilabel">landscape</span></em></span>), click on <span class="guibutton">Apply</span>; change the setting +back. +</p></li><li><p class="title"><b>Install the printer on a client +(Point'n'Print).</b></p><p> +<a class="indexterm" name="id2942767"></a> + </p><pre class="screen"> +<tt class="prompt">C:\> </tt><b class="userinput"><tt>rundll32 printui.dll,PrintUIEntry /in /n “<span class="quote">\\sambaserver\mysmbtstprn</span>”</tt></b> +</pre><p> +If it does not work it could be a permission problem with the +<i class="parameter"><tt>[print$]</tt></i> share. +</p></li><li><p class="title"><b>(Optional) Print a test page.</b></p><pre class="screen"> +<tt class="prompt">C:\> </tt><b class="userinput"><tt>rundll32 printui.dll,PrintUIEntry /p /n "\\sambaserver\mysmbtstprn"</tt></b> +</pre><p> +Then hit [TAB] five times, [ENTER] twice, [TAB] once and [ENTER] again +and march to the printer. +</p></li><li><p class="title"><b>(Recommended) Study the test page.</b></p><p> +Hmmm.... just kidding! By now you know everything about printer +installations and you do not 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" why not just throw it away! +</p></li><li><p class="title"><b>(Obligatory) Enjoy. Jump. Celebrate your +success.</b></p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>echo "Cheeeeerioooooo! Success..." >> /var/log/samba/log.smbd</tt></b> +</pre></li></ol></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2942909"></a>Troubleshooting Revisited</h3></div></div><div></div></div><p> +The setdriver command will fail, if in Samba's mind the queue is not +already there. You had promising messages about the: +</p><pre class="screen"> + Printer Driver ABC successfully installed. +</pre><p> +after the <b class="command">adddriver</b> parts of the procedure? But you are also seeing +a disappointing message like this one? +</p><p><tt class="computeroutput"> + result was NT_STATUS_UNSUCCESSFUL +</tt></p><p> +<a class="indexterm" name="id2942956"></a> +It is not good enough that you +can see the queue in CUPS, using +the <b class="command">lpstat -p ir85wm</b> command. A +bug in most recent versions of Samba prevents the proper update of +the queuelist. The recognition of newly installed CUPS printers +fails unless you restart Samba or send a HUP to all smbd +processes. To verify if this is the reason why Samba does not +execute the <b class="command">setdriver</b> command successfully, check if Samba “<span class="quote">sees</span>” +the printer: +</p><p> +<a class="indexterm" name="id2942993"></a> + </p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>rpcclient transmeta -N -U'root%xxxx' -c 'enumprinters 0'|grep ir85wm</tt></b> + printername:[ir85wm] +</pre><p> +An alternate command could be this: +</p><p> +<a class="indexterm" name="id2943033"></a> + </p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>rpcclient transmeta -N -U'root%secret' -c 'getprinter ir85wm' </tt></b> + cmd = getprinter ir85wm + flags:[0x800000] + name:[\\transmeta\ir85wm] + description:[\\transmeta\ir85wm,ir85wm,DPD] + comment:[CUPS PostScript-Treiber for Windows NT/200x/XP] +</pre><p> +By the way, you can use these commands, plus a few more, of course, +to install drivers on remote Windows NT print servers too! +</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2943077"></a>The Printing <tt class="filename">*.tdb</tt> Files</h2></div></div><div></div></div><p> +<a class="indexterm" name="id2943094"></a> +<a class="indexterm" name="id2943102"></a> +<a class="indexterm" name="id2943113"></a> +<a class="indexterm" name="id2943124"></a> +<a class="indexterm" name="id2943136"></a> +<a class="indexterm" name="id2943147"></a> +<a class="indexterm" name="id2943158"></a> +<a class="indexterm" name="id2943169"></a> +<a class="indexterm" name="id2943180"></a> +<a class="indexterm" name="id2943191"></a> +<a class="indexterm" name="id2943202"></a> +<a class="indexterm" name="id2943214"></a> +<a class="indexterm" name="id2943225"></a> +Some mystery is associated with the series of files with a +tdb suffix appearing in every Samba installation. They are +<tt class="filename">connections.tdb</tt>, +<tt class="filename">printing.tdb</tt>, +<tt class="filename">share_info.tdb</tt>, +<tt class="filename">ntdrivers.tdb</tt>, +<tt class="filename">unexpected.tdb</tt>, +<tt class="filename">brlock.tdb</tt>, +<tt class="filename">locking.tdb</tt>, +<tt class="filename">ntforms.tdb</tt>, +<tt class="filename">messages.tdb</tt> , +<tt class="filename">ntprinters.tdb</tt>, +<tt class="filename">sessionid.tdb</tt> and +<tt class="filename">secrets.tdb</tt>. What is their purpose? +</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2943322"></a>Trivial Database Files</h3></div></div><div></div></div><p> +<a class="indexterm" name="id2943333"></a> +A Windows NT (print) server keeps track of all information needed to serve +its duty toward its clients by storing entries in the Windows +registry. Client queries are answered by reading from the registry, +Administrator or user configuration settings that are saved by writing into +the registry. Samba and UNIX obviously do not have such a +Registry. Samba instead keeps track of all client related information in a +series of <tt class="filename">*.tdb</tt> files. (TDB = Trivial Data +Base). These are often located in <tt class="filename">/var/lib/samba/</tt> +or <tt class="filename">/var/lock/samba/</tt>. The printing related files +are <tt class="filename">ntprinters.tdb</tt>, +<tt class="filename">printing.tdb</tt>,<tt class="filename">ntforms.tdb</tt> and +<tt class="filename">ntdrivers.tdb</tt>. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2943400"></a>Binary Format</h3></div></div><div></div></div><p> +<tt class="filename">*.tdb</tt> files are not human readable. They are +written in a binary format. “<span class="quote">Why not ASCII?</span>”, you may ask. “<span class="quote">After all, +ASCII configuration files are a good and proven tradition on UNIX.</span>” +The reason for this design decision by the Samba team is mainly +performance. Samba needs to be fast; it runs a separate +<b class="command">smbd</b> process for each client connection, in some +environments many thousands of them. Some of these smbds might need to +write-access the same <tt class="filename">*.tdb</tt> file <span class="emphasis"><em>at the +same time</em></span>. The file format of Samba's +<tt class="filename">*.tdb</tt> files allows for this provision. Many smbd +processes may write to the same <tt class="filename">*.tdb</tt> file at the +same time. This wouldn't be possible with pure ASCII files. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2943470"></a>Losing <tt class="filename">*.tdb</tt> Files</h3></div></div><div></div></div><p> +It is very important that all <tt class="filename">*.tdb</tt> files remain +consistent over all write and read accesses. However, it may happen +that these files <span class="emphasis"><em>do</em></span> get corrupted. (A +<b class="command">kill -9 `pidof smbd'</b> 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 +<tt class="filename">*.tdb</tt> files may be the only option. After that you need to +re-create all print-related setup or you have made a +backup of the <tt class="filename">*.tdb</tt> files in time. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2943528"></a>Using <b class="command">tdbbackup</b></h3></div></div><div></div></div><p> +<a class="indexterm" name="id2943544"></a> +<a class="indexterm" name="id2943558"></a> +Samba ships with a little utility that helps the root user of your +system to backup your <tt class="filename">*.tdb</tt> files. If you run it +with no argument, it prints a usage message: +</p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>tdbbackup</tt></b> + Usage: tdbbackup [options] <fname...> + + Version:3.0a + -h this help message + -s suffix set the backup suffix + -v verify mode (restore if corrupt) + +</pre><p> +Here is how I backed up my <tt class="filename">printing.tdb</tt> file: +</p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>ls</tt></b> +. browse.dat locking.tdb ntdrivers.tdb printing.tdb +.. share_info.tdb connections.tdb messages.tdb ntforms.tdb +printing.tdbkp unexpected.tdb brlock.tdb gmon.out namelist.debug +ntprinters.tdb sessionid.tdb + +<tt class="prompt">root# </tt><b class="userinput"><tt>tdbbackup -s .bak printing.tdb</tt></b> + printing.tdb : 135 records + +<tt class="prompt">root# </tt><b class="userinput"><tt>ls -l printing.tdb*</tt></b> + -rw------- 1 root root 40960 May 2 03:44 printing.tdb + -rw------- 1 root root 40960 May 2 03:44 printing.tdb.bak + +</pre></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2943673"></a>CUPS Print Drivers from Linuxprinting.org</h2></div></div><div></div></div><p> +<a class="indexterm" name="id2943683"></a> +CUPS ships with good support for HP LaserJet-type printers. You can +install the generic driver as follows: +</p><p> +<a class="indexterm" name="id2943698"></a> + </p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>lpadmin -p laserjet4plus -v parallel:/dev/lp0 -E -m laserjet.ppd</tt></b> +</pre><p> +The <tt class="option">-m</tt> switch will retrieve the +<tt class="filename">laserjet.ppd</tt> from the standard repository for +not-yet-installed-PPDs, which CUPS typically stores in +<tt class="filename">/usr/share/cups/model</tt>. Alternately, you may use +<tt class="option">-P /path/to/your.ppd</tt>. +</p><p> +The generic <tt class="filename">laserjet.ppd,</tt> however, does not support every special option +for every LaserJet-compatible model. It constitutes a sort of “<span class="quote">least common +denominator</span>” of all the models. If for some reason +you must pay for the commercially available ESP Print Pro drivers, your +first move should be to consult the database on <ulink url="http://www.linuxprinting.org/printer_list.cgi">http://www.linuxprinting.org/printer_list.cgi</ulink>. +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 <b class="command">foomatic-rip</b> utility. +</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> +<a class="indexterm" name="id2943800"></a> +The former <b class="command">cupsomatic</b> concept is now being replaced by the new +successor, a much +more powerful <b class="command">foomatic-rip</b>. +<b class="command">cupsomatic</b> is no longer maintained. Here is the new URL +to the Foomatic-3.0 database: <ulink url="http://www.linuxprinting.org/driver_list.cgi">http://www.linuxprinting.org/driver_list.cgi</ulink>. +If you upgrade to <b class="command">foomatic-rip</b>, remember to also upgrade to the +new-style PPDs for your Foomatic-driven printers. foomatic-rip will +not work with PPDs generated for the old <b class="command">cupsomatic</b>. The new-style +PPDs are 100% compliant to the Adobe PPD specification. They are +also intended to be used by Samba and the cupsaddsmb utility, to +provide the driver files for the Windows clients! +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2943860"></a>foomatic-rip and Foomatic Explained</h3></div></div><div></div></div><p> +<a class="indexterm" name="id2943871"></a> +<a class="indexterm" name="id2943880"></a> +Nowadays, most Linux distributions rely on the utilities of Linuxprinting.org +to create their printing-related software (which, by the way, 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 that +allows for an easy update of drivers and PPDs for all supported +models, all spoolers, all operating systems, and all package formats +(because there is none). Its history goes back a few years. +</p><p> +Recently, Foomatic has achieved the astonishing milestone of <ulink url="http://www.linuxprinting.org/printer_list.cgi?make=Anyone">1000 +listed</ulink> 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 <ulink url="http://www.linuxprinting.org/foomatic.html">Foomatic</ulink> +database. Currently there are <ulink url="http://www.linuxprinting.org/driver_list.cgi">245 drivers</ulink> +in the database. Many drivers support various models, and many models +may be driven by different drivers its your choice! +</p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2943935"></a>690 “<span class="quote">Perfect</span>” Printers</h4></div></div><div></div></div><p> +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 by CUPS to perfection, by using +their own manufacturer-provided Windows-PPD), and that a +multifunctional device never qualifies as working perfectly if it +does not also scan and copy and fax under GNU/Linux then this is a +truly astonishing achievement! Three 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. +</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2943975"></a>How the Printing HOWTO Started It All</h4></div></div><div></div></div><p> +A few years ago <ulink url="http://www2.picante.com:81/~gtaylor/">Grant Taylor</ulink> +started it all. The roots of today's Linuxprinting.org are in the +first <ulink url="http://www.linuxprinting.org/foomatic2.9/howto/">Linux Printing +HOWTO</ulink> that 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 (to a scientist, printing is +“<span class="quote">applying a structured deposition of distinct patterns of ink or toner +particles on paper substrates</span>”, he started to +build in a little Postgres database with information 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. +</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2944020"></a>Foomatic's Strange Name</h4></div></div><div></div></div><p> +<a class="indexterm" name="id2944031"></a> +“<span class="quote">Why the funny name?</span>” 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 (<i class="parameter"><tt>pstoraster</tt></i>, derived from +Ghostscript). On the other hand, CUPS provided brilliant support for +<span class="emphasis"><em>controlling</em></span> all printer options through +standardized and well-defined PPD files (PostScript Printers +Description files). Plus, CUPS was designed to be easily extensible. +</p><p> +Taylor already had in his database a respectable compilation +of facts about many more printers and the Ghostscript “<span class="quote">drivers</span>” +they run with. His idea, to generate PPDs from the database information +and use them to make standard Ghostscript filters work within CUPS, +proved to work very well. It also killed several birds with one +stone: +</p><div class="itemizedlist"><ul type="disc"><li><p>It made all current and future Ghostscript filter +developments available for CUPS.</p></li><li><p>It made available a lot of additional printer models +to CUPS users (because often the traditional Ghostscript way of +printing was the only one available).</p></li><li><p>It gave all the advanced CUPS options (Web interface, +GUI driver configurations) to users wanting (or needing) to use +Ghostscript filters.</p></li></ul></div></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2944109"></a>cupsomatic, pdqomatic, lpdomatic, directomatic</h4></div></div><div></div></div><p> +<a class="indexterm" name="id2944121"></a> +<a class="indexterm" name="id2944129"></a> +<a class="indexterm" name="id2944137"></a> +CUPS worked through a quickly-hacked up filter script named <ulink url="http://www.linuxprinting.org/download.cgi?filename=cupsomatic&show=0">cupsomatic.</ulink> +cupsomatic ran the printfile through Ghostscript, constructing +automatically the rather complicated command line needed. It just +needed 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, Taylor implemented within a few +days a similar thing for two other spoolers. Names chosen for the +config-generator scripts were <ulink url="http://www.linuxprinting.org/download.cgi?filename=lpdomatic&show=0">PDQ-O-Matic</ulink> +(for PDQ) and <ulink url="http://www.linuxprinting.org/download.cgi?filename=lpdomatic&show=0">LPD-O-Matic</ulink> +(for you guessed it LPD); the configuration here didn't use PPDs +but other spooler-specific files. +</p><p> +From late summer of that year, <ulink url="http://www.linuxprinting.org/till/">Till Kamppeter</ulink> +started to put work into the database. Kamppeter had been newly employed by +<ulink url="http://www.mandrakesoft.com/">MandrakeSoft</ulink> to +convert its printing system over to CUPS, after they had seen his +<ulink url="http://www.fltk.org/">FLTK</ulink>-based <ulink url="http://cups.sourceforge.net/xpp/">XPP</ulink> (a GUI frontend to +the CUPS lp-command). He added a huge amount of new information and new +printers. He also developed the support for other spoolers, like +<ulink url="http://ppr.sourceforge.net/">PPR</ulink> (via ppromatic), +<ulink url="http://sourceforge.net/projects/lpr/">GNUlpr</ulink> and +<ulink url="http://www.lprng.org/">LPRng</ulink> (both via an extended +lpdomatic) and spoolerless printing (<ulink url="http://www.linuxprinting.org/download.cgi?filename=directomatic&show=0">directomatic</ulink>). +</p><p> +So, to answer your question: “<span class="quote">Foomatic</span>” is the general name for all +the overlapping code and data behind the “<span class="quote">*omatic</span>” scripts. +Foomatic, up to versions 2.0.x, required (ugly) Perl data structures +attached to Linuxprinting.org PPDs for CUPS. It had a different +“<span class="quote">*omatic</span>” script for every spooler, as well as different printer +configuration files. +</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2944302"></a>The <span class="emphasis"><em>Grand Unification</em></span> Achieved</h4></div></div><div></div></div><p> +<a class="indexterm" name="id2944318"></a> +This has all changed in Foomatic versions 2.9 (beta) and released as +“<span class="quote">stable</span>” 3.0. It has now achieved the convergence of all *omatic +scripts and is called the <ulink url="http://www.linuxprinting.org/foomatic2.9/download.cgi?filename=foomatic-rip&show=0">foomatic-rip.</ulink> +This single script is the unification of the previously different +spooler-specific *omatic scripts. foomatic-rip is used by all the +different spoolers alike and because it can read PPDs (both the +original PostScript printer PPDs and the Linuxprinting.org-generated +ones), all of a sudden all supported spoolers can 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. +</p><p> +Also, the New Generation of Linuxprinting.org PPDs no longer contains +Perl data structures. 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 remember to generate a new-version set of PPDs +via the new <ulink url="http://www.linuxprinting.org/download/foomatic/foomatic-db-engine-3.0.0beta1.tar.gz">foomatic-db-engine!</ulink> +Individual users just need to generate a single new PPD specific to +their model by <ulink url="http://www.linuxprinting.org/kpfeifle/LinuxKongress2002/Tutorial/II.Foomatic-User/II.tutorial-handout-foomatic-user.html">following +the steps</ulink> outlined in the Foomatic tutorial or in this chapter. This new development is truly amazing. +</p><p> +foomatic-rip is a very clever wrapper around the need to run +Ghostscript with a different syntax, options, device selections, and/or filters for each different printer +or 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 innovative features of +the Foomatic concept may surprise users. It will support custom paper +sizes for many printers and will support 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). +</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2944417"></a>Driver Development Outside</h4></div></div><div></div></div><p> +Most driver development itself does not happen within +Linuxprinting.org. Drivers are written by independent maintainers. +Linuxprinting.org just pools all the information 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. +</p><p> +Speaking of the different driver development groups, most of +the work is currently done in three projects. These are: +</p><div class="itemizedlist"><ul type="disc"><li><p><ulink url="http://www-124.ibm.com/developerworks/oss/linux/projects/omni/">Omni</ulink> + a free software project by IBM that tries to convert their printer +driver knowledge from good-ol' OS/2 times into a modern, modular, +universal driver architecture for Linux/UNIX (still beta). This +currently supports 437 models.</p></li><li><p><ulink url="http://hpinkjet.sf.net/">HPIJS</ulink> +a free software project by HP to provide the support for their own +range of models (very mature, printing in most cases is perfect and +provides true photo quality). This currently supports 369 +models.</p></li><li><p><ulink url="http://gimp-print.sf.net/">Gimp-Print</ulink> a free software +effort, started by Michael Sweet (also lead developer for CUPS), now +directed by Robert Krawitz, which has achieved an amazing level of +photo print quality (many Epson users swear that its quality is +better than the vendor drivers provided by Epson for the Microsoft +platforms). This currently supports 522 models.</p></li></ul></div></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2944507"></a>Forums, Downloads, Tutorials, Howtos also for Mac OS X and Commercial UNIX</h4></div></div><div></div></div><p> +Linuxprinting.org today is the one-stop shop to download printer +drivers. Look for printer information and <ulink url="http://www.linuxprinting.org//kpfeifle/LinuxKongress2002/Tutorial/">tutorials</ulink> +or solve printing problems in its popular <ulink url="http://www.linuxprinting.org/newsportal/">forums.</ulink> This forum +it's not just for GNU/Linux users, but admins of <ulink url="http://www.linuxprinting.org/macosx/">commercial UNIX +systems</ulink> are also going there, and the relatively new <ulink url="http://www.linuxprinting.org/newsportal/thread.php3?name=linuxprinting.macosx.general">Mac +OS X forum</ulink> has turned out to be one of the most frequented +forums after only a few weeks. +</p><p> +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 Kamppeter (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 Foomatic project. +</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> +Till Kamppeter from MandrakeSoft is doing an excellent job in his +spare time to maintain Linuxprinting.org and Foomatic. So if you use +it often, please send him a note showing your appreciation. +</p></div></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2944580"></a>Foomatic Database-Generated PPDs</h4></div></div><div></div></div><p> +The Foomatic database is an amazing piece of ingenuity in itself. Not +only does it keep the printer and driver information, but 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 do not 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 <i class="parameter"><tt>*cupsFilter</tt></i> +keyword. It tells the CUPS daemon how to proceed with the PostScript +print file (old-style Foomatic-PPDs named the +cupsomatic filter script, while the new-style +PPDs are now call 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 marvelous <ulink url="http://printing.kde.org/overview/kprinter.phtml">kprinter,</ulink> +or the GNOME <ulink url="http://gtklp.sourceforge.net/">gtklp,</ulink> xpp and the CUPS +Web interface) read the PPD as well and use this information to present +the available settings to the user as an intuitive menu selection. +</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2944657"></a>foomatic-rip and Foomatic-PPD Download and Installation</h3></div></div><div></div></div><p> +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 +<b class="command">foomatic-rip</b> utility. Going directly to +Linuxprinting.org ensures that you get the latest driver/PPD files): +</p><div class="itemizedlist"><ul type="disc"><li><p>Open your browser at the Linuxprinting.org printer list<ulink url="http://www.linuxprinting.org/printer_list.cgi">page.</ulink> +</p></li><li><p>Check the complete list of printers in the +<ulink url="http://www.linuxprinting.org/printer_list.cgi?make=Anyone">database.</ulink>. +</p></li><li><p>Select your model and click on the link. +</p></li><li><p>You'll arrive at a page listing all drivers working with this +model (for all printers, there will always be <span class="emphasis"><em>one</em></span> +recommended driver. Try this one first). +</p></li><li><p>In our case (HP LaserJet 4 Plus), we'll arrive at the default driver for the +<ulink url="http://www.linuxprinting.org/show_printer.cgi?recnum=HP-LaserJet_4_Plus">HP-LaserJet 4 Plus.</ulink> +</p></li><li><p>The recommended driver is ljet4.</p></li><li><p>Several links are provided here. You should visit them all if you +are not familiar with the Linuxprinting.org database. +</p></li><li><p>There is a link to the database page for the +<ulink url="http://www.linuxprinting.org/show_driver.cgi?driver=ljet4">ljet4.</ulink> +On the driver's page, you'll find important and detailed information +about how to use that driver within the various available +spoolers.</p></li><li><p>Another link may lead you to the homepage of the +driver author or the driver.</p></li><li><p>Important links are the ones that provide hints with +setup instructions for <ulink url="http://www.linuxprinting.org/cups-doc.html">CUPS</ulink>, +<ulink url="http://www.linuxprinting.org/pdq-doc.html">PDQ</ulink>, +<ulink url="http://www.linuxprinting.org/lpd-doc.html">LPD, LPRng and GNUlpr</ulink>) +as well as <ulink url="http://www.linuxprinting.org/ppr-doc.html">PPR</ulink> +or “<span class="quote">spooler-less</span>” <ulink url="http://www.linuxprinting.org/direct-doc.html">printing.</ulink> +</p></li><li><p>You can view the PPD in your browser through this link: +<ulink url="http://www.linuxprinting.org/ppd-o-matic.cgi?driver=ljet4&printer=HP-LaserJet_4_Plus&show=1">http://www.linuxprinting.org/ppd-o-matic.cgi?driver=ljet4&printer=HP-LaserJet_4_Plus&show=1</ulink> +</p></li><li><p>Most importantly, you can also generate and download +the <ulink url="http://www.linuxprinting.org/ppd-o-matic.cgi?driver=ljet4&printer=HP-LaserJet_4_Plus&show=0">PPD.</ulink> +</p></li><li><p>The PPD contains all the information needed to use our +model and the driver; once installed, this works transparently +for the user. Later you'll only need to choose resolution, paper size, +and so on from the Web-based menu, or from the print dialog GUI, or from +the command line.</p></li><li><p>If you ended up on the drivers +<ulink url="http://www.linuxprinting.org/show_driver.cgi?driver=ljet4">page</ulink> +you can choose to use the “<span class="quote">PPD-O-Matic</span>” online PPD generator +program.</p></li><li><p>Select the exact model and check either <span class="guilabel">Download</span> or +<span class="guilabel">Display PPD file</span> and click <span class="guilabel">Generate PPD file</span>.</p></li><li><p>If you save the PPD file from the browser view, please +do not use cut and paste (since it could possibly damage line endings +and tabs, which makes the PPD likely to fail its duty), but use <span class="guimenuitem">Save +as...</span> in your browser's menu. (It is best to use the <span class="guilabel">Download</span> option +directly from the Web page).</p></li><li><p>Another interesting part on each driver page is +the <span class="guimenuitem">Show execution details</span> button. If you +select your printer model and click on that button, +a complete Ghostscript command line will be displayed, enumerating all options +available for that combination of driver and printer model. This is a great way to +“<span class="quote">learn Ghostscript by doing</span>”. It is also an excellent cheat sheet +for all experienced users who need to re-construct a good command line +for that damn printing script, but can't remember the exact +syntax. </p></li><li><p>Some time during your visit to Linuxprinting.org, save +the PPD to a suitable place on your harddisk, say +<tt class="filename">/path/to/my-printer.ppd</tt> (if you prefer to install +your printers with the help of the CUPS Web interface, save the PPD to +the <tt class="filename">/usr/share/cups/model/</tt> path and restart +cupsd).</p></li><li><p>Then install the printer with a suitable command line, +like this: +</p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>lpadmin -p laserjet4plus -v parallel:/dev/lp0 -E \ + -P path/to/my-printer.ppd</tt></b> +</pre></li><li><p>For all the new-style “<span class="quote">Foomatic-PPDs</span>” +from Linuxprinting.org, you also need a special CUPS filter named +foomatic-rip. +</p></li><li><p>The foomatic-rip Perlscript itself also makes some +interesting <ulink url="http://www.linuxprinting.org/foomatic2.9/download.cgi?filename=foomatic-rip&show=1">reading</ulink> +because it is well documented by Kamppeter's inline comments (even +non-Perl hackers will learn quite a bit about printing by reading +it).</p></li><li><p>Save foomatic-rip either directly in +<tt class="filename">/usr/lib/cups/filter/foomatic-rip</tt> or somewhere in +your $PATH (and remember to make it world-executable). Again, +do not save by copy and paste but use the appropriate link or the +<span class="guimenuitem">Save as...</span> menu item in your browser.</p></li><li><p>If you save foomatic-rip in your $PATH, create a symlink: +</p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>cd /usr/lib/cups/filter/ ; ln -s `which foomatic-rip'</tt></b> +</pre><p> +</p><p> +CUPS will discover this new available filter at startup after restarting +cupsd.</p></li></ul></div><p> +Once you print to a print queue 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 and 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 the printer driver exactly how the resulting raster +data should look and which printer commands to embed into the +data stream. You need: +</p><div class="itemizedlist"><ul type="disc"><li><p>A “<span class="quote">foomatic+something</span>” PPD but this is not enough +to print with CUPS (it is only <span class="emphasis"><em>one</em></span> important +component).</p></li><li><p>The <i class="parameter"><tt>foomatic-rip</tt></i> filter script (Perl) in +<tt class="filename">/usr/lib/cups/filters/</tt>.</p></li><li><p>Perl to make foomatic-rip run.</p></li><li><p>Ghostscript (because it is doing the main work, +controlled by the PPD/foomatic-rip combo) to produce the raster data +fit for your printer model's consumption.</p></li><li><p>Ghostscript <span class="emphasis"><em>must</em></span> (depending on +the driver/model) contain support for a certain device representing +the selected driver for your model (as shown by <b class="command">gs + -h</b>).</p></li><li><p>foomatic-rip needs a new version of PPDs (PPD versions +produced for cupsomatic do not work with +foomatic-rip).</p></li></ul></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2945207"></a>Page Accounting with CUPS</h2></div></div><div></div></div><p> +<a class="indexterm" name="id2945218"></a> +Often there are questions regarding print quotas where Samba users +(that is, Windows clients) should not be able to print beyond a +certain number 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 <span class="emphasis"><em>or</em></span> unfiltered) and hand it over to this +printing subsystem. +</p><p> +Of course one could hack things with one's own scripts. But then +there is CUPS. CUPS supports quotas that can be based on the size of +jobs or on the number of pages or both, and span any time +period you want. +</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2945248"></a>Setting Up Quotas</h3></div></div><div></div></div><p> +<a class="indexterm" name="id2945260"></a> +This is an example command of how root would set a print quota in CUPS, +assuming an existing printer named “<span class="quote">quotaprinter</span>”: +</p><p> +<a class="indexterm" name="id2945281"></a> + </p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>lpadmin -p quotaprinter -o job-quota-period=604800 \ + -o job-k-limit=1024 -o job-page-limit=100</tt></b> +</pre><p> +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). +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2945318"></a>Correct and Incorrect Accounting</h3></div></div><div></div></div><p> +For CUPS to count correctly, the printfile needs to pass the CUPS +pstops filter, otherwise it uses a dummy count of “<span class="quote">one</span>”. Some +print files do not pass it (e.g., image files) but then those are mostly one- +page jobs anyway. This also means that proprietary drivers for the +target printer running on the client computers and CUPS/Samba, which +then spool these files as “<span class="quote">raw</span>” (i.e., leaving them untouched, not +filtering them), will be counted as one-pagers too! +</p><p> +You need to send PostScript from the clients (i.e., run a PostScript +driver there) to have the chance to get accounting done. If the +printer is a non-PostScript model, you need to let CUPS do the job to +convert the file to a print-ready format for the target printer. This +is currently working for about a thousand different printer models. +Linuxprinting has a driver +<ulink url="http://www.linuxprinting.org/printer_list.cgi">list.</ulink> +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2945366"></a>Adobe and CUPS PostScript Drivers for Windows Clients</h3></div></div><div></div></div><p> +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 <b class="command">pstops</b> filter on the CUPS/Samba side, and +therefore was not counted correctly (the reason is that it often, +depending on the PPD being used, wrote a PJL-header in front of +the real PostScript which caused CUPS to skip <b class="command">pstops</b> and go directly +to the <b class="command">pstoraster</b> stage). +</p><p> +From CUPS 1.1.16 onward, you can use the CUPS PostScript Driver for +Windows NT/200x/XP clients (which is tagged in the download area of +<tt class="filename">http://www.cups.org/</tt> as the <tt class="filename">cups-samba-1.1.16.tar.gz</tt> +package). It does <span class="emphasis"><em>not</em></span> work for Windows 9x/ME clients, but it guarantees: +</p><div class="itemizedlist"><ul type="disc"><li><p> <a class="indexterm" name="id2945443"></a> To not write a PJL-header.</p></li><li><p>To still read and support all PJL-options named in the +driver PPD with its own means.</p></li><li><p>That the file will pass through the <b class="command">pstops</b> filter +on the CUPS/Samba server.</p></li><li><p>To page-count correctly the print file.</p></li></ul></div><p> +You can read more about the setup of this combination in the man page +for <b class="command">cupsaddsmb</b> (which is only present with CUPS installed, and only +current from CUPS 1.1.16). +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2945495"></a>The page_log File Syntax</h3></div></div><div></div></div><p> +<a class="indexterm" name="id2945506"></a> +These are the items CUPS logs in the <tt class="filename">page_log</tt> for every +page of a job: +</p><div class="itemizedlist"><ul type="disc"><li><p>Printer name</p></li><li><p>User name</p></li><li><p>Job ID</p></li><li><p>Time of printing</p></li><li><p>The page number</p></li><li><p>The number of copies</p></li><li><p>A billing information string (optional)</p></li><li><p>The host that sent the job (included since version 1.1.19)</p></li></ul></div><p> +Here is an extract of my CUPS server's <tt class="filename">page_log</tt> file to illustrate the +format and included items: +</p><pre class="screen"> +tec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 1 3 #marketing 10.160.50.13 +tec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 2 3 #marketing 10.160.50.13 +tec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 3 3 #marketing 10.160.50.13 +tec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 4 3 #marketing 10.160.50.13 +Dig9110 boss 402 [22/Apr/2003:10:33:22 +0100] 1 440 finance-dep 10.160.51.33 +</pre><p> +This was job ID <i class="parameter"><tt>401</tt></i>, printed on <i class="parameter"><tt>tec_IS2027</tt></i> +by user <i class="parameter"><tt>kurt</tt></i>, a 64-page job printed in three copies and billed to +<i class="parameter"><tt>#marketing</tt></i>, sent from IP address <tt class="constant">10.160.50.13.</tt> + The next job had ID <i class="parameter"><tt>402</tt></i>, was sent by user <i class="parameter"><tt>boss</tt></i> +from IP address <tt class="constant">10.160.51.33</tt>, printed from one page 440 copies and +is set to be billed to <i class="parameter"><tt>finance-dep</tt></i>. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2945665"></a>Possible Shortcomings</h3></div></div><div></div></div><p> +What flaws or shortcomings are there with this quota system? +</p><div class="itemizedlist"><ul type="disc"><li><p>The ones named above (wrongly logged job in case of +printer hardware failure, and so on).</p></li><li><p>In reality, CUPS counts the job pages that are being +processed in <span class="emphasis"><em>software</em></span> (that is, going through the +RIP) rather than the physical sheets successfully leaving the +printing device. Thus if there is a jam while printing the fifth sheet out +of a thousand and the job is aborted by the printer, the page count will +still show the figure of a thousand for that job.</p></li><li><p>All quotas are the same for all users (no flexibility +to give the boss a higher quota than the clerk) and no support for +groups.</p></li><li><p>No means to read out the current balance or the +“<span class="quote">used-up</span>” number of current quota.</p></li><li><p>A user having used up 99 sheets of a 100 quota will +still be able to send and print a thousand sheet job.</p></li><li><p>A user being denied a job because of a filled-up quota +does not get a meaningful error message from CUPS other than +“<span class="quote">client-error-not-possible</span>”.</p></li></ul></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2945745"></a>Future Developments</h3></div></div><div></div></div><p> +This is the best system currently available, and there are huge +improvements under development for CUPS 1.2: +</p><div class="itemizedlist"><ul type="disc"><li><p>Page counting will go into the backends (these talk +directly to the printer and will increase the count in sync with the +actual printing process; thus, a jam at the fifth sheet will lead to a +stop in the counting).</p></li><li><p>Quotas will be handled more flexibly.</p></li><li><p>Probably there will be support for users to inquire +about their accounts in advance.</p></li><li><p>Probably there will be support for some other tools +around this topic.</p></li></ul></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2945799"></a>Additional Material</h2></div></div><div></div></div><p> +A printer queue with <span class="emphasis"><em>no</em></span> PPD associated to it is a +“<span class="quote">raw</span>” printer and all files will go directly there as received by the +spooler. The exceptions are file types <i class="parameter"><tt>application/octet-stream</tt></i> +that need passthrough feature enabled. “<span class="quote">Raw</span>” queues do not do any +filtering at all, they hand the file directly to the CUPS backend. +This backend is responsible for sending the data to the device +(as in the “<span class="quote">device URI</span>” notation: <tt class="filename">lpd://, socket://, +smb://, ipp://, http://, parallel:/, serial:/, usb:/</tt>, and so on). +</p><p> +cupsomatic/Foomatic are <span class="emphasis"><em>not</em></span> native CUPS drivers +and they do not ship with CUPS. They are a third party add-on +developed at Linuxprinting.org. As such, they are a brilliant hack to +make all models (driven by Ghostscript drivers/filters in traditional +spoolers) also work via CUPS, with the same (good or bad!) quality as +in these other spoolers. <i class="parameter"><tt>cupsomatic</tt></i> is only a vehicle to execute a +Ghostscript commandline at that stage in the CUPS filtering chain, +where normally the native CUPS <i class="parameter"><tt>pstoraster</tt></i> filter would kick +in. cupsomatic bypasses pstoraster, kidnaps the printfile from CUPS +away and redirects it to go through Ghostscript. CUPS accepts this, +because the associated cupsomatic/foomatic-PPD specifies: + +</p><pre class="programlisting"> + *cupsFilter: "application/vnd.cups-postscript 0 cupsomatic" +</pre><p> + +This line persuades CUPS to hand the file to cupsomatic, once it has +successfully converted it to the MIME type +<i class="parameter"><tt>application/vnd.cups-postscript</tt></i>. This conversion will not happen for +Jobs arriving from Windows that are auto-typed +<i class="parameter"><tt>application/octet-stream</tt></i>, with the according changes in +<tt class="filename">/etc/cups/mime.types</tt> in place. +</p><p> +CUPS is widely configurable and flexible, even regarding its filtering +mechanism. Another workaround in some situations would be to have in +<tt class="filename">/etc/cups/mime.types</tt> entries as follows: + +</p><pre class="programlisting"> + application/postscript application/vnd.cups-raw 0 - + application/vnd.cups-postscript application/vnd.cups-raw 0 - +</pre><p> + +This would prevent all PostScript files from being filtered (rather, +they will through the virtual <span class="emphasis"><em>nullfilter</em></span> +denoted with “<span class="quote">-</span>”). This could only be useful for PS printers. If you +want to print PS code on non-PS printers (provided they support ASCII +text printing), an entry as follows could be useful: + +</p><pre class="programlisting"> + */* application/vnd.cups-raw 0 - +</pre><p> + +and would effectively send <span class="emphasis"><em>all</em></span> files to the +backend without further processing. +</p><p> +You could have the following entry: + +</p><pre class="programlisting"> +application/vnd.cups-postscript application/vnd.cups-raw 0 \ + my_PJL_stripping_filter +</pre><p> + +You will need to write a <i class="parameter"><tt>my_PJL_stripping_filter</tt></i> +(which could be a shell script) that parses the PostScript and removes the +unwanted PJL. This needs to conform to CUPS filter design +(mainly, receive and pass the parameters printername, job-id, +username, jobtitle, copies, print options and possibly the +filename). It is installed as world executable into +<tt class="filename">/usr/lib/cups/filters/</tt> and is called by CUPS +if it encounters a MIME type <i class="parameter"><tt>application/vnd.cups-postscript</tt></i>. +</p><p> +CUPS can handle <i class="parameter"><tt>-o job-hold-until=indefinite</tt></i>. +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 (such as when the operators often need +to load the proper paper type before running the 10,000 page job +requested by marketing for the mailing, and so on). +</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2946030"></a>Auto-Deletion or Preservation of CUPS Spool Files</h2></div></div><div></div></div><p> +Samba print files pass through two spool directories. One is the +incoming directory managed by Samba, (set in the +<a class="indexterm" name="id2946043"></a><i class="parameter"><tt>path</tt></i> = /var/spool/samba +directive in the <i class="parameter"><tt>[printers]</tt></i> section of +<tt class="filename">smb.conf</tt>). The other is the spool directory of +your UNIX print subsystem. For CUPS it is normally +<tt class="filename">/var/spool/cups/</tt>, as set by the <tt class="filename">cupsd.conf</tt> +directive <tt class="filename">RequestRoot /var/spool/cups</tt>. +</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2946094"></a>CUPS Configuration Settings Explained</h3></div></div><div></div></div><p> +Some important parameter settings in the CUPS configuration file +<tt class="filename">cupsd.conf</tt> are: +</p><div class="variablelist"><dl><dt><span class="term">PreserveJobHistory Yes</span></dt><dd><p> +This keeps some details of jobs in cupsd's mind (well it keeps the +c12345, c12346, and so on, files in the CUPS spool directory, which do a +similar job as the old-fashioned BSD-LPD control files). This is set +to “<span class="quote">Yes</span>” as a default. +</p></dd><dt><span class="term">PreserveJobFiles Yes</span></dt><dd><p> +This keeps the job files themselves in cupsd's mind +(it keeps the d12345, d12346 etc. files in the CUPS spool +directory). This is set to “<span class="quote">No</span>” as the CUPS +default. +</p></dd><dt><span class="term"><span class="emphasis"><em>“<span class="quote">MaxJobs 500</span>”</em></span></span></dt><dd><p> +This directive controls the maximum number of jobs +that are kept in memory. Once the number of jobs reaches the limit, +the oldest completed job is automatically purged from the system to +make room for the new one. If all of the known jobs are still +pending or active, then the new job will be rejected. Setting the +maximum to 0 disables this functionality. The default setting is +0. +</p></dd></dl></div><p> +(There are also additional settings for <i class="parameter"><tt>MaxJobsPerUser</tt></i> and +<i class="parameter"><tt>MaxJobsPerPrinter</tt></i>...) +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2946198"></a>Pre-Conditions</h3></div></div><div></div></div><p> +For everything to work as announced, you need to have three +things: +</p><div class="itemizedlist"><ul type="disc"><li><p>A Samba-smbd that is compiled against <tt class="filename">libcups</tt> (check +on Linux by running <b class="userinput"><tt>ldd `which smbd'</tt></b>).</p></li><li><p>A Samba-<tt class="filename">smb.conf</tt> setting of + <a class="indexterm" name="id2946246"></a><i class="parameter"><tt>printing</tt></i> = cups.</p></li><li><p>Another Samba-<tt class="filename">smb.conf</tt> setting of + <a class="indexterm" name="id2946272"></a><i class="parameter"><tt>printcap</tt></i> = cups.</p></li></ul></div><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> +In this case, all other manually set printing-related commands (like +<a class="indexterm" name="id2946294"></a><i class="parameter"><tt>print command</tt></i>, +<a class="indexterm" name="id2946308"></a><i class="parameter"><tt>lpq command</tt></i>, +<a class="indexterm" name="id2946321"></a><i class="parameter"><tt>lprm command</tt></i>, +<a class="indexterm" name="id2946335"></a><i class="parameter"><tt>lppause command</tt></i> or +<a class="indexterm" name="id2946349"></a><i class="parameter"><tt>lpresume command</tt></i>) are ignored and they should normally have no +influence whatsoever on your printing. +</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2946367"></a>Manual Configuration</h3></div></div><div></div></div><p> +If you want to do things manually, replace the <a class="indexterm" name="id2946378"></a><i class="parameter"><tt>printing</tt></i> = cups +by <a class="indexterm" name="id2946391"></a><i class="parameter"><tt>printing</tt></i> = bsd. Then your manually set commands may work +(I haven't tested this), and a <a class="indexterm" name="id2946407"></a><i class="parameter"><tt>print command</tt></i> = lp -d %P %s; rm %s" +may do what you need. +</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2946425"></a>Printing from CUPS to Windows Attached Printers</h2></div></div><div></div></div><p> +>From time to time the question arises, how can you print +<span class="emphasis"><em>to</em></span> a Windows attached printer +<span class="emphasis"><em>from</em></span> Samba? Normally the local connection +from Windows host to printer would be done by USB or parallel +cable, but this does not matter to Samba. From here only an 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 +<span class="emphasis"><em>backends</em></span> to talk to printers and other +servers. To talk to Windows shared printers, you need to use the +<tt class="filename">smb</tt> (surprise, surprise!) backend. Check if this +is in the CUPS backend directory. This usually resides in +<tt class="filename">/usr/lib/cups/backend/</tt>. You need to find an <tt class="filename">smb</tt> +file there. It should be a symlink to <tt class="filename">smbspool</tt> +and the file must exist and be executable: +</p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>ls -l /usr/lib/cups/backend/</tt></b> +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/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 + +<tt class="prompt">root# </tt><b class="userinput"><tt>ls -l `which smbspool`</tt></b> +-rwxr-xr-x 1 root root 563245 Dec 28 14:49 /usr/bin/smbspool +</pre><p> +If this symlink does not exist, create it: +</p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>ln -s `which smbspool` /usr/lib/cups/backend/smb</tt></b> +</pre><p> +<b class="command">smbspool</b> has been written by Mike Sweet from the CUPS folks. It is +included and ships with Samba. It may also be used with print +subsystems other than CUPS, to spool jobs to Windows printer shares. To +set up printer <i class="replaceable"><tt>winprinter</tt></i> on CUPS, you need to have a driver for +it. Essentially this means to convert the print data on the CUPS/Samba +host to a format that 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 were 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, and so on. +</p><p> +To install a printer with the <i class="parameter"><tt>smb</tt></i> backend on CUPS, use this command: +</p><pre class="screen"> +<tt class="prompt">root# </tt><b class="userinput"><tt>lpadmin -p winprinter -v smb://WINDOWSNETBIOSNAME/printersharename \ + -P /path/to/PPD</tt></b> +</pre><p> +The PPD must be able 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 can you 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: You can include the required parameters as part of the +<tt class="filename">smb://</tt> device-URI like this: +</p><div class="itemizedlist"><ul type="disc"><li><tt class="filename">smb://WORKGROUP/WINDOWSNETBIOSNAME/printersharename</tt></li><li><tt class="filename">smb://username:password@WORKGROUP/WINDOWSNETBIOSNAME/printersharename</tt></li><li><tt class="filename">smb://username:password@WINDOWSNETBIOSNAME/printersharename</tt></li></ul></div><p> +Note that the device-URI will be visible in the process list of the +Samba server (e.g., when someone uses the <b class="command">ps -aux</b> +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, however, it is the only one. Don't use it if you want +to protect your passwords. Better share the printer in a way that +does not require a password! Printing will only work if you have a +working netbios name resolution up and running. Note that this is a +feature of CUPS and you do not necessarily need to have smbd running. + +</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2946721"></a>More CUPS-Filtering Chains</h2></div></div><div></div></div><p> +The following diagrams reveal how CUPS handles print jobs. +</p><div class="figure"><a name="cups1"></a><p class="title"><b>Figure 19.17. Filtering chain 1.</b></p><div class="mediaobject"><img src="projdoc/imagefiles/cups1.png" width="270" alt="Filtering chain 1."></div></div><div class="figure"><a name="cups2"></a><p class="title"><b>Figure 19.18. Filtering chain with cupsomatic</b></p><div class="mediaobject"><img src="projdoc/imagefiles/cups2.png" width="270" alt="Filtering chain with cupsomatic"></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2946814"></a>Common Errors</h2></div></div><div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2946820"></a>Windows 9x/ME Client Can't Install Driver</h3></div></div><div></div></div><p>For Windows 9x/ME, clients require the printer names to be eight +characters (or “<span class="quote">8 plus 3 chars suffix</span>”) max; otherwise, the driver files +will not get transferred when you want to download them from +Samba.</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2946839"></a>“<span class="quote">cupsaddsmb</span>” Keeps Asking for Root Password in Never-ending Loop</h3></div></div><div></div></div><p>Have you <a class="indexterm" name="id2946853"></a><i class="parameter"><tt>security</tt></i> = user? Have +you used <b class="command">smbpasswd</b> to give root a Samba account? +You can do two things: open another terminal and execute +<b class="command">smbpasswd -a root</b> to create the account and +continue entering the password into the first terminal. Or break +out of the loop by pressing ENTER twice (without trying to type a +password).</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2946889"></a>“<span class="quote">cupsaddsmb</span>” Errors</h3></div></div><div></div></div><p> + The use of “<span class="quote">cupsaddsmb</span>” gives “<span class="quote">No PPD file for printer...</span>” Message While PPD File Is Present. + What might the problem be? + </p><p>Have you enabled printer sharing on CUPS? This means: +Do you have a <i class="parameter"><tt><Location +/printers>....</Location></tt></i> section in CUPS +server's <tt class="filename">cupsd.conf</tt> that does not deny access to +the host you run “<span class="quote">cupsaddsmb</span>” from? It <span class="emphasis"><em>could</em></span> be +an issue if you use cupsaddsmb remotely, or if you use it with a +<tt class="option">-h</tt> parameter: <b class="userinput"><tt>cupsaddsmb -H + sambaserver -h cupsserver -v printername</tt></b>. +</p><p>Is your +<i class="parameter"><tt>TempDir</tt></i> directive in +<tt class="filename">cupsd.conf</tt> +set to a valid value and is it writeable? +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2946973"></a>Client Can't Connect to Samba Printer</h3></div></div><div></div></div><p>Use <b class="command">smbstatus</b> to check which user +you are from Samba's point of view. Do you have the privileges to +write into the <i class="parameter"><tt>[print$]</tt></i> +share?</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2947002"></a>New Account Reconnection from Windows 200x/XP Troubles</h3></div></div><div></div></div><p>Once you are connected as the wrong user (for +example, as <tt class="constant">nobody</tt>, which often occurs if you have +<a class="indexterm" name="id2947018"></a><i class="parameter"><tt>map to guest</tt></i> = bad user), Windows Explorer will not accept an +attempt to connect again as a different user. There will not be any byte +transfered on the wire to Samba, but still you'll see a stupid error +message that makes you think Samba has denied access. Use +<b class="command">smbstatus</b> to check for active connections. Kill the +PIDs. You still can't re-connect and you get the dreaded +<tt class="computeroutput">You can't connect with a second account from the same +machine</tt> message, as soon as you are trying. And you +do not see any single byte arriving at Samba (see logs; use “<span class="quote">ethereal</span>”) +indicating a renewed connection attempt. Shut all Explorer Windows. +This makes Windows forget what it has cached in its memory as +established connections. Then reconnect as the right user. The best +method is to use a DOS terminal window and <span class="emphasis"><em>first</em></span> +do <b class="userinput"><tt>net use z: \\GANDALF\print$ /user:root</tt></b>. Check +with <b class="command">smbstatus</b> that you are connected under a +different account. Now open the <span class="guilabel">Printers</span> folder (on the Samba server +in the <span class="guilabel">Network Neighborhood</span>), right-click on the +printer in question and select +<span class="guibutton">Connect...</span></p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2947106"></a>Avoid Being Connected to the Samba Server as the Wrong User</h3></div></div><div></div></div><p>You see per <b class="command">smbstatus</b> that you are +connected as user nobody; while you want to be root or +printeradmin. This is probably due to +<a class="indexterm" name="id2947126"></a><i class="parameter"><tt>map to guest</tt></i> = bad user, which silently connects you under the guest account +when you gave (maybe by accident) an incorrect username. Remove +<a class="indexterm" name="id2947142"></a><i class="parameter"><tt>map to guest</tt></i>, if you want to prevent +this.</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2947158"></a>Upgrading to CUPS Drivers from Adobe Drivers</h3></div></div><div></div></div><p> +This information came from a mailinglist posting regarding problems experienced when +upgrading from Adobe drivers to CUPS drivers on Microsoft Windows NT/200x/XP Clients. +</p><p>First delete all old Adobe-using printers. Then +delete all old Adobe drivers. (On Windows 200x/XP, right-click in +the background of <span class="guilabel">Printers</span> folder, select <span class="guimenuitem">Server Properties...</span>, select +tab <span class="guilabel">Drivers</span> and delete here).</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2947200"></a>Can't Use “<span class="quote">cupsaddsmb</span>” on Samba Server Which Is a PDC</h3></div></div><div></div></div><p>Do you use the “<span class="quote">naked</span>” root user name? Try to do it +this way: <b class="userinput"><tt>cupsaddsmb -U <i class="replaceable"><tt>DOMAINNAME</tt></i>\\root -v +<i class="replaceable"><tt>printername</tt></i></tt></b>> (note the two backslashes: the first one is +required to “<span class="quote">escape</span>” the second one).</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2947239"></a>Deleted Windows 200x Printer Driver Is Still Shown</h3></div></div><div></div></div><p>Deleting a printer on the client will not delete the +driver too (to verify, right-click on the white background of the +<span class="guilabel">Printers</span> folder, select <span class="guimenuitem">Server Properties</span> and click on the +<span class="guilabel">Drivers</span> tab). These same old drivers will be re-used when you try to +install a printer with the same name. If you want to update to a new +driver, delete the old ones first. Deletion is only possible if no +other printer uses the same driver.</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2947278"></a>Windows 200x/XP "Local Security Policies"</h3></div></div><div></div></div><p>Local Security Policies may not +allow the installation of unsigned drivers. “<span class="quote">Local Security Policies</span>” +may not allow the installation of printer drivers at +all.</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2947293"></a>Administrator Cannot Install Printers for All Local Users</h3></div></div><div></div></div><p>Windows XP handles SMB printers on a “<span class="quote">per-user</span>” 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 +<i class="parameter"><tt>http://cupsserver:631/printers/printername</tt></i>. +We're still looking into this one. Maybe a logon script could +automatically install printers for all +users.</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2947323"></a>Print Change Notify Functions on NT-clients</h3></div></div><div></div></div><p>For print change, notify functions on NT++ clients. +These need to run the <b class="command">Server</b> service first (renamed to +<b class="command">File & Print Sharing for MS Networks</b> in +XP).</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2947350"></a>WinXP-SP1</h3></div></div><div></div></div><p>WinXP-SP1 introduced a Point and Print Restriction Policy (this restriction does not apply to +“<span class="quote">Administrator</span>” or “<span class="quote">Power User</span>” groups of users). In Group Policy +Object Editor, go to <span class="guimenu">User Configuration -> Administrative Templates -> + Control Panel -> Printers</span>. The policy is automatically set to +<tt class="constant">Enabled</tt> and the <tt class="constant">Users can only Point +and Print to machines in their Forest</tt> . You probably need +to change it to <tt class="constant">Disabled</tt> or <tt class="constant">Users can +only Point and Print to these servers</tt> to make +driver downloads from Samba possible. +</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2947402"></a>Print Options for All Users Can't Be Set on Windows 200x/XP</h3></div></div><div></div></div><p>How are you doing it? I bet the wrong way (it is not +easy to find out, though). There are three different ways to bring +you to a dialog that <span class="emphasis"><em>seems</em></span> to set everything. All +three dialogs <span class="emphasis"><em>look</em></span> the same, yet only one of them +does what you intend. You need to be +Administrator or Print Administrator to do this for all users. Here +is how I do in on XP: +</p><div class="orderedlist"><ol type="A"><li><p>The first wrong way: + +</p><div class="orderedlist"><ol type="I"><li><p>Open the <span class="guilabel">Printers</span> +folder.</p></li><li><p>Right-click on the printer +(<span class="guilabel">remoteprinter on cupshost</span>) and +select in context menu <span class="guimenuitem">Printing +Preferences...</span></p></li><li><p>Look at this dialog closely and remember what it looks +like.</p></li></ol></div><p> +</p></li><li><p>The second wrong way: + +</p><div class="orderedlist"><ol type="I"><li><p>Open the <span class="guilabel">Printers</span> +folder.</p></li><li><p>Right-click on the printer (<span class="guilabel">remoteprinter on +cupshost</span>) and select the context menu +<span class="guimenuitem">Properties</span>.</p></li><li><p>Click on the <span class="guilabel">General</span> +tab.</p></li><li><p>Click on the button <span class="guibutton">Printing +Preferences...</span></p></li><li><p>A new dialog opens. Keep this dialog open and go back +to the parent dialog.</p></li></ol></div><p> +</p></li><li><p>The third, and the correct way: + +</p><div class="orderedlist"><ol type="I"><li><p>Open the <span class="guilabel">Printers</span> +folder.</p></li><li><p>Click on the <span class="guilabel">Advanced</span> +tab. (If everything is “<span class="quote">grayed out,</span>” then you are not logged +in as a user with enough privileges).</p></li><li><p>Click on the <span class="guibutton">Printing +Defaults...</span> button.</p></li><li><p>On any of the two new tabs, click on the +<span class="guibutton">Advanced...</span> +button.</p></li><li><p>A new dialog opens. Compare this one to the other +identical looking one from “<span class="quote">B.5</span>” or A.3".</p></li></ol></div><p> +</p></li></ol></div><p> +Do you see any difference? I don't either. However, only the last +one, which you arrived at with steps “<span class="quote">C.1.-6.</span>”, will save any settings +permanently and be the defaults for new users. If you want all clients +to get the same defaults, you need to conduct these steps <span class="emphasis"><em>as +Administrator</em></span> (<a class="indexterm" name="id2947677"></a><i class="parameter"><tt>printer admin</tt></i> in +<tt class="filename">smb.conf</tt>) <span class="emphasis"><em>before</em></span> a client +downloads the driver (the clients can later set their own +<span class="emphasis"><em>per-user defaults</em></span> by following the +procedures <span class="emphasis"><em>A</em></span> or <span class="emphasis"><em>B</em></span> +above).</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2947717"></a>Most Common Blunders in Driver Settings on Windows Clients</h3></div></div><div></div></div><p>Don't use <i class="parameter"><tt>Optimize for +Speed</tt></i>, but use <i class="parameter"><tt>Optimize for +Portability</tt></i> instead (Adobe PS Driver). Don't use +<i class="parameter"><tt>Page Independence: No</tt></i>: always +settle with <i class="parameter"><tt>Page Independence: +Yes</tt></i> (Microsoft PS Driver and CUPS PS Driver for +Windows NT/200x/XP). If there are problems with fonts, use +<i class="parameter"><tt>Download as Softfont into +printer</tt></i> (Adobe PS Driver). For +<span class="guilabel">TrueType Download Options</span> +choose <tt class="constant">Outline</tt>. Use PostScript +Level 2, if you are having trouble with a non-PS printer and if +there is a choice.</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2947779"></a><b class="command">cupsaddsmb</b> Does Not Work with Newly Installed Printer</h3></div></div><div></div></div><p>Symptom: The last command of +<b class="command">cupsaddsmb</b> does not complete successfully: +<b class="command">cmd = setdriver printername printername</b> result was +NT_STATUS_UNSUCCESSFUL then possibly the printer was not yet +recognized by Samba. Did it show up in Network +Neighborhood? Did it show up i n <b class="command">rpcclient +hostname -c `enumprinters'</b>? Restart smbd (or send a +<b class="command">kill -HUP</b> to all processes listed by +<b class="command">smbstatus</b> and try +again.</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2947835"></a>Permissions on <tt class="filename">/var/spool/samba/</tt> Get Reset After Each Reboot</h3></div></div><div></div></div><p>Have you ever by accident set the CUPS spool directory to +the same location? (<i class="parameter"><tt>RequestRoot /var/spool/samba/</tt></i> in <tt class="filename">cupsd.conf</tt> or +the other way round: <tt class="filename">/var/spool/cups/</tt> is set as +<a class="indexterm" name="id2947875"></a><i class="parameter"><tt>path</tt></i>> in the <i class="parameter"><tt>[printers]</tt></i> +section). These <i class="parameter"><tt>must</tt></i> be different. Set + +<i class="parameter"><tt>RequestRoot /var/spool/cups/</tt></i> in +<tt class="filename">cupsd.conf</tt> and <a class="indexterm" name="id2947919"></a><i class="parameter"><tt>path</tt></i> = +/var/spool/samba in the <i class="parameter"><tt>[printers]</tt></i> +section of <tt class="filename">smb.conf</tt>. Otherwise cupsd will +sanitize permissions to its spool directory with each restart and +printing will not work reliably.</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2947951"></a>Print Queue Called “<span class="quote">lp</span>” Mis-handles Print Jobs</h3></div></div><div></div></div><p> +In this case a print queue called “<span class="quote">lp</span>” intermittently swallows jobs and +spits out completely different ones from what was sent. +</p><p>It is a bad idea to name any printer “<span class="quote">lp</span>”. 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 +load-balancing the jobs across them in a round-robin fashion. Chances +are high that someone else has a printer named “<span class="quote">lp</span>” too. You may +receive his jobs and send your own to his device unwittingly. To have +tight control over the printer names, set <i class="parameter"><tt>BrowseShortNames +No</tt></i>. It will present any printer as <i class="replaceable"><tt>printername@cupshost</tt></i> +and then gives you better control over what may happen in a large +networked environment.</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2948008"></a>Location of Adobe PostScript Driver Files for “<span class="quote">cupsaddsmb</span>”</h3></div></div><div></div></div><p>Use <b class="command">smbclient</b> to connect to any +Windows box with a shared PostScript printer: <b class="command">smbclient +//windowsbox/print\$ -U guest</b>. You can navigate to the +<tt class="filename">W32X86/2</tt> subdir to <b class="command">mget ADOBE*</b> +and other files or to <tt class="filename">WIN40/0</tt> to do the same. +Another option is to download the <tt class="filename">*.exe</tt> packaged +files from the Adobe Web site.</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2948065"></a>Overview of the CUPS Printing Processes</h2></div></div><div></div></div><p>A complete overview of the CUPS printing processes can be found in <link linkend="a_small">.</p><div class="figure"><a name="a_small"></a><p class="title"><b>Figure 19.19. CUPS printing overview.</b></p><div class="mediaobject"><img src="projdoc/imagefiles/a_small.png" width="270" alt="CUPS printing overview."></div></div></div><div class="footnotes"><br><hr width="100" align="left"><div class="footnote"><ulink url="http://www.cups.org/cups-help.html"><sup>[<a name="ftn.id2936587" href="#id2936587">4</a>] </sup>http://www.cups.org/cups-help.html</ulink></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="printing.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="optional.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="VFS.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 18. Classical Printing Support </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 20. Stackable VFS modules</td></tr></table></div></body></html> |