diff options
Diffstat (limited to 'docs/htmldocs/CUPS-printing.html')
| -rw-r--r-- | docs/htmldocs/CUPS-printing.html | 3734 |
1 files changed, 0 insertions, 3734 deletions
diff --git a/docs/htmldocs/CUPS-printing.html b/docs/htmldocs/CUPS-printing.html deleted file mode 100644 index dff70b1726..0000000000 --- a/docs/htmldocs/CUPS-printing.html +++ /dev/null @@ -1,3734 +0,0 @@ -<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> -<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 19. CUPS Printing Support in Samba 3.0</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 in Samba 3.0</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 in Samba 3.0</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><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#id2957297">Introduction</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2957304">Features and Benefits</a></dt><dt><a href="CUPS-printing.html#id2957352">Overview</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2957404">Basic Configuration of CUPS support</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2957483">Linking of smbd with libcups.so</a></dt><dt><a href="CUPS-printing.html#id2950396">Simple smb.conf Settings for CUPS</a></dt><dt><a href="CUPS-printing.html#id2957550">More complex smb.conf Settings for -CUPS</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2950555">Advanced Configuration</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2950575">Central spooling vs. "Peer-to-Peer" printing</a></dt><dt><a href="CUPS-printing.html#id2950602">CUPS/Samba as a "spooling-only" Print Server; "raw" printing -with Vendor Drivers on Windows Clients</a></dt><dt><a href="CUPS-printing.html#id2950639">Driver Installation Methods on Windows Clients</a></dt><dt><a href="CUPS-printing.html#id2950697">Explicitly enable "raw" printing for -application/octet-stream!</a></dt><dt><a href="CUPS-printing.html#id2950858">Three familiar Methods for driver upload plus a new one</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2950951">Using CUPS/Samba in an advanced Way -- intelligent printing -with PostScript Driver Download</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2951026">GDI on Windows -- PostScript on Unix</a></dt><dt><a href="CUPS-printing.html#id2951071">Windows Drivers, GDI and EMF</a></dt><dt><a href="CUPS-printing.html#id2951170">Unix Printfile Conversion and GUI Basics</a></dt><dt><a href="CUPS-printing.html#id2951241">PostScript and Ghostscript</a></dt><dt><a href="CUPS-printing.html#id2951338">Ghostscript -- the Software RIP for non-PostScript Printers</a></dt><dt><a href="CUPS-printing.html#id2951433">PostScript Printer Description (PPD) Specification</a></dt><dt><a href="CUPS-printing.html#id2964250">CUPS can use all Windows-formatted Vendor PPDs</a></dt><dt><a href="CUPS-printing.html#id2964339">CUPS also uses PPDs for non-PostScript Printers</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2964362">The CUPS Filtering Architecture</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2964500">MIME types and CUPS Filters</a></dt><dt><a href="CUPS-printing.html#id2964688">MIME type Conversion Rules</a></dt><dt><a href="CUPS-printing.html#id2964804">Filter Requirements</a></dt><dt><a href="CUPS-printing.html#id2964973">Prefilters</a></dt><dt><a href="CUPS-printing.html#id2965058">pstops</a></dt><dt><a href="CUPS-printing.html#id2965161">pstoraster</a></dt><dt><a href="CUPS-printing.html#id2965317">imagetops and imagetoraster</a></dt><dt><a href="CUPS-printing.html#id2965372">rasterto [printers specific]</a></dt><dt><a href="CUPS-printing.html#id2965457">CUPS Backends</a></dt><dt><a href="CUPS-printing.html#id2965771">cupsomatic/Foomatic -- how do they fit into the Picture?</a></dt><dt><a href="CUPS-printing.html#id2965874">The Complete Picture</a></dt><dt><a href="CUPS-printing.html#id2965889">mime.convs</a></dt><dt><a href="CUPS-printing.html#id2965942">"Raw" printing</a></dt><dt><a href="CUPS-printing.html#id2965996">"application/octet-stream" printing</a></dt><dt><a href="CUPS-printing.html#id2966212">PostScript Printer Descriptions (PPDs) for non-PS Printers</a></dt><dt><a href="CUPS-printing.html#id2966439">Difference between cupsomatic/foomatic-rip and -native CUPS printing</a></dt><dt><a href="CUPS-printing.html#id2966596">Examples for filtering Chains</a></dt><dt><a href="CUPS-printing.html#id2966825">Sources of CUPS drivers / PPDs</a></dt><dt><a href="CUPS-printing.html#id2966950">Printing with Interface Scripts</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2967012">Network printing (purely Windows)</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2967028">From Windows Clients to an NT Print Server</a></dt><dt><a href="CUPS-printing.html#id2967067">Driver Execution on the Client</a></dt><dt><a href="CUPS-printing.html#id2967126">Driver Execution on the Server</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2967189">Network Printing (Windows clients -- UNIX/Samba Print -Servers)</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2967210">From Windows Clients to a CUPS/Samba Print Server</a></dt><dt><a href="CUPS-printing.html#id2967370">Samba receiving Jobfiles and passing them to CUPS</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2967448">Network PostScript RIP: CUPS Filters on Server -- clients use -PostScript Driver with CUPS-PPDs</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2967503">PPDs for non-PS Printers on UNIX</a></dt><dt><a href="CUPS-printing.html#id2967544">PPDs for non-PS Printers on Windows</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2967609">Windows Terminal Servers (WTS) as CUPS Clients</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2967626">Printer Drivers running in "Kernel Mode" cause many -Problems</a></dt><dt><a href="CUPS-printing.html#id2967661">Workarounds impose Heavy Limitations</a></dt><dt><a href="CUPS-printing.html#id2967682">CUPS: a "Magical Stone"?</a></dt><dt><a href="CUPS-printing.html#id2967709">PostScript Drivers with no major problems -- even in Kernel -Mode</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2967743"> Setting up CUPS for driver Download</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2967762">cupsaddsmb: the unknown Utility</a></dt><dt><a href="CUPS-printing.html#id2967853">Prepare your smb.conf for -cupsaddsmb</a></dt><dt><a href="CUPS-printing.html#id2967900">CUPS Package of "PostScript Driver for WinNT/2k/XP"</a></dt><dt><a href="CUPS-printing.html#id2968097">Recognize the different Driver Files</a></dt><dt><a href="CUPS-printing.html#id2968155">Acquiring the Adobe Driver Files</a></dt><dt><a href="CUPS-printing.html#id2968188">ESP Print Pro Package of "PostScript Driver for -WinNT/2k/XP"</a></dt><dt><a href="CUPS-printing.html#id2968238">Caveats to be considered</a></dt><dt><a href="CUPS-printing.html#id2968459">What are the Benefits of using the "CUPS PostScript Driver for -Windows NT/2k/XP" as compared to the Adobe Driver?</a></dt><dt><a href="CUPS-printing.html#id2968640">Run "cupsaddsmb" (quiet Mode)</a></dt><dt><a href="CUPS-printing.html#id2968741">Run "cupsaddsmb" with verbose Output</a></dt><dt><a href="CUPS-printing.html#id2968884">Understanding cupsaddsmb</a></dt><dt><a href="CUPS-printing.html#id2968978">How to recognize if cupsaddsm completed successfully</a></dt><dt><a href="CUPS-printing.html#id2969065">cupsaddsmb with a Samba PDC</a></dt><dt><a href="CUPS-printing.html#id2969100">cupsaddsmb Flowchart</a></dt><dt><a href="CUPS-printing.html#id2969151">Installing the PostScript Driver on a Client</a></dt><dt><a href="CUPS-printing.html#id2969266">Avoiding critical PostScript Driver Settings on the -Client</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2969400">Installing PostScript Driver Files manually (using -rpcclient)</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2969515">A Check of the rpcclient man Page</a></dt><dt><a href="CUPS-printing.html#id2969627">Understanding the rpcclient man Page</a></dt><dt><a href="CUPS-printing.html#id2969706">Producing an Example by querying a Windows Box</a></dt><dt><a href="CUPS-printing.html#id2969796">What is required for adddriver and setdriver to succeed</a></dt><dt><a href="CUPS-printing.html#id2969958">Manual Commandline Driver Installation in 15 little Steps</a></dt><dt><a href="CUPS-printing.html#id2970578">Troubleshooting revisited</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2970680">The printing *.tdb Files</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2970783">Trivial DataBase Files</a></dt><dt><a href="CUPS-printing.html#id2970853">Binary Format</a></dt><dt><a href="CUPS-printing.html#id2970915">Losing *.tdb Files</a></dt><dt><a href="CUPS-printing.html#id2970974">Using tdbbackup</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2971036">CUPS Print Drivers from Linuxprinting.org</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2971142">foomatic-rip and Foomatic explained</a></dt><dt><a href="CUPS-printing.html#id2971770">foomatic-rip and Foomatic-PPD Download and Installation</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2972228">Page Accounting with CUPS</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2972259">Setting up Quotas</a></dt><dt><a href="CUPS-printing.html#id2972290">Correct and incorrect Accounting</a></dt><dt><a href="CUPS-printing.html#id2972331">Adobe and CUPS PostScript Drivers for Windows Clients</a></dt><dt><a href="CUPS-printing.html#id2972403">The page_log File Syntax</a></dt><dt><a href="CUPS-printing.html#id2972504">Possible Shortcomings</a></dt><dt><a href="CUPS-printing.html#id2972576">Future Developments</a></dt><dt><a href="CUPS-printing.html#id2972624">Other Accounting Tools</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2972639">Additional Material</a></dt><dt><a href="CUPS-printing.html#id2972832">Auto-Deletion or Preservation of CUPS Spool Files</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2972878">CUPS Configuration Settings explained</a></dt><dt><a href="CUPS-printing.html#id2972960">Pre-conditions</a></dt><dt><a href="CUPS-printing.html#id2973021">Manual Configuration</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2973039">When not to use Samba to print to -CUPS</a></dt><dt><a href="CUPS-printing.html#id2973056">In Case of Trouble.....</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2973091">Where to find Documentation</a></dt><dt><a href="CUPS-printing.html#id2973104">How to ask for Help</a></dt><dt><a href="CUPS-printing.html#id2973117">Where to find Help</a></dt></dl></dd><dt><a href="CUPS-printing.html#id2973131">Appendix</a></dt><dd><dl><dt><a href="CUPS-printing.html#id2973138">Printing from CUPS to Windows attached -Printers</a></dt><dt><a href="CUPS-printing.html#id2973332">More CUPS filtering Chains</a></dt><dt><a href="CUPS-printing.html#id2973586">Trouble Shooting Guidelines to fix typical Samba printing -Problems</a></dt><dt><a href="CUPS-printing.html#id2974692">An Overview of the CUPS Printing Processes</a></dt></dl></dd></dl></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2957297"></a>Introduction</h2></div></div><div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2957304"></a>Features and Benefits</h3></div></div><div></div></div><p> - The Common Unix Print System (<a href="http://www.cups.org/" target="_top">CUPS</a>) has become very popular. All - big Linux distributions now ship it as their default printing - system. But to many it is still a very mystical tool. Normally it - "just works" (TM). People tend to regard it as a sort of "black box", - which they don't want to look into, as long as it works OK. But once - there is a little problem, they are in trouble to find out where to - start debugging it. Also, even the most recent and otherwise excellent - printed Samba documentation has only limited attention paid to CUPS - printing, leaving out important pieces or even writing plain wrong - things about it. This demands rectification. But before you dive into - this chapter, make sure that you don't forget to refer to the - "Classical Printing" chapter also. It contains a lot of information - that is relevant for CUPS too. - </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 to try and not apply any prior knowledge about - printing upon this new system. Rather try to start understand CUPS - from the beginning. This documentation will lead you here to a - complete understanding of CUPS, if you study all of the material - contained. But lets start with the most basic things first. Maybe this - is all you need for now. Then you can skip most of the other - paragraphs. - </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2957352"></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 IPP - (<span class="emphasis"><em>Internet Printing Protocol</em></span>). IPP is an industry - and IETF (<span class="emphasis"><em>Internet Engineering Task Force</em></span>) - standard for network printing. Many of its functions can be managed - remotely (or locally) via a web browser (giving you a - platform-independent access to the CUPS print server). In addition it - has the traditional commandline and several more modern GUI interfaces - (GUI interfaces developed by 3rd parties, like KDE's - overwhelming <a href="http://printing.kde.org/" target="_top">KDEPrint</a>). - </p><p> - CUPS allows creation of "raw" printers (ie: NO print file - format translation) as well as "smart" printers (i.e. CUPS does - file format conversion as required for the printer). In many ways - this gives CUPS similar capabilities to the MS Windows print - monitoring system. Of course, if you are a CUPS advocate, you would - argue that CUPS is better! In any case, let us now move on to - explore how one may configure CUPS for interfacing with MS Windows - print clients via Samba. - </p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2957404"></a>Basic Configuration of CUPS support</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: <i class="parameter"><tt>printing = cups</tt></i> and <i class="parameter"><tt>printcap - = cups</tt></i>. CUPS itself doesn't need a printcap file - anymore. However, the <tt class="filename">cupsd.conf</tt> configuration - file knows two related directives: they control if such a file should - be automatically created and maintained by CUPS for the convenience of - third party applications (example: <i class="parameter"><tt>Printcap - /etc/printcap</tt></i> and <i class="parameter"><tt>PrintcapFormat - BSD</tt></i>). These legacy programs often require the existence of - printcap file containing printernames or they will refuse to - print. Make sure CUPS is set to generate and maintain a printcap! 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: <a href="http://localhost:631/documentation.html" target="_top">http://localhost:631/documentation.html</a>. - </p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2957483"></a>Linking of smbd with libcups.so</h3></div></div><div></div></div><p> - Samba has a very special relationship to CUPS. The reason is: Samba - can be compiled with CUPS library support. Most recent installations - have this support enabled, and per default CUPS linking is compiled - into smbd and other Samba binaries. Of course, you can use CUPS even - if Samba is not linked against <tt class="filename">libcups.so</tt> -- but - there are some differences in required or supported configuration - then. - </p><p> - If SAMBA is compiled against libcups, then <i class="parameter"><tt>printcap = - cups</tt></i> uses the CUPS API to list printers, submit jobs, - query queues, etc. 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"> - transmeta:/home/kurt # ldd `which smbd` - libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x4002d000) - libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x4005a000) - libcups.so.2 => /usr/lib/libcups.so.2 (0x40123000) - [....] - </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 you require -- for any reason -- to set your own - print commands, you can still do this by setting <i class="parameter"><tt>printing = - sysv</tt></i>. However, you'll loose all the benefits from the - close CUPS/Samba integration. You are on your own then to manually - configure the rest of the printing system commands (most important: - <i class="parameter"><tt>print command</tt></i>; other commands are - <i class="parameter"><tt>lppause command, lpresume command, lpq command, lprm - command, queuepause command </tt></i> and <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="id2950396"></a>Simple <tt class="filename">smb.conf</tt> Settings for CUPS</h3></div></div><div></div></div><p> - To summarize, here is the simplest printing-related setup - for <tt class="filename">smb.conf</tt> to enable basic CUPS support: - </p><pre class="screen"> - - [global] - load printers = yes - printing = cups - printcap name = cups - - [printers] - comment = All Printers - path = /var/spool/samba - browseable = no - public = yes - guest ok = yes - writable = no - printable = yes - printer admin = root, @ntadmins - - </pre><p> - This is all you need for basic printing setup for CUPS. It will print - all Graphic, Text, PDF and PostScript file submitted from Windows - clients. However, most of your Windows users would not know how to - send these kind of files to print without opening a GUI - application. Windows clients tend to have local printer drivers - installed. And the GUI application's print buttons start a printer - driver. Your users also very rarely send files from the command - line. Unlike UNIX clients, they hardly submit graphic, text or PDF - formatted files directly to the spooler. They nearly exclusively print - from GUI applications, with a "printer driver" hooked in between the - applications native format and the print data stream. If the backend - printer is not a PostScript device, the print data stream is "binary", - sensible only for the target printer. Read on to learn which problem - this may cause and how to avoid it. - </p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2957550"></a>More complex <tt class="filename">smb.conf</tt> Settings for -CUPS</h3></div></div><div></div></div><p> -Here 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><pre class="screen"> - - [global] - printing = cups - printcap name = cups - load printers = yes - - [printers] - comment = All Printers - path = /var/spool/samba - public = yes - guest ok = yes - writable = no - printable = yes - printer admin = root, @ntadmins - - [special_printer] - comment = A special printer with his own settings - path = /var/spool/samba-special - printing = sysv - printcap = lpstat - print command = echo "NEW: `date`: printfile %f" >> /tmp/smbprn.log ;\ - echo " `date`: p-%p s-%s f-%f" >> /tmp/smbprn.log ;\ - echo " `date`: j-%j J-%J z-%z c-%c" >> /tmp/smbprn.log :\ - rm %f - public = no - guest ok = no - writeable = no - printable = yes - printer admin = kurt - hosts deny = 0.0.0.0 - hosts allow = turbo_xp, 10.160.50.23, 10.160.51.60 - -</pre><p> -This special share is only there for my testing purposes. It doesn't -even 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 <i class="parameter"><tt>printer -admin</tt></i> of this share is "kurt" (not the "@ntadmins" group); -guest access is not allowed; the share isn't announced in Network -Neighbourhood (so you need to know it is there), and it is only -allowing access from three hosts. To prevent CUPS kicking in and -taking over the print jobs for that share, we need to set -<i class="parameter"><tt>printing = sysv</tt></i> and <i class="parameter"><tt>printcap = -lpstat</tt></i>. -</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2950555"></a>Advanced Configuration</h2></div></div><div></div></div><p> -Before we dive into all the configuration options, let's clarify a few -points. <span class="emphasis"><em>Network printing needs to be organized and setup -correctly</em></span>. Often this is not done correctly. Legacy systems -or small LANs in business environments often lack a clear design and -good housekeeping. -</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2950575"></a>Central spooling vs. "Peer-to-Peer" printing</h3></div></div><div></div></div><p> -Many small office or home networks, as well as badly organized larger -environments, allow each client a direct access to available network -printers. Generally, this is a bad idea. It often blocks one client's -access to the printer when another client's job is printing. It also -might freeze the first client's application while it is waiting to get -rid of the job. Also, there are frequent complaints about various jobs -being printed with their pages mixed with each other. A better concept -is the usage of a "print server": it routes all jobs through one -central system, which responds immediately, takes jobs from multiple -concurrent clients at the same time and in turn transfers them to the -printer(s) in the correct order. -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2950602"></a>CUPS/Samba as a "spooling-only" Print Server; "raw" printing -with Vendor Drivers on Windows Clients</h3></div></div><div></div></div><p> -Most traditionally configured Unix print servers acting on behalf of -Samba's Windows clients represented a really simple setup. Their only -task was to manage the "raw" spooling of all jobs handed to them by -Samba. This approach meant that the Windows clients were expected to -prepare the print job file in such a way that it became fit to be fed to -the printing device. Here a native (vendor-supplied) Windows printer -driver for the target device needed to be installed on each and every -client. -</p><p> -Of course you can setup CUPS, Samba and your Windows clients in the -same, traditional and simple way. When CUPS printers are configured -for RAW print-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="id2950639"></a>Driver Installation Methods on Windows Clients</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; it uses a <tt class="filename">\\sambaserver\printershare</tt> -type of connection.</p></li><li><p>deposit and prepare the drivers (for later download) on -the print server (Samba); this enables the clients to use -"Point'n'Print" to get drivers semi-automatically installed the -first time they access the printer; with this method NT/2K/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="id2950697"></a>Explicitly enable "raw" printing for -<span class="emphasis"><em>application/octet-stream</em></span>!</h3></div></div><div></div></div><p> -If you use the first option (drivers are installed on the client -side), there is one setting to take care of: CUPS needs to be told -that it should allow "raw" printing of deliberate (binary) file -formats. The CUPS files that need to be correctly set for RAW mode -printers to work are: -</p><div class="itemizedlist"><ul type="disc"><li><p>/etc/cups/mime.types -</p></li><li><p>/etc/cups/mime.convs</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="screen"> - - application/octet-stream - -</pre><p> -In <tt class="filename">/etc/cups/mime.convs</tt>, -have this line: -</p><pre class="screen"> - - 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> "raw" 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 a user to send deliberate (possibly binary) -data to printing devices. This could be easily abused to launch a -"Denial of Service" attack on your printer(s), causing at the least -the loss of a lot of paper and ink. "Unknown" data are tagged by CUPS -as <span class="emphasis"><em>MIME type: application/octet-stream</em></span> and not -allowed to go to the printer. By default, you can only send other -(known) MIME types "raw". Sending data "raw" means that CUPS does not -try to convert them and passes them to the printer untouched (see next -chapter for even more background explanations). -</p><p> -This is all you need to know to get the CUPS/Samba combo printing -"raw" files prepared by Windows clients, which have vendor drivers -locally installed. If you are not interested in background information about -more advanced CUPS/Samba printing, simply skip the remaining sections -of this chapter. -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2950858"></a>Three familiar Methods for driver upload plus a new one</h3></div></div><div></div></div><p> -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 that the Windows clients can download and use them via -"Point'n'Print") please also refer to the previous chapter of this -HOWTO Collection. There you will find a description or reference to -three methods of preparing the client drivers on the Samba server: -</p><div class="itemizedlist"><ul type="disc"><li><p>the GUI, "Add Printer Wizard" -<span class="emphasis"><em>upload-from-a-Windows-client</em></span> -method;</p></li><li><p>the commandline, "smbclient/rpcclient" -<span class="emphasis"><em>upload-from-a-UNIX-workstation</em></span> -method;</p></li><li><p>the <span class="emphasis"><em>Imprints</em></span> Toolset -method.</p></li></ul></div><p> -These 3 methods apply to CUPS all the same. A new and more -convenient way to load the Windows drivers into Samba is provided -provided if you use CUPS: -</p><div class="itemizedlist"><ul type="disc"><li><p>the <span class="emphasis"><em>cupsaddsmb</em></span> -utility.</p></li></ul></div><p> -cupsaddsmb is discussed in much detail further below. But we will -first explore the CUPS filtering system and compare the Windows and -UNIX printing architectures. -</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2950951"></a>Using CUPS/Samba in an advanced Way -- intelligent printing -with PostScript Driver Download</h2></div></div><div></div></div><p> -Still reading on? Good. Let's go into more detail then. We now know -how to set up a "dump" printserver, that is, a server which is spooling -printjobs "raw", leaving the print data untouched. -</p><p> -Possibly you need to setup CUPS in a more smart 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 departments 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 shall be re-organized from a clean beginning?</p></li><li><p>Maybe you have experiencing too many "Blue Screens", -originating from poorly debugged printer drivers running in NT "kernel -mode"?</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 is the time for 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="id2951026"></a>GDI on Windows -- PostScript on Unix</h3></div></div><div></div></div><p> -Network printing is one of the most complicated and error-prone -day-to-day tasks any user or an administrator may encounter. This is -true for all OS platforms. And there are reasons for this. -</p><p> -You can't expect for most file formats to just throw them towards -printers and they get printed. There needs to be a file format -conversion in between. The problem is: there is no common standard for -print file formats across all manufacturers and printer types. While -<span class="emphasis"><em>PostScript</em></span> (trademark held by Adobe), and, to an -extent, <span class="emphasis"><em>PCL</em></span> (trademark held by HP), have developed -into semi-official "standards", by being the most widely used PDLs -(<span class="emphasis"><em>Page Description Languages</em></span>), there are still -many manufacturers who "roll their own" (their reasons may be -unacceptable license fees for using printer-embedded PostScript -interpreters, etc.). -</p></div><div xmlns:ns52="" class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2951071"></a>Windows Drivers, GDI and EMF</h3></div></div><div></div></div><p> -In Windows OS, the format conversion job is done by the printer -drivers. On MS Windows OS platforms all application programmers have -at their disposal a built-in API, the GDI (<span class="emphasis"><em>Graphical Device -Interface</em></span>), 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 ("What You See Is What You Get") is -relatively easy, because the on-screen graphic primitives, as well as -the on-paper drawn objects, come from one common source. This source, -the GDI, produces often a file format called EMF (<span class="emphasis"><em>Enhanced -MetaFile</em></span>). 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> -To the GDI foundation in MS Windows, Apple has chosen to -put paper and screen output on a common foundation for their -(BSD-Unix-based, did you know??) Mac OS X and Darwin Operating -Systems.Their <span class="emphasis"><em>Core Graphic Engine</em></span> uses a -<span class="emphasis"><em>PDF</em></span> derivate for all display work. -</p></div><ns52:p> - -</ns52:p><div class="figure"><a name="id2951136"></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" alt="Windows Printing to a local Printer"></div></div><ns52:p> -</ns52:p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2951170"></a>Unix Printfile Conversion and GUI Basics</h3></div></div><div></div></div><p> -In Unix and Linux, there is no comparable layer built into the OS -kernel(s) or the X (screen display) server. Every application is -responsible for itself to create its print output. Fortunately, most -use PostScript. That gives at least some common ground. Unfortunately, -there are many different levels of quality for this PostScript. And -worse: there is a huge difference (and no common root) in the way how -the same document is displayed on screen and how it is presented on -paper. WYSIWYG is more difficult to achieve. This goes back to the -time decades ago, when the predecessors of <span class="emphasis"><em>X.org</em></span>, -designing the UNIX foundations and protocols for Graphical User -Interfaces refused to take over responsibility for "paper output" -also, as some had demanded at the time, and restricted itself to -"on-screen only". (For some years now, the "Xprint" project has been -under development, attempting to build printing support into the X -framework, including a PostScript and a PCL driver, but it is not yet -ready for prime time.) You can see this unfavorable inheritance up to -the present day by looking into the various "font" directories on your -system; there are separate ones for fonts used for X display and fonts -to be used on paper. -</p><p><b>Background. </b> -The PostScript programming language is an "invention" by Adobe Inc., -but its specifications have been published to the full. Its strength -lies in its powerful abilities to describe graphical objects (fonts, -shapes, patterns, lines, curves, dots...), their attributes (color, -linewidth...) and the way to manipulate (scale, distort, rotate, -shift...) them. Because of its open specification, anybody with the -skill can start writing his own implementation of a PostScript -interpreter and use it to display PostScript files on screen or on -paper. Most graphical output devices are based on the concept of -"raster images" or "pixels" (one notable exception are pen -plotters). Of course, you can look at a PostScript file in its textual -form and you will be reading its PostScript code, the language -instructions which need to be interpreted by a rasterizer. Rasterizers -produce pixel images, which may be displayed on screen by a viewer -program or on paper by a printer. -</p></div><div xmlns:ns53="" class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2951241"></a>PostScript and Ghostscript</h3></div></div><div></div></div><p> -So, Unix is lacking a common ground for printing on paper and -displaying on screen. Despite this unfavorable legacy for Unix, basic -printing is fairly easy: if you have PostScript printers at your -disposal! The reason is: these devices have a built-in PostScript -language "interpreter", also called a <span class="emphasis"><em>Raster Image -Processor</em></span> (RIP), (which makes them more expensive than -other types of printers); throw PostScript towards them, and they will -spit out your printed pages. Their RIP is doing all the hard work of -converting the PostScript drawing commands into a bitmap picture as -you see it on paper, in a resolution as done by your printer. This is -no different to PostScript printing of a file from a Windows origin. -</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>Traditional Unix programs and printing systems -- while -using PostScript -- are largely not PPD-aware. PPDs are "PostScript -Printer Description" files. They enable you to specify and control all -options a printer supports: duplexing, stapling, punching... Therefore -Unix users for a long time couldn't choose many of the supported -device and job options, unlike Windows or Apple users. But now there -is CUPS.... ;-) -</p></div><ns53:p> -</ns53:p><div class="figure"><a name="id2951288"></a><p class="title"><b>Figure 19.2. Printing to a Postscript Printer</b></p><div class="mediaobject"><img src="projdoc/imagefiles/2small.png" alt="Printing to a Postscript Printer"></div></div><ns53:p> -</ns53:p><p> -However, there are other types of printers out there. These don't know -how to print PostScript. They use their own <span class="emphasis"><em>Page Description -Language</em></span> (PDL, often proprietary). To print to them is much -more demanding. Since your Unix applications mostly produce -PostScript, and since these devices don't understand PostScript, you -need to convert the printfiles to a format suitable for your printer -on the host, before you can send it away. -</p></div><div xmlns:ns54="" class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2951338"></a>Ghostscript -- the Software RIP for non-PostScript Printers</h3></div></div><div></div></div><p> -Here is where <span class="emphasis"><em>Ghostscript</em></span> kicks in. Ghostscript is -the traditional (and quite powerful) PostScript interpreter used on -Unix platforms. It is a RIP in software, capable to do a -<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 is what enables PostScript printing -to non-PostScript hardware. -</p><ns54:p> -</ns54:p><div class="figure"><a name="id2951368"></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" alt="Ghostscript as a RIP for non-postscript printers"></div></div><ns54:p> -</ns54:p><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p> -Use the "gs -h" command to check for all built-in "devices" of your -Ghostscript version. If you specify e.g. 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 "device" on the commandline is the most important -single parameter to tell Ghostscript how exactly it should render the -input. New Ghostscript versions are released at fairly regular -intervals, now by artofcode LLC. They are initially put under the -"AFPL" license, but re-released under the GNU GPL as soon as the next -AFPL version appears. GNU Ghostscript is probably the version -installed on most Samba systems. But it has got some -deficiencies. Therefore ESP Ghostscript was developed as an -enhancement over GNU Ghostscript, with lots of bug-fixes, additional -devices and improvements. It is jointly maintained by developers from -CUPS, Gimp-Print, MandrakeSoft, SuSE, RedHat and Debian. It includes -the "cups" device (essential to print to non-PS printers from CUPS). -</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2951433"></a>PostScript Printer Description (PPD) Specification</h3></div></div><div></div></div><p> -While PostScript in essence is a <span class="emphasis"><em>Page Description -Language</em></span> (PDL) to represent the page layout in a -<span class="emphasis"><em>device independent</em></span> way, real world print jobs are -always ending up to be output on a hardware with device-specific -features. To take care of all the differences in hardware, and to -allow for innovations, Adobe has specified a syntax and file format -for <span class="emphasis"><em>PostScript Printer Description</em></span> (PPD) -files. Every PostScript printer ships with one of these files. -</p><p> -PPDs contain all information about general and special features of the -given printer model: Which different resolutions can it handle? Does -it have a Duplexing Unit? How many paper trays are there? What media -types and sizes does it take? For each item it also names the special -command string to be sent to the printer (mostly inside the PostScript -file) in order to enable it. -</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 as choice of print options. In the end, the -user selections are somehow written (in the form of special -PostScript, PJL, JCL or vendor-dependent commands) into the PostScript -file created by the driver. -</p><div class="warning" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Warning</h3><p> -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="id2964250"></a>CUPS can use all 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 -Unix/Linux-illiterate 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 hold of 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 <a href="http://www.cups.org/testppd.php" target="_top">http://www.cups.org/testppd.php</a> -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> -For real PostScript printers <span class="emphasis"><em>don't</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="id2964339"></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="id2964362"></a>The CUPS Filtering Architecture</h2></div></div><div></div></div><p> -The core of the CUPS filtering system is based on -<span class="emphasis"><em>Ghostscript</em></span>. 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 <span class="emphasis"><em>MIME types</em></span>. Every incoming -printfile is subjected to an initial -<span class="emphasis"><em>auto-typing</em></span>. 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 <span class="emphasis"><em>natively</em></span> to -a bitmap, this is done in 2 stages: -</p><div class="itemizedlist"><ul type="disc"><li><p>the first stage uses a Ghostscript device named "cups" -(this is since version 1.1.15) and produces a generic raster format -called "CUPS raster". -</p></li><li><p>the second stage uses a "raster driver" which converts -the generic CUPS raster to a device specific raster.</p></li></ul></div><p> -Make sure your Ghostscript version has the "cups" 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 "cups" as a -device in your Ghostscript, you either need to <span class="emphasis"><em>patch GNU -Ghostscript</em></span> and re-compile or use <a href="http://www.cups.org/ghostscript.php" target="_top">ESP Ghostscript</a>. 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> -CUPS printers may be setup to use <span class="emphasis"><em>external</em></span> -rendering paths. One of the most common ones is provided by the -<span class="emphasis"><em>Foomatic/cupsomatic</em></span> concept, from <a href="http://www.linuxprinting.org/" target="_top">Linuxprinting.org</a>. This -uses the classical Ghostscript approach, doing everything in one -step. It doesn't use the "cups" device, but one of the many -others. However, even for Foomatic/cupsomatic usage, best results and -broadest printer model support is provided by ESP Ghostscript (more -about cupsomatic/Foomatic, 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="id2964500"></a>MIME types and CUPS Filters</h3></div></div><div></div></div><p> -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 which 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: -</p><pre class="screen"> - - 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 (<span class="emphasis"><em>application/pdf</em></span>). -Another rule is this: -</p><pre class="screen"> - - application/postscript ai eps ps string(0,%!) string(0,<04>%!) - -</pre><p> -Its meaning: 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 -(<span class="emphasis"><em>application/postscript</em></span>). -</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> -There is a very important difference between two similar MIME type in -CUPS: one is <span class="emphasis"><em>application/postscript</em></span>, the other is -<span class="emphasis"><em>application/vnd.cups-postscript</em></span>. While -<span class="emphasis"><em>application/postscript</em></span> is meant to be device -independent (job options for the file are still outside the PS file -content, embedded in commandline or environment variables by CUPS), -<span class="emphasis"><em>application/vnd.cups-postscript</em></span> may have the job -options inserted into the PostScript data itself (were -applicable). The transformation of the generic PostScript -(application/postscript) to the device-specific version -(application/vnd.cups-postscript) is the responsibility of the -CUPS <span class="emphasis"><em>pstops</em></span> filter. pstops uses information -contained in the PPD to do the transformation. -</p></div><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 file your system might be using -with the one in the <tt class="filename">/etc/cups/</tt> directory. -</p></div><p> -CUPS can handle ASCII text, HP-GL, PDF, PostScript, DVI and a -lot of image formats (GIF. PNG, TIFF, JPEG, Photo-CD, SUN-Raster, -PNM, PBM, SGI-RGB and some more) and their associated MIME types -with its filters. -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2964688"></a>MIME type Conversion Rules</h3></div></div><div></div></div><p> -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 which can produce the output from the input type -and virtual costs associated with this conversion. One example line -reads like this: -</p><pre class="screen"> - - application/pdf application/postscript 33 pdftops - -</pre><p> -This means that the <span class="emphasis"><em>pdftops</em></span> filter will take -<span class="emphasis"><em>application/pdf</em></span> as input and produce -<span class="emphasis"><em>application/postscript</em></span> as output, the virtual -cost of this operation is 33 CUPS-$. The next filter is more -expensive, costing 66 CUPS-$: -</p><pre class="screen"> - - application/vnd.hp-HPGL application/postscript 66 hpgltops - -</pre><p> -This is the <span class="emphasis"><em>hpgltops</em></span>, which processes HP-GL -plotter files to PostScript. -</p><pre class="screen"> - - application/octet-stream - -</pre><p> -Here are two more examples: -</p><pre class="screen"> - - application/x-shell application/postscript 33 texttops - text/plain application/postscript 33 texttops - -</pre><p> -The last two examples name the <span class="emphasis"><em>texttops</em></span> filter -to work on "text/plain" as well as on "application/x-shell". (Hint: -this differentiation is needed for the syntax highlighting feature of -"texttops"). -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2964804"></a>Filter Requirements</h3></div></div><div></div></div><p> -There are many more combinations named in mime.convs. However, you -are not limited to use the ones pre-defined there. You can plug in any -filter you like into the CUPS framework. It must meet, or must be made -to meet some minimal requirements. If you find (or write) a cool -conversion filter of some kind, make sure it complies to what CUPS -needs, and put in the right lines in <tt class="filename">mime.types</tt> -and <tt class="filename">mime.convs</tt>, then it will work seamlessly -inside CUPS! -</p><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p> -The mentioned "CUPS requirements" 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">Printer</span></dt><dd><p>The string from the originating-user-name -attribute</p></dd><dt><span class="term">Printer</span></dt><dd><p>The string from the job-name attribute</p></dd><dt><span class="term">Printer</span></dt><dd><p>The numeric value from the number-copies -attribute</p></dd><dt><span class="term">Printer</span></dt><dd><p>The job options</p></dd><dt><span class="term">Printer</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 very easy to write a simple wrapper script around existing -filters to make them work with CUPS.</p></dd></dl></div></div></div><div xmlns:ns55="" class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2964973"></a>Prefilters</h3></div></div><div></div></div><p> -As was said, PostScript is the central file format to any Unix based -printing system. From PostScript, CUPS generates raster data to feed -non-PostScript printers. -</p><p> -But what is happening if you send one of the supported non-PS formats -to print? Then CUPS runs "pre-filters" on these input formats to -generate PostScript first. There are pre-filters to create PS from -ASCII text, PDF, DVI or HP-GL. The outcome of these filters is always -of MIME type <span class="emphasis"><em>application/postscript</em></span> (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 <span class="emphasis"><em>imagetops</em></span> filter. Its outcome is always of -MIME type <span class="emphasis"><em>application/vnd.cups-postscript</em></span> -(<span class="emphasis"><em>not</em></span> application/postscript), meaning it has the -print options already embedded into the file. -</p><ns55:p> -</ns55:p><div class="figure"><a name="id2965024"></a><p class="title"><b>Figure 19.4. Prefiltering in CUPS to form Postscript</b></p><div class="mediaobject"><img src="projdoc/imagefiles/4small.png" alt="Prefiltering in CUPS to form Postscript"></div></div><ns55:p> -</ns55:p></div><div xmlns:ns56="" class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2965058"></a>pstops</h3></div></div><div></div></div><p> -<span class="emphasis"><em>pstops</em></span>is the filter to convert -<span class="emphasis"><em>application/postscript</em></span> to -<span class="emphasis"><em>application/vnd.cups-postscript</em></span>. It was said -above that this filter inserts all device-specific print options -(commands to the printer to ask for the duplexing of output, or -stapling an punching it, etc.) into the PostScript file. -</p><ns56:p> -</ns56:p><div class="figure"><a name="id2965089"></a><p class="title"><b>Figure 19.5. Adding Device-specific Print Options</b></p><div class="mediaobject"><img src="projdoc/imagefiles/5small.png" alt="Adding Device-specific Print Options"></div></div><ns56:p> -</ns56: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 "3, 6, 8-11, 16, 19-21", or only the odd numbered -ones) -</p></li><li><p> -putting 2 or more logical pages on one sheet of paper (the -so-called "number-up" 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 xmlns:ns57="" class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2965161"></a>pstoraster</h3></div></div><div></div></div><p> -<span class="emphasis"><em>pstoraster</em></span> 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><ns57:p> -</ns57:p><div class="figure"><a name="id2965191"></a><p class="title"><b>Figure 19.6. Postscript to intermediate Raster format</b></p><div class="mediaobject"><img src="projdoc/imagefiles/6small.png" alt="Postscript to intermediate Raster format"></div></div><ns57:p> -</ns57: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 very easy and inexpensive for -manufacturers to develop Linux and Unix raster drivers for their -printer models, should they choose to do so. CUPS always takes care -for the first stage of rasterization so these vendors don't need to care -about Ghostscript complications (in fact, there is currently more -than one vendor financing the development of CUPS raster drivers). -</p><ns57:p> -</ns57:p><div class="figure"><a name="id2965243"></a><p class="title"><b>Figure 19.7. CUPS-raster production using Ghostscript</b></p><div class="mediaobject"><img src="projdoc/imagefiles/7small.png" alt="CUPS-raster production using Ghostscript"></div></div><ns57:p> -</ns57:p><p> -CUPS versions before version 1.1.15 were shipping a binary (or source -code) standalone filter, named "pstoraster". pstoraster was derived -from GNU Ghostscript 5.50, and could be installed besides and in -addition to any GNU or AFPL Ghostscript package without conflicting. -</p><p> -From version 1.1.15, this has changed. The functions for this has been -integrated back into Ghostscript (now based on GNU Ghostscript version -7.05). The "pstoraster" filter is now a simple shell script calling -<b class="command">gs</b> with the <b class="command">-sDEVICE=cups</b> -parameter. If your Ghostscript doesn't show a success on asking for -<b class="command">gs -h |grep cups</b>, you might not be able to -print. Update your Ghostscript then! -</p></div><div xmlns:ns58="" class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2965317"></a>imagetops and imagetoraster</h3></div></div><div></div></div><p> -Above in the section about prefilters, we mentioned the prefilter -that generates PostScript from image formats. The imagetoraster -filter is used to convert directly from image to raster, without the -intermediate PostScript stage. It is used more often than the above -mentioned prefilters. Here is a summarizing flowchart of image file -filtering: -</p><ns58:p> -</ns58:p><div class="figure"><a name="id2965338"></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" alt="Image format to CUPS-raster format conversion"></div></div><ns58:p> -</ns58:p></div><div xmlns:ns59="" class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2965372"></a>rasterto [printers specific]</h3></div></div><div></div></div><p> -CUPS ships with quite some different raster drivers processing CUPS -raster. On my system I find in /usr/lib/cups/filter/ these: -<i class="parameter"><tt>rastertoalps, rastertobj, rastertoepson, rastertoescp, -rastertopcl, rastertoturboprint, rastertoapdk, rastertodymo, -rastertoescp, 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 3rd party driver -development projects (such as Gimp-Print) wanting to cooperate as -closely as possible with CUPS. -</p><ns59:p> -</ns59:p><div class="figure"><a name="id2965423"></a><p class="title"><b>Figure 19.9. Raster to Printer Specific formats</b></p><div class="mediaobject"><img src="projdoc/imagefiles/9small.png" alt="Raster to Printer Specific formats"></div></div><ns59:p> -</ns59:p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2965457"></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 printqueue needs to have a CUPS "device-URI" -associated with it. The device URI is the way to encode the backend -used to send the job to its destination. Network device-URIs are using -two slashes in their syntax, local device URIs only one, as you can -see from the following list. Keep in mind that local interface names -may vary much from my examples, if your OS is not Linux: -</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 to use are: -<tt class="filename">smb://workgroup/server/printersharename</tt> -Or -<tt class="filename">Smb://server/printersharename</tt> -or -<tt class="filename">smb://username:password@workgroup/server/printersharename</tt> -or -<tt class="filename">smb://username:password@server/printersharename</tt>. -The smb:// backend is a symlink to the Samba utility -<span class="emphasis"><em>smbspool</em></span> (doesn't 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 "special" printers which send -the printjobs as email (through a "mailto:/" backend), convert them to -PDF (through a "pdfgen:/" backend) or dump them to "/dev/null" (In -fact I have the system-wide default printer set up to be connected to -a "devnull:/" backend: there are just too many people sending jobs -without specifying a printer, or scripts and programs which don't name -a printer. The system-wide default deletes the job and sends a polite -mail back to the $USER asking him to always specify a correct -printername). -</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 <i class="parameter"><tt>-v</tt></i> parameter, it lists -all available backends: -</p><pre class="screen"> - - lpinfo -v - -</pre></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2965771"></a>cupsomatic/Foomatic -- how do they fit into the Picture?</h3></div></div><div></div></div><p> -"cupsomatic" filters may be the most widely used on CUPS -installations. You must be clear about the fact that these were not -developed by the CUPS people. They are a "Third Party" add-on to -CUPS. They utilize the traditional Ghostscript devices to render jobs -for CUPS. When troubleshooting, you should know about the -difference. Here the whole rendering process is done in one stage, -inside Ghostscript, using an appropriate "device" for the target -printer. cupsomatic uses PPDs which are generated from the "Foomatic" -Printer & Driver Database at Linuxprinting.org. -</p><p> -You can recognize these PPDs from the line calling the -<span class="emphasis"><em>cupsomatic</em></span> filter: -</p><pre class="screen"> - - *cupsFilter: "application/vnd.cups-postscript 0 cupsomatic" - -</pre><p> -This line you may find amongst the first 40 or so lines of the PPD -file. If you have such a PPD installed, the printer shows up in the -CUPS web interface with a <span class="emphasis"><em>foomatic</em></span> namepart for -the driver description. cupsomatic is a Perl script that runs -Ghostscript, with all the complicated commandline options -auto-constructed from the selected PPD and commandline options give to -the printjob. -</p><p> -However, cupsomatic is now deprecated. Its PPDs (especially the first -generation of them, still in heavy use out there) are not meeting the -Adobe specifications. You might also suffer difficulties when you try -to download them with "Point'n'Print" to Windows clients. A better, -and more powerful successor is now in a very stable Beta-version -available: it is called <span class="emphasis"><em>foomatic-rip</em></span>. To use -foomatic-rip as a filter with CUPS, you need the new-type PPDs. These -have a similar, but different line: -</p><pre class="screen"> - - *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, draft...) with a single click (whereas before you -could have required 5 or more different selections (media type, -resolution, inktype, dithering algorithm...). There is support for -custom-size media built in. There is support to switch -print-options from page to page, in the middle of a job. And the -best thing is: the new foomatic-rip now works seamlessly with all -legacy spoolers too (like LPRng, BSD-LPD, PDQ, PPR etc.), providing -for them access to use PPDs for their printing! -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2965874"></a>The Complete Picture</h3></div></div><div></div></div><p> -If you want to see an overview over all the filters and how they -relate to each other, the complete picture of the puzzle is at the end -of this document. -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2965889"></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 3rd column of the mime.convs file. They represent virtual costs -assigned to this filter. Every possible filtering chain will sum up to -a total "filter cost". CUPS decides for the most "inexpensive" route. -</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 a very efficient way to limit the load of any CUPS -server by setting an appropriate "FilterLimit" value. A FilterLimit of -200 allows roughly 1 job at a time, while a FilterLimit of 1000 allows -approximately 5 jobs maximum at a time. -</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2965942"></a>"Raw" printing</h3></div></div><div></div></div><p> -You can tell CUPS to print (nearly) any file "raw". "Raw" means it -will not be filtered. CUPS will send the file to the printer "as is" -without bothering if the printer is able to digest it. Users need to -take care themselves that they send sensible data formats only. Raw -printing can happen on any queue if the "-o raw" option is specified -on the command line. You can also set up raw-only queues by simply not -associating any PPD with it. This command: -</p><pre class="screen"> - - lpadmin -P rawprinter -v socket://11.12.13.14:9100 -E - -</pre><p> -sets up a queue named "rawprinter", connected via the "socket" -protocol (a.k.a. "HP JetDirect") to the device at IP address -11.12.1.3.14, using port 9100. (If you had added a PPD with -<b class="command">-P /path/to/PPD</b> to this command line, you would -have installed a "normal" printqueue. -</p><p> -CUPS will automatically treat each job sent to a queue as a "raw" one, -if it can't find a PPD associated with the queue. However, CUPS will -only send known MIME types (as defined in its own mime.types file) and -refuse others. -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2965996"></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 <span class="emphasis"><em>application/octet-stream</em></span> and will not be -sent. Because CUPS refuses to print unknown MIME types per default, -you will probably have experienced the fact that printjobs originating -from Windows clients were not printed. You may have found an error -message in your CUPS logs like: -</p><pre class="screen"> - - Unable to convert file 0 to printable format for job - -</pre><p> -To enable the printing of "application/octet-stream" 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 -application/octet-stream. In <tt class="filename">/etc/cups/mime.types</tt> -make sure this line is present: -</p><pre class="screen"> - - application/octet-stream - -</pre><p> -This line (with no specific auto-typing rule set) makes all files -not otherwise auto-typed a member of application/octet-stream. In -<tt class="filename">/etc/cups/mime.convs</tt>, have this -line: -</p><pre class="screen"> - - application/octet-stream application/vnd.cups-raw 0 - - -</pre><p> -This line tells CUPS to use the <span class="emphasis"><em>Null Filter</em></span> -(denoted as "-", doing... nothing at all) on -<span class="emphasis"><em>application/octet-stream</em></span>, and tag the result as -<span class="emphasis"><em>application/vnd.cups-raw</em></span>. 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> "raw" 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...) "Unknown" 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 "raw", 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 "rules" 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="id2966212"></a>PostScript Printer Descriptions (PPDs) for non-PS Printers</h3></div></div><div></div></div><p> -Originally PPDs were meant to be used for PostScript printers -only. Here, they help to send device-specific commands and settings -to the RIP which processes the jobfile. CUPS has extended this -scope for PPDs to cover non-PostScript printers too. This was not -very difficult, because it is a standardized file format. In a way -it was logical too: CUPS handles PostScript and uses a PostScript -RIP (=Ghostscript) to process the jobfiles. The only difference is: -a PostScript printer has the RIP built-in, for other types of -printers the Ghostscript RIP runs on the host computer. -</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: -</p><pre class="screen"> - - *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 "rastertoprinter". This filter -should be served as input an "application/vnd.cups-raster" MIME type -file. Therefore CUPS should auto-construct a filtering chain, which -delivers as its last output the specified MIME type. This is then -taken as input to the specified "rastertoprinter" filter. After this -the last filter has done its work ("rastertoprinter" is a Gimp-Print -filter), the file should go to the backend, which sends it to the -output device. -</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): -</p><div class="variablelist"><dl><dt><span class="term">deskjet.ppd</span></dt><dd><p>older HP inkjet printers and compatible -</p></dd><dt><span class="term">deskjet2.ppd</span></dt><dd><p>newer HP inkjet printers and compatible -</p></dd><dt><span class="term">dymo.ppd</span></dt><dd><p>label printers -</p></dd><dt><span class="term">epson9.ppd</span></dt><dd><p>Epson 24pin impact printers and compatible -</p></dd><dt><span class="term">epson24.ppd</span></dt><dd><p>Epson 24pin impact printers and compatible -</p></dd><dt><span class="term">okidata9.ppd</span></dt><dd><p>Okidata 9pin impact printers and compatible -</p></dd><dt><span class="term">okidat24.ppd</span></dt><dd><p>Okidata 24pin impact printers and compatible -</p></dd><dt><span class="term">stcolor.ppd</span></dt><dd><p>older Epson Stylus Color printers -</p></dd><dt><span class="term">stcolor2.ppd</span></dt><dd><p>newer Epson Stylus Color printers -</p></dd><dt><span class="term">stphoto.ppd</span></dt><dd><p>older Epson Stylus Photo printers -</p></dd><dt><span class="term">stphoto2.ppd</span></dt><dd><p>newer Epson Stylus Photo printers -</p></dd><dt><span class="term">laserjet.ppd</span></dt><dd><p>all PCL printers. Further below is a discussion -of several other driver/PPD-packages suitable fur use with CUPS. -</p></dd></dl></div></div><div xmlns:ns60="" class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2966439"></a>Difference between <span class="emphasis"><em>cupsomatic/foomatic-rip</em></span> and -<span class="emphasis"><em>native CUPS</em></span> printing</h3></div></div><div></div></div><p> -Native CUPS rasterization works in two steps. -</p><div class="itemizedlist"><ul type="disc"><li><p> -First is the "pstoraster" step. It uses the special "cups" -device from ESP Ghostscript 7.05.x as its tool -</p></li><li><p> -Second comes the "rasterdriver" 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, some are proprietary.</p></li></ul></div><p> -Often this produces better quality (and has several more -advantages) than other methods. -</p><ns60:p> -</ns60:p><div class="figure"><a name="id2966490"></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" alt="cupsomatic/foomatic processing versus Native CUPS"></div></div><ns60:p> -</ns60:p><p> -One other method is the <span class="emphasis"><em>cupsomatic/foomatic-rip</em></span> -way. Note that cupsomatic 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 (see also <a href="http://www.cups.org/cups-help.html" target="_top">http://www.cups.org/cups-help.html</a>). -cupsomatic is no longer developed and maintained and is no longer -supported. It has now been replaced by -<span class="emphasis"><em>foomatic-rip</em></span>. foomatic-rip is a complete re-write -of the old cupsomatic idea, but very much improved and generalized to -other (non-CUPS) spoolers. An upgrade to foomatic-rip is strongly -advised, especially if you are upgrading to a recent version of CUPS -too. -</p><p> -Both the cupsomatic (old) and the foomatic-rip (new) methods from -Linuxprinting.org use the traditional Ghostscript print file -processing, doing everything in a single step. It therefore relies on -all the other devices built-in into Ghostscript. The quality is as -good (or bad) as Ghostscript rendering is in other spoolers. The -advantage is that this method supports many printer models not -supported (yet) by the more modern CUPS method. -</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> -cupsomatic "kidnaps" the printfile after the -<span class="emphasis"><em>application/vnd.cups-postscript</em></span> stage and -deviates it through the CUPS-external, system wide Ghostscript -installation: Therefore the printfile bypasses the "pstoraster" filter -(and thus also bypasses the CUPS-raster-drivers -"rastertosomething"). After Ghostscript finished its rasterization, -cupsomatic hands the rendered file directly to the CUPS backend. The -flowchart above illustrates the difference between native CUPS -rendering and the Foomatic/cupsomatic method. -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2966596"></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 a HP JetDirect-connected -PostScript printer, but you want to print the pages 3-5, 7, 11-13 -only, and you want to print them "2-up" and "duplex": -</p><div class="itemizedlist"><ul type="disc"><li><p>your print options (page selection as required, 2-up, -duplex) are passed to CUPS on the commandline;</p></li><li><p>the (complete) PDF file is sent to CUPS and autotyped as -<span class="emphasis"><em>application/pdf</em></span>;</p></li><li><p>the file therefore first must pass the -<span class="emphasis"><em>pdftops</em></span> pre-filter, which produces PostScript -MIME type <span class="emphasis"><em>application/postscript</em></span> (a preview here -would still show all pages of the original PDF);</p></li><li><p>the file then passes the <span class="emphasis"><em>pstops</em></span> -filter which applies the commandline options: it selects the pages -2-5, 7 and 11-13, creates and imposed layout "2 pages on 1 sheet" and -inserts the correct "duplex" command (as is defined in the printer's -PPD) into the new PostScript file; the file now is of PostScript MIME -type -<span class="emphasis"><em>application/vnd.cups-postscript</em></span>;</p></li><li><p>the file goes to the <span class="emphasis"><em>socket</em></span> -backend, which transfers the job to the printers.</p></li></ul></div><p> -The resulting filter chain therefore is: -</p><pre class="screen"> -pdftops --> pstops --> socket -</pre><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, 2-up, -duplex) are passed to CUPS on the commandline;</p></li><li><p>the (complete) PDF file is sent to CUPS and autotyped as -<span class="emphasis"><em>application/pdf</em></span>;</p></li><li><p>the file therefore first must pass the -<span class="emphasis"><em>pdftops</em></span> pre-filter, which produces PostScript -MIME type <span class="emphasis"><em>application/postscript</em></span> (a preview here -would still show all pages of the original PDF);</p></li><li><p>the file then passes the "pstops" filter which applies -the commandline options: it selects the pages 2-5, 7 and 11-13, -creates and imposed layout "2 pages on 1 sheet" and inserts the -correct "duplex" command... (OOoops -- this printer and his PPD -don't support duplex printing at all -- this option will be ignored -then) into the new PostScript file; the file now is of PostScript -MIME type -<span class="emphasis"><em>application/vnd.cups-postscript</em></span>;</p></li><li><p>the file then passes the -<span class="emphasis"><em>pstoraster</em></span> stage and becomes MIME type -<span class="emphasis"><em>application/cups-raster</em></span>;</p></li><li><p>finally, the <span class="emphasis"><em>rastertoepson</em></span> filter -does its work (as is indicated in the printer's PPD), creating the -printer-specific raster data and embedding any user-selected -print-options into the print data stream;</p></li><li><p>the file goes to the <span class="emphasis"><em>usb</em></span> backend, -which transfers the job to the printers.</p></li></ul></div><p> -The resulting filter chain therefore is: -</p><pre class="screen"> -pdftops --> pstops --> pstoraster --> rastertoepson --> usb -</pre></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2966825"></a>Sources of CUPS drivers / PPDs</h3></div></div><div></div></div><p> -On the internet you can find now many thousand CUPS-PPD files -(with their companion filters), in many national languages, -supporting more than 1000 non-PostScript models. -</p><div class="itemizedlist"><ul type="disc"><li><p><a href="http://wwwl.easysw.com/printpro/" target="_top">ESP -PrintPro (http://wwwl.easysw.com/printpro/)</a> (commercial, -non-Free) is packaged with more than 3000 PPDs, ready for -successful use "out of the box" 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 <a href="http://gimp-print.sourceforge.net/" target="_top">Gimp-Print-Project -(http://gimp-print.sourceforge.net/)</a> (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><a href="http://www.turboprint.com/" target="_top">TurboPrint -(http://www.turboprint.com/)</a> (Shareware, non-Free) supports -roughly the same amount of printers in excellent -quality;</p></li><li><p><a href="http://www-124.ibm.com/developerworks/oss/linux/projects/omni/" target="_top">OMNI -(http://www-124.ibm.com/developerworks/oss/linux/projects/omni/)</a> -(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><a href="http://hpinkjet.sourceforge.net/" target="_top">HPIJS -(http://hpinkjet.sourceforge.net/)</a> (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><a href="http://www.linuxprinting.org/" target="_top">Foomatic/cupsomatic -(http://www.linuxprinting.org/)</a> (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 class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> -The cupsomatic/Foomatic trick from Linuxprinting.org works -differently from the other drivers. This is explained elsewhere in this -document. -</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2966950"></a>Printing with Interface Scripts</h3></div></div><div></div></div><p> -CUPS also supports the usage of "interface scripts" as known from -System V AT&T printing systems. These are often used for PCL -printers, from applications that generate PCL print jobs. Interface -scripts are specific to printer models. They have a similar role as -PPDs for PostScript printers. Interface scripts may inject the Escape -sequences as required into the print data stream, if the user has -chosen to select a certain paper tray, or print landscape, or use A3 -paper, etc. Interfaces scripts are practically unknown in the Linux -realm. On HP-UX platforms they are more often used. You can use any -working interface script on CUPS too. Just install the printer with -the <b class="command">-i</b> option: -</p><pre class="screen"> - - lpadmin -p pclprinter -v socket://11.12.13.14:9100 -i /path/to/interface-script - -</pre><p> -Interface scripts might be the "unknown animal" to many. However, -with CUPS they provide the most easy way to plug in your own -custom-written filtering script or program into one specific print -queue (some information about the traditional usage of interface scripts is -to be found at <a href="http://playground.sun.com/printing/documentation/interface.html" target="_top">http://playground.sun.com/printing/documentation/interface.html</a>). -</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2967012"></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 "purely Windows" 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="id2967028"></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 -</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, -or</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 below. -</p></div><div xmlns:ns61="" class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2967067"></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 traditional Unix-based print server can do too; and -at a better performance and more reliably than NT print server. This -is what most Samba administrators probably are familiar with. One -advantage of this setup is that this "spooling-only" print server may -be used even if no driver(s) for Unix are available it is sufficient -to have the Windows client drivers available and installed on the -clients. -</p><ns61:p> -</ns61:p><div class="figure"><a name="id2967092"></a><p class="title"><b>Figure 19.11. Print Driver execution on the Client</b></p><div class="mediaobject"><img src="projdoc/imagefiles/11small.png" alt="Print Driver execution on the Client"></div></div><ns61:p> -</ns61:p></div><div xmlns:ns62="" class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2967126"></a>Driver Execution on the Server</h3></div></div><div></div></div><p> -The other path executes the printer driver on the server. The clients -transfers print files in EMF format to the server. The server uses the -PostScript, PCL, ESC/P or other driver to convert the EMF file into -the printer-specific language. It is not possible for Unix to do the -same. Currently there is no program or method to convert a Windows -client's GDI output on a Unix server into something a printer could -understand. -</p><ns62:p> -</ns62:p><div class="figure"><a name="id2967148"></a><p class="title"><b>Figure 19.12. Print Driver execution on the Server</b></p><div class="mediaobject"><img src="projdoc/imagefiles/12small.png" alt="Print Driver execution on the Server"></div></div><ns62:p> -</ns62: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="id2967189"></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 doesn't limit your options all that -much. In the contrary, you may have a way here to implement printing -features which are not possible otherwise. -</p><div xmlns:ns63="" class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2967210"></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> -Firstly, to enable CUPS based printing through Samba the -following options should be set in your <tt class="filename">smb.conf</tt> file [globals] -section: -</p><div class="itemizedlist"><ul type="disc"><li><p><i class="parameter"><tt>printing = CUPS</tt></i></p></li><li><p><i class="parameter"><tt>printcap = CUPS</tt></i></p></li></ul></div><p> -When these parameters are specified, all manually set print directives -(like <i class="parameter"><tt>print command =...</tt></i>, or <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 it's application program interface (API) - -as long as Samba has been compiled with CUPS library (libcups) -support. If Samba has NOT been compiled with CUPS support, and if no -other print commands are set up, then printing will use the -<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 <i class="parameter"><tt>printing = sysv</tt></i>). -</p><ns63:p> -</ns63:p><div class="figure"><a name="id2967336"></a><p class="title"><b>Figure 19.13. Printing via CUPS/samba server</b></p><div class="mediaobject"><img src="projdoc/imagefiles/13small.png" alt="Printing via CUPS/samba server"></div></div><ns63:p> -</ns63:p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2967370"></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 <i class="parameter"><tt>path = /var/spool/samba</tt></i>, -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 re-start. We have -seen quite some people who had used a common spooling space for Samba -and CUPS, and were struggling for weeks with this "problem". -</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 "localhost" 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="id2967448"></a>Network PostScript RIP: CUPS Filters on Server -- clients use -PostScript Driver with CUPS-PPDs</h2></div></div><div></div></div><p> -PPDs can control all print device options. They are usually provided -by the manufacturer; if you own a PostScript printer, that is. PPD -files (PostScript Printer Descriptions) are always a component of -PostScript printer drivers on MS Windows or Apple Mac OS systems. They -are ASCII files containing user-selectable print options, mapped to -appropriate PostScript, PCL or PJL commands for the target -printer. Printer driver GUI dialogs translate these options -"on-the-fly" into buttons and drop-down lists for the user to select. -</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 <a href="http://localhost:631/printers/" target="_top">http://localhost:631/printers/</a> -and click on one <span class="emphasis"><em>Configure Printer</em></span> button to see -it), or a commandline interface (see <b class="command">man lpoptions</b> -or see if you have lphelp 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="id2967503"></a>PPDs for non-PS Printers on UNIX</h3></div></div><div></div></div><p> -CUPS doesn't limit itself to "real" PostScript printers in its usage -of PPDs. The CUPS developers have extended the scope of the PPD -concept, to also describe available device and driver options for -non-PostScript printers through CUPS-PPDs. -</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="id2967544"></a>PPDs for non-PS Printers on Windows</h3></div></div><div></div></div><p> -CUPS-PPDs can also be used on Windows-Clients, on top of a -"core" PostScript driver (now recommended is the "CUPS PostScript -Driver for WindowsNT/2K/XP"; you can also use the Adobe one, with -limitations). This feature enables CUPS to do a few tricks no other -spooler can do: -</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 can not happen with "raw" 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 too. -</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2967609"></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 need often a multitude of -non-PostScript drivers installed to run their clients' variety of -different printer models. This often imposes the price of much -increased instability. -</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2967626"></a>Printer Drivers running in "Kernel Mode" cause many -Problems</h3></div></div><div></div></div><p> -The reason is that in Win NT printer drivers run in "Kernel -Mode", this introduces a high risk for the stability of the system -if the driver is not really stable and well-tested. And there are a -lot of bad drivers out there! Especially notorious is the example -of the PCL printer driver that had an additional sound module -running, to notify users via soundcard of their finished jobs. Do I -need to say that this one was also reliably causing "Blue Screens -of Death" on a regular basis? -</p><p> -PostScript drivers generally are very well tested. They are not known -to cause any problems, even though they run in Kernel Mode too. This -might be because there have so far only been 2 different PostScript -drivers the ones from Adobe and the one from Microsoft. Both are -very well tested and are as stable as you ever can imagine on -Windows. The CUPS driver is derived from the Microsoft one. -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2967661"></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 restrict the allowed drivers installed -on their WTS to one generic PCL- and one PostScript driver. This -however restricts the clients in the amount of printer options -available for them; often they can't get out more than simplex -prints from one standard paper tray, while their devices could do much -better, if driven by a different driver! ) -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2967682"></a>CUPS: a "Magical Stone"?</h3></div></div><div></div></div><p> -Using a PostScript driver, enabled with a CUPS-PPD, seems to be a very -elegant way to overcome all these shortcomings. There are, depending -on the version of Windows OS you use, up to 3 different PostScript -drivers available: Adobe, Microsoft and CUPS PostScript drivers. None -of them is known to cause major stability problems on WTS (even if -used with many different PPDs). The clients will be able to (again) -chose paper trays, duplex printing and other settings. However, there -is a certain price for this too: a CUPS server acting as a PostScript -RIP for its clients requires more CPU and RAM than when just acting as -a "raw spooling" device. Plus, this setup is not yet widely tested, -although the first feedbacks look very promising. -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2967709"></a>PostScript Drivers with no major problems -- even in Kernel -Mode</h3></div></div><div></div></div><p> -More recent printer drivers on W2K and XP don't run in Kernel mode -(unlike Win NT) any more. However, both operating systems can still -use the NT drivers, running in Kernel mode (you can roughly tell which -is which as the drivers in subdirectory "2" of "W32X86" are "old" -ones). As was said before, the Adobe as well as the Microsoft -PostScript drivers are not known to cause any stability problems. The -CUPS driver is derived from the Microsoft one. There is a simple -reason for this: The MS DDK (Device Development Kit) for Win NT (which -used to be available at no cost to licensees of Visual Studio) -includes the source code of the Microsoft driver, and licensees of -Visual Studio are allowed to use and modify it for their own driver -development efforts. This is what the CUPS people have done. The -license doesn't allow them to publish the whole of the source code. -However, they have released the "diff" under the GPL, and if you are -owner of an "MS DDK for Win NT", you can check the driver yourself. -</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2967743"></a> Setting up 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/Win client -relationship. -</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2967762"></a><span class="emphasis"><em>cupsaddsmb</em></span>: the unknown Utility</h3></div></div><div></div></div><p> -The cupsaddsmb utility (shipped with all current CUPS versions) is an -alternative 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 very easy. cupsaddsmb can use the Adobe PostScript driver as -well as the newly developed <span class="emphasis"><em>CUPS PostScript Driver for -WinNT/2K/XP</em></span>. Note, that cupsaddsmb 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 need to get the respective part of Adobe driver -too 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="id2967853"></a>Prepare your <tt class="filename">smb.conf</tt> for -cupsaddsmb</h3></div></div><div></div></div><p> -Prior to running cupsaddsmb, you need the following settings in -<tt class="filename">smb.conf</tt>: -</p><pre class="screen"> - - [global] - load printers = yes - printing = cups - printcap name = cups - - [printers] - comment = All Printers - path = /var/spool/samba - browseable = no - public = yes - guest ok = yes # setting depends on your requirements - writable = no - printable = yes - printer admin = root - - [print$] - comment = Printer Drivers - path = /etc/samba/drivers - browseable = yes - guest ok = no - read only = yes - write list = root - -</pre></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2967900"></a>CUPS Package of "PostScript Driver for WinNT/2k/XP"</h3></div></div><div></div></div><p> -CUPS users may get the exactly same packages from<a href="http://www.cups.org/software.html" target="_top"><span class="emphasis"><em>http://www.cups.org/software.html</em></span></a>. -It is a separate package from the CUPS base software files, tagged as -<span class="emphasis"><em>CUPS 1.1.x Windows NT/2k/XP Printer Driver for SAMBA -(tar.gz, 192k)</em></span>. The filename to download is -<tt class="filename">cups-samba-1.1.x.tar.gz</tt>. Upon untar-/unzip-ing, -it will reveal these files: -</p><pre class="screen"> - -# tar xvzf cups-samba-1.1.19.tar.gz - - cups-samba.install - cups-samba.license - cups-samba.readme - cups-samba.remove - cups-samba.ss - -</pre><p> -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 untar-ed by "tar" -too). Then it puts the content into -<tt class="filename">/usr/share/cups/drivers/</tt>. This content includes 3 -files: -</p><pre class="screen"> - -# tar tv cups-samba.ss - - cupsdrvr.dll - cupsui.dll - cups.hlp - -</pre><p> -The <span class="emphasis"><em>cups-samba.install</em></span> shell scripts is easy to -handle: -</p><pre class="screen"> - -# ./cups-samba.install - - [....] - 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 -right place. -</p></div><pre class="screen"> - - cp /usr/share/drivers/cups.hlp /usr/share/cups/drivers/ - -</pre><p> -This new CUPS PostScript driver is currently binary-only, but free of -charge. No complete source code is provided (yet). The reason is this: -it has been developed with the help of the <span class="emphasis"><em>Microsoft Driver -Developer Kit</em></span> (DDK) and compiled with Microsoft Visual -Studio 6. Driver developers are not allowed to distribute the whole of -the source code as Free Software. However, CUPS developers released -the "diff" in source code under the GPL, so anybody with a license of -Visual Studio and a DDK will be able to compile for him/herself. -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2968097"></a>Recognize the different Driver Files</h3></div></div><div></div></div><p> -The CUPS drivers don't support the "older" Windows 95/98/ME, but only -the Windows NT/2000/XP client: -</p><pre class="screen"> - - [Windows NT, 2000, and XP are supported by:] - cups.hlp - cupsdrvr.dll - cupsui.dll - -</pre><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 for the -different platforms. -</p><pre class="screen"> - - [Windows 95, 98, and Me are supported by:] - ADFONTS.MFM - ADOBEPS4.DRV - ADOBEPS4.HLP - DEFPRTR2.PPD - ICONLIB.DLL - PSMON.DLL - - [Windows NT, 2000, and XP are supported by:] - ADOBEPS5.DLL - ADOBEPSU.DLL - ADOBEPSU.HLP - -</pre><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 WinNT/2k/XP are present in , the Adobe ones will be ignored -and the CUPS ones will be used. If you prefer -- for whatever reason --- to use Adobe-only drivers, move away the 3 CUPS driver files. The -Win95/98/ME clients use the Adobe drivers in any case. -</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2968155"></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 website as single -files and the self-extracting and/or self-installing Windows-exe is -not easy to locate either. Probably you need to use the included -native installer and run the installation process on one client -once. This will install the drivers (and one Generic PostScript -printer) locally on the client. When they are installed, share the -Generic PostScript printer. After this, the client's -<i class="parameter"><tt>[print$]</tt></i> share holds the Adobe files, from -where you can get them with smbclient from the CUPS host. A more -detailed description about this is in the next (the CUPS printing) -chapter. -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2968188"></a>ESP Print Pro Package of "PostScript Driver for -WinNT/2k/XP"</h3></div></div><div></div></div><p> -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<a href="http://www.easysw.com/software.html" target="_top">http://www.easysw.com/software.html</a>. -You need to locate the link labelled "SAMBA" amongst the -<span class="emphasis"><em>Download Printer Drivers for ESP Print Pro 4.x</em></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="emphasis"><em>Export Driver...</em></span> from the menu. Of -course you need to have prepared Samba beforehand too to handle the -driver files; i.e. mainly setup the <i class="parameter"><tt>[print$]</tt></i> -share, etc. The ESP Print Pro package includes the CUPS driver files -as well as a (licensed) set of Adobe drivers for the Windows 95/98/ME -client family. -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2968238"></a>Caveats to be considered</h3></div></div><div></div></div><p> -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 subdir -tree with <span class="emphasis"><em>WIN40</em></span> and -<span class="emphasis"><em>W32X86</em></span> branches): You do this by running -"cupsaddsmb" (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> -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 Win NT/2k/XP clients. -</p><div xmlns:ns64="" class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><ns64:p> -</ns64:p><div class="orderedlist"><ol type="1"><li><p> -Win 9x/ME clients won't work with the CUPS PostScript driver. For -these you'd still need to use the <tt class="filename">ADOBE*.*</tt> -drivers as previously. -</p></li><li><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 <span class="emphasis"><em>cupsaddsmb</em></span> (from 1.1.16) will -automatically prefer "its own" drivers if it finds both. -</p></li><li><p> -Should your Win 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/2k/XP -will fail at first. You need to wipe the old driver from the clients -first. It is not enough to "delete" the printer, as the driver files -will still be kept by the clients and re-used if you try to re-install -the printer. To really get rid of the Adobe driver files on the -clients, open the "Printers" folder (possibly via <span class="emphasis"><em>Start ---> Settings --> Control Panel --> Printers</em></span>), -right-click onto the folder background and select <span class="emphasis"><em>Server -Properties</em></span>. When the new dialog opens, select the -<span class="emphasis"><em>Drivers</em></span> tab. On the list select the driver you -want to delete and click on the <span class="emphasis"><em>Delete</em></span> -button. This will only work if there is not one single printer left -which uses that particular driver. You need to "delete" all printers -using this driver in the "Printers" folder first. You will need -Administrator privileges to do this. -</p></li><li><p> -Once you have successfully downloaded the CUPS PostScript driver to a -client, you can easily switch all printers to this one by proceeding -as described elsewhere in the "Samba HOWTO Collection": either change -a driver for an existing printer by running the "Printer Properties" -dialog, or use <b class="command">rpcclient</b> with the -<b class="command">setdriver</b> sub-command. -</p></li></ol></div><ns64:p> -</ns64:p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2968459"></a>What are the Benefits of using the "CUPS PostScript Driver for -Windows NT/2k/XP" as compared to the Adobe Driver?</h3></div></div><div></div></div><p> -You are interested in a comparison between the CUPS and the Adobe -PostScript drivers? For our purposes these are the most important -items which weigh in favor of the CUPS ones: -</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>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 "pstops" filter (to speak more -technically, it is not regarded as the generic MIME type -<span class="emphasis"><em>application/postscript</em></span>, but as -the more special MIME type -<span class="emphasis"><em>application/cups.vnd-postscript</em></span>), -which therefore also leads to the page accounting in -<span class="emphasis"><em>/var/log/cups/page_log</em></span> not -receiving the exact number of pages; instead the dummy page number -of "1" is logged in a standard setup)</p></li><li><p>the Adobe driver has more options to "mis-configure" the -PostScript generated by it (like setting it inadvertently to -<span class="emphasis"><em>Optimize for Speed</em></span>, instead of -<span class="emphasis"><em>Optimize for Portability</em></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 will be guaranteed to be auto-typed always -as generic MIME type <span class="emphasis"><em>application/postscript</em></span>, -thusly passing through the CUPS "pstops" 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 Win NT/2k/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 -<span class="emphasis"><em>page-label</em></span> option, setting a -<span class="emphasis"><em>job-priority</em></span> and setting the <span class="emphasis"><em>scheduled -time of printing</em></span> (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 <span class="emphasis"><em>*cupsJobTicket</em></span> 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/2K/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="id2968640"></a>Run "cupsaddsmb" (quiet Mode)</h3></div></div><div></div></div><p> -The cupsaddsmb 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 -towards Samba. If you have a small network you are probably using user -level security (<i class="parameter"><tt>security = user</tt></i>). Probably your -root has already a Samba account. Otherwise, create it now, using -<b class="command">smbpasswd</b>: -</p><pre class="screen"> - - # smbpasswd -a root - New SMB password: [type in password 'secret'] - Retype new SMB password: [type in password 'secret'] - -</pre><p> -Here is an example of a successfully run cupsaddsmb command. -</p><pre class="screen"> - - # cupsaddsmb -U root infotec_IS2027 - Password for root required to access localhost via SAMBA: [type in password 'secret'] - -</pre><p> -To share <span class="emphasis"><em>all</em></span> printers and drivers, use the -<i class="parameter"><tt>-a</tt></i> parameter instead of a printer name. Since -cupsaddsmb "exports" the printer drivers to Samba, it should be -obvious that it only works for queues with a CUPS driver associated. -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2968741"></a>Run "cupsaddsmb" with verbose Output</h3></div></div><div></div></div><p> -Probably you want to see what's going on. Use the -<i class="parameter"><tt>-v</tt></i> parameter to get a more verbose output. The -output below was edited for better readability: all "\" at the end of -a line indicate that I inserted an artificial line break plus some -indentation here: -</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. If you use remote access, the password will go over the wire -unencrypted! -</p></div><pre class="screen"> - - # cupsaddsmb -U root -v infotec_2105 - Password for root required to access localhost via SAMBA: - 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 (2328.8 kb/s) \ - (average 2328.8 kb/s) - putting file /usr/share/cups/drivers/cupsdrvr.dll as \W32X86/cupsdrvr.dll (9374.3 kb/s) \ - (average 5206.6 kb/s) - putting file /usr/share/cups/drivers/cupsui.dll as \W32X86/cupsui.dll (8107.2 kb/s) \ - (average 5984.1 kb/s) - putting file /usr/share/cups/drivers/cups.hlp as \W32X86/cups.hlp (3475.0 kb/s) \ - (average 5884.7 kb/s) - - 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 (2328.8 kb/s) \ - (average 2328.8 kb/s) - putting file /usr/share/cups/drivers/ADFONTS.MFM as \WIN40/ADFONTS.MFM (9368.0 kb/s) \ - (average 6469.6 kb/s) - putting file /usr/share/cups/drivers/ADOBEPS4.DRV as \WIN40/ADOBEPS4.DRV (9958.2 kb/s) \ - (average 8404.3 kb/s) - putting file /usr/share/cups/drivers/ADOBEPS4.HLP as \WIN40/ADOBEPS4.HLP (8341.5 kb/s) \ - (average 8398.6 kb/s) - putting file /usr/share/cups/drivers/DEFPRTR2.PPD as \WIN40/DEFPRTR2.PPD (2195.9 kb/s) \ - (average 8254.3 kb/s) - putting file /usr/share/cups/drivers/ICONLIB.DLL as \WIN40/ICONLIB.DLL (8239.9 kb/s) \ - (average 8253.6 kb/s) - putting file /usr/share/cups/drivers/PSMON.DLL as \WIN40/PSMON.DLL (6222.2 kb/s) \ - (average 8188.5 kb/s) - - 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 transfered -unencrypted over the wire, so beware! Also, if you look further her, -you'll discover error messages like NT_STATUS_OBJECT_NAME_COLLISION in -between. They occur, because the directories WIN40 and W32X86 already -existed in the <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="id2968884"></a>Understanding cupsaddsmb</h3></div></div><div></div></div><p> -What has happened? What did cupsaddsmb do? There are five stages of -the procedure -</p><div class="orderedlist"><ol type="1"><li><p>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 Win95/98/ME) and W32X86/ (for WinNT/2k/XP) sub - directories;</p></li><li><p>connect via rpcclient to the Samba server and -execute the "adddriver" command with the correct -parameters;</p></li><li><p>connect via rpcclient to the Samba server a second -time and execute the "setdriver" command.</p></li></ol></div><p> -Note, that you can run the cupsaddsmb utility with parameters to -specify one remote host as Samba host and a second remote host as CUPS -host. Especially if you want to get a deeper understanding, it is a -good idea try it and see more clearly what is going on (though in real -life most people will have their CUPS and Samba servers run on the -same host): -</p><pre class="screen"> - - # cupsaddsmb -H sambaserver -h cupsserver -v printername - -</pre></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2968978"></a>How to recognize if cupsaddsm 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 3 messages -amongst 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 == WinNT/2K/XP -architecture...)</p></li><li><p><span class="emphasis"><em>Printer Driver infotec_2105 successfully -installed.</em></span> # (for the WIN40 == Win9x/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 probably not easily recognized in the general -output. If you run cupsaddsmb with the <i class="parameter"><tt>-a</tt></i> -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 to install 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 don't run -cupsaddsmb in verbose mode. Therefore we strongly recommend to not -use the default quiet mode. It will hide any problems from you which -might occur. -</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2969065"></a>cupsaddsmb with a Samba PDC</h3></div></div><div></div></div><p> -You can't get the standard cupsaddsmb command to run on a Samba PDC? -You are asked for the password credential all over again and again and -the command just will not take off at all? Try one of these -variations: -</p><pre class="screen"> - - # cupsaddsmb -U DOMAINNAME\\root -v printername - # cupsaddsmb -H SAMBA-PDC -U DOMAINNAME\\root -v printername - # cupsaddsmb -H SAMBA-PDC -U DOMAINNAME\\root -h cups-server -v printername - -</pre><p> -(Note the two backslashes: the first one is required to -"escape" the second one). -</p></div><div xmlns:ns65="" class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2969100"></a>cupsaddsmb Flowchart</h3></div></div><div></div></div><p> -Here is a chart about the procedures, commandflows and -dataflows of the "cupaddsmb" command. Note again: cupsaddsmb is -not intended to, and does not work with, "raw" queues! -</p><ns65:p> -</ns65:p><div class="figure"><a name="id2969117"></a><p class="title"><b>Figure 19.14. cupsaddsmb flowchart</b></p><div class="mediaobject"><img src="projdoc/imagefiles/1small.png" alt="cupsaddsmb flowchart"></div></div><ns65:p> -</ns65:p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2969151"></a>Installing the PostScript Driver on a Client</h3></div></div><div></div></div><p> -After cupsaddsmb completed, your driver is prepared for the clients to -use. Here are the steps you must perform to download and install it -via "Point'n'Print". From a Windows client, browse to the CUPS/Samba -server; -</p><div class="itemizedlist"><ul type="disc"><li><p>open the <span class="emphasis"><em>Printers</em></span> -share of Samba in Network Neighbourhood;</p></li><li><p>right-click on the printer in -question;</p></li><li><p>from the opening context-menu select -<span class="emphasis"><em>Install...</em></span> or -<span class="emphasis"><em>Connect...</em></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> "Printers" 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 will appears in a -<tt class="filename">\\SambaServer\PrinterName</tt> entry in the -dropdown list of available printers. -</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> -cupsaddsmb will only reliably work with CUPS version 1.1.15 or higher -and Samba from 2.2.4. If it doesn't work, or if the automatic printer -driver download to the clients doesn't succeed, you can still manually -install the CUPS printer PPD on top of the Adobe PostScript driver on -clients. Then point the client's printer queue to the Samba printer -share for a UNC type of connection: -</p></div><pre class="screen"> - - net use lpt1: \\sambaserver\printershare /user:ntadmin - -</pre><p> -should you desire to use the CUPS networked PostScript RIP -functions. (Note that user "ntadmin" needs to be a valid Samba user -with the required privileges to access the printershare) This would -set up the printer connection in the traditional -<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="id2969266"></a>Avoiding critical PostScript Driver Settings on the -Client</h3></div></div><div></div></div><p> -Soooo: printing works, but there are still problems. Most jobs print -well, some don't print at all. Some jobs have problems with fonts, -which don't look very good. Some jobs print fast, and some are -dead-slow. Many of these problems can be greatly reduced or even -completely eliminated if you follow a few guidelines. Remember, if -your print device is not PostScript-enabled, you are treating your -Ghostscript installation on your CUPS host with the output your client -driver settings produce. Treat it well: -</p><div class="itemizedlist"><ul type="disc"><li><p>Avoid the <span class="emphasis"><em>PostScript Output Option: Optimize -for Speed</em></span> setting. Rather use the <span class="emphasis"><em>Optimize for -Portability</em></span> instead (Adobe PostScript -driver).</p></li><li><p>Don't use the <span class="emphasis"><em>Page Independence: -NO</em></span> setting. Instead use <span class="emphasis"><em>Page Independence -YES</em></span> (CUPS PostScript Driver)</p></li><li><p>Recommended is the <span class="emphasis"><em>True Type Font -Downloading Option: Native True Type</em></span> over -<span class="emphasis"><em>Automatic</em></span> and <span class="emphasis"><em>Outline</em></span>; you -should by all means avoid <span class="emphasis"><em>Bitmap</em></span> (Adobe -PostScript Driver)</p></li><li><p>Choose <span class="emphasis"><em>True Type Font: Download as Softfont -into Printer</em></span> over the default <span class="emphasis"><em>Replace by Device -Font</em></span> (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 <span class="emphasis"><em>PostScript Language -Level</em></span>: in case of problems try <span class="emphasis"><em>2</em></span> -instead of <span class="emphasis"><em>3</em></span> (the latest ESP Ghostscript package -handles Level 3 PostScript very well) (Adobe).</p></li><li><p>Say <span class="emphasis"><em>Yes</em></span> to <span class="emphasis"><em>PostScript -Error Handler</em></span> (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="id2969400"></a>Installing PostScript Driver Files manually (using -rpcclient)</h2></div></div><div></div></div><p> -Of course you can run all the commands which are embedded into the -cupsaddsmb convenience utility yourself, one by one, and hereby upload -and prepare the driver files for future client downloads. -</p><div class="orderedlist"><ol type="1"><li><p>prepare Samba (a CUPS printqueue 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>run <b class="command">rpcclient adddriver</b> -(for each client architecture you want to support):</p></li><li><p>run <b class="command">rpcclient -setdriver.</b></p></li></ol></div><p> -We are going to do this now. First, read the man page on "rpcclient" -to get a first idea. Look at all the printing related -sub-commands. <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 amongst -the most interesting ones. rpcclient implements an important part of -the MS-RPC protocol. You can use it to query (and command) a Win NT -(or 2K/XP) PC too. MS-RPC is used by Windows clients, amongst other -things, to benefit from the "Point'n'Print" features. Samba can now -mimic this too. -</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2969515"></a>A Check of the rpcclient man Page</h3></div></div><div></div></div><p> -First let's have a little check of the rpcclient man page. Here are -two relevant passages: -</p><p> -<b class="command">adddriver <arch> <config></b> Execute an -AddPrinterDriver() RPC to install the printer driver information on -the server. Note that the driver files should already exist in the -directory returned by <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 "NULL". </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 "NULL". -On a remote NT print server, the Print Monitor for a driver must -already be installed prior to adding the driver or else the RPC will -fail -</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 enumprinters and enumdrivers 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="id2969627"></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 "\". Usually you would type the -command in one line without the linebreaks: -</p><pre class="screen"> - - adddriver "Architecture" \ - "LongPrinterName:DriverFile:DataFile:ConfigFile:HelpFile:\ - LanguageMonitorFile:DataType:ListOfFiles,Comma-separated" - -</pre><p> -What the man pages denotes as a simple <config> -keyword, does in reality consist of 8 colon-separated fields. The -last field may take multiple (in some, very insane, cases, even -20 different additional files. This might sound confusing at first. -Note, that what the man pages names the "LongPrinterName" in -reality should rather be called the "Driver Name". You can name it -anything you want, as long as you use this name later in the -<span class="emphasis"><em>rpcclient ... setdriver</em></span> command. For -practical reasons, many name the driver the same as the -printer. -</p><p> -True: it isn't simple at all. I hear you asking: -<span class="emphasis"><em>How do I know which files are "Driver -File", "Data File", "Config File", "Help File" and "Language -Monitor File" in each case?</em></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 which we've read just -now. -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2969706"></a>Producing an Example by querying a Windows Box</h3></div></div><div></div></div><p> -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 UNIX or -Linux workstation with the Samba utilities installed. Then type the -following command: -</p><pre class="screen"> - - rpcclient -U'USERNAME%PASSWORD' NT-SERVER-NAME -c 'getdriver printername 3' - -</pre><p> -From the result it should become clear which is which. Here is an -example from my installation: -</p><pre class="screen"> - -# rpcclient -U'Danka%xxxx' W2KSERVER -c'getdriver "DANKA InfoStream Virtual Printer" 3' - cmd = getdriver "DANKA InfoStream Virtual Printer" 3 - - [Windows NT x86] - Printer Driver Info 3: - Version: [2] - Driver Name: [DANKA InfoStream] - Architecture: [Windows NT x86] - Driver Path: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\PSCRIPT.DLL] - Datafile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\INFOSTRM.PPD] - Configfile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\PSCRPTUI.DLL] - Helpfile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\PSCRIPT.HLP] - - Dependentfiles: [] - Dependentfiles: [] - Dependentfiles: [] - Dependentfiles: [] - Dependentfiles: [] - Dependentfiles: [] - Dependentfiles: [] - - Monitorname: [] - Defaultdatatype: [] - -</pre><p> -Some printer drivers list additional files under the label -"Dependentfiles": these would go into the last field -<span class="emphasis"><em>ListOfFiles,Comma-separated</em></span>. For the CUPS -PostScript drivers we don't need any (nor would we for the Adobe -PostScript driver): therefore the field will get a "NULL" entry. -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2969796"></a>What is required for adddriver and setdriver to succeed</h3></div></div><div></div></div><p> -From the manpage (and from the quoted output -of <span class="emphasis"><em>cupsaddsmb</em></span>, above) it becomes clear that you -need to have certain conditions in order to make the manual uploading -and initializing of the driver files succeed. The two rpcclient -subcommands (<b class="command">adddriver</b> and -<b class="command">setdriver</b>) need to encounter the following -pre-conditions to complete successfully: -</p><div class="itemizedlist"><ul type="disc"><li><p>you are connected as "printer admin", or root (note, -that this is <span class="emphasis"><em>not</em></span> the "Printer Operators" 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">\\sambaserver\print$\w32x86</tt> and -<tt class="filename">\\sambaserver\print$\win40</tt> as appropriate. They -will end up in the "0" respective "2" subdirectories later -- for now -<span class="emphasis"><em>don't</em></span> put them there, they'll be automatically -used by the <b class="command">adddriver</b> subcommand.! (if you use -"smbclient" to put the driver files into the share, note that you need -to escape the "$": <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>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 -rpcclient. 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 -shortly ago 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="id2969958"></a>Manual Commandline Driver Installation in 15 little 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="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2969975"></a>First Step: Install the Printer on CUPS</h4></div></div><div></div></div><pre class="screen"> - -# lpadmin -p mysmbtstprn -v socket://10.160.51.131:9100 -E -P /home/kurt/canonIR85.ppd - -</pre><p> -This installs printer with the name <span class="emphasis"><em>mysmbtstprn</em></span> -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></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2970005"></a>Second Step (optional): Check if the Printer is recognized by -Samba</h4></div></div><div></div></div><pre class="screen"> - - # rpcclient -Uroot%xxxx -c 'enumprinters' localhost | grep -C2 mysmbtstprn - - 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 re-start -the Samba daemon (smbd), or send a HUP signal: <b class="command">kill -HUP -`pidof smbd`</b>. Check again. Troubleshoot and repeat until -success. Note the "empty" field between the two commas in the -"description" line. Here would the driver name appear if there was one -already. You need to know root's Samba password (as set by the -<b class="command">smbpasswd</b> command) for this step and most of the -following steps. Alternatively you can authenticate as one of the -users from the "write list" as defined in <tt class="filename">smb.conf</tt> for -<i class="parameter"><tt>[print$]</tt></i>. -</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2970068"></a>Third Step (optional): Check if Samba knows a Driver for the -Printer</h4></div></div><div></div></div><pre class="screen"> - -# rpcclient -Uroot%xxxx -c 'getprinter mysmbtstprn 2' localhost | grep driver - drivername:[] - -# rpcclient -Uroot%xxxx -c 'getprinter mysmbtstprn 2' localhost | grep -C4 driv - servername:[\\kde-bitshop] - printername:[\\kde-bitshop\mysmbtstprn] - sharename:[mysmbtstprn] - portname:[Samba Printer Port] - drivername:[] - comment:[mysmbtstprn] - location:[] - sepfile:[] - printprocessor:[winprint] - -# rpcclient -U root%xxxx -c 'getdriver mysmbtstprn' localhost - result was WERR_UNKNOWN_PRINTER_DRIVER - -</pre><p> -Neither method 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: "The server has not the required printer -driver installed". -</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2970106"></a>Fourth Step: Put all required Driver Files into Samba's -[print$]</h4></div></div><div></div></div><pre class="screen"> - -# 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' - -</pre><p> -(Note that this command should be entered in one long single -line. Line-breaks and the line-end indicating "\" has been inserted -for readability reasons.) This step is <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 "not installed here" message. -</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2970157"></a>Fifth Step: Verify where the Driver Files are now</h4></div></div><div></div></div><pre class="screen"> - -# ls -l /etc/samba/drivers/W32X86/ - 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 "root" of -<i class="parameter"><tt>[print$]</tt></i>. -</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2970195"></a>Sixth Step: Tell Samba that these are -<span class="emphasis"><em>Driver</em></span> Files -(<b class="command">adddriver</b>)</h4></div></div><div></div></div><pre class="screen"> - -# rpcclient -Uroot%xxxx -c `adddriver "Windows NT x86" "mydrivername: \ - cupsdrvr.dll:mysmbtstprn.PPD: \ - cupsui.dll:cups.hlp:NULL:RAW[<span class="citation">:</span>]NULL" \ - localhost - - Printer Driver mydrivername successfully installed. - -</pre><p> -Note that your 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 "2" subdirectory. If this step fails, you -need to go back to the fourth step and repeat it, before you can try -this one again. In this step you need to choose a name for your -driver. It is normally a good idea to use the same name as is used for -the printername; however, in big installations you may use this driver -for a number of printers which have obviously different names. So the -name of the driver is not fixed. -</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2970250"></a>Seventh Step: Verify where the Driver Files are now</h4></div></div><div></div></div><pre class="screen"> - -# ls -l /etc/samba/drivers/W32X86/ - 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 - - -# ls -l /etc/samba/drivers/W32X86/2 - 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 did also move the driver files to the appropriate -subdirectory. Compare with the situation after step 5. -</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2970283"></a>Eighth Step (optional): Verify if Samba now recognizes the -Driver</h4></div></div><div></div></div><pre class="screen"> - -# rpcclient -Uroot%xxxx -c 'enumdrivers 3' localhost | grep -B2 -A5 mydrivername - - 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 did choose for the -driver in step Six. This command must succeed before you can proceed. -</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2970316"></a>Ninth Step: Tell Samba which Printer should use these Driver -Files (<b class="command">setdriver</b>)</h4></div></div><div></div></div><pre class="screen"> - -# rpcclient -Uroot%xxxx -c 'setdriver mysmbtstprn mydrivername' localhost - - Successfully set mysmbtstprn to driver mydrivername - -</pre><p> -Since you can bind any printername (=printqueue) to any driver, this -is a very convenient way to setup many queues which use the same -driver. You don't need to repeat all the previous steps for the -setdriver command to succeed. The only pre-conditions are: -<b class="command">enumdrivers</b> must find the driver and -<b class="command">enumprinters</b> must find the printer. -</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2970366"></a>Tenth Step (optional): Verify if Samba has this Association -recognized</h4></div></div><div></div></div><pre class="screen"> - -# rpcclient -Uroot%xxxx -c 'getprinter mysmbtstprn 2' localhost | grep driver - drivername:[mydrivername] - -# rpcclient -Uroot%xxxx -c 'getprinter mysmbtstprn 2' localhost | grep -C4 driv - servername:[\\kde-bitshop] - printername:[\\kde-bitshop\mysmbtstprn] - sharename:[mysmbtstprn] - portname:[Done] - drivername:[mydrivername] - comment:[mysmbtstprn] - location:[] - sepfile:[] - printprocessor:[winprint] - -# rpcclient -U root%xxxx -c 'getdriver mysmbtstprn' localhost - [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] - -# rpcclient -Uroot%xxxx -c 'enumprinters' localhost | grep mysmbtstprn - name:[\\kde-bitshop\mysmbtstprn] - description:[\\kde-bitshop\mysmbtstprn,mydrivername,mysmbtstprn] - comment:[mysmbtstprn] - -</pre><p> -Compare these results with the ones from steps 2 and 3. Note that -every single of these commands show the driver is installed. Even -the <b class="command">enumprinters</b> command now lists the driver -on the "description" line. -</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2970422"></a>Eleventh Step (optional): Tickle the Driver into a correct -Device Mode</h4></div></div><div></div></div><p> -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 Neighbourhood, go to the Samba server, 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 alternative way is to -open the "Printers (and Faxes)" folder, right-click on the printer in -question and select "Connect" or "Install". As a result, a new printer -should have appeared in your client's local "Printers (and Faxes)" -folder, named something like "printersharename on Sambahostname". -</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 commandline, which you may type -into the "DOS box" (type root's smbpassword when prompted): -</p><pre class="screen"> - - C:\> runas /netonly /user:root "rundll32 printui.dll,PrintUIEntry /in /n \\sambacupsserver\mysmbtstprn" - -</pre><p> -Change any printer setting once (like <span class="emphasis"><em>"portrait" ---> "landscape"</em></span>), click "Apply"; change the setting -back. -</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2970484"></a>Twelfth Step: Install the Printer on a Client -("Point'n'Print")</h4></div></div><div></div></div><pre class="screen"> - - C:\> rundll32 printui.dll,PrintUIEntry /in /n "\\sambacupsserver\mysmbtstprn" - -</pre><p> -If it doesn't work it could be a permission problem with the -<i class="parameter"><tt>[print$]</tt></i> share. -</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2970515"></a>Thirteenth Step (optional): Print a Test Page</h4></div></div><div></div></div><pre class="screen"> - - C:\> rundll32 printui.dll,PrintUIEntry /p /n "\\sambacupsserver\mysmbtstprn" - -</pre><p> -Then hit [TAB] 5 times, [ENTER] twice, [TAB] once and [ENTER] again -and march to the printer. -</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2970540"></a>Fourteenth Step (recommended): Study the Test Page</h4></div></div><div></div></div><p> -Hmmm.... just kidding! By now you know everything about printer -installations and you don't need to read a word. Just put it in a -frame and bolt it to the wall with the heading "MY FIRST -RPCCLIENT-INSTALLED PRINTER" - why not just throw it away! -</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2970558"></a>Fifteenth Step (obligatory): Enjoy. Jump. Celebrate your -Success</h4></div></div><div></div></div><pre class="screen"> - -# echo "Cheeeeerioooooo! Success..." >> /var/log/samba/log.smbd - -</pre></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2970578"></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 "adddriver" parts of the procedure? But you are also seeing -a disappointing message like this one beneath? -</p><pre class="screen"> - - result was NT_STATUS_UNSUCCESSFUL - -</pre><p> -It is not good enough that <span class="emphasis"><em>you</em></span> -can see the queue <span class="emphasis"><em>in CUPS</em></span>, 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 re-start Samba or send a HUP to all smbd -processes. To verify if this is the reason why Samba doesn't -execute the setdriver command successfully, check if Samba "sees" -the printer: -</p><pre class="screen"> - -# rpcclient transmeta -N -U'root%secret' -c 'enumprinters 0'| grep ir85wm - printername:[ir85wm] - -</pre><p> -An alternative command could be this: -</p><pre class="screen"> - -# rpcclient transmeta -N -U'root%secret' -c 'getprinter ir85wm' - cmd = getprinter ir85wm - flags:[0x800000] - name:[\\transmeta\ir85wm] - description:[\\transmeta\ir85wm,ir85wm,DPD] - comment:[CUPS PostScript-Treiber for WinNT/2K/XP] - -</pre><p> -BTW, 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="id2970680"></a>The printing <tt class="filename">*.tdb</tt> Files</h2></div></div><div></div></div><p> -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="id2970783"></a>Trivial DataBase Files</h3></div></div><div></div></div><p> -A Windows NT (Print) Server keeps track of all information needed to serve -its duty toward its clients by storing entries in the Windows -"Registry". Client queries are answered by reading from the registry, -Administrator or user configuration settings are saved by writing into -the Registry. Samba and Unix obviously don't have such a kind of -Registry. Samba instead keeps track of all client related information in a -series of <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="id2970853"></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. "Why not ASCII?", you may ask. "After all, -ASCII configuration files are a good and proofed tradition on UNIX." --- The reason for this design decision by the Samba Team is mainly -performance. Samba needs to be fast; it runs a separate -<b class="command">smbd</b> process for each client connection, in some -environments many thousand 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="id2970915"></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. You need to -re-create all print related setup after that. 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="id2970974"></a>Using <span class="emphasis"><em>tdbbackup</em></span></h3></div></div><div></div></div><p> -Samba ships with a little utility which helps the root user of your -system to back up your <tt class="filename">*.tdb</tt> files. If you run it -with no argument, it prints a little usage message: -</p><pre class="screen"> - -# tdbbackup - 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 printing.tdb file: -</p><pre class="screen"> - -# ls - . browse.dat locking.tdb ntdrivers.tdb printing.tdb share_info.tdb - .. connections.tdb messages.tdb ntforms.tdb printing.tdbkp unexpected.tdb - brlock.tdb gmon.out namelist.debug ntprinters.tdb sessionid.tdb - - kde-bitshop:/var/lock/samba # tdbbackup -s .bak printing.tdb - printing.tdb : 135 records - - kde-bitshop:/var/lock/samba # ls -l printing.tdb* - -rw------- 1 root root 40960 May 2 03:44 printing.tdb - -rw------- 1 root root 40960 May 2 03:44 printing.tdb.bak - -</pre></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2971036"></a>CUPS Print Drivers from Linuxprinting.org</h2></div></div><div></div></div><p> -CUPS ships with good support for HP LaserJet type printers. You can -install the generic driver as follows: -</p><pre class="screen"> - -lpadmin -p laserjet4plus -v parallel:/dev/lp0 -E -m laserjet.ppd - -</pre><p> -The <i class="parameter"><tt>-m</tt></i> 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>. Alternatively, you may use -<i class="parameter"><tt>-P /path/to/your.ppd</tt></i>. -</p><p> -The generic laserjet.ppd however does not support every special option -for every LaserJet-compatible model. It constitutes a sort of "least -denominator" of all the models. If for some reason it is ruled out to -you to pay for the commercially available ESP Print Pro drivers, your -first move should be to consult the database on <a href="http://www.linuxprinting.org/printer_list.cgi" target="_top">http://www.linuxprinting.org/printer_list.cgi</a>. -Linuxprinting.org has excellent recommendations about which driver is -best used for each printer. Its database is kept current by the -tireless work of Till Kamppeter from MandrakeSoft, who is also the -principal author of the foomatic-rip utility. -</p><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p> -The former "cupsomatic" concept is now be replaced by the new, much -more powerful "foomatic-rip". foomatic-rip is the successor of -cupsomatic. cupsomatic is no longer maintained. Here is the new URL -to the Foomatic-3.0 database:<a href="http://www.linuxprinting.org/driver_list.cgi" target="_top">http://www.linuxprinting.org/driver_list.cgi</a>. -If you upgrade to foomatic-rip, don't forget to also upgrade to the -new-style PPDs for your foomatic-driven printers. foomatic-rip will -not work with PPDs generated for the old cupsomatic. The new-style -PPDs are 100% compliant to the Adobe PPD specification. They are -intended to be used by Samba and the cupsaddsmb utility also, to -provide the driver files for the Windows clients also! -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2971142"></a>foomatic-rip and Foomatic explained</h3></div></div><div></div></div><p> -Nowadays most Linux distros rely on the utilities of Linuxprinting.org -to create their printing related software (which, BTW, works on all -UNIXes and on Mac OS X or Darwin too). It is not known as well as it -should be, that it also has a very end-user friendly interface which -allows for an easy update of drivers and PPDs, for all supported -models, all spoolers, all operating systems and all package formats -(because there is none). Its history goes back a few years. -</p><p> -Recently Foomatic has achieved the astonishing milestone of <a href="http://www.linuxprinting.org/printer_list.cgi?make=Anyone" target="_top">1000 -listed</a> 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 <a href="http://www.linuxprinting.org/foomatic.html" target="_top">Foomatic</a> -database. Currently there are <a href="http://www.linuxprinting.org/driver_list.cgi" target="_top">245 drivers</a> -in the database: many drivers support various models, and many models -may be driven by different drivers; it's your choice! -</p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2971197"></a>690 "perfect" 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 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 -doesn't 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="id2971222"></a>How the "Printing HOWTO" started it all</h4></div></div><div></div></div><p> -A few years ago <a href="http://www2.picante.com:81/~gtaylor/" target="_top">Grant Taylor</a> -started it all. The roots of today's Linuxprinting.org are in the -first <a href="http://www.linuxprinting.org/foomatic2.9/howto/" target="_top">Linux Printing -HOWTO</a> which he authored. As a side-project to this document, -which served many Linux users and admins to guide their first steps in -this complicated and delicate setup (to a scientist, printing is -"applying a structured deposition of distinct patterns of ink or toner -particles on paper substrates" <span class="emphasis"><em>;-)</em></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="id2971267"></a>Foomatic's strange Name</h4></div></div><div></div></div><p> -"Why the funny name?", you ask. When it really took off, around spring -2000, CUPS was far less popular than today, and most systems used LPD, -LPRng or even PDQ to print. CUPS shipped with a few generic "drivers" -(good for a few hundred different printer models). These didn't -support many device-specific options. CUPS also shipped with its own -built-in rasterization filter ("pstoraster", derived from -Ghostscript). On the other hand, CUPS 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> -Grant already had in his database a respectable compilation -of facts about a many more printers, and the Ghostscript "drivers" -they run with. His idea, to generate PPDs from the database info -and use them to make standard Ghostscript filters work within CUPS, -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="id2971334"></a>cupsomatic, pdqomatic, lpdomatic, directomatic</h4></div></div><div></div></div><p> -CUPS worked through a quickly-hacked up filter script named <a href="http://www.linuxprinting.org/download.cgi?filename=cupsomatic&show=0" target="_top">cupsomatic</a>. -cupsomatic ran the printfile through Ghostscript, constructing -automatically the rather complicated command line needed. It just -required to be copied into the CUPS system to make it work. To -"configure" the way cupsomatic controls the Ghostscript rendering -process, it needs a CUPS-PPD. This PPD is generated directly from the -contents of the database. For CUPS and the respective printer/filter -combo another Perl script named "CUPS-O-Matic" did the PPD -generation. After that was working, Grant implemented within a few -days a similar thing for two other spoolers. Names chosen for the -config-generator scripts were <a href="http://www.linuxprinting.org/download.cgi?filename=lpdomatic&show=0" target="_top">PDQ-O-Matic</a> -(for PDQ) and <a href="http://www.linuxprinting.org/download.cgi?filename=lpdomatic&show=0" target="_top">LPD-O-Matic</a> -(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, <a href="http://www.linuxprinting.org/till/" target="_top">Till Kamppeter</a> -started to put work into the database. Till had been newly employed by -<a href="http://www.mandrakesoft.com/" target="_top">MandrakeSoft</a> to -convert their printing system over to CUPS, after they had seen his -<a href="http://www.fltk.org/" target="_top">FLTK</a>-based <a href="http://cups.sourceforge.net/xpp/" target="_top">XPP</a> (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 -<a href="http://ppr.sourceforge.net/" target="_top">PPR</a> (via ppromatic), -<a href="http://sourceforge.net/projects/lpr/" target="_top">GNUlpr</a> and -<a href="http://www.lprng.org/" target="_top">LPRng</a> (both via an extended -lpdomatic) and "spoolerless" printing (<a href="http://www.linuxprinting.org/download.cgi?filename=directomatic&show=0" target="_top">directomatic</a>).... -</p><p> -So, to answer your question: "Foomatic" is the general name for all -the overlapping code and data behind the "*omatic" scripts.... -- -Foomatic up to versions 2.0.x required (ugly) Perl data structures -attached the Linuxprinting.org PPDs for CUPS. It had a different -"*omatic" script for every spooler, as well as different printer -configuration files.. -</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id2971466"></a>7.13.1.5.The <span class="emphasis"><em>Grand Unification</em></span> -achieved...</h4></div></div><div></div></div><p> -This all has changed in Foomatic versions 2.9 (Beta) and released as -"stable" 3.0. This has now achieved the convergence of all *omatic -scripts: it is called the <a href="http://www.linuxprinting.org/foomatic2.9/download.cgi?filename=foomatic-rip&show=0" target="_top">foomatic-rip</a>. -This single script is the unification of the previously different -spooler-specific *omatic scripts. foomatic-rip is used by all the -different spoolers alike. Because foomatic-rip can read PPDs (both 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 doesn't contain -Perl data structures any more. If you are a distro maintainer and have -used the previous version of Foomatic, you may want to give the new -one a spin: but don't forget to generate a new-version set of PPDs, -via the new <a href="http://www.linuxprinting.org/download/foomatic/foomatic-db-engine-3.0.0beta1.tar.gz" target="_top">foomatic-db-engine</a>! -Individual users just need to generate a single new PPD specific to -their model by <a href="http://www.linuxprinting.org/kpfeifle/LinuxKongress2002/Tutorial/II.Foomatic-User/II.tutorial-handout-foomatic-user.html" target="_top">following -the steps</a> outlined in the Foomatic tutorial or further -below. 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, different options, different -device selections and/or different filters for each different printer -or different spooler. At the same time it can read the PPD associated -with a print queue and modify the print job according to the user -selections. Together with this comes the 100% compliance of the new -Foomatic PPDs with the Adobe spec. Some really innovative features of -the Foomatic concept will surprise users: it will support custom paper -sizes for many printers; and it 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="id2971554"></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><a href="http://www-124.ibm.com/developerworks/oss/linux/projects/omni/" target="_top">Omni</a> --- a Free Software project by IBM which 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><a href="http://hpinkjet.sf.net/" target="_top">HPIJS</a> -- -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><a href="http://gimp-print.sf.net/" target="_top">Gimp-Print</a> -- 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="id2971632"></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 <a href="http://www.linuxprinting.org//kpfeifle/LinuxKongress2002/Tutorial/" target="_top">tutorials</a> -or solve printing problems in its popular <a href="http://www.linuxprinting.org/newsportal/" target="_top">forums</a>. But -it's not just for GNU/Linux: users and admins of <a href="http://www.linuxprinting.org/macosx/" target="_top">commercial UNIX -systems</a> are also going there, and the relatively new <a href="http://www.linuxprinting.org/newsportal/thread.php3?name=linuxprinting.macosx.general" target="_top">Mac -OS X forum</a> has turned out to be one of the most frequented -fora 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 Till (who works at Mandrake), many -additional contributions came from engineers with SuSE, RedHat, -Connectiva, Debian and others. Vendor-neutrality is an important goal -of the 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="id2971705"></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 don't normally drive PostScript -printers: they are used to describe all the bells and whistles you -could ring or blow on an Epson Stylus inkjet, or a HP Photosmart or -what-have-you. The main "trick" is one little additional line, not -envisaged by the PPD specification, starting with the "*cupsFilter" -keyword: it tells the CUPS daemon how to proceed with the PostScript -print file (old-style Foomatic-PPDs named the -<span class="emphasis"><em>cupsomatic</em></span> filter script, while the new-style -PPDs now call <span class="emphasis"><em>foomatic-rip</em></span>). This filter -script calls Ghostscript on the host system (the recommended variant -is ESP Ghostscript) to do the rendering work. foomatic-rip knows which -filter or internal device setting it should ask from Ghostscript to -convert the PostScript printjob into a raster format ready for the -target device. This usage of PPDs to describe the options of non-PS -printers was the invention of the CUPS developers. The rest is easy: -GUI tools (like KDE's marvellous <a href="http://printing.kde.org/overview/kprinter.phtml" target="_top">"kprinter"</a>, -or the GNOME <a href="http://gtklp.sourceforge.net/" target="_top">"gtklp"</a>, "xpp" and the CUPS -web interface) read the PPD too 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="id2971770"></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 foomatic-rip utility. going directly to -Linuxprinting.org ensures you to get the latest driver/PPD files): -</p><div class="itemizedlist"><ul type="disc"><li><p>Surf to <a href="http://www.linuxprinting.org/printer_list.cgi" target="_top">http://www.linuxprinting.org/printer_list.cgi</a> -</p></li><li><p>Check the complete list of printers in the database: -<a href="http://www.linuxprinting.org/printer_list.cgi?make=Anyone" target="_top">http://www.linuxprinting.org/printer_list.cgi?make=Anyone</a> -</p></li><li><p>There 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 here: -<a href="http://www.linuxprinting.org/show_printer.cgi?recnum=HP-LaserJet_4_Plus" target="_top">http://www.linuxprinting.org/show_printer.cgi?recnum=HP-LaserJet_4_Plus</a> -</p></li><li><p>The recommended driver is "ljet4".</p></li><li><p>There are several links 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 "ljet4": -<a href="http://www.linuxprinting.org/show_driver.cgi?driver=ljet4" target="_top">http://www.linuxprinting.org/show_driver.cgi?driver=ljet4</a> -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 which provide hints with -setup instructions for CUPS (<a href="http://www.linuxprinting.org/cups-doc.html" target="_top">http://www.linuxprinting.org/cups-doc.html</a>), -PDQ (<a href="http://www.linuxprinting.org/pdq-doc.html" target="_top">http://www.linuxprinting.org/pdq-doc.html</a>), -LPD, LPRng and GNUlpr (<a href="http://www.linuxprinting.org/lpd-doc.html" target="_top">http://www.linuxprinting.org/lpd-doc.html</a>) -as well as PPR (<a href="http://www.linuxprinting.org/ppr-doc.html" target="_top">http://www.linuxprinting.org/ppr-doc.html)</a> -or "spooler-less" printing (<a href="http://www.linuxprinting.org/direct-doc.html" target="_top">http://www.linuxprinting.org/direct-doc.html</a> -).</p></li><li><p>You can view the PPD in your browser through this -link: <a href="http://www.linuxprinting.org/ppd-o-matic.cgi?driver=ljet4&printer=HP-LaserJet_4_Plus&show=1" target="_top">http://www.linuxprinting.org/ppd-o-matic.cgi?driver=ljet4&printer=HP-LaserJet_4_Plus&show=1</a> -</p></li><li><p>You can also (most importantly) -generate and download the PPD: <a href="http://www.linuxprinting.org/ppd-o-matic.cgi?driver=ljet4&printer=HP-LaserJet_4_Plus&show=0" target="_top">http://www.linuxprinting.org/ppd-o-matic.cgi?driver=ljet4&printer=HP-LaserJet_4_Plus&show=0</a> -</p></li><li><p>The PPD contains all the information needed to use our -model and the driver; this is, once installed, working transparently -for the user. Later you'll only need to choose resolution, paper size -etc. from the web-based menu, or from the print dialog GUI, or from -the commandline.</p></li><li><p>Should you have ended up on the driver's page (<a href="http://www.linuxprinting.org/show_driver.cgi?driver=ljet4" target="_top">http://www.linuxprinting.org/show_driver.cgi?driver=ljet4</a>), -you can choose to use the "PPD-O-Matic" online PPD generator -program.</p></li><li><p>Select the exact model and check either "download" or -"display PPD file" and click on "Generate PPD file".</p></li><li><p>If you save the PPD file from the browser view, please -don't use "cut'n'past" (since it could possibly damage line endings -and tabs, which makes the PPD likely to fail its duty), but use "Save -as..." in your browser's menu. (Best is to use the "download" option -from the web page directly).</p></li><li><p>Another very interesting part on each driver page is -the <span class="emphasis"><em>Show execution details</em></span> button. If you -select your printer model and click that button, you will get -displayed a complete Ghostscript command line, enumerating all options -available for that driver/printermodel combo. This is a great way to -"Learn Ghostscript By Doing". 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 re-start -cupsd).</p></li><li><p>Then install the printer with a suitable commandline, -e.g.: -</p><pre class="screen"> - -lpadmin -p laserjet4plus -v parallel:/dev/lp0 -E -P path/to/my-printer.ppd - -</pre></li><li><p>Note again this: for all the new-style "Foomatic-PPDs" -from Linuxprinting.org, you also need a special "CUPS filter" named -"foomatic-rip".Get the latest version of "foomatic-rip" from: <a href="http://www.linuxprinting.org/foomatic2.9/download.cgi?filename=foomatic-rip&show=0" target="_top">http://www.linuxprinting.org/foomatic2.9/download.cgi?filename=foomatic-rip&show=0</a> -</p></li><li><p>The foomatic-rip Perlscript itself also makes some -interesting reading (<a href="http://www.linuxprinting.org/foomatic2.9/download.cgi?filename=foomatic-rip&show=1" target="_top">http://www.linuxprinting.org/foomatic2.9/download.cgi?filename=foomatic-rip&show=1</a>), -because it is very well documented by Till'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 don't forget to make it world-executable). Again, -don't save by "copy'n'paste" but use the appropriate link, or the -"Save as..." menu item in your browser.</p></li><li><p>If you save foomatic-rip in your $PATH, create a symlink: -<b class="command">cd /usr/lib/cups/filter/ ; ln -s `which -foomatic-rip`</b>. For CUPS to discover this new -available filter at startup, you need to re-start -cupsd.</p></li></ul></div><p> -Once you print to a printqueue set up with the Foomatic-PPD, CUPS will -insert the appropriate commands and comments into the resulting -PostScript jobfile. foomatic-rip is able to read and act upon -these. foomatic-rip uses some specially encoded Foomatic comments, -embedded in the jobfile. These in turn are used to construct -(transparently for you, the user) the complicated ghostscript command -line telling for the printer driver how exactly the resulting raster -data should look like and which printer commands to embed into the -data stream. -</p><p> -You need: -</p><div class="itemizedlist"><ul type="disc"><li><p>A "foomatic+something" PPD -- but it this not enough -to print with CUPS (it is only <span class="emphasis"><em>one</em></span> important -component)</p></li><li><p>The "foomatic-rip" filter script (Perl) in -/usr/lib/cups/filters/</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 printermodel'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 "gs --h")</p></li><li><p>foomatic-rip needs a new version of PPDs (PPD versions -produced for cupsomatic don't 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="id2972228"></a>Page Accounting with CUPS</h2></div></div><div></div></div><p> -Often there are questions regarding "print quotas" wherein Samba users -(that is, Windows clients) should not be able to print beyond a -certain amount of pages or data volume per day, week or month. This -feature is dependent on the real print subsystem you're using. -Samba's part is always to receive the job files from the clients -(filtered <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" which can be based on sizes of -jobs or on the number of pages or both, and are spanning any time -period you want. -</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2972259"></a>Setting up Quotas</h3></div></div><div></div></div><p> -This is an example command how root would set a print quota in CUPS, -assuming an existing printer named "quotaprinter": -</p><pre class="screen"> - - lpadmin -p quotaprinter -o job-quota-period=604800 -o job-k-limit=1024 -o job-page-limit=100 - -</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="id2972290"></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 "1". Some -printfiles don't pass it (eg: image files) but then those are mostly 1 -page jobs anyway. This also means that proprietary drivers for the -target printer running on the client computers and CUPS/Samba, which -then spool these files as "raw" (i.e. leaving them untouched, not -filtering them), will be counted as "1-pagers" too! -</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 -will be working for currently about 1,000 different printer models, -see <a href="http://www.linuxprinting.org/printer_list.cgi" target="_top">http://www.linuxprinting.org/printer_list.cgi</a>). -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2972331"></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 "pstops" filter on the CUPS/Samba side, and -therefore was not counted correctly (the reason is that it often, -depending on the "PPD" being used, wrote a "PJL"-header in front of -the real PostScript which caused CUPS to skip pstops and go directly -to the "pstoraster" stage). -</p><p> -From CUPS-1.1.16 onward you can use the "CUPS PostScript Driver for -Windows NT/2K/XP clients" (which is tagged in the download area of -http://www.cups.org/ as the "cups-samba-1.1.16.tar.gz" package). It does -<span class="emphasis"><em>not</em></span> work for Win9x/ME clients. But it guarantees: -</p><div class="itemizedlist"><ul type="disc"><li><p>to not write an 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 "pstops" filter -on the CUPS/Samba server</p></li><li><p>to page-count correctly the -printfile</p></li></ul></div><p> -You can read more about the setup of this combination in the manpage -for "cupsaddsmb" (which is only present with CUPS installed, and only -current from CUPS 1.1.16). -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2972403"></a>The page_log File Syntax</h3></div></div><div></div></div><p> -These are the items CUPS logs in the "page_log" for every -single <span class="emphasis"><em>page</em></span> 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 which sent the job (included since version -1.1.19)</p></li></ul></div><p> -Here is an extract of my CUPS server's page_log file to illustrate the -format and included items: -</p><pre class="screen"> - - infotec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 1 3 #marketing 10.160.50.13 - infotec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 2 3 #marketing 10.160.50.13 - infotec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 3 3 #marketing 10.160.50.13 - infotec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 4 3 #marketing 10.160.50.13 - DigiMaster9110 boss 402 [22/Apr/2003:10:33:22 +0100] 1 440 finance-dep 10.160.51.33 - -</pre><p> -This was job ID "401", printed on "infotec_IS2027" by user "kurt", a -64-page job printed in 3 copies and billed to "#marketing", sent -from IP address 10.160.50.13. The next job had ID "402", was sent by -user "boss" from IP address 10.160.51.33,printed from one page 440 -copies and is set to be billed to "finance-dep". -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2972504"></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, etc.)</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 5th sheet out -of 1000 and the job is aborted by the printer, the "page count" will -still show the figure of 1000 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) no support for -groups</p></li><li><p>no means to read out the current balance or the -"used-up" number of current quota</p></li><li><p>a user having used up 99 sheets of 100 quota will -still be able to send and print a 1,000 sheet job</p></li><li><p>a user being denied a job because of a filled-up quota -doesn't get a meaningful error message from CUPS other than -"client-error-not-possible".</p></li></ul></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2972576"></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 5th 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 -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 class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2972624"></a>Other Accounting Tools</h3></div></div><div></div></div><p> -PrintAnalyzer, pyKota, printbill, LogReport. -</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2972639"></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 -"raw" printer and all files will go directly there as received by the -spooler. The exceptions are file types "application/octet-stream" -which need "passthrough feature" enabled. "Raw" queues don't do any -filtering at all, they hand the file directly to the CUPS backend. -This backend is responsible for the sending of the data to the device -(as in the "device URI" notation: <tt class="filename">lpd://, socket://, -smb://, ipp://, http://, parallel:/, serial:/, usb:/</tt> etc.) -</p><p> -"cupsomatic"/Foomatic are <span class="emphasis"><em>not</em></span> native CUPS drivers -and they don't 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. "cupsomatic" is only a vehicle to execute a -ghostscript commandline at that stage in the CUPS filtering chain, -where "normally" the native CUPS "pstoraster" filter would kick -in. cupsomatic by-passes pstoraster, "kidnaps" the printfile from CUPS -away and re-directs it to go through Ghostscript. CUPS accepts this, -because the associated CUPS-O-Matic-/Foomatic-PPD specifies: -</p><pre class="screen"> - - *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 -"application/vnd.cups-postscript". This conversion will not happen for -Jobs arriving from Windows which are auto-typed -"application/octet-stream", 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="screen"> - - 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 "-"). 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="screen"> - - */* 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> -Lastly, you could have the following entry: -</p><pre class="screen"> - - application/vnd.cups-postscript application/vnd.cups-raw 0 my_PJL_stripping_filter - -</pre><p> -You will need to write a <span class="emphasis"><em>my_PJL_stripping_filter</em></span> -(could be a shellscript) that parses the PostScript and removes the -unwanted PJL. This would need 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 would be installed as world executable into -<tt class="filename">/usr/lib/cups/filters/</tt> and will be called by CUPS -if it encounters a MIME type "application/vnd.cups-postscript". -</p><p> -CUPS can handle <span class="emphasis"><em>-o job-hold-until=indefinite</em></span>. -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, etc.). -</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2972832"></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 <span class="emphasis"><em>path = -/var/spool/samba</em></span> directive in the -<span class="emphasis"><em>[printers]</em></span> 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 cupsd.conf -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="id2972878"></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" etc. files in the CUPS spool directory, which do a -similar job as the old-fashioned BSD-LPD control files). This is set -to "Yes" 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 -(well it keeps the "d12345", "d12346" etc. files in the CUPS spool -directory...). This is set to "No" as the CUPS -default. -</p></dd><dt><span class="term"><span class="emphasis"><em>"MaxJobs 500"</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 "MaxJobsPerUser" and -"MaxJobsPerPrinter"...) -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2972960"></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 which is compiled against "libcups" (Check -on Linux by running "ldd `which smbd`")</p></li><li><p>a Samba-<tt class="filename">smb.conf</tt> setting of -"printing = cups"</p></li><li><p>another Samba-<tt class="filename">smb.conf</tt> setting of -"printcap = 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 -"print command", "lpq command", "lprm command", "lppause command" or -"lpresume command") are ignored and they should normally have no -influence what-so-ever on your printing. -</p></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2973021"></a>Manual Configuration</h3></div></div><div></div></div><p> -If you want to do things manually, replace the "printing = -cups" by "printing = bsd". Then your manually set commands may work -(haven't tested this), and a "print command = lp -d %P %s; rm %s" -may do what you need. -</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2973039"></a>When <span class="emphasis"><em>not</em></span> to use Samba to print to -CUPS</h2></div></div><div></div></div><p> -[TO BE DONE] -</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2973056"></a>In Case of Trouble.....</h2></div></div><div></div></div><p> -If you have more problems, post the output of these commands -to the CUPS or Samba mailing lists (choose the one which seems more -relevant to your problem): -</p><pre class="screen"> - - grep -v ^# /etc/cups/cupsd.conf | grep -v ^$ - grep -v ^# /etc/samba/smb.conf | grep -v ^$ | grep -v "^;" - -</pre><p> -(adapt paths as needed). These commands leave out the empty -lines and lines with comments, providing the "naked settings" in a -compact way. Don't forget to name the CUPS and Samba versions you -are using! This saves bandwidth and makes for easier readability -for experts (and you are expecting experts to read them, right? -;-) -</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2973091"></a>Where to find Documentation</h3></div></div><div></div></div><p> -[TO BE DONE] -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2973104"></a>How to ask for Help</h3></div></div><div></div></div><p> -[TO BE DONE] -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2973117"></a>Where to find Help</h3></div></div><div></div></div><p> -[TO BE DONE] -</p></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id2973131"></a>Appendix</h2></div></div><div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2973138"></a>Printing <span class="emphasis"><em>from</em></span> CUPS to Windows attached -Printers</h3></div></div><div></div></div><p> -From time to time the question arises, how you can print -<span class="emphasis"><em>to</em></span> a Windows attached printer -<span class="emphasis"><em>from</em></span> Samba. Normally the local connection -"Windows host <--> printer" would be done by USB or parallel -cable, but this doesn't matter to Samba. From here only 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 -<span class="emphasis"><em>smb</em></span> (surprise, surprise!) backend. Check if this -is in the CUPS backend directory. This resides usually in -<tt class="filename">/usr/lib/cups/backend/</tt>. You need to find a "smb" -file there. It should be a symlink to <tt class="filename">smbspool</tt> -which file must exist and be executable: -</p><pre class="screen"> - - # ls -l /usr/lib/cups/backend/ - total 253 - drwxr-xr-x 3 root root 720 Apr 30 19:04 . - drwxr-xr-x 6 root root 125 Dec 19 17:13 .. - -rwxr-xr-x 1 root root 10692 Feb 16 21:29 canon - -rwxr-xr-x 1 root root 10692 Feb 16 21:29 epson - lrwxrwxrwx 1 root root 3 Apr 17 22:50 http -> ipp - -rwxr-xr-x 1 root root 17316 Apr 17 22:50 ipp - -rwxr-xr-x 1 root root 15420 Apr 20 17:01 lpd - -rwxr-xr-x 1 root root 8656 Apr 20 17:01 parallel - -rwxr-xr-x 1 root root 2162 Mar 31 23:15 pdfdistiller - lrwxrwxrwx 1 root root 25 Apr 30 19:04 ptal -> /usr/local/sbin/ptal-cups - -rwxr-xr-x 1 root root 6284 Apr 20 17:01 scsi - lrwxrwxrwx 1 root root 17 Apr 2 03:11 smb -> /usr/bin/smbspool - -rwxr-xr-x 1 root root 7912 Apr 20 17:01 socket - -rwxr-xr-x 1 root root 9012 Apr 20 17:01 usb - -# ls -l `which smbspool` - -rwxr-xr-x 1 root root 563245 Dec 28 14:49 /usr/bin/smbspool - -</pre><p> -If this symlink doesn't exist, create it: -</p><pre class="screen"> - -# ln -s `which smbspool` /usr/lib/cups/backend/smb - -</pre><p> -smbspool 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 "winprinter" on CUPS, you need to have a "driver" for -it. Essentially this means to convert the print data on the CUPS/Samba -host to 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, etc. -</p><p> -To install a printer with the smb backend on CUPS, use this command: -</p><pre class="screen"> - -# lpadmin -p winprinter -v smb://WINDOWSNETBIOSNAME/printersharename -P /path/to/PPD - -</pre><p> -The <span class="emphasis"><em>PPD</em></span> 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><pre class="screen"> - - smb://WORKGROUP/WINDOWSNETBIOSNAME/printersharename - smb://username:password@WORKGROUP/WINDOWSNETBIOSNAME/printersharename - smb://username:password@WINDOWSNETBIOSNAME/printersharename - -</pre><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 -doesn't 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 don't necessarily need to have smbd running -(but who wants that? :-). -</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2973332"></a>More CUPS filtering Chains</h3></div></div><div></div></div><p> -The following diagrams reveal how CUPS handles print jobs. -</p><pre class="screen"> -######################################################################### -# -# CUPS in and of itself has this (general) filter chain (CAPITAL -# letters are FILE-FORMATS or MIME types, other are filters (this is -# true for pre-1.1.15 of pre-4.3 versions of CUPS and ESP PrintPro): -# -# SOMETHNG-FILEFORMAT -# | -# V -# somethingtops -# | -# V -# APPLICATION/POSTSCRIPT -# | -# V -# pstops -# | -# V -# APPLICATION/VND.CUPS-POSTSCRIPT -# | -# V -# pstoraster # as shipped with CUPS, independent from any Ghostscipt -# | # installation on the system -# | (= "postscipt interpreter") -# V -# APPLICATION/VND.CUPS-RASTER -# | -# V -# rastertosomething (e.g. Gimp-Print filters may be plugged in here) -# | (= "raster driver") -# V -# SOMETHING-DEVICE-SPECIFIC -# | -# V -# backend -# -# -# ESP PrintPro has some enhanced "rastertosomething" filters as compared to -# CUPS, and also a somewhat improved "pstoraster" filter. -# -# NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to -# CUPS and ESP PrintPro plug-in where rastertosomething is noted. -# -######################################################################### -</pre><pre class="screen"> -######################################################################### -# -# This is how "cupsomatic" comes into play: -# ========================================= -# -# SOMETHNG-FILEFORMAT -# | -# V -# somethingtops -# | -# V -# APPLICATION/POSTSCRIPT -# | -# V -# pstops -# | -# V -# APPLICATION/VND.CUPS-POSTSCRIPT ----------------+ -# | V -# V cupsomatic -# pstoraster (constructs complicated -# | (= "postscipt interpreter") Ghostscript commandline -# | to let the file be -# V processed by a -# APPLICATION/VND.CUPS-RASTER "-sDEVICE=s.th." -# | call...) -# V | -# rastertosomething V -# | (= "raster driver") +-------------------------+ -# | | Ghostscript at work.... | -# V | | -# SOMETHING-DEVICE-SPECIFIC *-------------------------+ -# | | -# V | -# backend <------------------------------------+ -# | -# V -# THE PRINTER -# -# -# Note, that cupsomatic "kidnaps" the printfile after the -# "APPLICATION/VND.CUPS-POSTSCRPT" stage and deviates it gh -# the CUPS-external, systemwide Ghostscript installation, bypassing the -# "pstoraster" filter (therefore also bypassing the CUPS-raster-drivers -# "rastertosomething", and hands the rasterized file directly to the CUPS -# backend... -# -# cupsomatic is not made by the CUPS developers. It is an independent -# contribution to printing development, made by people from -# Linuxprinting.org. (see also http://www.cups.org/cups-help.html) -# -# NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to -# CUPS and ESP PrintPro plug-in where rastertosomething is noted. -# -######################################################################### -</pre><pre class="screen"> -######################################################################### -# -# And this is how it works for ESP PrintPro from 4.3: -# =================================================== -# -# SOMETHNG-FILEFORMAT -# | -# V -# somethingtops -# | -# V -# APPLICATION/POSTSCRIPT -# | -# V -# pstops -# | -# V -# APPLICATION/VND.CUPS-POSTSCRIPT -# | -# V -# gsrip -# | (= "postscipt interpreter") -# V -# APPLICATION/VND.CUPS-RASTER -# | -# V -# rastertosomething (e.g. Gimp-Print filters may be plugged in here) -# | (= "raster driver") -# V -# SOMETHING-DEVICE-SPECIFIC -# | -# V -# backend -# -# NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to -# CUPS and ESP PrintPro plug-in where rastertosomething is noted. -# -######################################################################### -</pre><pre class="screen"> -######################################################################### -# -# This is how "cupsomatic" would come into play with ESP PrintPro: -# ================================================================ -# -# -# SOMETHNG-FILEFORMAT -# | -# V -# somethingtops -# | -# V -# APPLICATION/POSTSCRIPT -# | -# V -# pstops -# | -# V -# APPLICATION/VND.CUPS-POSTSCRIPT ----------------+ -# | V -# V cupsomatic -# gsrip (constructs complicated -# | (= "postscipt interpreter") Ghostscript commandline -# | to let the file be -# V processed by a -# APPLICATION/VND.CUPS-RASTER "-sDEVICE=s.th." -# | call...) -# V | -# rastertosomething V -# | (= "raster driver") +-------------------------+ -# | | Ghostscript at work.... | -# V | | -# SOMETHING-DEVICE-SPECIFIC *-------------------------+ -# | | -# V | -# backend <------------------------------------+ -# | -# V -# THE PRINTER -# -# NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to -# CUPS and ESP PrintPro plug-in where rastertosomething is noted. -# -######################################################################### -</pre><pre class="screen"> -######################################################################### -# -# And this is how it works for CUPS from 1.1.15: -# ============================================== -# -# SOMETHNG-FILEFORMAT -# | -# V -# somethingtops -# | -# V -# APPLICATION/POSTSCRIPT -# | -# V -# pstops -# | -# V -# APPLICATION/VND.CUPS-POSTSCRIPT-----+ -# +------------------v------------------------------+ -# | Ghostscript | -# | at work... | -# | (with | -# | "-sDEVICE=cups") | -# | | -# | (= "postscipt interpreter") | -# | | -# +------------------v------------------------------+ -# | -# APPLICATION/VND.CUPS-RASTER >-------+ -# | -# V -# rastertosomething -# | (= "raster driver") -# V -# SOMETHING-DEVICE-SPECIFIC -# | -# V -# backend -# -# -# NOTE: since version 1.1.15 CUPS "outsourced" the pstoraster process to -# Ghostscript. GNU Ghostscript needs to be patched to handle the -# CUPS requirement; ESP Ghostscript has this builtin. In any case, -# "gs -h" needs to show up a "cups" device. pstoraster is now a -# calling an appropriate "gs -sDEVICE=cups..." commandline to do -# the job. It will output "application/vnd.cup-raster", which will -# be finally processed by a CUPS raster driver "rastertosomething" -# Note the difference to "cupsomatic", which will <span class="emphasis"><em>not</em></span> output -# CUPS-raster, but a final version of the printfile, ready to be -# sent to the printer. cupsomatic also doesn't use the "cups" -# devicemode in Ghostscript, but one of the classical devicemodes.... -# -# NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to -# CUPS and ESP PrintPro plug-in where rastertosomething is noted. -# -######################################################################### -</pre><pre class="screen"> -######################################################################### -# -# And this is how it works for CUPS from 1.1.15, with cupsomatic included: -# ======================================================================== -# -# SOMETHNG-FILEFORMAT -# | -# V -# somethingtops -# | -# V -# APPLICATION/POSTSCRIPT -# | -# V -# pstops -# | -# V -# APPLICATION/VND.CUPS-POSTSCRIPT-----+ -# +------------------v------------------------------+ -# | Ghostscript . Ghostscript at work.... | -# | at work... . (with "-sDEVICE= | -# | (with . s.th." | -# | "-sDEVICE=cups") . | -# | . | -# | (CUPS standard) . (cupsomatic) | -# | . | -# | (= "postscript interpreter") | -# | . | -# +------------------v--------------v---------------+ -# | | -# APPLICATION/VND.CUPS-RASTER >-------+ | -# | | -# V | -# rastertosomething | -# | (= "raster driver") | -# V | -# SOMETHING-DEVICE-SPECIFIC >------------------------+ -# | -# V -# backend -# -# -# NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to -# CUPS and ESP PrintPro plug-in where rastertosomething is noted. -# -########################################################################## -</pre></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2973586"></a>Trouble Shooting Guidelines to fix typical Samba printing -Problems</h3></div></div><div></div></div><p> -This is a short description of how to debug printing problems -with Samba. This describes how to debug problems with printing from -a SMB client to a Samba server, not the other way around. -</p><div class="variablelist"><dl><dt><span class="term">Win9x client can't install driver</span></dt><dd><p>For Win9x clients require the printer names to be 8 -chars (or "8 plus 3 chars suffix") max; otherwise the driver files -won't get transferred when you want to download them from -Samba.</p></dd><dt><span class="term">testparm</span></dt><dd><p>Run <b class="command">testparm</b>: It will tell you if -<tt class="filename">smb.conf</tt> parameters are in the wrong -section. Many people have had the "printer admin" parameter in the -<i class="parameter"><tt>[printers]</tt></i> section and experienced -problems. "testparm" will tell you if it sees -this.</p></dd><dt><span class="term">"cupsaddsmb" keeps asking for a root password in a -neverending loop</span></dt><dd><p>Have you <i class="parameter"><tt>security = user</tt></i>? Have -you used <b class="command">smbpasswd</b> to give root a Samba account? -You can do 2 things: open another terminal and execute -<b class="command">smbpasswd -a root</b> to create the account, and -continue with entering the password into the first terminal. Or break -out of the loop by hitting ENTER twice (without trying to type a -password).</p></dd><dt><span class="term">"cupsaddsmb" gives "No PPD file for printer..." -message (but I swear there is one!)</span></dt><dd><div class="itemizedlist"><ul type="disc"><li><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> which doesn't deny access to -the host you run "cupsaddsmb" from? It <span class="emphasis"><em>could</em></span> be -an issue if you use cupsaddsmb remotely, or if you use it with a -<i class="parameter"><tt>-h</tt></i> parameter: <b class="command">cupsaddsmb -H -sambaserver -h cupsserver -v printername</b>. -</p></li><li><p>Is your -"TempDir" directive in -<span class="emphasis"><em>cupsd.conf</em></span> -set to a valid value and is it writeable? -</p></li></ul></div></dd><dt><span class="term">I can't connect client to Samba printer.</span></dt><dd><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></dd><dt><span class="term">I can't reconnect to Samba under a new account -from Win2K/XP</span></dt><dd><p>Once you are connected as the "wrong" user (for -example as "nobody", which often occurs if you have <i class="parameter"><tt>map to -guest = bad user</tt></i>), Windows Explorer will not accept an -attempt to connect again as a different user. There won't be any byte -transfered on the wire to Samba, but still you'll see a stupid error -message which makes you think that Samba has denied access. Use -<b class="command">smbstatus</b> to check for active connections. Kill the -PIDs. You still can't re-connect and 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 -don't see any single byte arriving at Samba (see logs; use "ethereal") -indicating a renewed connection attempt? Shut all Explorer Windows. -This makes Windows forget what it has cached in its memory as -established connections. Then re-connect as the right user. Best -method is to use a DOS terminal window and <span class="emphasis"><em>first</em></span> -do <b class="command">net use z: \\SAMBAHOST\print$ /user:root</b>. Check -with <b class="command">smbstatus</b> that you are connected under a -different account. Now open the "Printers" folder (on the Samba server -in the <span class="emphasis"><em>Network Neighbourhood</em></span>), right-click the -printer in question and select -<span class="emphasis"><em>Connect...</em></span></p></dd><dt><span class="term">Avoid being connected to the Samba server as the -"wrong" user</span></dt><dd><p>You see per <b class="command">smbstatus</b> that you are -connected as user "nobody"; while you wanted to be "root" or -"printeradmin"? This is probably due to <i class="parameter"><tt>map to guest = bad -user</tt></i>, which silently connects you under the guest account, -when you gave (maybe by accident) an incorrect username. Remove -<i class="parameter"><tt>map to guest</tt></i>, if you want to prevent -this.</p></dd><dt><span class="term">Upgrading to CUPS drivers from Adobe drivers on -NT/2K/XP clients gives problems</span></dt><dd><p>First delete all "old" Adobe-using printers. Then -delete all "old" Adobe drivers. (On Win2K/XP, right-click in -background of "Printers" folder, select "Server Properties...", select -tab "Drivers" and delete here).</p></dd><dt><span class="term">I can't use "cupsaddsmb"on a Samba server which is -a PDC</span></dt><dd><p>Do you use the "naked" root user name? Try to do it -this way: <span class="emphasis"><em>cupsaddsmb -U DOMAINNAME\\root -v -printername</em></span> (note the two backslashes: the first one is -required to "escape" the second one).</p></dd><dt><span class="term">I deleted a printer on Win2K; but I still see -its driver</span></dt><dd><p>Deleting a printer on the client won't delete the -driver too (to verify, right-click on the white background of the -"Printers" folder, select "Server Properties" and click on the -"Drivers" tab). These same old drivers will be re-used when you try to -install a printer with the same name. If you want to update to a new -driver, delete the old ones first. Deletion is only possible if no -other printer uses the same driver.</p></dd><dt><span class="term">Win2K/XP "Local Security -Policies"</span></dt><dd><p><span class="emphasis"><em>Local Security Policies</em></span> may not -allow the installation of unsigned drivers. "Local Security Policies" -may not allow the installation of printer drivers at -all.</p></dd><dt><span class="term">WinXP clients: "Administrator can not install -printers for all local users"</span></dt><dd><p>Windows XP handles SMB printers on a "per-user" basis. -This means every user needs to install the printer himself. To have a -printer available for everybody, you might want to use the built-in -IPP client capabilities of WinXP. Add a printer with the print path of -<span class="emphasis"><em>http://cupsserver:631/printers/printername</em></span>. -Still looking into this one: maybe a "logon script" could -automatically install printers for all -users.</p></dd><dt><span class="term">"Print Change Notify" functions on -NT-clients</span></dt><dd><p>For "print change notify" functions on NT++ clients, -these need to run the "Server" service first (re-named to -<span class="emphasis"><em>File & Print Sharing for MS Networks</em></span> in -XP).</p></dd><dt><span class="term">WinXP-SP1</span></dt><dd><p>WinXP-SP1 introduced a <span class="emphasis"><em>Point and Print -Restriction Policy</em></span> (this restriction doesn't apply to -"Administrator" or "Power User" groups of users). In Group Policy -Object Editor: go to <span class="emphasis"><em>User Configuration --> -Administrative Templates --> Control Panel --> -Printers</em></span>. The policy is automatically set to -<span class="emphasis"><em>Enabled</em></span> and the <span class="emphasis"><em>Users can only Point -and Print to machines in their Forest</em></span> . You probably need -to change it to <span class="emphasis"><em>Disabled</em></span> or <span class="emphasis"><em>Users can -only Point and Print to these servers</em></span> in order to make -driver downloads from Samba possible.</p></dd><dt><span class="term">I can't set and save default print options for all -users on Win2K/XP</span></dt><dd><p>How are you doing it? I bet the wrong way (it is not -very easy to find out, though). There are 3 different ways to bring -you to a dialog that <span class="emphasis"><em>seems</em></span> to set everything. All -three dialogs <span class="emphasis"><em>look</em></span> the same. Only one of them -<span class="emphasis"><em>does</em></span> 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 xmlns:ns66=""><ns66:p>The first "wrong" way: - -</ns66:p><div class="orderedlist"><ol type="1"><li><p>Open the <span class="emphasis"><em>Printers</em></span> -folder.</p></li><li><p>Right-click on the printer -(<span class="emphasis"><em>remoteprinter on cupshost</em></span>) and -select in context menu <span class="emphasis"><em>Printing -Preferences...</em></span></p></li><li><p>Look at this dialog closely and remember what it looks -like.</p></li></ol></div><ns66:p> -</ns66:p></li><li xmlns:ns67=""><ns67:p>The second "wrong" way: - -</ns67:p><div class="orderedlist"><ol type="1"><li><p>Open the <span class="emphasis"><em>Printers</em></span> -folder.</p></li><li><p>Right-click on the printer (<span class="emphasis"><em>remoteprinter on -cupshost</em></span>) and select in the context menu -<span class="emphasis"><em>Properties</em></span></p></li><li><p>Click on the <span class="emphasis"><em>General</em></span> -tab</p></li><li><p>Click on the button <span class="emphasis"><em>Printing -Preferences...</em></span></p></li><li><p>A new dialog opens. Keep this dialog open and go back -to the parent dialog.</p></li></ol></div><ns67:p> -</ns67:p></li><li xmlns:ns68=""><ns68:p>The third, the "correct" way: (should you do -this from the beginning, just carry out steps 1. and 2. from second -"way" above) - -</ns68:p><div class="orderedlist"><ol type="1"><li><p>Click on the <span class="emphasis"><em>Advanced</em></span> -tab. (Hmmm... if everything is "Grayed Out", then you are not logged -in as a user with enough privileges).</p></li><li><p>Click on the <span class="emphasis"><em>Printing -Defaults...</em></span> button.</p></li><li><p>On any of the two new tabs, click on the -<span class="emphasis"><em>Advanced...</em></span> -button.</p></li><li><p>A new dialog opens. Compare this one to the other, -identical looking one from "B.5" or A.3".</p></li></ol></div><ns68:p> -</ns68: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 "C.1.-6." will save any settings -permanently and be the defaults for new users. If you want all clients -to get the same defaults, you need to conduct these steps <span class="emphasis"><em>as -Administrator</em></span> (<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></dd><dt><span class="term">What are the most common blunders in driver -settings on Windows clients?</span></dt><dd><p>Don't use <span class="emphasis"><em>Optimize for -Speed</em></span>: use <span class="emphasis"><em>Optimize for -Portability</em></span> instead (Adobe PS Driver) Don't use -<span class="emphasis"><em>Page Independence: No</em></span>: always -settle with <span class="emphasis"><em>Page Independence: -Yes</em></span> (Microsoft PS Driver and CUPS PS Driver for -WinNT/2K/XP) If there are problems with fonts: use -<span class="emphasis"><em>Download as Softfont into -printer</em></span> (Adobe PS Driver). For -<span class="emphasis"><em>TrueType Download Options</em></span> -choose <span class="emphasis"><em>Outline</em></span>. Use PostScript -Level 2, if you are having trouble with a non-PS printer, and if -there is a choice.</p></dd><dt><span class="term">I can't make <b class="command">cupsaddsmb</b> work -with newly installed printer</span></dt><dd><p>Symptom: the last command of -<b class="command">cupsaddsmb</b> doesn't 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 <span class="emphasis"><em>Network -Neighbourhood</em></span>? Did it show up in <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></dd><dt><span class="term">My permissions on -<tt class="filename">/var/spool/samba/</tt> get reset after each -reboot</span></dt><dd><p>Have you 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 -<i class="parameter"><tt>path</tt></i> in the <i class="parameter"><tt>[printers]</tt></i> -section). These <span class="emphasis"><em>must</em></span> be different. Set -<i class="parameter"><tt>RequestRoot /var/spool/cups/</tt></i> in -<tt class="filename">cupsd.conf</tt> and <i class="parameter"><tt>path = -/var/spool/samba</tt></i> 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></dd><dt><span class="term">My printers work fine: just the printer named "lp" -intermittently swallows jobs and spits out completely different -ones</span></dt><dd><p>It is a very bad idea to name any printer "lp". This -is the traditional Unix name for the default printer. CUPS may be set -up to do an automatic creation of "Implicit Classes". This means, to -group all printers with the same name to a pool of devices, and -loadbalancing the jobs across them in a round-robin fashion. Chances -are high that someone else has an "lp" named printer too. You may -receive his jobs and send your own to his device unwittingly. To have -tight control over the printer names, set <i class="parameter"><tt>BrowseShortNames -No</tt></i>. It will present any printer as "printername@cupshost" -then, giving you a better control over what may happen in a large -networked environment.</p></dd><dt><span class="term">How do I "watch" my Samba server?</span></dt><dd><p>You can use <b class="command">tail -f -/var/log/samba/log.smbd</b> (you may need a different path) to -see a live scrolling of all log messages. <b class="command">smbcontrol smbd -debuglevel</b> tells you which verbosity goes into the -logs. <b class="command">smbcontrol smbd debug 3</b> sets the verbosity to -a quite high level (you can choose from 0 to 10 or 100). This works -"on the fly", without the need to restart the smbd daemon. Don't use -more than 3 initially; or you'll drown in an ocean of -messages.</p></dd><dt><span class="term">I can't use Samba from my WinXP Home box, while -access from WinXP Prof works flawlessly</span></dt><dd><p>You have our condolences! WinXP home has been -completely neutered by Microsoft as compared to WinXP Prof: you can -not log into a WinNT domain. It cannot join a Win NT domain as a -member server. While it is possible to access domain resources, users -don't have "single sign-on". They need to supply username and password -each time they connect to a resource. Logon scripts and roaming -profiles are not supported. It can serve file and print shares; but -only in "share-mode security" level. It can not use "user-mode -security" (what Windows 95/98/ME still can -do).</p></dd><dt><span class="term">Where do I find the Adobe PostScript driver files -I need for "cupsaddsmb"?</span></dt><dd><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 website.</p></dd></dl></div></div><div xmlns:ns69="" class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id2974692"></a>An Overview of the CUPS Printing Processes</h3></div></div><div></div></div><ns69:p> -</ns69:p><div class="figure"><a name="id2974702"></a><p class="title"><b>Figure 19.15. CUPS Printing Overview</b></p><div class="mediaobject"><img src="projdoc/imagefiles/a_small.png" alt="CUPS Printing Overview"></div></div><ns69:p> -</ns69:p></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> |