<chapter id="CUPS-printing">
-
<chapterinfo>
- &author.jht;
+
<author>
<firstname>Kurt</firstname><surname>Pfeifle</surname>
<affiliation>
- <address><email>kpfeifle@danka.de</email></address>
+ <orgname> Danka Deutschland GmbH </orgname>
+ <address><email>kpfeifle@danka.de</email></address>
</affiliation>
</author>
- <pubdate> (25 March 2003) </pubdate>
+ <pubdate> (3 June 2003) </pubdate>
</chapterinfo>
-<title>CUPS Printing Support</title>
+<title>CUPS Printing Support in Samba 3.0</title>
<sect1>
+
<title>Introduction</title>
-
+
+<sect2>
+<title>Features and Benefits</title>
+
<para>
-The Common Unix Print System (CUPS) has become very popular, but to many it is
-a very mystical tool. There is a great deal of uncertainty regarding CUPS and how
-it works. The result is seen in a large number of posting on the samba mailing lists
-expressing frustration when MS Windows printers appear not to work with a CUPS
-backr-end.
+The Common Unix Print System (<ulink
+url="http://www.cups.org/">CUPS</ulink>) 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.
</para>
<para>
-This is a good time to point out how CUPS can be used and what it does. CUPS is more
-than just a print spooling system - it is a complete printer management system that
-complies with HTTP and IPP protocols. It can be managed remotely via a web browser
-and it can print using http and ipp protocols.
+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.
</para>
+</sect2>
+
+<sect2>
+<title>Overview</title>
+
<para>
-CUPS allows to creation of RAW printers (ie: NO file format translation) as well as
-SMART printers (ie: 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 agrue 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.
+CUPS is more than just a print spooling system. It is a complete
+printer management system that complies with the new IPP
+(<emphasis>Internet Printing Protocol</emphasis>). IPP is an industry
+and IETF (<emphasis>Internet Engineering Task Force</emphasis>)
+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 <ulink
+url="http://printing.kde.org/">KDEPrint</ulink>).
</para>
<para>
-<ulink url="http://www.cups.org/">CUPS</ulink> is a newcomer in the UNIX printing scene,
-which has convinced many people upon first trial already. However, it has quite a few
-new features, which make it different from other, more traditional printing systems.
+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.
</para>
-
+</sect2>
</sect1>
<sect1>
-<title>Configuring &smb.conf; for CUPS</title>
+<title>Basic Configuration of CUPS support</title>
+
+<para>
+Printing with CUPS in the most basic <filename>smb.conf</filename>
+setup in Samba 3.0 (as was true for 2.2.x) only needs two
+settings: <parameter>printing = cups</parameter> and <parameter>printcap
+= cups</parameter>. CUPS itself doesn't need a printcap file
+anymore. However, the <filename>cupsd.conf</filename> 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: <parameter>Printcap
+/etc/printcap</parameter> and <parameter>PrintcapFormat
+BSD</parameter>). 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 <command>man cupsd.conf</command> and other CUPS-related
+documentation, like the wealth of documents on your CUPS server
+itself: <ulink
+url="http://localhost:631/documentation.html">http://localhost:631/documentation.html</ulink>.
+</para>
+
+<sect2>
+<title>Linking of smbd with <filename>libcups.so</filename></title>
+
+<para>
+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 <filename>libcups.so</filename> -- but
+there are some differences in required or supported configuration
+then.
+</para>
+
+<para>
+If SAMBA is compiled against libcups, then <parameter>printcap =
+cups</parameter> uses the CUPS API to list printers, submit jobs,
+query queues, etc. Otherwise it maps to the System V commands with an
+additional <command>-oraw</command> option for printing. On a Linux
+system, you can use the <command>ldd</command> utility to find out
+details (ldd may not be present on other OS platforms, or its function
+may be embodied by a different command):
+</para>
+
+<para><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)
+ [....]
+</screen></para>
<para>
-Printing with CUPS in the most basic &smb.conf;
-setup in Samba-3 only needs two settings: <command>printing = cups</command> and
-<command>printcap = cups</command>. While CUPS itself doesn't need a printcap
-anymore, the <filename>cupsd.conf</filename> configuration file knows two directives
-(example: <command>Printcap /etc/printcap</command> and <command>PrintcapFormat
-BSD</command>), which control if such a file should be created for the
-convenience of third party applications. Make sure it is set! For details see
-<command>man cupsd.conf</command> and other CUPS-related documentation.
+The line <computeroutput>libcups.so.2 => /usr/lib/libcups.so.2
+(0x40123000)</computeroutput> shows there is CUPS support compiled
+into this version of Samba. If this is the case, and printing = cups
+is set, then <emphasis>any otherwise manually set print command in
+<filename>smb.conf</filename> is ignored</emphasis>. This is an
+important point to remember!
</para>
+<tip><para> Should you require -- for any reason -- to set your own
+print commands, you can still do this by setting <parameter>printing =
+sysv</parameter>. 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:
+<parameter>print command</parameter>; other commands are
+<parameter>lppause command, lpresume command, lpq command, lprm
+command, queuepause command </parameter> and <parameter>queue resume
+command</parameter>).</para></tip>
+</sect2>
+
+<sect2>
+<title>Simple <filename>smb.conf</filename> Settings for CUPS</title>
+
+<para>
+To summarize, here is the simplest printing-related setup
+for<filename>smb.conf</filename> to enable basic CUPS support:
+</para>
+
+<para><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
+
+</screen></para>
+
<para>
-If SAMBA is compiled against libcups, then <command>printcap = cups</command> uses the
-CUPS API to list printers, submit jobs, etc. Otherwise it maps to the System V commands
-with an additional <parameter>-oraw</parameter> option for printing. On a Linux system,
-you can use the <command>ldd</command> command to find out details (ldd may not be
-present on other OS platforms, or its function may be embodied by a different command):
+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.
</para>
+</sect2>
+
+<sect2>
+<title>More complex <filename>smb.conf</filename> Settings for
+CUPS</title>
<para>
-<programlisting>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)
- libdl.so.2 => /lib/libdl.so.2 (0x401e8000)
- libnsl.so.1 => /lib/libnsl.so.1 (0x401ec000)
- libpam.so.0 => /lib/libpam.so.0 (0x40202000)
- libc.so.6 => /lib/libc.so.6 (0x4020b000)
- /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
-</programlisting></para>
+Here is a slightly more complex printing-related setup
+for<filename>smb.conf</filename>. It enables general CUPS printing
+support for all printers, but defines one printer share which is set
+up differently.
+</para>
+
+<para><screen>
+<![CDATA[
+ [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
+]]>
+</screen></para>
<para>
-The line "libcups.so.2 => /usr/lib/libcups.so.2
-(0x40123000)" shows there is CUPS support compiled into this version of
-Samba. If this is the case, and <command>printing = cups</command> is set, then any
-otherwise manually set print command in &smb.conf; is ignored.
+This special share is only there for my testing purposes. It doesn't
+even write the printjob to a file. It just logs the job parameters
+known to Samba into the <filename>/tmp/smbprn.log</filename> file and
+deletes the jobfile. Moreover, the <parameter>printer
+admin</parameter> 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
+<parameter>printing = sysv</parameter> and <parameter>printcap =
+lpstat</parameter>.
</para>
+</sect2>
</sect1>
<sect1>
-<title>CUPS - RAW Print Through Mode</title>
+<title>Advanced Configuration</title>
-<note>
<para>
-When used in raw print through mode is will be necessary to use the printer
-vendor's drivers in each Windows client PC.
+Before we dive into all the configuration options, let's clarify a few
+points. <emphasis>Network printing needs to be organized and setup
+correctly</emphasis>. Often this is not done correctly. Legacy systems
+or small LANs in business environments often lack a clear design and
+good housekeeping.
+</para>
+
+<sect2>
+<title>Central spooling vs. "Peer-to-Peer" printing</title>
+
+<para>
+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.
+</para>
+</sect2>
+
+<sect2>
+<title>CUPS/Samba as a "spooling-only" Print Server; "raw" printing
+with Vendor Drivers on Windows Clients</title>
+
+<para>
+Most traditionally configured Unix print servers acting on behalf of
+Samba's Windows clients represented a really simple setup. Their only
+task was to manage the "raw" spooling of all jobs handed to them by
+Samba. This approach meant that the Windows clients were expected to
+prepare the printjob file in such a way that it 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.
</para>
-</note>
<para>
-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) in a format
-that is suitable for direct delivery to the printer. In this case CUPS will NOT
-do any print file format conversion work.
+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.
</para>
+</sect2>
+
+<sect2>
+<title>Driver Installation Methods on Windows Clients</title>
<para>
-The CUPS files that need to be correctly set for RAW mode printers to work are:
+The printer drivers on the Windows clients may be installed
+in two functionally different ways:
+</para>
<itemizedlist>
- <listitem><para><filename>/etc/cups/mime.types</filename></para></listitem>
- <listitem><para><filename>/etc/cups/mime.convs</filename></para></listitem>
+<listitem><para>manually install the drivers locally on each client,
+one by one; this yields the old <emphasis>LanMan</emphasis> style
+printing; it uses a <filename>\\sambaserver\printershare</filename>
+type of connection.</para></listitem>
+
+<listitem><para>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 <emphasis>SPOOLSS/MS-RPC</emphasis>
+type printing calls.</para></listitem>
</itemizedlist>
-Both contain entries that must be uncommented to allow <emphasis>RAW</emphasis> mode
-operation.
+<para>
+The second method is recommended for use over the first.
</para>
+</sect2>
+
+<sect2>
+<title>Explicitly enable "raw" printing for
+<emphasis>application/octet-stream</emphasis>!</title>
<para>
-Firstly, to enable CUPS based printing from Samba the following options must be
-enabled in your &smb.conf; file [globals] section:
+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:
+</para>
<itemizedlist>
- <listitem><para>printing = CUPS</para></listitem>
+<listitem><para>/etc/cups/mime.types
+</para></listitem>
- <listitem><para>printcap = CUPS</para></listitem>
+<listitem><para>/etc/cups/mime.convs</para></listitem>
</itemizedlist>
-When these parameters are specified the print directives in &smb.conf; (as well as in
-samba itself) will be ignored because samba will directly interface with CUPS through
-it's application program interface (API) - so long as Samba has been compiled with
-CUPS library (libcups) support. If samba has NOT been compiled with CUPS support then
-printing will use the System V AT&T command set with the <emphasis>-oraw</emphasis>
-option automatically passing through.
+<para>
+Both contain entries (at the end of the respective files) which must
+be uncommented to allow RAW mode operation.
+In<filename>/etc/cups/mime.types</filename> make sure this line is
+present:
+</para>
+
+<para><screen>
+
+ application/octet-stream
+
+</screen></para>
+
+<para>
+In <filename>/etc/cups/mime.convs</filename>,
+have this line:
+</para>
+
+<para><screen>
+
+ application/octet-stream application/vnd.cups-raw 0 -
+
+</screen></para>
+
+<para>
+If these two files are not set up correctly for raw Windows client
+printing, you may encounter the dreaded <computeroutput>Unable to
+convert file 0</computeroutput> in your CUPS error_log file.
+</para>
+
+<note><para>editing the <filename>mime.convs</filename> and the
+<filename>mime.types</filename> file does not
+<emphasis>enforce</emphasis> "raw" printing, it only
+<emphasis>allows</emphasis> it.
+</para></note>
+
+<formalpara><title>Background</title>
+
+<para>
+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 <emphasis>MIME type: application/octet-stream</emphasis> 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).
+</para>
+</formalpara>
+
+<para>
+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.
</para>
+</sect2>
+
+<sect2>
+<title>Three familiar Methods for driver upload plus a new one</title>
<para>
-Cupsomatic (an enhanced printing utility that is part of some CUPS implementations)
-on the Samba/CUPS server does *not* add any features if a file is really
-printed "raw". However, if you have loaded the driver for the Windows client from
-the CUPS server, using the "cupsaddsmb" utility, and if this driver is one using
-a "Foomatic" PPD, the PJL header in question is already added on the Windows client,
-at the time when the driver initially generated the PostScript data and CUPS in true
-"-oraw" manner doesn't remove this PJL header and passes the file "as is" to its
-printer communication backend.
+If you want to use the MS-RPC type printing, you must upload the
+drivers onto the Samba server first (<parameter>[print$]</parameter>
+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:
</para>
-<note><para>NOTE: editing in the "mime.convs" and the "mime.types" file does not *enforce*
-"raw" printing, it only *allows* it.</para></note>
+<itemizedlist>
+<listitem><para>the GUI, "Add Printer Wizard"
+<emphasis>upload-from-a-Windows-client</emphasis>
+method;</para></listitem>
+
+<listitem><para>the commandline, "smbclient/rpcclient"
+<emphasis>upload-from-a-UNIX-workstation</emphasis>
+method;</para></listitem>
+
+<listitem><para>the <emphasis>Imprints</emphasis> Toolset
+method.</para></listitem>
+</itemizedlist>
<para>
-Print files that arrive from MS Windows printing are "auto-typed" by CUPS. This aids
-the process of determining proper treatment while in the print queue system.
+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:
+</para>
<itemizedlist>
- <listitem><para>
- Files generated by PCL drivers and directed at PCK printers get auto-typed as
- <filename>application/octet-stream</filename>. Unknown file format types also
- get auto-typed with this tag.
- </para></listitem>
-
- <listitem><para>
- Files generated by a Postscript driver and directed at a Postscript printer
- are auto-typed depending on the auto-detected most suitable MIME type as:
-
- <itemizedlist>
- <listitem><para>* application/postscript</para></listitem>
- <listitem><para>* application/vnd.cups-postscript</para></listitem>
- </itemizedlist>
- </para>
- </listitem>
+<listitem><para>the <emphasis>cupsaddsmb</emphasis>
+utility.</para></listitem>
</itemizedlist>
+
+<para>
+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.
+</para>
+</sect2>
+</sect1>
+
+<sect1>
+<title>Using CUPS/Samba in an advanced Way -- intelligent printing
+with PostScript Driver Download</title>
+
+<para>
+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.
+</para>
+
+<para>
+Possibly you need to setup CUPS in a more smart way. The reasons could
+be manifold:
</para>
+<itemizedlist>
+<listitem><para>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?</para></listitem>
+
+<listitem><para>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?</para></listitem>
+
+<listitem><para>Maybe your previous network printing setup is a mess
+and shall be re-organized from a clean beginning?</para></listitem>
+
+<listitem><para>Maybe you have experiencing too many "Blue Screens",
+originating from poorly debugged printer drivers running in NT "kernel
+mode"?</para></listitem>
+</itemizedlist>
+
+<para>
+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.
+</para>
<para>
-"application/postscript" first goes thru the "pstops" filter (where the page counting
-and accounting takes place). The outcome will be of MIME type
-"application/vnd.cups-postscript". The pstopsfilter reads and uses information from
-the PPD and inserts user-provided options into the PostScript file. As a consequence,
-the filtered file could possibly have an unwanted PJL header.
+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.
</para>
+<sect2>
+<title>GDI on Windows -- PostScript on Unix</title>
+
<para>
-"application/postscript" will be all files with a ".ps", ".ai", ".eps" suffix or which
-have as their first character string one of "%!" or ">04<%".
+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.
</para>
<para>
-"application/vnd.cups-postscript" will files which contain the string
-"LANGUAGE=POSTSCRIPT" (or similar variations with different capitalization) in the
-first 512 bytes, and also contain the "PJL super escape code" in the first 128 bytes
-(">1B<%-12345X"). Very likely, most PostScript files generated on Windows using a CUPS
-or other PPD, will have to be auto-typed as "vnd.cups-postscript". A file produced
-with a "Generic PostScript driver" will just be tagged "application/postscript".
+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
+<emphasis>PostScript</emphasis> (trademark held by Adobe), and to an
+extend<emphasis>PCL</emphasis> (trademark held by HP), have developed
+into semi-official "standards", by being the most widely used PDLs
+(<emphasis>Page Description Languages</emphasis>), there are still
+many manufacturers who "roll their own" (their reasons may be
+unacceptable license fees for using printer-embedded PostScript
+interpreters, etc.).
</para>
+</sect2>
+
+<sect2>
+<title>Windows Drivers, GDI and EMF</title>
<para>
-Once the file is in "application/vnd.cups-postscript" format, either "pstoraster"
-or "cupsomatic" will take over (depending on the printer configuration, as
-determined by the PPD in use).
+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 (<emphasis>Graphical Device
+Interface</emphasis>), 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
+<emphasis>on screen</emphasis> as well as <emphasis>on
+paper</emphasis> (=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 (<emphasis>Enhanced
+MetaFile</emphasis>). The EMF is processed by the printer driver and
+converted to the printer-specific file format.
</para>
<note><para>
-A printer queue with *no* PPD associated to it is a "raw" printer and all files
-will go directly there as received by the spooler. The exeptions 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 as lpd://, socket://, smb://, ipp://, http://,
-parallel:/, serial:/, usb:/ etc.)
+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 <emphasis>Core Graphic Engine</emphasis> uses a
+<emphasis>PDF</emphasis> derivate for all display work.
</para></note>
-<note><para>
-"cupsomatic"/Foomatic are *not* 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 Ghostscipt. CUPS accepts this,
-because the associated CUPS-O-Matic-/Foomatic-PPD specifies:
+<para>
+
+<figure><title>Windows Printing to a local Printer</title>
+<graphic fileref="projdoc/imagefiles/1small.png"/>
+</figure>
</para>
+</sect2>
-<programlisting>
- *cupsFilter: "application/vnd.cups-postscript 0 cupsomatic"
-</programlisting>
+<sect2>
+<title>Unix Printfile Conversion and GUI Basics</title>
<para>
-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 "/etc/cups/mime.types" in place.
-</para></note>
+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 <emphasis>X.org</emphasis>,
+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.
+</para>
+
+<formalpara>
+<title>Background</title>
<para>
-CUPS is widely configurable and flexible, even regarding its filtering mechanism.
-Another workaround in some situations would be to have
-in "/etc/cups/mime.types" entries as follows:
+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.
</para>
+</formalpara>
+</sect2>
-<programlisting>
- application/postscript application/vnd.cups-raw 0 -
- application/vnd.cups-postscript application/vnd.cups-raw 0 -
-</programlisting>
+<sect2>
+<title>PostScript and Ghostscript</title>
<para>
-This would prevent all Postscript files from being filtered (rather, they will go
-thru the virtual "nullfilter" denoted with "-"). This could only be useful for
-PS printers. If you want to print PS code on non-PS printers an entry as follows
-could be useful:
+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 <emphasis>Raster Image
+Processor</emphasis> (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.
</para>
-<programlisting>
- */* application/vnd.cups-raw 0 -
-</programlisting>
+<note><para>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.... ;-)
+</para>
+</note>
<para>
-and would effectively send *all* files to the backend without further processing.
+<figure><title>Printing to a Postscript Printer</title>
+<graphic fileref="projdoc/imagefiles/2small.png"/>
+</figure>
</para>
<para>
-Lastly, you could have the following entry:
+However, there are other types of printers out there. These don't know
+how to print PostScript. They use their own <emphasis>Page Description
+Language</emphasis> (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.
</para>
+</sect2>
-<programlisting>
- application/vnd.cups-postscript application/vnd.cups-raw 0 my_PJL_stripping_filter
-</programlisting>
+<sect2>
+<title>Ghostscript -- the Software RIP for non-PostScript Printers</title>
<para>
-You will need to write a "my_PJL_stripping_filter" (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 "/usr/lib/cups/filters/" and will be called
-by CUPS if it encounters a MIME type "application/vnd.cups-postscript".
+Here is where<emphasis>Ghostscript</emphasis> 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
+<emphasis>lot</emphasis> 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.
</para>
<para>
-CUPS can handle "-o job-hold-until=indefinite". This keeps the job in the queue
-"on hold". It will only be printed upon manual release by the printer operator.
-This is a requirement in many "central reproduction departments", where a few
-operators manage the jobs of hundreds of users on some big machine, where no
-user is allowed to have direct access. (The operators often need to load the
-proper paper type before running the 10.000 page job requested by marketing
-for the mailing, etc.).
+<figure><title>Ghostscript as a RIP for non-postscript printers</title>
+<graphic fileref="projdoc/imagefiles/3small.png"/>
+</figure>
</para>
-</sect1>
+<tip><para>
+Use the "gs -h" command to check for all built-in "devices" of your
+Ghostscript version. If you specify e.g. a parameter of
+<parameter>-sDEVICE=png256</parameter> 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).
+</para></tip>
+</sect2>
-<sect1>
-<title>CUPS as a network PostScript RIP</title>
+<sect2>
+<title>PostScript Printer Description (PPD) Specification</title>
<para>
-This is the configuration where CUPS drivers are working on server, and where the
-Adobe PostScript driver with CUPS-PPDs is downloaded to clients.
+While PostScript in essence is a <emphasis>Page Description
+Language</emphasis> (PDL) to represent the page layout in a
+<emphasis>device independent</emphasis> 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 <emphasis>PostScript Printer Description</emphasis> (PPD)
+files. Every PostScript printer ships with one of these files.
</para>
<para>
-CUPS is perfectly able to use PPD files (PostScript
-Printer Descriptions). PPDs can control all print device options. They
-are usually provided by the manufacturer -- if you own a PostSript printer,
-that is. PPD files 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.
+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.
</para>
<para>
-CUPS can load, without any conversions, the PPD file from
-any Windows (NT is recommended) PostScript driver and handle the options.
-There is a web browser interface to the print options (select
-http://localhost:631/printers/ and click on one "Configure Printer" button
-to see it), a commandline interface (see <command>man lpoptions</command> or
-try if you have <command>lphelp</command> on your system) plus some different GUI frontends on Linux
-UNIX, which can present PPD options to the users. PPD options are normally
-meant to become evaluated by the PostScript RIP on the real PostScript
-printer.
+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.
</para>
+<warning><para>
+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).
+</para></warning>
+</sect2>
+
+<sect2>
+<title>CUPS can use all Windows-formatted Vendor PPDs</title>
+
<para>
-CUPS doesn't stop at "real" PostScript printers in its
-usage of PPDs. The CUPS developers have extended the PPD concept, to also
-describe available device and driver options for non-PostScript printers
-through CUPS-PPDs.
+CUPS can handle all spec-compliant PPDs as supplied by the
+manufacturers for their PostScript models. Even if a
+Unix/Linux-illiterate vendor might not have mentioned our favorite
+OS in his manuals and brochures -- you can safely trust this:
+<emphasis>if you get hold of the Windows NT version of the PPD, you
+can use it unchanged in CUPS</emphasis> and thus access the full
+power of your printer just like a Windows NT user could!
</para>
+<tip><para>
+To check the spec compliance of any PPD online, go to <ulink
+url="http://www.cups.org/testppd.php">http://www.cups.org/testppd.php</ulink>
+and upload your PPD. You will see the results displayed
+immediately. CUPS in all versions after 1.1.19 has a much more strict
+internal PPD parsing and checking code enabled; in case of printing
+trouble this online resource should be one of your first pitstops.
+</para></tip>
+
+<warning><para>
+For real PostScript printers <emphasis>don't</emphasis> use the
+<emphasis>Foomatic</emphasis> or <emphasis>cupsomatic</emphasis>
+PPDs from Linuxprinting.org. With these devices the original
+vendor-provided PPDs are always the first choice!
+</para></warning>
+
+<tip><para>
+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
+<command>smbclient //NT4-box/print\$ -U username</command> to
+access the Windows directory where all printer driver files are
+stored. First look in the <filename>W32X86/2</filename> subdir for
+the PPD you are seeking.
+</para></tip>
+</sect2>
+
+<sect2>
+<title>CUPS also uses PPDs for non-PostScript Printers</title>
+
<para>
-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 <parameter>*cupsFilter</parameter>.
-This line
-tells the CUPS print system which printer-specific filter to use for the
-interpretation of the accompanying PostScript. Thus CUPS lets all its
-printers appear as PostScript devices to its clients, because it can act as a
-PostScript RIP for those printers, processing the received PostScript code
-into a proper raster print format.
+CUPS 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.
</para>
+</sect2>
+</sect1>
+
+<sect1>
+<title>The CUPS Filtering Architecture</title>
<para>
-CUPS-PPDs can also be used on Windows-Clients, on top of a
-PostScript driver (recommended is the Adobe one).
+The core of the CUPS filtering system is based on
+<emphasis>Ghostscript</emphasis>. 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 <emphasis>MIME types</emphasis>. Every incoming
+printfile is subjected to an initial
+<emphasis>auto-typing</emphasis>. 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.
</para>
<para>
-This feature enables CUPS to do a few tricks no other
-spooler can do:
+If CUPS rasterizes a PostScript file <emphasis>natively</emphasis> to
+a bitmap, this is done in 2 stages:
</para>
<itemizedlist>
- <listitem><para>act as a networked PostScript RIP (Raster Image Processor), handling
- printfiles from all client platforms in a uniform way;</para></listitem>
- <listitem><para>act as a central accounting and billing server, as all files are passed
- through the <command>pstops</command> Filter and are therefor logged in
- the CUPS <filename>page_log</filename>. - <emphasis>NOTE: </emphasis>this
- can not happen with "raw" print jobs, which always remain unfiltered
- per definition;</para></listitem>
- <listitem><para>enable clients to consolidate on a single PostScript driver, even for
- many different target printers.</para></listitem>
+<listitem><para>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".
+</para></listitem>
+
+<listitem><para>the second stage uses a "raster driver" which converts
+the generic CUPS raster to a device specific raster.</para></listitem>
</itemizedlist>
-</sect1>
-<sect1>
-<title>Windows Terminal Servers (WTS) as CUPS clients</title>
+<para>
+Make sure your Ghostscript version has the "cups" device compiled in
+(check with <command>gs -h | grep cups</command>). Otherwise you
+may encounter the dreaded <computeroutput>Unable to convert file
+0</computeroutput> in your CUPS error_log file. To have "cups" as a
+device in your Ghostscript, you either need to <emphasis>patch GNU
+Ghostscript</emphasis> and re-compile or use <ulink
+url="http://www.cups.org/ghostscript.php">ESP Ghostscript</ulink>. The
+superior alternative is ESP Ghostscript: it supports not just CUPS,
+but 300 other devices too (while GNU Ghostscript supports only about
+180). Because of this broad output device support, ESP Ghostscript is
+the first choice for non-CUPS spoolers too. It is now recommended by
+Linuxprinting.org for all spoolers.
+</para>
<para>
-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. In many cases, in an attempt to overcome this problem, site
-administrators have resorted to restrict the allowed drivers installed on
-their WTS to one generic PCL- and one PostScript driver. This however
-restricts the clients in the amount of printer options available for them --
-often they can't get out more then simplex prints from one standard paper
-tray, while their devices could do much better, if driven by a different
-driver!
+CUPS printers may be setup to use <emphasis>external</emphasis>
+rendering paths. One of the most common ones is provided by the
+<emphasis>Foomatic/cupsomatic</emphasis> concept, from <ulink
+url="http://www.linuxprinting.org/">Linuxprinting.org</ulink>. 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
+<emphasis>foomatic-rip</emphasis>, follows below).
</para>
+<sect2>
+<title>MIME types and CUPS Filters</title>
+
<para>
-Using an Adobe PostScript driver, enabled with a CUPS-PPD,
-seems to be a very elegant way to overcome all these shortcomings. The
-PostScript driver is not 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 just to act as a "raw spooling" device. Plus,
-this setup is not yet widely tested, although the first feedbacks look very
-promising...
+CUPS reads the file <filename>/etc/cups/mime.types</filename>
+(and all other files carrying a <filename>*.types</filename> 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 <filename>mime.types</filename> and in the comments section of the
+<filename>mime.types</filename> file itself. A simple rule reads
+like this:
</para>
-</sect1>
+<para><screen>
-<sect1>
-<title>Setting up CUPS for driver download</title>
-
-<para>
-The <command>cupsadsmb</command> utility (shipped with all current
-CUPS versions) makes the sharing of any (or all) installed CUPS printers very
-easy. Prior to using it, you need the following settings in &smb.conf;:
-</para>
-
- <para><programlisting>[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
-
- [print$]
- comment = Printer Drivers
- path = /etc/samba/drivers
- browseable = yes
- guest ok = no
- read only = yes
- write list = root
- </programlisting></para>
-
-<para>
-For licensing reasons the necessary files of the Adobe
-Postscript driver can not be distributed with either Samba or CUPS. You need
-to download them yourself from the Adobe website. Once extracted, create a
-<filename>drivers</filename> directory in the CUPS data directory (usually
-<filename>/usr/share/cups/</filename>). Copy the Adobe files using
-UPPERCASE filenames, to this directory as follows:
-</para>
-
- <para><programlisting>
- ADFONTS.MFM
- ADOBEPS4.DRV
- ADOBEPS4.HLP
- ADOBEPS5.DLL
- ADOBEPSU.DLL
- ADOBEPSU.HLP
- DEFPRTR2.PPD
- ICONLIB.DLL
- </programlisting></para>
-
-<para>
-Users of the ESP Print Pro software are able to install
-their "Samba Drivers" package for this purpose with no problem.
+ application/pdf pdf string(0,%PDF)
+
+</screen></para>
+
+<para>
+This means: if a filename has either a
+<filename>.pdf</filename> suffix, or if the magic
+string <emphasis>%PDF</emphasis> is right at the
+beginning of the file itself (offset 0 from the start), then it is
+a PDF file (<emphasis>application/pdf</emphasis>).
+Another rule is this:
</para>
-</sect1>
+<para><screen>
+ application/postscript ai eps ps string(0,%!) string(0,<04>%!)
-<sect1>
-<title>Sources of CUPS drivers / PPDs</title>
+</screen></para>
<para>
-On the internet you can find now many thousand CUPS-PPD
-files (with their companion filters), in many national languages,
-supporting more than 1.000 non-PostScript models.
+Its meaning: if the filename has one of the suffixes
+<filename>.ai</filename>, <filename>.eps</filename>,
+<filename>.ps</filename> or if the file itself starts with one of the
+strings <emphasis>%!</emphasis> or <emphasis><![CDATA[<04>%!]]></emphasis>, it
+is a generic PostScript file
+(<emphasis>application/postscript</emphasis>).
</para>
-<itemizedlist>
- <listitem><para><ulink url="http://wwwl.easysw.com/printpro/">ESP PrintPro
- (http://wwwl.easysw.com/printpro/)</ulink>
- (commercial, non-Free) is packaged with more than 3.000 PPDs, ready for
- successful usage "out of the box" on Linux, 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)</para></listitem>
- <listitem><para>the <ulink
- url="http://gimp-print.sourceforge.net/">Gimp-Print-Project
- (http://gimp-print.sourceforge.net/)</ulink>
- (GPL, Free Software) provides around 120 PPDs (supporting nearly 300
- printers, many driven to photo quality output), to be used alongside the
- Gimp-Print CUPS filters;</para></listitem>
- <listitem><para><ulink url="http://www.turboprint.com/">TurboPrint
- (http://www.turboprint.com/)</ulink>
- (Shareware, non-Freee) supports roughly the same amount of printers in
- excellent quality;</para></listitem>
- <listitem><para><ulink
- url="http://www-124.ibm.com/developerworks/oss/linux/projects/omni/">OMNI
- (http://www-124.ibm.com/developerworks/oss/linux/projects/omni/)</ulink>
- (LPGL, Free) is a package made by IBM, now containing support for more
- than 400 printers, stemming from the inheritance of IBM OS/2 KnowHow
- ported over to Linux (CUPS support is in a Beta-stage at present);</para></listitem>
- <listitem><para><ulink url="http://hpinkjet.sourceforge.net/">HPIJS
- (http://hpinkjet.sourceforge.net/)</ulink>
- (BSD-style licnes, Free) supports around 120 of HP's own printers and is
- also providing excellent print quality now;</para></listitem>
- <listitem><para><ulink
- url="http://www.linuxprinting.org/">Foomatic/cupsomatic (http://www.linuxprinting.org/)</ulink>
- (LPGL, Free) from Linuxprinting.org are providing PPDs for practically every
- Ghostscript filter known to the world, now usable with CUPS.</para></listitem>
-</itemizedlist>
+<note><para>
+There is a very important difference between two similar MIME type in
+CUPS: one is <emphasis>application/postscript</emphasis>, the other is
+<emphasis>application/vnd.cups-postscript</emphasis>. While
+<emphasis>application/postscript</emphasis> 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),
+<emphasis>application/vnd.cups-postscript</emphasis> 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 <emphasis>pstops</emphasis> filter. pstops uses information
+contained in the PPD to do the transformation.
+</para></note>
+
+<warning><para>
+Don't confuse the other mime.types file your system might be using
+with the one in the <filename>/etc/cups/</filename> directory.
+</para></warning>
<para>
-<emphasis>NOTE: </emphasis>the cupsomatic trick from Linuxprinting.org is
-working different from the other drivers. While the other drivers take the
-generic CUPS raster (produced by CUPS' own pstoraster PostScript RIP) as
-their input, cupsomatic "kidnaps" the PostScript inside CUPS, before
-RIP-ping, deviates it to an external Ghostscript installation (which now
-becomes the RIP) and gives it back to a CUPS backend once Ghostscript is
-finished. -- CUPS versions from 1.1.15 and later will provide their pstoraster
-PostScript RIP function again inside a system-wide Ghostscript
-installation rather than in "their own" pstoraster filter. (This
-CUPS-enabling Ghostscript version may be installed either as a
-patch to GNU or AFPL Ghostscript, or as a complete ESP Ghostscript package).
-However, this will not change the cupsomatic approach of guiding the printjob
-along a different path through the filtering system than the standard CUPS
-way...
+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.
</para>
+</sect2>
+
+<sect2>
+<title>MIME type Conversion Rules</title>
<para>
-Once you installed a printer inside CUPS with one of the
-recommended methods (the lpadmin command, the web browser interface or one of
-the available GUI wizards), you can use <command>cupsaddsmb</command> to share the
-printer via Samba. <command>cupsaddsmb</command> prepares the driver files for
-comfortable client download and installation upon their first contact with
-this printer share.
+CUPS reads the file <filename>/etc/cups/mime.convs</filename>
+(and all other files named with a <filename>*.convs</filename>
+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:
</para>
+<para><screen>
+ application/pdf application/postscript 33 pdftops
-<sect2>
-<title><command>cupsaddsmb</command></title>
+</screen></para>
+
+<para>
+This means that the <emphasis>pdftops</emphasis> filter will take
+<emphasis>application/pdf</emphasis> as input and produce
+<emphasis>application/postscript</emphasis> as output, the virtual
+cost of this operation is 33 CUPS-$. The next filter is more
+expensive, costing 66 CUPS-$:
+</para>
+
+<para><screen>
+
+ application/vnd.hp-HPGL application/postscript 66 hpgltops
+</screen></para>
<para>
-The <command>cupsaddsmb</command> command copies the needed files
-for convenient Windows client installations from the previously prepared CUPS
-data directory to your [print$] share. Additionally, the PPD
-associated with this printer is copied from <filename>/etc/cups/ppd/</filename> to
-[print$].
+This is the <emphasis>hpgltops</emphasis>, which processes HP-GL
+plotter files to PostScript.
</para>
-<para><programlisting>
-<prompt>root# </prompt> <command>cupsaddsmb -U root infotec_IS2027</command>
-Password for root required to access localhost via
-SAMBA: <userinput>[type in password 'secret']</userinput>
-</programlisting></para>
+<para><screen>
+
+ application/octet-stream
+
+</screen></para>
<para>
-To share all printers and drivers, use the <parameter>-a</parameter>
-parameter instead of a printer name.
+Here are two more examples:
</para>
+<para><screen>
+
+ application/x-shell application/postscript 33 texttops
+ text/plain application/postscript 33 texttops
+
+</screen></para>
<para>
-Probably you want to see what's going on. Use the
-<parameter>-v</parameter> parameter to get a more verbose output:
+The last two examples name the <emphasis>texttops</emphasis> 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").
</para>
+</sect2>
+
+<sect2>
+<title>Filter Requirements</title>
<para>
-Probably you want to see what's going on. Use the
-<parameter>-v</parameter> parameter to get a more verbose output:
+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 <filename>mime.types</filename>
+and <filename>mime.convs</filename>, then it will work seamlessly
+inside CUPS!
</para>
-<para><programlisting>
-Note: The following line shave been wrapped so that information is not lost.
-
-<prompt>root# </prompt> cupsaddsmb -v -U root infotec_IS2027
- 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/3cd1cc66376c0 W32X86/infotec_IS2027.PPD;put
- /usr/share/cups/drivers/
- ADOBEPS5.DLL W32X86/ADOBEPS5.DLL;put /usr/share/cups/drivers/ADOBEPSU.DLLr
- W32X86/ADOBEPSU.DLL;put /usr/share/cups/drivers/ADOBEPSU.HLP W32X86/ADOBEPSU.HLP'
- added interface ip=10.160.16.45 bcast=10.160.31.255 nmask=255.255.240.0
- added interface ip=192.168.182.1 bcast=192.168.182.255 nmask=255.255.255.0
- added interface ip=172.16.200.1 bcast=172.16.200.255 nmask=255.255.255.0
- Domain=[TUX-NET] OS=[Unix] Server=[Samba 2.2.3a.200204262025cvs]
- NT_STATUS_OBJECT_NAME_COLLISION making remote directory \W32X86
- putting file /var/spool/cups/tmp/3cd1cc66376c0 as
- \W32X86/infotec_IS2027.PPD (17394.6 kb/s) (average 17395.2 kb/s)
- putting file /usr/share/cups/drivers/ADOBEPS5.DLL as
- \W32X86/ADOBEPS5.DLL (10877.4 kb/s) (average 11343.0 kb/s)
- putting file /usr/share/cups/drivers/ADOBEPSU.DLL as
- \W32X86/ADOBEPSU.DLL (5095.2 kb/s) (average 9260.4 kb/s)
- putting file /usr/share/cups/drivers/ADOBEPSU.HLP as
- \W32X86/ADOBEPSU.HLP (8828.7 kb/s) (average 9247.1 kb/s)
-
- Running command: smbclient //localhost/print\$ -N -U'root%secret' -c 'mkdir WIN40;put
- /var/spool/cups/tmp/3cd1cc66376c0 WIN40/infotec_IS2027.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.16.45 bcast=10.160.31.255 nmask=255.255.240.0
- added interface ip=192.168.182.1 bcast=192.168.182.255 nmask=255.255.255.0
- added interface ip=172.16.200.1 bcast=172.16.200.255 nmask=255.255.255.0
- Domain=[TUX-NET] OS=[Unix] Server=[Samba 2.2.3a.200204262025cvs]
- NT_STATUS_OBJECT_NAME_COLLISION making remote directory \WIN40
- putting file /var/spool/cups/tmp/3cd1cc66376c0 as
- \WIN40/infotec_IS2027.PPD (26091.5 kb/s) (average 26092.8 kb/s)
- putting file /usr/share/cups/drivers/ADFONTS.MFM as
- \WIN40/ADFONTS.MFM (11241.6 kb/s) (average 11812.9 kb/s)
- putting file /usr/share/cups/drivers/ADOBEPS4.DRV as
- \WIN40/ADOBEPS4.DRV (16640.6 kb/s) (average 14679.3 kb/s)
- putting file /usr/share/cups/drivers/ADOBEPS4.HLP as
- \WIN40/ADOBEPS4.HLP (11285.6 kb/s) (average 14281.5 kb/s)
- putting file /usr/share/cups/drivers/DEFPRTR2.PPD as
- \WIN40/DEFPRTR2.PPD (823.5 kb/s) (average 12944.0 kb/s)
- putting file /usr/share/cups/drivers/ICONLIB.DLL as
- \WIN40/ICONLIB.DLL (19226.2 kb/s) (average 13169.7 kb/s)
- putting file /usr/share/cups/drivers/PSMON.DLL as
- \WIN40/PSMON.DLL (18666.1 kb/s) (average 13266.7 kb/s)
-
- Running command: rpcclient localhost -N -U'root%secret'
- -c 'adddriver "Windows NT x86"
- "infotec_IS2027:ADOBEPS5.DLL:infotec_IS2027.PPD:ADOBEPSU.DLL:
- ADOBEPSU.HLP:NULL:RAW:NULL"'
- cmd = adddriver "Windows NT x86"
- "infotec_IS2027:ADOBEPS5.DLL:infotec_IS2027.PPD:ADOBEPSU.DLL:
- ADOBEPSU.HLP:NULL:RAW:NULL"
- Printer Driver infotec_IS2027 successfully installed.
-
- Running command: rpcclient localhost -N -U'root%secret'
- -c 'adddriver "Windows 4.0"
- "infotec_IS2027:ADOBEPS4.DRV:infotec_IS2027.PPD:NULL:
- ADOBEPS4.HLP:PSMON.DLL:RAW: ADFONTS.MFM,DEFPRTR2.PPD,ICONLIB.DLL"'
- cmd = adddriver "Windows 4.0" "infotec_IS2027:ADOBEPS4.DRV:
- infotec_IS2027.PPD:NULL:ADOBEPS4.HLP:PSMON.DLL:RAW:
- ADFONTS.MFM,DEFPRTR2.PPD,ICONLIB.DLL"
- Printer Driver infotec_IS2027 successfully installed.
-
- Running command: rpcclient localhost -N -U'root%secret'
- -c 'setdriver infotec_IS2027 infotec_IS2027'
- cmd = setdriver infotec_IS2027 infotec_IS2027
- Succesfully set infotec_IS2027 to driver infotec_IS2027.
-
- <prompt>root# </prompt>
-</programlisting></para>
-
-<para>
-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
-<constant>NT_STATUS_OBJECT_NAME_COLLISION</constant> in between. They occur, because
-the directories <filename>WIN40</filename> and <filename>W32X86</filename> already
-existed in the [print$] driver download share (from a previous driver
-installation). They are harmless here.
-</para>
-
-<para>
-Now your printer is prepared for the clients to use. From
-a client, browse to the CUPS/Samba server, open the "Printers"
-share, right-click on this printer and select "Install..." or
-"Connect..." (depending on the Windows version you use). Now their
-should be a new printer in your client's local "Printers" folder,
-named (in my case) "infotec_IS2027 on kdebitshop"
-</para>
-
-<para>
-<emphasis>NOTE: </emphasis>
-<command>cupsaddsmb</command> will only reliably work i
-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 and then point the client's printer queue to the Samba printer
-share for connection, should you desire to use the CUPS networked
-PostScript RIP functions.
+<tip><para>
+The mentioned "CUPS requirements" for filters are simple. Take
+filenames or <filename>stdin</filename> as input and write to
+<filename>stdout</filename>. They should take these 5 or 6 arguments:
+<emphasis>printer job user title copies options [filename]</emphasis>
</para>
+
+<variablelist>
+<varlistentry><term>Printer</term>
+<listitem><para>The name of the printer queue (normally this is the
+name of the filter being run)</para></listitem>
+</varlistentry>
+
+<varlistentry><term>job</term>
+<listitem><para>The numeric job ID for the job being
+printed</para></listitem>
+</varlistentry>
+
+<varlistentry><term>Printer</term>
+<listitem><para>The string from the originating-user-name
+attribute</para></listitem>
+</varlistentry>
+
+<varlistentry><term>Printer</term>
+<listitem><para>The string from the job-name attribute</para></listitem>
+</varlistentry>
+
+<varlistentry><term>Printer</term>
+<listitem><para>The numeric value from the number-copies
+attribute</para></listitem>
+</varlistentry>
+
+<varlistentry><term>Printer</term>
+<listitem><para>The job options</para></listitem>
+</varlistentry>
+
+<varlistentry><term>Printer</term>
+<listitem><para>(Optionally) The print request file (if missing,
+filters expected data fed through <filename>stdin</filename>). In most
+cases it is very easy to write a simple wrapper script around existing
+filters to make them work with CUPS.</para></listitem>
+</varlistentry>
+</variablelist>
+</tip>
</sect2>
-</sect1>
+<sect2>
+<title>Prefilters</title>
-<sect1>
-<title>The CUPS Filter Chains</title>
+<para>
+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.
+</para>
<para>
-The following diagrams reveal how CUPS handles print jobs.
+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 <emphasis>application/postscript</emphasis> (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 <emphasis>imagetops</emphasis> filter. Its outcome is always of
+MIME type <emphasis>application/vnd.cups-postscript</emphasis>
+(<emphasis>not</emphasis> application/postscript), meaning it has the
+print options already embedded into the file.
</para>
-<programlisting>
-#########################################################################
-#
-# 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):
-#
-# <replaceable>SOMETHNG</replaceable>-FILEFORMAT
-# |
-# |
-# V
-# <replaceable>something</replaceable>tops
-# |
-# |
-# 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
-# rasterto<replaceable>something</replaceable> (f.e. Gimp-Print filters may be plugged in here)
-# | (= "raster driver")
-# |
-# V
-# SOMETHING-DEVICE-SPECIFIC
-# |
-# |
-# V
-# backend
-#
-#
-# ESP PrintPro has some enhanced "rasterto<replaceable>something</replaceable>" 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 rasterto<replaceable>something</replaceable> is noted.
-#
-#########################################################################
-</programlisting>
+<para>
+<figure><title>Prefiltering in CUPS to form Postscript</title>
+<graphic fileref="projdoc/imagefiles/4small.png"/>
+</figure>
+</para>
+</sect2>
-<programlisting>
-#########################################################################
+<sect2>
+<title>pstops</title>
+
+<para>
+<emphasis>pstops</emphasis>is the filter to convert
+<emphasis>application/postscript</emphasis> to
+<emphasis>application/vnd.cups-postscript</emphasis>. 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.
+</para>
+
+<para>
+<figure><title>Adding Device-specific Print Options</title>
+<graphic fileref="projdoc/imagefiles/5small.png"/>
+</figure>
+</para>
+
+<para>
+This is not all: other tasks performed by it are:
+</para>
+
+<itemizedlist>
+<listitem><para>
+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)
+</para></listitem>
+
+<listitem><para>
+putting 2 or more logical pages on one sheet of paper (the
+so-called "number-up" function)
+</para></listitem>
+
+<listitem><para>counting the pages of the job to insert the accounting
+information into the <filename>/var/log/cups/page_log</filename>
+</para></listitem>
+</itemizedlist>
+</sect2>
+
+<sect2>
+<title>pstoraster</title>
+
+<para>
+<emphasis>pstoraster</emphasis> 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 <emphasis>raster drivers</emphasis>,
+that are able to generate device-specific printer data.
+</para>
+
+<para>
+<figure><title>Postscript to intermediate Raster format</title>
+<graphic fileref="projdoc/imagefiles/6small.png"/>
+</figure>
+</para>
+
+<para>
+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).
+</para>
+
+<para>
+<figure><title>CUPS-raster production using Ghostscript</title>
+<graphic fileref="projdoc/imagefiles/7small.png"/>
+</figure>
+</para>
+
+<para>
+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.
+</para>
+
+<para>
+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
+<command>gs</command> with the <command>-sDEVICE=cups</command>
+parameter. If your Ghostscript doesn't show a success on asking for
+<command>gs -h |grep cups</command>, you might not be able to
+print. Update your Ghostscript then!
+</para>
+</sect2>
+
+<sect2>
+<title>imagetops and imagetoraster</title>
+
+<para>
+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:
+</para>
+
+<para>
+<figure><title>Image format to CUPS-raster format conversion</title>
+<graphic fileref="projdoc/imagefiles/8small.png"/>
+</figure>
+</para>
+
+</sect2>
+
+<sect2>
+<title>rasterto [printerspecific]</title>
+
+<para>
+CUPS ships with quite some different raster drivers processing CUPS
+raster. On my system I find in /usr/lib/cups/filter/ these:
+<parameter>rastertoalps, rastertobj, rastertoepson, rastertoescp,
+rastertopcl, rastertoturboprint, rastertoapdk, rastertodymo,
+rastertoescp, rastertohp</parameter> and
+<parameter>rastertoprinter</parameter>. Don't worry if you have less
+than this; some of these are installed by commercial add-ons to CUPS
+(like <parameter>rastertoturboprint</parameter>), others (like
+<parameter>rastertoprinter</parameter>) by 3rd party driver
+development projects (such as Gimp-Print) wanting to cooperate as
+closely as possible with CUPS.
+</para>
+
+<para>
+<figure><title>Raster to Printer Specific formats</title>
+<graphic fileref="projdoc/imagefiles/9small.png"/>
+</figure>
+</para>
+</sect2>
+
+<sect2>
+<title>CUPS Backends</title>
+
+<para>
+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:
+</para>
+
+<variablelist>
+<varlistentry><term>usb</term>
+<listitem><para>
+This backend sends printfiles to USB-connected printers. An
+example for the CUPS device-URI to use is:
+<filename>usb:/dev/usb/lp0</filename>
+</para></listitem></varlistentry>
+
+<varlistentry><term>serial</term>
+<listitem><para>
+This backend sends printfiles to serially connected printers.
+An example for the CUPS device-URI to use is:
+<filename>serial:/dev/ttyS0?baud=11500</filename>
+</para></listitem></varlistentry>
+
+<varlistentry><term>parallel</term>
+<listitem><para>
+This backend sends printfiles to printers connected to the
+parallel port. An example for the CUPS device-URI to use is:
+<filename>parallel:/dev/lp0</filename>
+</para></listitem></varlistentry>
+
+<varlistentry><term>scsi</term>
+<listitem><para>
+This backend sends printfiles to printers attached to the
+SCSI interface. An example for the CUPS device-URI to use is:
+<filename>scsi:/dev/sr1</filename>
+</para></listitem></varlistentry>
+
+<varlistentry><term>lpd</term>
+<listitem><para>
+This backend sends printfiles to LPR/LPD connected network
+printers. An example for the CUPS device-URI to use is:
+<filename>lpd://remote_host_name/remote_queue_name</filename>
+</para></listitem></varlistentry>
+
+<varlistentry><term>AppSocket/HP JetDirect</term>
+<listitem><para>
+This backend sends printfiles to AppSocket (a.k.a. "HP
+JetDirect") connected network printers. An example for the CUPS
+device-URI to use is:
+<filename>socket://10.11.12.13:9100</filename>
+</para></listitem></varlistentry>
+
+<varlistentry><term>ipp</term>
+<listitem><para>
+This backend sends printfiles to IPP connected network
+printers (or to other CUPS servers). Examples for CUPS device-URIs
+to use are:
+<filename>ipp:://192.193.194.195/ipp</filename>
+(for many HP printers) or
+<filename>ipp://remote_cups_server/printers/remote_printer_name</filename>
+</para></listitem></varlistentry>
+
+<varlistentry><term>http</term>
+<listitem><para>
+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:
+<filename>http:://192.193.194.195:631/ipp</filename>
+(for many HP printers) or
+<filename>http://remote_cups_server:631/printers/remote_printer_name</filename>
+</para></listitem></varlistentry>
+
+<varlistentry><term>smb</term>
+<listitem><para>
+This backend sends printfiles to printers shared by a Windows
+host. An example for CUPS device-URIs to use are:
+<filename>smb://workgroup/server/printersharename</filename>
+Or
+<filename>Smb://server/printersharename</filename>
+or
+<filename>smb://username:password@workgroup/server/printersharename</filename>
+or
+<filename>smb://username:password@server/printersharename</filename>.
+The smb:// backend is a symlink to the Samba utility
+<emphasis>smbspool</emphasis> (doesn't ship with CUPS). If the
+symlink is not present in your CUPS backend directory, have your
+root user create it: <command>ln -s `which smbspool`
+/usr/lib/cups/backend/smb</command>.
+</para></listitem></varlistentry>
+</variablelist>
+
+<para>
+It is easy to write your own backends as Shell or Perl scripts, if you
+need any modification or extension to the CUPS print system. One
+reason could be that you want to create "special" printers which send
+the printjobs as email (through a "mailto:/" backend), convert them to
+PDF (through a "pdfgen:/" backend) or dump them to "/dev/null" (In
+fact I have the system-wide default printer set up to be connected to
+a "devnull:/" backend: there are just too many people sending jobs
+without specifying a printer, or scripts and programs which don't name
+a printer. The system-wided default deletes the job and sends a polite
+mail back to the $USER asking him to alsways specify a correct
+printername).
+</para>
+
+<para>
+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 <emphasis>lpinfo</emphasis>
+utility. Used with the <parameter>-v</parameter> parameter, it lists
+all available backends:
+</para>
+
+<para><screen>
+
+ lpinfo -v
+
+</screen></para>
+</sect2>
+
+<sect2>
+<title>cupsomatic/Foomatic -- how do they fit into the Picture?</title>
+
+<para>
+"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.
+</para>
+
+<para>
+You can recognize these PPDs from the line calling the
+<emphasis>cupsomatic</emphasis> filter:
+</para>
+
+<para><screen>
+
+ *cupsFilter: "application/vnd.cups-postscript 0 cupsomatic"
+
+</screen></para>
+
+<para>
+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 <emphasis>foomatic</emphasis> namepart for
+the driver description. cupsomatic is a Perlscript that runs
+Ghostscript, with all the complicated commandline options
+auto-constructed from the selected PPD and commandline options give to
+the printjob.
+</para>
+
+<para>
+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 <emphasis>foomatic-rip</emphasis>. To use
+foomatic-rip as a filter with CUPS, you need the new-type PPDs. These
+have a similar, but different line:
+</para>
+
+<para><screen>
+
+ *cupsFilter: "application/vnd.cups-postscript 0 foomatic-rip"
+
+</screen></para>
+
+<para>
+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!
+</para>
+</sect2>
+
+<sect2>
+<title>The Complete Picture</title>
+
+<para>
+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.
+</para>
+</sect2>
+
+<sect2>
+<title><filename>mime.convs</filename></title>
+
+<para>
+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.
+</para>
+
+<tip><para>
+The setting of <parameter>FilterLimit 1000</parameter> in
+<filename>cupsd.conf</filename> 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.
+</para></tip>
+</sect2>
+
+<sect2>
+<title>"Raw" printing</title>
+
+<para>
+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:
+</para>
+
+<para><screen>
+
+ lpadmin -P rawprinter -v socket://11.12.13.14:9100 -E
+
+</screen></para>
+
+<para>
+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
+<command>-P /path/to/PPD</command> to this command line, you would
+have installed a "normal" printqueue.
+</para>
+
+<para>
+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.
+</para>
+</sect2>
+
+<sect2>
+<title>"application/octet-stream" printing</title>
+
+<para>
+Any MIME type with no rule in the
+<filename>/etc/cups/mime.types</filename> file is regarded as unknown
+or <emphasis>application/octet-stream</emphasis> 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:
+</para>
+
+<para><screen>
+
+ Unable to convert file 0 to printable format for job
+
+</screen></para>
+
+<para>
+To enable the printing of "application/octet-stream" files, edit
+these two files:
+</para>
+
+<itemizedlist>
+<listitem><para><filename>/etc/cups/mime.convs</filename></para></listitem>
+
+<listitem><para><filename>/etc/cups/mime.types</filename></para></listitem>
+</itemizedlist>
+
+<para>
+Both contain entries (at the end of the respective files) which must
+be uncommented to allow RAW mode operation for
+application/octet-stream. In <filename>/etc/cups/mime.types</filename>
+make sure this line is present:
+</para>
+
+<para><screen>
+
+ application/octet-stream
+
+</screen></para>
+
+<para>
+This line (with no specific auto-typing rule set) makes all files
+not otherwise auto-typed a member of application/octet-stream. In
+<filename>/etc/cups/mime.convs</filename>, have this
+line:
+</para>
+
+<para><screen>
+
+ application/octet-stream application/vnd.cups-raw 0 -
+
+</screen></para>
+
+<para>
+This line tells CUPS to use the <emphasis>Null Filter</emphasis>
+(denoted as "-", doing... nothing at all) on
+<emphasis>application/octet-stream</emphasis>, and tag the result as
+<emphasis>application/vnd.cups-raw</emphasis>. 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.
+</para>
+
+<note><para> Editing the <filename>mime.convs</filename> and the
+<filename>mime.types</filename> file does not
+<emphasis>enforce</emphasis> "raw" printing, it only
+<emphasis>allows</emphasis> it.
+</para></note>
+
+<formalpara>
+<title>Background</title>
+
+<para>
+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<emphasis>MIME type</emphasis>
+<emphasis>application/octet-stream</emphasis>. While you
+<emphasis>can</emphasis> send data "raw", the MIME type for these must
+be one that is known to CUPS and an allowed one. The file
+<filename>/etc/cups/mime.types</filename> defines the "rules" how CUPS
+recognizes MIME types. The file
+<filename>/etc/cups/mime.convs</filename> decides which file
+conversion filter(s) may be applied to which MIME types.
+</para>
+</formalpara>
+</sect2>
+
+<sect2>
+<title>PostScript Printer Descriptions (PPDs) for non-PS Printers</title>
+
+<para>
+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.
+</para>
+
+<para>
+PPDs for a non-PS printer have a few lines that are unique to
+CUPS. The most important one looks similar to this:
+</para>
+
+<para><screen>
+
+ *cupsFilter: application/vnd.cups-raster 66 rastertoprinter
+
+</screen></para>
+
+<para>
+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.
+</para>
+
+<para>
+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):
+</para>
+
+<variablelist>
+<varlistentry><term>deskjet.ppd</term>
+<listitem><para>older HP inkjet printers and compatible
+</para></listitem>
+</varlistentry>
+
+<varlistentry><term>deskjet2.ppd</term>
+<listitem><para>newer HP inkjet printers and compatible
+</para></listitem>
+</varlistentry>
+
+<varlistentry><term>dymo.ppd</term>
+<listitem><para>label printers
+</para></listitem>
+</varlistentry>
+
+<varlistentry><term>epson9.ppd</term>
+<listitem><para>Epson 24pin impact printers and compatible
+</para></listitem>
+</varlistentry>
+
+<varlistentry><term>epson24.ppd</term>
+<listitem><para>Epson 24pin impact printers and compatible
+</para></listitem>
+</varlistentry>
+
+<varlistentry><term>okidata9.ppd</term>
+<listitem><para>Okidata 9pin impact printers and compatible
+</para></listitem>
+</varlistentry>
+
+<varlistentry><term>okidat24.ppd</term>
+<listitem><para>Okidata 24pin impact printers and compatible
+</para></listitem>
+</varlistentry>
+
+<varlistentry><term>stcolor.ppd</term>
+<listitem><para>older Epson Stylus Color printers
+</para></listitem>
+</varlistentry>
+
+<varlistentry><term>stcolor2.ppd</term>
+<listitem><para>newer Epson Stylus Color printers
+</para></listitem>
+</varlistentry>
+
+<varlistentry><term>stphoto.ppd</term>
+<listitem><para>older Epson Stylus Photo printers
+</para></listitem>
+</varlistentry>
+
+<varlistentry><term>stphoto2.ppd</term>
+<listitem><para>newer Epson Stylus Photo printers
+</para></listitem>
+</varlistentry>
+
+<varlistentry><term>laserjet.ppd</term>
+<listitem><para>all PCL printersFurther below is a discussion
+of several other driver/PPD-packages suitable fur use with CUPS.
+</para></listitem>
+</varlistentry>
+</variablelist>
+</sect2>
+
+<sect2>
+<title>Difference between <emphasis>cupsomatic/foomatic-rip</emphasis> and
+<emphasis>native CUPS</emphasis> printing</title>
+
+<para>
+Native CUPS rasterization works in two steps.
+</para>
+
+<itemizedlist>
+<listitem><para>
+First is the "pstoraster" step. It uses the special "cups"
+device from ESP Ghostscript 7.05.x as its tool
+</para></listitem>
+
+<listitem><para>
+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.</para></listitem>
+</itemizedlist>
+
+<para>
+Often this produces better quality (and has several more
+advantages) than other methods.
+</para>
+
+<para>
+<figure><title>cupsomatic/foomatic processing versus Native CUPS</title>
+<graphic fileref="projdoc/imagefiles/10small.png"/>
+</figure>
+</para>
+
+<para>
+One other method is the <emphasis>cupsomatic/foomatic-rip</emphasis>
+way. Note that cupsomatic is <emphasis>not</emphasis> made by the CUPS
+developers. It is an independent contribution to printing development,
+made by people from Linuxprinting.org (see also <ulink
+url="http://www.cups.org/cups-help.html">http://www.cups.org/cups-help.html</ulink>).
+cupsomatic is no longer developed and maintained and is no longer
+supported. It has now been replaced by
+<emphasis>foomatic-rip</emphasis>. foomatic-rip is a complete re-write
+of the old cupsomatic idea, but very much improved and generalized to
+other (non-CUPS) spoolers. An upgrade to foomatic-rip is strongly
+adviced, especially if you are upgrading to a recent version of CUPS
+too.
+</para>
+
+<para>
+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.
+</para>
+
+<para>
+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.
+</para>
+
+<para>
+cupsomatic "kidnaps" the printfile after the
+<emphasis>application/vnd.cups-postscript</emphasis> stage and
+deviates it through the CUPS-external, systemwide Ghostscript
+installation: Therefore the printfile bypasses the "pstoraster" filter
+(and thus also bypasses the CUPS-raster-drivers
+"rastertosomething"). After Ghostscript finished its rasterization,
+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.
+</para>
+</sect2>
+
+<sect2>
+<title>Examples for filtering Chains</title>
+
+<para>
+Here are a few examples of commonly occurring filtering chains to
+illustrate the workings of CUPS.
+</para>
+
+<para>
+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":
+</para>
+
+<itemizedlist>
+<listitem><para>your print options (page selection as required, 2-up,
+duplex) are passed to CUPS on the commandline;</para></listitem>
+
+<listitem><para>the (complete) PDF file is sent to CUPS and autotyped as
+<emphasis>application/pdf</emphasis>;</para></listitem>
+
+<listitem><para>the file therefore first must pass the
+<emphasis>pdftops</emphasis> pre-filter, which produces PostScript
+MIME type <emphasis>application/postscript</emphasis> (a preview here
+would still show all pages of the original PDF);</para></listitem>
+
+<listitem><para>the file then passes the <emphasis>pstops</emphasis>
+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
+<emphasis>application/vnd.cups-postscript</emphasis>;</para></listitem>
+
+<listitem><para>the file goes to the <emphasis>socket</emphasis>
+backend, which transfers the job to the printers.</para></listitem>
+</itemizedlist>
+
+<para>
+The resulting filter chain therefore is:
+</para>
+
+<para><screen>
+pdftops --> pstops --> socket
+</screen></para>
+
+<para>
+Assume your want to print the same filter to an USB-connected
+Epson Stylus Photo printer, installed with the CUPS
+<filename>stphoto2.ppd</filename>. The first few filtering stages
+are nearly the same:
+</para>
+
+<itemizedlist>
+<listitem><para>your print options (page selection as required, 2-up,
+duplex) are passed to CUPS on the commandline;</para></listitem>
+
+<listitem><para>the (complete) PDF file is sent to CUPS and autotyped as
+<emphasis>application/pdf</emphasis>;</para></listitem>
+
+<listitem><para>the file therefore first must pass the
+<emphasis>pdftops</emphasis> pre-filter, which produces PostScript
+MIME type <emphasis>application/postscript</emphasis> (a preview here
+would still show all pages of the original PDF);</para></listitem>
+
+<listitem><para>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
+<emphasis>application/vnd.cups-postscript</emphasis>;</para></listitem>
+
+<listitem><para>the file then passes the
+<emphasis>pstoraster</emphasis> stage and becomes MIME type
+<emphasis>application/cups-raster</emphasis>;</para></listitem>
+
+<listitem><para>finally, the <emphasis>rastertoepson</emphasis> 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;</para></listitem>
+
+<listitem><para>the file goes to the <emphasis>usb</emphasis> backend,
+which transfers the job to the printers.</para></listitem>
+</itemizedlist>
+
+<para>
+The resulting filter chain therefore is:
+</para>
+
+<para><screen>
+pdftops --> pstops --> pstoraster --> rastertoepson --> usb
+</screen></para>
+</sect2>
+
+<sect2>
+<title>Sources of CUPS drivers / PPDs</title>
+
+<para>
+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.
+</para>
+
+<itemizedlist>
+<listitem><para><ulink url="http://wwwl.easysw.com/printpro/">ESP
+PrintPro (http://wwwl.easysw.com/printpro/)</ulink> (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).</para></listitem>
+
+<listitem><para>the <ulink
+url="http://gimp-print.sourceforge.net/">Gimp-Print-Project
+(http://gimp-print.sourceforge.net/)</ulink> (GPL, Free Software)
+provides around 140 PPDs (supporting nearly 400 printers, many driven
+to photo quality output), to be used alongside the Gimp-Print CUPS
+filters;</para></listitem>
+
+<listitem><para><ulink url="http://www.turboprint.com/">TurboPrint
+(http://www.turboprint.com/)</ulink> (Shareware, non-Free) supports
+roughly the same amount of printers in excellent
+quality;</para></listitem>
+
+<listitem><para><ulink
+url="http://www-124.ibm.com/developerworks/oss/linux/projects/omni/">OMNI
+(http://www-124.ibm.com/developerworks/oss/linux/projects/omni/)</ulink>
+(LPGL, Free) is a package made by IBM, now containing support for more
+than 400 printers, stemming from the inheritance of IBM OS/2 KnowHow
+ported over to Linux (CUPS support is in a Beta-stage at
+present);</para></listitem>
+
+<listitem><para><ulink url="http://hpinkjet.sourceforge.net/">HPIJS
+(http://hpinkjet.sourceforge.net/)</ulink> (BSD-style licenses, Free)
+supports around 150 of HP's own printers and is also providing
+excellent print quality now (currently available only via the Foomatic
+path);</para></listitem>
+
+<listitem><para><ulink
+url="http://www.linuxprinting.org/">Foomatic/cupsomatic
+(http://www.linuxprinting.org/)</ulink> (LPGL, Free) from
+Linuxprinting.org are providing PPDs for practically every Ghostscript
+filter known to the world (including Omni, Gimp-Print and
+HPIJS).</para></listitem>
+</itemizedlist>
+
+<note><para>
+The cupsomatic/Foomatic trick from Linuxprinting.org works
+differently from the other drivers. This is explained elsewhere in this
+document.
+</para></note>
+</sect2>
+
+<sect2>
+<title>Printing with Interface Scripts</title>
+
+<para>
+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 <command>-i</command> option:
+</para>
+
+<para><screen>
+
+ lpadmin -p pclprinter -v socket://11.12.13.14:9100 -i /path/to/interface-script
+
+</screen></para>
+
+<para>
+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 <ulink
+url="http://playground.sun.com/printing/documentation/interface.html">http://playground.sun.com/printing/documentation/interface.html</ulink>).
+</para>
+</sect2>
+</sect1>
+
+<sect1>
+<title>Network printing (purely Windows)</title>
+
+<para>
+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.
+</para>
+
+<sect2>
+<title>From Windows Clients to an NT Print Server</title>
+
+<para>
+Windows clients printing to an NT-based print server have two
+options. They may
+</para>
+
+<itemizedlist>
+<listitem><para>execute the driver locally and render the GDI output
+(EMF) into the printer specific format on their own,
+or</para></listitem>
+
+<listitem><para>send the GDI output (EMF) to the server, where the
+driver is executed to render the printer specific
+output.</para></listitem>
+</itemizedlist>
+
+<para>
+Both print paths are shown in the flowcharts below.
+</para>
+</sect2>
+
+<sect2>
+<title>Driver Execution on the Client</title>
+
+<para>
+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.
+</para>
+
+<para>
+<figure><title>Print Driver execution on the Client</title>
+<graphic fileref="projdoc/imagefiles/11small.png"/>
+</figure>
+</para>
+</sect2>
+
+<sect2>
+<title>Driver Execution on the Server</title>
+
+<para>
+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.
+</para>
+
+<para>
+<figure><title>Print Driver execution on the Server</title>
+<graphic fileref="projdoc/imagefiles/12small.png"/>
+</figure>
+</para>
+
+<para>
+However, there is something similar possible with CUPS. Read on...
+</para>
+</sect2>
+</sect1>
+
+<sect1>
+<title>Network Printing (Windows clients -- UNIX/Samba Print
+Servers)</title>
+
+<para>
+Since UNIX print servers <emphasis>cannot</emphasis> 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.
+</para>
+
+<sect2>
+<title>From Windows Clients to a CUPS/Samba Print Server</title>
+
+<para>
+Here is a simple recipe showing how you can take advantage of CUPS
+powerful features for the benefit of your Windows network printing
+clients:
+</para>
+
+<itemizedlist>
+
+<listitem><para>Let the Windows clients send PostScript to the CUPS
+server.</para></listitem>
+
+<listitem><para>Let the CUPS server render the PostScript into device
+specific raster format.</para></listitem>
+</itemizedlist>
+
+<para>
+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.
+</para>
+
+<para>
+Firstly, to enable CUPS based printing through Samba the
+following options should be set in your <filename>smb.conf</filename> file [globals]
+section:
+</para>
+
+<itemizedlist>
+<listitem><para><parameter>printing = CUPS</parameter></para></listitem>
+
+<listitem><para><parameter>printcap = CUPS</parameter></para></listitem>
+</itemizedlist>
+
+<para>
+When these parameters are specified, all manually set print directives
+(like <parameter>print command =...</parameter>, or <parameter>lppause
+command =...</parameter>) in <filename>smb.conf</filename> (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
+<emphasis>System V</emphasis> 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 <parameter>printing = sysv</parameter>).
+</para>
+
+<para>
+<figure><title>Printing via CUPS/samba server</title>
+<graphic fileref="projdoc/imagefiles/13small.png"/>
+</figure>
+</para>
+</sect2>
+
+<sect2>
+<title>Samba receiving Jobfiles and passing them to CUPS</title>
+
+<para>
+Samba<emphasis>must</emphasis> use its own spool directory (it is set
+by a line similar to <parameter>path = /var/spool/samba</parameter>,
+in the <parameter>[printers]</parameter> or
+<parameter>[printername]</parameter> section of
+<filename>smb.conf</filename>). 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 <parameter>RequestRoot</parameter>
+directive, in a line that defaults to <parameter>RequestRoot
+/var/spool/cups</parameter>). 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".
+</para>
+
+<para>
+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.
+</para>
+</sect2>
+</sect1>
+
+<sect1>
+<title>Network PostScript RIP: CUPS Filters on Server -- clients use
+PostScript Driver with CUPS-PPDs</title>
+
+<para>
+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.
+</para>
+
+<para>
+CUPS can load, without any conversions, the PPD file from any Windows
+(NT is recommended) PostScript driver and handle the options. There is
+a web browser interface to the print options (select <ulink
+url="http://localhost:631/printers/">http://localhost:631/printers/</ulink>
+and click on one <emphasis>Configure Printer</emphasis> button to see
+it), or a commandline interface (see <command>man lpoptions</command>
+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.
+</para>
+
+<sect2>
+<title>PPDs for non-PS Printers on UNIX</title>
+
+<para>
+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.
+</para>
+
+<para>
+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
+<parameter>*cupsFilter</parameter> . 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.
+</para>
+</sect2>
+
+<sect2>
+<title>PPDs for non-PS Printers on Windows</title>
+
+<para>
+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:
+</para>
+
+<itemizedlist>
+
+<listitem><para>act as a networked PostScript RIP (Raster Image
+Processor), handling printfiles from all client platforms in a uniform
+way;</para></listitem>
+
+<listitem><para>act as a central accounting and billing server, since
+all files are passed through the pstops filter and are therefore
+logged in the CUPS <filename>page_log</filename> file.
+<emphasis>NOTE:</emphasis> this can not happen with "raw" print jobs,
+which always remain unfiltered per definition;</para></listitem>
+
+<listitem><para>enable clients to consolidate on a single PostScript
+driver, even for many different target printers.</para></listitem>
+</itemizedlist>
+
+<para>
+Using CUPS PPDs on Windows clients enables these to control
+all print job settings just as a UNIX client can do too.
+</para>
+</sect2>
+</sect1>
+
+<sect1>
+<title>Windows Terminal Servers (WTS) as CUPS Clients</title>
+
+<para>
+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.
+</para>
+
+<sect2>
+<title>Printer Drivers running in "Kernel Mode" cause many
+Problems</title>
+
+<para>
+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?
+</para>
+
+<para>
+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.
+</para>
+</sect2>
+
+<sect2>
+<title>Workarounds impose Heavy Limitations</title>
+
+<para>
+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! )
+</para>
+</sect2>
+
+<sect2>
+<title>CUPS: a "Magical Stone"?</title>
+
+<para>
+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.
+</para>
+</sect2>
+
+<sect2>
+<title>PostScript Drivers with no major problems -- even in Kernel
+Mode</title>
+
+<para>
+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.
+</para>
+</sect2>
+</sect1>
+
+<sect1>
+<title> Setting up CUPS for driver Download</title>
+
+<para>
+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.
+</para>
+
+<sect2>
+<title><emphasis>cupsaddsmb</emphasis>: the unknown Utility</title>
+
+<para>
+The cupsaddsmb utility (shipped with all current CUPS versions) is an
+alternative method to transfer printer drivers into the Samba
+<parameter>[print$]</parameter> 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 <emphasis>CUPS PostScript Driver for
+WinNT/2K/XP</emphasis>. Note, that cupsaddsmb does
+<emphasis>not</emphasis> work with arbitrary vendor printer drivers,
+but only with the <emphasis>exact</emphasis> driver files that are
+named in its man page.
+</para>
+
+<para>
+The CUPS printer driver is available from the CUPS download site. Its
+package name is <filename>cups-samba-[version].tar.gz</filename> . It
+is prefered over the Adobe drivers since it has a number of
+advantages:
+</para>
+
+<itemizedlist>
+<listitem><para>it supports a much more accurate page
+accounting;</para></listitem>
+
+<listitem><para>it supports banner pages, and page labels on all
+printers;</para></listitem>
+
+<listitem><para>it supports the setting of a number of job IPP
+attributes (such as job-priority, page-label and
+job-billing)</para></listitem>
+</itemizedlist>
+
+<para>
+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.
+</para>
+</sect2>
+
+<sect2>
+<title>Prepare your <filename>smb.conf</filename> for
+cupsaddsmb</title>
+
+<para>
+Prior to running cupsaddsmb, you need the following settings in
+<filename>smb.conf</filename>:
+</para>
+
+<para><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
+
+</screen></para>
+</sect2>
+
+<sect2>
+<title>CUPS Package of "PostScript Driver for WinNT/2k/XP"</title>
+
+<para>
+CUPS users may get the exactly same packages from<ulink
+url="http://www.cups.org/software.html"><emphasis>http://www.cups.org/software.html</emphasis></ulink>.
+It is a separate package from the CUPS base software files, tagged as
+<emphasis>CUPS 1.1.x Windows NT/2k/XP Printer Driver for SAMBA
+(tar.gz, 192k)</emphasis>. The filename to download is
+<filename>cups-samba-1.1.x.tar.gz</filename>. Upon untar-/unzip-ing,
+it will reveal these files:
+</para>
+
+<para><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
+
+</screen></para>
+
+<para>
+These have been packaged with the ESP meta packager software
+"EPM". The <filename>*.install</filename> and
+<filename>*.remove</filename> files are simple shell scripts, which
+untars the <filename>*.ss</filename> (the <filename>*.ss</filename> is
+nothing else but a tar-archive, which can be untar-ed by "tar"
+too). Then it puts the content into
+<filename>/usr/share/cups/drivers/</filename>. This content includes 3
+files:
+</para>
+
+<para><screen>
+
+# tar tv cups-samba.ss
+
+ cupsdrvr.dll
+ cupsui.dll
+ cups.hlp
+
+</screen></para>
+
+<para>
+The <emphasis>cups-samba.install</emphasis> shell scripts is easy to
+handle:
+</para>
+
+<para><screen>
+
+# ./cups-samba.install
+
+ [....]
+ Installing software...
+ Updating file permissions...
+ Running post-install commands...
+ Installation is complete.
+
+</screen></para>
+
+<para>
+The script should automatically put the driver files into the
+<filename>/usr/share/cups/drivers/</filename> directory.
+</para>
+
+<warning><para>
+Due to a bug, one recent CUPS release puts the
+<filename>cups.hlp</filename> driver file
+into<filename>/usr/share/drivers/</filename> instead of
+<filename>/usr/share/cups/drivers/</filename>. To work around this,
+copy/move the file (after running the
+<command>./cups-samba.install</command> script) manually to the
+right place.
+</para></warning>
+
+<para><screen>
+
+ cp /usr/share/drivers/cups.hlp /usr/share/cups/drivers/
+
+</screen></para>
+
+<para>
+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 <emphasis>Microsoft Driver
+Developer Kit</emphasis> (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.
+</para>
+</sect2>
+
+<sect2>
+<title>Recognize the different Driver Files</title>
+
+<para>
+The CUPS drivers don't support the "older" Windows 95/98/ME, but only
+the Windows NT/2000/XP client:
+</para>
+
+<para><screen>
+
+ [Windows NT, 2000, and XP are supported by:]
+ cups.hlp
+ cupsdrvr.dll
+ cupsui.dll
+
+</screen></para>
+
+<para>
+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.
+</para>
+
+<para><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
+
+</screen></para>
+
+<note><para>
+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.
+</para></note>
+</sect2>
+
+<sect2>
+<title>Acquiring the Adobe Driver Files</title>
+
+<para>
+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
+<parameter>[print$]</parameter> 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.
+</para>
+</sect2>
+
+<sect2>
+<title>ESP Print Pro Package of "PostScript Driver for
+WinNT/2k/XP"</title>
+
+<para>
+Users of the ESP Print Pro software are able to install their "Samba
+Drivers" package for this purpose with no problem. Retrieve the driver
+files from the normal download area of the ESP Print Pro software
+at<ulink
+url="http://www.easysw.com/software.html">http://www.easysw.com/software.html</ulink>.
+You need to locate the link labelled "SAMBA" amongst the
+<emphasis>Download Printer Drivers for ESP Print Pro 4.x</emphasis>
+area and download the package. Once installed, you can prepare any
+driver by simply highlighting the printer in the Printer Manager GUI
+and select <emphasis>Export Driver...</emphasis> from the menu. Of
+course you need to have prepared Samba beforehand too to handle the
+driver files; i.e. mainly setup the <parameter>[print$]</parameter>
+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.
+</para>
+</sect2>
+
+<sect2>
+<title>Caveats to be considered</title>
+
+<para>
+Once you have run the install script (and possibly manually
+moved the <filename>cups.hlp</filename> file to
+<filename>/usr/share/cups/drivers/</filename>), the driver is
+ready to be put into Samba's <parameter>[print$]</parameter> share (which often maps to
+<filename>/etc/samba/drivers/</filename> and contains a subdir
+tree with <emphasis>WIN40</emphasis> and
+<emphasis>W32X86</emphasis> branches): You do this by running
+"cupsaddsmb" (see also <command>man cupsaddsmb</command> for
+CUPS since release 1.1.16).
+</para>
+
+<tip><para>
+You may need to put root into the smbpasswd file by running
+<command>smbpasswd</command>; 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
+<emphasis>Single Sign On</emphasis> to a Windows Domain Controller.
+</para></tip>
+
+<para>
+Once the driver files are in the <parameter>[print$]</parameter> share
+and are initialized, they are ready to be downloaded and installed by
+the Win NT/2k/XP clients.
+</para>
+
+<note><para>
+<orderedlist>
+<listitem><para>
+Win 9x/ME clients won't work with the CUPS PostScript driver. For
+these you'd still need to use the <filename>ADOBE*.*</filename>
+drivers as previously.
+</para></listitem>
+
+<listitem><para>
+It is not harmful if you still have the
+<filename>ADOBE*.*</filename> driver files from previous
+installations in the <filename>/usr/share/cups/drivers/</filename>
+directory. The new <emphasis>cupsaddsmb</emphasis> (from 1.1.16) will
+automatically prefer "its own" drivers if it finds both.
+</para></listitem>
+
+<listitem><para>
+Should your Win clients have had the old <filename>ADOBE*.*</filename>
+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 <emphasis>Start
+--> Settings --> Control Panel --> Printers</emphasis>),
+right-click onto the folder background and select <emphasis>Server
+Properties</emphasis>. When the new dialog opens, select the
+<emphasis>Drivers</emphasis> tab. On the list select the driver you
+want to delete and click on the <emphasis>Delete</emphasis>
+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.
+</para></listitem>
+
+<listitem><para>
+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 <command>rpcclient</command> with the
+<command>setdriver</command> sub-command.
+</para></listitem>
+</orderedlist>
+</para></note>
+</sect2>
+
+<sect2>
+<title>What are the Benefits of using the "CUPS PostScript Driver for
+Windows NT/2k/XP" as compared to the Adobe Driver?</title>
+
+<para>
+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:
+</para>
+
+<itemizedlist>
+<listitem><para>no hassle with the Adobe EULA</para></listitem>
+
+<listitem><para>no hassle with the question <quote>Where do I
+get the ADOBE*.* driver files from?</quote></para></listitem>
+
+<listitem><para>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
+<parameter><1B >%-12345X</parameter> or
+<parameter><escape>%-12345X</parameter> instead
+of <parameter>%!PS</parameter>). 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
+<emphasis>application/postscript</emphasis>, but as
+the more special MIME type
+<emphasis>application/cups.vnd-postscript</emphasis>),
+which therefore also leads to the page accounting in
+<emphasis>/var/log/cups/page_log</emphasis> not
+receiving the exact mumber of pages; instead the dummy page number
+of "1" is logged in a standard setup)</para></listitem>
+
+<listitem><para>the Adobe driver has more options to "mis-configure" the
+PostScript generated by it (like setting it inadvertedly to
+<emphasis>Optimize for Speed</emphasis>, instead of
+<emphasis>Optimize for Portability</emphasis>, which
+could lead to CUPS being unable to process it)</para></listitem>
+
+<listitem><para>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 <emphasis>application/postscript</emphasis>,
+thusly passing through the CUPS "pstops" filter and logging the
+correct number of pages in the <filename>page_log</filename> for
+accounting and quota purposes</para></listitem>
+
+<listitem><para>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
+<emphasis>banner pages</emphasis> (or the custom ones, should they be
+installed at the time of driver download), using the CUPS
+<emphasis>page-label</emphasis> option, setting a
+<emphasis>job-priority</emphasis> and setting the <emphasis>scheduled
+time of printing</emphasis> (with the option to support additional
+useful IPP job attributes in the future).</para></listitem>
+
+<listitem><para>the CUPS PostScript driver supports the inclusion of
+the new <emphasis>*cupsJobTicket</emphasis> 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).</para></listitem>
+
+<listitem><para>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).</para></listitem>
+</itemizedlist>
+
+</sect2>
+
+<sect2>
+<title>Run "cupsaddsmb" (quiet Mode)</title>
+
+<para>
+The cupsaddsmb command copies the needed files into your
+<parameter>[print$]</parameter> share. Additionally, the PPD
+associated with this printer is copied from
+<filename>/etc/cups/ppd/</filename> to
+<parameter>[print$]</parameter>. 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 (<parameter>security = user</parameter>). Probably your
+root has already a Samba account. Otherwise, create it now, using
+<command>smbpasswd</command>:
+</para>
+
+<para><screen>
+
+ # smbpasswd -a root
+ New SMB password: [type in password 'secret']
+ Retype new SMB password: [type in password 'secret']
+
+</screen></para>
+
+<para>
+Here is an example of a successfully run cupsaddsmb command.
+</para>
+
+<para><screen>
+
+ # cupsaddsmb -U root infotec_IS2027
+ Password for root required to access localhost via SAMBA: [type in password 'secret']
+
+</screen></para>
+
+<para>
+To share<emphasis>all</emphasis> printers and drivers, use the
+<parameter>-a</parameter> 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.
+</para>
+</sect2>
+
+<sect2>
+<title>Run "cupsaddsmb" with verbose Output</title>
+
+<para>
+Probably you want to see what's going on. Use the
+<parameter>-v</parameter> 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:
+</para>
+
+<warning><para>
+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!
+</para></warning>
+
+<para><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
+ Succesfully set infotec_2105 to driver infotec_2105.
+
+</screen></para>
+
+<para>
+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 <parameter>[print$]</parameter> driver download share
+(from a previous driver installation). They are harmless here.
+</para>
+</sect2>
+
+<sect2>
+<title>Understanding cupsaddsmb</title>
+
+<para>
+What has happened? What did cupsaddsmb do? There are five stages of
+the procedure
+</para>
+
+<orderedlist>
+
+<listitem><para>call the CUPS server via IPP and request the
+driver files and the PPD file for the named printer;</para></listitem>
+
+<listitem><para>store the files temporarily in the local
+TEMPDIR (as defined in
+<filename>cupsd.conf</filename>);</para></listitem>
+
+<listitem><para>connect via smbclient to the Samba server's
+ <parameter>[print$]</parameter> share and put the files into the
+ share's WIN40 (for Win95/98/ME) and W32X86/ (for WinNT/2k/XP) sub
+ directories;</para></listitem>
+
+<listitem><para>connect via rpcclient to the Samba server and
+execute the "adddriver" command with the correct
+parameters;</para></listitem>
+
+<listitem><para>connect via rpcclient to the Samba server a second
+time and execute the "setdriver" command.</para></listitem>
+</orderedlist>
+
+<para>
+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):
+</para>
+
+<para><screen>
+
+ # cupsaddsmb -H sambaserver -h cupsserver -v printername
+
+</screen></para>
+</sect2>
+
+<sect2>
+<title>How to recognize if cupsaddsm completed successfully</title>
+
+<para>
+You <emphasis>must</emphasis> always check if the utility completed
+successfully in all fields. You need as a minimum these 3 messages
+amongst the output:
+</para>
+
+<orderedlist>
+
+<listitem><para><emphasis>Printer Driver infotec_2105 successfully
+installed.</emphasis> # (for the W32X86 == WinNT/2K/XP
+architecture...)</para></listitem>
+
+<listitem><para><emphasis>Printer Driver infotec_2105 successfully
+installed.</emphasis> # (for the WIN40 == Win9x/ME
+architecture...)</para></listitem>
+
+<listitem><para><emphasis>Succesfully set [printerXPZ] to driver
+[printerXYZ].</emphasis></para></listitem>
+</orderedlist>
+
+<para>
+These messages probably not easily recognized in the general
+output. If you run cupsaddsmb with the <parameter>-a</parameter>
+parameter (which tries to prepare <emphasis>all</emphasis> 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.
+</para>
+
+<note><para>
+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.
+</para></note>
+</sect2>
+
+<sect2>
+<title>cupsaddsmb with a Samba PDC</title>
+
+<para>
+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:
+</para>
+
+<para><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
+
+</screen></para>
+
+<para>
+(Note the two backslashes: the first one is required to
+"escape" the second one).
+</para>
+</sect2>
+
+<sect2>
+<title>cupsaddsmb Flowchart</title>
+
+<para>
+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!
+</para>
+
+<para>
+<figure><title>cupsaddsmb flowchart</title>
+<graphic fileref="projdoc/imagefiles/14small.png"/>
+</figure>
+</para>
+</sect2>
+
+<sect2>
+<title>Installing the PostScript Driver on a Client</title>
+
+<para>
+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;
+</para>
+
+<itemizedlist>
+
+<listitem><para>open the <emphasis>Printers</emphasis>
+share of Samba in Network Neighbourhood;</para></listitem>
+
+<listitem><para>right-click on the printer in
+question;</para></listitem>
+
+<listitem><para>from the opening context-menu select
+<emphasis>Install...</emphasis> or
+<emphasis>Connect...</emphasis> (depending on the Windows version you
+use).</para></listitem>
+</itemizedlist>
+
+<para>
+After a few seconds, there should be a new printer in your
+client's <emphasis>local</emphasis> "Printers" folder: On Windows
+XP it will follow a naming convention of <emphasis>PrinterName on
+SambaServer</emphasis>. (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
+<filename>\\SambaServer\PrinterName</filename> entry in the
+dropdown list of available printers.
+</para>
+
+<note><para>
+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:
+</para></note>
+
+<para><screen>
+
+ net use lpt1: \\sambaserver\printershare /user:ntadmin
+
+</screen></para>
+
+<para>
+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
+<emphasis>LanMan</emphasis> way (not using MS-RPC).
+</para>
+</sect2>
+
+<sect2>
+<title>Avoiding critical PostScript Driver Settings on the
+Client</title>
+
+<para>
+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:
+</para>
+
+<itemizedlist>
+<listitem><para>Avoid the <emphasis>PostScript Output Option: Optimize
+for Speed</emphasis> settting. Rather use the <emphasis>Optimize for
+Portability</emphasis> instead (Adobe PostScript
+driver).</para></listitem>
+
+<listitem><para>Don't use the <emphasis>Page Independence:
+NO</emphasis> setting. Instead use <emphasis>Page Independence
+YES</emphasis> (CUPS PostScript Driver)</para></listitem>
+
+<listitem><para>Recommended is the <emphasis>True Type Font
+Downloading Option: Native True Type</emphasis> over
+<emphasis>Automatic</emphasis> and <emphasis>Outline</emphasis>; you
+should by all means avoid <emphasis>Bitmap</emphasis> (Adobe
+PostScript Driver)</para></listitem>
+
+<listitem><para>Choose <emphasis>True Type Font: Download as Softfont
+into Printer</emphasis> over the default <emphasis>Replace by Device
+Font</emphasis> (for exotic fonts you may need to change it back to
+get a printout at all) (Adobe)</para></listitem>
+
+<listitem><para>Sometimes you can choose <emphasis>PostScript Language
+Level</emphasis>: in case of problems try <emphasis>2</emphasis>
+instead of <emphasis>3</emphasis> (the latest ESP Ghostscript package
+handels Level 3 PostScript very well) (Adobe).</para></listitem>
+
+<listitem><para>Say <emphasis>Yes</emphasis> to <emphasis>PostScript
+Error Handler</emphasis> (Adobe)</para></listitem>
+</itemizedlist>
+</sect2>
+</sect1>
+
+<sect1>
+<title>Installing PostScript Driver Files manually (using
+rpcclient)</title>
+
+<para>
+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.
+</para>
+
+<orderedlist>
+<listitem><para>prepare Samba (a CUPS printqueue with the name of the
+printer should be there. We are providing the driver
+now);</para></listitem>
+
+<listitem><para>copy all files to
+<parameter>[print$]:</parameter></para></listitem>
+
+<listitem><para>run <command>rpcclient adddriver</command>
+(for each client architecture you want to support):</para></listitem>
+
+<listitem><para>run <command>rpcclient
+setdriver.</command></para></listitem>
+</orderedlist>
+
+<para>
+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. <command>enumprinters</command>,
+<command>enumdrivers</command>, <command>enumports</command>,
+<command>adddriver</command>, <command>setdriver</command> 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.
+</para>
+
+<sect2>
+<title>A Check of the rpcclient man Page</title>
+
+<para>
+First let's have a little check of the rpcclient man page. Here are
+two relevant passages:
+</para>
+
+<para>
+<command>adddriver <arch> <config></command> 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 <command>getdriverdir</command>. Possible
+values for <parameter>arch</parameter> are the same as those for the
+<command>getdriverdir</command> command. The
+<parameter>config</parameter> parameter is defined as follows:
+</para>
+
+<para><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
+</screen></para>
+
+<para>Any empty fields should be enter as the string "NULL". </para>
+
+<para>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
+</para>
+
+<para>
+<command>setdriver <printername> <drivername></command>
+Execute a <command>SetPrinter()</command> command to update the
+printer driver associated with an installed printer. The printer
+driver must already be correctly installed on the print server.
+</para>
+
+<para> See also the enumprinters and enumdrivers commands for
+obtaining a list of installed printers and drivers.
+</para>
+
+</sect2>
+
+<sect2>
+<title>Understanding the rpcclient man Page</title>
+
+<para>
+The <emphasis>exact</emphasis> 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:
+</para>
+
+<para><screen>
+
+ adddriver "Architecture" \
+ "LongPrinterName:DriverFile:DataFile:ConfigFile:HelpFile:\
+ LanguageMonitorFile:DataType:ListOfFiles,Comma-separated"
+
+</screen></para>
+
+<para>
+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
+<emphasis>rpcclient ... setdriver</emphasis> command. For
+practical reasons, many name the driver the same as the
+printer.
+</para>
+
+<para>
+True: it isn't simple at all. I hear you asking:
+<emphasis>How do I know which files are "Driver
+File", "Data File", "Config File", "Help File" and "Language
+Monitor File" in each case?</emphasis> -- 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 <command>rpcclient</command> to see what it tells us and
+try to understand the man page more clearly which we've read just
+now.
+</para>
+</sect2>
+
+<sect2>
+<title>Producing an Example by querying a Windows Box</title>
+
+<para>
+We could run <command>rpcclient</command> with a
+<command>getdriver</command> or a <command>getprinter</command>
+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:
+</para>
+
+<para><screen>
+
+ rpcclient -U'USERNAME%PASSWORD' NT-SERVER-NAME -c 'getdriver printername 3'
+
+</screen></para>
+
+<para>
+From the result it should become clear which is which. Here is an
+example from my installation:
+</para>
+
+<para><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: []
+
+</screen></para>
+
+<para>
+Some printer drivers list additional files under the label
+"Dependentfiles": these would go into the last field
+<emphasis>ListOfFiles,Comma-separated</emphasis>. 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.
+</para>
+</sect2>
+
+<sect2>
+<title>What is required for adddriver and setdriver to succeed</title>
+
+<para>
+From the manpage (and from the quoted output
+of<emphasis>cupsaddsmb</emphasis>, 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 (<command>adddriver</command> and
+<command>setdriver</command>) need to encounter the following
+pre-conditions to complete successfully:
+</para>
+<itemizedlist>
+
+<listitem><para>you are connected as "printer admin", or root (note,
+that this is <emphasis>not</emphasis> the "Printer Operators" group in
+NT, but the <emphasis>printer admin</emphasis> group, as defined in
+the <parameter>[global]</parameter> section of
+<filename>smb.conf</filename>);</para></listitem>
+
+<listitem><para>copy all required driver files to
+<filename>\\sambaserver\print$\w32x86</filename> and
+<filename>\\sambaserver\print$\win40</filename> as appropriate. They
+will end up in the "0" respective "2" subdirectories later -- for now
+<emphasis>don't</emphasis> put them there, they'll be automatically
+used by the <command>adddriver</command> subcommand.! (if you use
+"smbclient" to put the driver files into the share, note that you need
+to escape the "$": <command>smbclient //sambaserver/print\$ -U
+root</command>);</para></listitem>
+
+<listitem><para>the user you're connecting as must be able to write to
+the <parameter>[print$]</parameter> share and create
+subdirectories;</para></listitem>
+
+<listitem><para>the printer you are going to setup for the Windows
+clients, needs to be installed in CUPS already;</para></listitem>
+
+<listitem><para>the CUPS printer must be known to Samba, otherwise the
+<command>setdriver</command> subcommand fails with an
+NT_STATUS_UNSUCCESSFUL error. To check if the printer is known by
+Samba you may use the <command>enumprinters</command> 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.</para></listitem>
+</itemizedlist>
+</sect2>
+
+<sect2>
+<title>Manual Commandline Driver Installation in 15 little Steps</title>
+
+<para>
+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.
+</para>
+
+<sect3>
+<title>First Step: Install the Printer on CUPS</title>
+
+<para><screen>
+
+# lpadmin -p mysmbtstprn -v socket://10.160.51.131:9100 -E -P /home/kurt/canonIR85.ppd
+
+</screen></para>
+
+<para>
+This installs printer with the name <emphasis>mysmbtstprn</emphasis>
+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
+</para>
+</sect3>
+
+<sect3>
+<title>Second Step (optional): Check if the Printer is recognized by
+Samba</title>
+
+<para><screen>
+
+ # rpcclient -Uroot%xxxx -c 'enumprinters' localhost | grep -C2 mysmbtstprn
+
+ flags:[0x800000]
+ name:[\\kde-bitshop\mysmbtstprn]
+ description:[\\kde-bitshop\mysmbtstprn,,mysmbtstprn]
+ comment:[mysmbtstprn]
+
+</screen></para>
+
+<para>
+This should show the printer in the list. If not, stop and re-start
+the Samba daemon (smbd), or send a HUP signal: <command>kill -HUP
+`pidof smbd`</command>. 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
+<command>smbpasswd</command> 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 <filename>smb.conf</filename> for
+<parameter>[print$]</parameter>.
+</para>
+</sect3>
+
+<sect3>
+<title>Third Step (optional): Check if Samba knows a Driver for the
+Printer</title>
+
+<para><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
+
+</screen></para>
+
+<para>
+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".
+</para>
+</sect3>
+
+<sect3>
+<title>Fourth Step: Put all required Driver Files into Samba's
+<parameter>[print$]</parameter></title>
+
+<para><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'
+
+</screen></para>
+
+<para>
+(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 <emphasis>required</emphasis>
+for the next one to succeed. It makes the driver files physically
+present in the <parameter>[print$]</parameter> 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.
+</para>
+</sect3>
+
+<sect3>
+<title>Fifth Step: Verify where the Driver Files are now</title>
+
+<para><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
+
+</screen></para>
+
+<para>
+The driver files now are in the W32X86 architecture "root" of
+<parameter>[print$]</parameter>.
+</para>
+</sect3>
+
+<sect3>
+<title>Sixth Step: Tell Samba that these are
+<emphasis>Driver</emphasis> Files
+(<command>adddriver</command>)</title>
+
+<para><screen>
+
+# rpcclient -Uroot%xxxx -c `adddriver "Windows NT x86" "mydrivername: \
+ cupsdrvr.dll:mysmbtstprn.PPD: \
+ cupsui.dll:cups.hlp:NULL:RAW<citation>:</citation>NULL" \
+ localhost
+
+ Printer Driver mydrivername successfully installed.
+
+</screen></para>
+
+<para>
+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.
+</para>
+</sect3>
+
+<sect3>
+<title>Seventh Step: Verify where the Driver Files are now</title>
+
+<para><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
+
+</screen></para>
+
+<para>
+Notice how step 6 did also move the driver files to the appropriate
+subdirectory. Compare with the situation after step 5.
+</para>
+</sect3>
+
+<sect3>
+<title>Eighth Step (optional): Verify if Samba now recognizes the
+Driver</title>
+
+<para><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]
+
+</screen></para>
+
+<para>
+Remember, this command greps for the name you did choose for the
+driver in step Six. This command must succeed before you can proceed.
+</para>
+</sect3>
+
+<sect3>
+<title>Ninth Step: Tell Samba which Printer should use these Driver
+Files (<command>setdriver</command>)</title>
+
+<para><screen>
+
+# rpcclient -Uroot%xxxx -c 'setdriver mysmbtstprn mydrivername' localhost
+
+ Successfully set mysmbtstprn to driver mydrivername
+
+</screen></para>
+
+<para>
+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:
+<command>enumdrivers</command> must find the driver and
+<command>enumprinters</command> must find the printer.
+</para>
+</sect3>
+
+<sect3>
+<title>Tenth Step (optional): Verify if Samba has this Association
+recognized</title>
+
+<para><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]
+
+</screen></para>
+
+<para>
+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 <command>enumprinters</command> command now lists the driver
+on the "description" line.
+</para>
+</sect3>
+
+<sect3>
+<title>Eleventh Step (optional): Tickle the Driver into a correct
+Device Mode</title>
+
+<para>
+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".
+</para>
+
+<para>
+It is important that you execute this step as a Samba printer admin
+(as defined in <filename>smb.conf</filename>). 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):
+</para>
+
+<para><screen>
+
+ C:\> runas /netonly /user:root "rundll32 printui.dll,PrintUIEntry /in /n \\sambacupsserver\mysmbtstprn"
+
+</screen></para>
+
+<para>
+Change any printer setting once (like <emphasis>"portrait"
+--> "landscape"</emphasis>), click "Apply"; change the setting
+back.
+</para>
+</sect3>
+
+<sect3>
+<title>Twelveth Step: Install the Printer on a Client
+("Point'n'Print")</title>
+
+<para><screen>
+
+ C:\> rundll32 printui.dll,PrintUIEntry /in /n "\\sambacupsserver\mysmbtstprn"
+
+</screen></para>
+
+<para>
+If it doesn't work it could be a permission problem with the
+<parameter>[print$]</parameter> share.
+</para>
+</sect3>
+
+<sect3>
+<title>Thirteenth Step (optional): Print a Test Page</title>
+
+<para><screen>
+
+ C:\> rundll32 printui.dll,PrintUIEntry /p /n "\\sambacupsserver\mysmbtstprn"
+
+</screen></para>
+
+<para>
+Then hit [TAB] 5 times, [ENTER] twice, [TAB] once and [ENTER] again
+and march to the printer.
+</para>
+</sect3>
+
+<sect3>
+<title>Fourteenth Step (recommended): Study the Test Page</title>
+
+<para>
+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!
+</para>
+</sect3>
+
+<sect3>
+<title>Fifteenth Step (obligatory): Enjoy. Jump. Celebrate your
+Success</title>
+
+<para><screen>
+
+# echo "Cheeeeerioooooo! Success..." >> /var/log/samba/log.smbd
+
+</screen></para>
+</sect3>
+</sect2>
+
+<sect2>
+<title>Troubleshooting revisited</title>
+
+<para>
+The setdriver command will fail, if in Samba's mind the queue is not
+already there. You had promising messages about the:
+</para>
+
+<para><screen>
+
+ Printer Driver ABC successfully installed.
+
+</screen></para>
+
+<para>
+after the "adddriver" parts of the procedure? But you are also seeing
+a disappointing message like this one beneath?
+</para>
+
+<para><screen>
+
+ result was NT_STATUS_UNSUCCESSFUL
+
+</screen></para>
+
+<para>
+It is not good enough that <emphasis>you</emphasis>
+can see the queue <emphasis>in CUPS</emphasis>, using
+the <command>lpstat -p ir85wm</command> 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:
+</para>
+
+<para><screen>
+
+# rpcclient transmeta -N -U'root%secret' -c 'enumprinters 0'| grep ir85wm
+ printername:[ir85wm]
+
+</screen></para>
+
+<para>
+An alternative command could be this:
+</para>
+
+<para><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 für WinNT/2K/XP]
+
+</screen></para>
+
+<para>
+BTW, you can use these commands, plus a few more, of course,
+to install drivers on remote Windows NT print servers too!
+</para>
+</sect2>
+</sect1>
+
+<sect1>
+<title>The printing <filename>*.tdb</filename> Files</title>
+
+<para>
+Some mystery is associated with the series of files with a
+tdb-suffix appearing in every Samba installation. They are
+<filename>connections.tdb</filename>,
+<filename>printing.tdb</filename>,
+<filename>share_info.tdb</filename> ,
+<filename>ntdrivers.tdb</filename>,
+<filename>unexpected.tdb</filename>,
+<filename>brlock.tdb</filename> ,
+<filename>locking.tdb</filename>,
+<filename>ntforms.tdb</filename>,
+<filename>messages.tdb</filename> ,
+<filename>ntprinters.tdb</filename>,
+<filename>sessionid.tdb</filename> and
+<filename>secrets.tdb</filename>. What is their purpose?
+</para>
+
+<sect2>
+<title>Trivial DataBase Files</title>
+
+<para>
+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 <filename>*.tdb</filename> files. (TDB = Trivial Data
+Base). These are often located in <filename>/var/lib/samba/</filename>
+or <filename>/var/lock/samba/</filename> . The printing related files
+are <filename>ntprinters.tdb</filename>,
+<filename>printing.tdb</filename>,<filename>ntforms.tdb</filename> and
+<filename>ntdrivers.tdb</filename>.
+</para>
+</sect2>
+
+<sect2>
+<title>Binary Format</title>
+
+<para>
+<filename>*.tdb</filename> 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
+<command>smbd</command> process for each client connection, in some
+environments many thousand of them. Some of these smbds might need to
+write-access the same <filename>*.tdb</filename> file <emphasis>at the
+same time</emphasis>. The file format of Samba's
+<filename>*.tdb</filename> files allows for this provision. Many smbd
+processes may write to the same <filename>*.tdb</filename> file at the
+same time. This wouldn't be possible with pure ASCII files.
+</para>
+</sect2>
+
+<sect2>
+<title>Losing <filename>*.tdb</filename> Files</title>
+
+<para>
+It is very important that all <filename>*.tdb</filename> files remain
+consistent over all write and read accesses. However, it may happen
+that these files <emphasis>do</emphasis> get corrupted. (A
+<command>kill -9 `pidof smbd`</command> 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
+<filename>*.tdb</filename> 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 <filename>*.tdb</filename> files in time.
+</para>
+</sect2>
+
+<sect2>
+<title>Using <emphasis>tdbbackup</emphasis></title>
+
+<para>
+Samba ships with a little utility which helps the root user of your
+system to back up your <filename>*.tdb</filename> files. If you run it
+with no argument, it prints a little usage message:
+</para>
+
+<para><screen>
+
+# tdbbackup
+ Usage: tdbbackup [options] <fname...>
+
+ Version:3.0a
+ -h this help message
+ -s suffix set the backup suffix
+ -v veryify mode (restore if corrupt)
+
+</screen></para>
+
+<para>
+Here is how I backed up my printing.tdb file:
+</para>
+
+<para><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
+
+</screen></para>
+</sect2>
+</sect1>
+
+<sect1>
+<title>CUPS Print Drivers from Linuxprinting.org</title>
+
+<para>
+CUPS ships with good support for HP LaserJet type printers. You can
+install the generic driver as follows:
+</para>
+
+<para><screen>
+
+lpadmin -p laserjet4plus -v parallel:/dev/lp0 -E -m laserjet.ppd
+
+</screen></para>
+
+<para>
+The <parameter>-m</parameter> switch will retrieve the
+<filename>laserjet.ppd</filename> from the standard repository for
+not-yet-installed-PPDs, which CUPS typically stores in
+<filename>/usr/share/cups/model</filename>. Alternatively, you may use
+<parameter>-P /path/to/your.ppd</parameter>.
+</para>
+
+<para>
+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 <ulink
+url="http://www.linuxprinting.org/printer_list.cgi">http://www.linuxprinting.org/printer_list.cgi</ulink>.
+Linuxprinting.org has excellent recommendations about which driver is
+best used for each printer. Its database is kept current by the
+tireless work of Till Kamppeter from MandrakeSoft, who is also the
+principal author of the foomatic-rip utility.
+</para>
+
+<note><para>
+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:<ulink
+url="http://www.linuxprinting.org/driver_list.cgi">http://www.linuxprinting.org/driver_list.cgi</ulink>.
+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!
+</para></note>
+
+<sect2>
+<title>foomatic-rip and Foomatic explained</title>
+
+<para>
+Nowadays most Linux distros rely on the utilities of Linuxprinting.org
+to create their printing related software (which, BTW, works on all
+UNIXes and on Mac OS X or Darwin too). It is not known as well as it
+should be, that it also has a very end-user friendly interface which
+allows for an easy update of drivers and PPDs, for all supported
+models, all spoolers, all operatings systems and all package formats
+(because there is none). Its history goes back a few years.
+</para>
+
+<para>
+Recently Foomatic has achieved the astonishing milestone of <ulink
+url="http://www.linuxprinting.org/printer_list.cgi?make=Anyone">1000
+listed</ulink> printer models. Linuxprinting.org keeps all the
+important facts about printer drivers, supported models and which
+options are available for the various driver/printer combinations in
+its <ulink
+url="http://www.linuxprinting.org/foomatic.html">Foomatic</ulink>
+database. Currently there are <ulink
+url="http://www.linuxprinting.org/driver_list.cgi">245 drivers</ulink>
+in the database: many drivers support various models, and many models
+may be driven by different drivers; it's your choice!
+</para>
+
+<sect3>
+<title>690 "perfect" Printers</title>
+
+<para>
+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
+truely 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!
+</para>
+</sect3>
+
+<sect3>
+<title>How the "Printing HOWTO" started it all</title>
+
+<para>
+A few years ago <ulink
+url="http://www2.picante.com:81/~gtaylor/">Grant Taylor</ulink>
+started it all. The roots of today's Linuxprinting.org are in the
+first <ulink
+url="http://www.linuxprinting.org/foomatic2.9/howto/">Linux Printing
+HOWTO</ulink> 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" <emphasis>;-)</emphasis>, 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.
+</para>
+</sect3>
+
+<sect3>
+<title>Foomatic's strange Name</title>
+
+<para>
+"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
+<emphasis>controlling</emphasis> all printer options through
+standardized and well-defined "PPD files" (PostScript Printers
+Description files). Plus, CUPS was designed to be easily extensible.
+</para>
+
+<para>
+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":
+</para>
+
+<itemizedlist>
+<listitem><para>It made all current and future Ghostscript filter
+developments available for CUPS;</para></listitem>
+
+<listitem><para>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);</para></listitem>
+
+<listitem><para>It gave all the advanced CUPS options (web interface,
+GUI driver configurations) to users wanting (or needing) to use
+Ghostscript filters.</para></listitem>
+</itemizedlist>
+</sect3>
+
+<sect3>
+<title>cupsomatic, pdqomatic, lpdomatic, directomatic</title>
+
+<para>
+CUPS worked through a quickly-hacked up filter script named <ulink
+url="http://www.linuxprinting.org/download.cgi?filename=cupsomatic&show=0">cupsomatic</ulink>.
+cupsomatic ran the printfile through Ghostscript, constructing
+automatically the rather complicated command line needed. It just
+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 <ulink
+url="http://www.linuxprinting.org/download.cgi?filename=lpdomatic&show=0">PDQ-O-Matic</ulink>
+(for PDQ) and <ulink
+url="http://www.linuxprinting.org/download.cgi?filename=lpdomatic&show=0">LPD-O-Matic</ulink>
+(for - you guessed it - LPD); the configuration here didn't use PPDs
+but other spooler-specific files.
+</para>
+
+<para>
+From late summer of that year, <ulink
+url="http://www.linuxprinting.org/till/">Till Kamppeter</ulink>
+started to put work into the database. Till had been newly employed by
+<ulink url="http://www.mandrakesoft.com/">MandrakeSoft</ulink> to
+convert their printing system over to CUPS, after they had seen his
+<ulink url="http://www.fltk.org/">FLTK</ulink>-based <ulink
+url="http://cups.sourceforge.net/xpp/">XPP</ulink> (a GUI frontend to
+the CUPS lp-command). He added a huge amount of new information and new
+printers. He also developed the support for other spoolers, like
+<ulink url="http://ppr.sourceforge.net/">PPR</ulink> (via ppromatic),
+<ulink url="http://sourceforge.net/projects/lpr/">GNUlpr</ulink> and
+<ulink url="http://www.lprng.org/">LPRng</ulink> (both via an extended
+lpdomatic) and "spoolerless" printing (<ulink
+url="http://www.linuxprinting.org/download.cgi?filename=directomatic&show=0">directomatic</ulink>)....
+</para>
+
+<para>
+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..
+</para>
+</sect3>
+
+<sect3>
+<title>7.13.1.5.The <emphasis>Grand Unification</emphasis>
+achieved...</title>
+
+<para>
+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 <ulink
+url="http://www.linuxprinting.org/foomatic2.9/download.cgi?filename=foomatic-rip&show=0">foomatic-rip</ulink>.
+This single script is the unification of the previously different
+spooler-specific *omatic scripts. foomatic-rip is used by all the
+different spoolers alike. 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.
+</para>
+
+<para>
+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 <ulink
+url="http://www.linuxprinting.org/download/foomatic/foomatic-db-engine-3.0.0beta1.tar.gz">foomatic-db-engine</ulink>!
+Individual users just need to generate a single new PPD specific to
+their model by <ulink
+url="http://www.linuxprinting.org/kpfeifle/LinuxKongress2002/Tutorial/II.Foomatic-User/II.tutorial-handout-foomatic-user.html">following
+the steps</ulink> outlined in the Foomatic tutorial or further
+below. This new development is truly amazing.
+</para>
+
+<para>
+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).
+</para>
+</sect3>
+
+<sect3>
+<title>Driver Development outside</title>
+
+<para>
+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.
+</para>
+
+<para>
+Speaking of the different driver development groups: most of
+the work is currently done in three projects. These are:
+</para>
+
+<itemizedlist>
+<listitem><para><ulink
+url="http://www-124.ibm.com/developerworks/oss/linux/projects/omni/">Omni</ulink>
+-- 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.</para></listitem>
+
+<listitem><para><ulink url="http://hpinkjet.sf.net/">HPIJS</ulink> --
+a Free Software project by HP to provide the support for their own
+range of models (very mature, printing in most cases is perfect and
+provides true photo quality). This currently supports 369
+models.</para></listitem>
+
+<listitem><para><ulink
+url="http://gimp-print.sf.net/">Gimp-Print</ulink> -- a Free software
+effort, started by Michael Sweet (also lead developer for CUPS), now
+directed by Robert Krawitz, which has achieved an amazing level of
+photo print quality (many Epson users swear that its quality is
+better than the vendor drivers provided by Epson for the Microsoft
+platforms). This currently supports 522 models.</para></listitem>
+</itemizedlist>
+</sect3>
+
+<sect3>
+<title>Forums, Downloads, Tutorials, Howtos -- also for Mac OS X and
+commercial Unix</title>
+
+<para>
+Linuxprinting.org today is the one-stop "shop" to download printer
+drivers. Look for printer information and <ulink
+url="http://www.linuxprinting.org//kpfeifle/LinuxKongress2002/Tutorial/">tutorials</ulink>
+or solve printing problems in its popular <ulink
+url="http://www.linuxprinting.org/newsportal/">forums</ulink>. But
+it's not just for GNU/Linux: users and admins of <ulink
+url="http://www.linuxprinting.org/macosx/">commercial UNIX
+systems</ulink> are also going there, and the relatively new <ulink
+url="http://www.linuxprinting.org/newsportal/thread.php3?name=linuxprinting.macosx.general">Mac
+OS X forum</ulink> has turned out to be one of the most frequented
+fora after only a few weeks.
+</para>
+
+<para>
+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.
+</para>
+
+<note><para>
+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.
+</para></note>
+</sect3>
+
+<sect3>
+<title>Foomatic Database generated PPDs</title>
+
+<para>
+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
+<emphasis>cupsomatic</emphasis> filter script, while the new-style
+PPDs now call <emphasis>foomatic-rip</emphasis>). 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 <ulink
+url="http://printing.kde.org/overview/kprinter.phtml">"kprinter"</ulink>,
+or the GNOME <ulink
+url="http://gtklp.sourceforge.net/">"gtklp"</ulink>, "xpp" and the CUPS
+web interface) read the PPD too and use this information to present
+the available settings to the user as an intuitive menu selection.
+</para>
+</sect3>
+</sect2>
+
+<sect2>
+<title>foomatic-rip and Foomatic-PPD Download and Installation</title>
+
+<para>
+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):
+</para>
+<itemizedlist>
+<listitem><para>Surf to <ulink
+url="http://www.linuxprinting.org/printer_list.cgi">http://www.linuxprinting.org/printer_list.cgi</ulink>
+</para></listitem>
+
+<listitem><para>Check the complete list of printers in the database:
+<ulink
+url="http://www.linuxprinting.org/printer_list.cgi?make=Anyone">http://www.linuxprinting.org/printer_list.cgi?make=Anyone</ulink>
+</para></listitem>
+
+<listitem><para>There select your model and click on the
+link.</para></listitem>
+
+<listitem><para>You'll arrive at a page listing all drivers working
+with this model (for all printers, there will always be
+<emphasis>one</emphasis> recommended driver. Try this one
+first).</para></listitem>
+
+<listitem><para>In our case ("HP LaserJet 4 Plus"), we'll arrive here:
+<ulink
+url="http://www.linuxprinting.org/show_printer.cgi?recnum=HP-LaserJet_4_Plus">http://www.linuxprinting.org/show_printer.cgi?recnum=HP-LaserJet_4_Plus</ulink>
+</para></listitem>
+
+<listitem><para>The recommended driver is "ljet4".</para></listitem>
+
+<listitem><para>There are several links provided here. You should
+visit them all, if you are not familiar with the Linuxprinting.org
+database.</para></listitem>
+
+<listitem><para>There is a link to the database page for the "ljet4":
+<ulink
+url="http://www.linuxprinting.org/show_driver.cgi?driver=ljet4">http://www.linuxprinting.org/show_driver.cgi?driver=ljet4</ulink>
+On the driver's page, you'll find important and detailed information
+about how to use that driver within the various available
+spoolers.</para></listitem>
+
+<listitem><para>Another link may lead you to the homepage of the
+driver author or the driver.</para></listitem>
+
+<listitem><para>Important links are the ones which provide hints with
+setup instructions for CUPS (<ulink
+url="http://www.linuxprinting.org/cups-doc.html">http://www.linuxprinting.org/cups-doc.html</ulink>),
+PDQ (<ulink
+url="http://www.linuxprinting.org/pdq-doc.html">http://www.linuxprinting.org/pdq-doc.html</ulink>),
+LPD, LPRng and GNUlpr (<ulink
+url="http://www.linuxprinting.org/lpd-doc.html">http://www.linuxprinting.org/lpd-doc.html</ulink>)
+as well as PPR (<ulink
+url="http://www.linuxprinting.org/ppr-doc.html">http://www.linuxprinting.org/ppr-doc.html)</ulink>
+or "spooler-less" printing (<ulink
+url="http://www.linuxprinting.org/direct-doc.html">http://www.linuxprinting.org/direct-doc.html</ulink>
+).</para></listitem>
+
+<listitem><para>You can view the PPD in your browser through this
+link: <ulink
+url="http://www.linuxprinting.org/ppd-o-matic.cgi?driver=ljet4&printer=HP-LaserJet_4_Plus&show=1">http://www.linuxprinting.org/ppd-o-matic.cgi?driver=ljet4&printer=HP-LaserJet_4_Plus&show=1</ulink>
+</para></listitem> <listitem><para>You can also (most importantly)
+generate and download the PPD: <ulink
+url="http://www.linuxprinting.org/ppd-o-matic.cgi?driver=ljet4&printer=HP-LaserJet_4_Plus&show=0">http://www.linuxprinting.org/ppd-o-matic.cgi?driver=ljet4&printer=HP-LaserJet_4_Plus&show=0</ulink>
+</para></listitem>
+
+<listitem><para>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.</para></listitem>
+
+<listitem><para>Should you have ended up on the driver's page (<ulink
+url="http://www.linuxprinting.org/show_driver.cgi?driver=ljet4">http://www.linuxprinting.org/show_driver.cgi?driver=ljet4</ulink>),
+you can choose to use the "PPD-O-Matic" online PPD generator
+program.</para></listitem>
+
+<listitem><para>Select the exact model and check either "download" or
+"display PPD file" and click on "Generate PPD file".</para></listitem>
+
+<listitem><para>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).</para></listitem>
+
+<listitem><para>Another very interesting part on each driver page is
+the <emphasis>Show execution details</emphasis> 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. ;-)</para></listitem>
+
+<listitem><para>Some time during your visit to Linuxprinting.org, save
+the PPD to a suitable place on your harddisk, say
+<filename>/path/to/my-printer.ppd</filename> (if you prefer to install
+your printers with the help of the CUPS web interface, save the PPD to
+the <filename>/usr/share/cups/model/</filename> path and re-start
+cupsd).</para></listitem>
+
+<listitem><para>Then install the printer with a suitable commandline,
+e.g.:
+</para>
+
+<para><screen>
+
+lpadmin -p laserjet4plus -v parallel:/dev/lp0 -E -P path/to/my-printer.ppd
+
+</screen></para></listitem>
+
+<listitem><para>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: <ulink
+url="http://www.linuxprinting.org/foomatic2.9/download.cgi?filename=foomatic-rip&show=0">http://www.linuxprinting.org/foomatic2.9/download.cgi?filename=foomatic-rip&show=0</ulink>
+</para></listitem>
+
+<listitem><para>The foomatic-rip Perlscript itself also makes some
+interesting reading (<ulink
+url="http://www.linuxprinting.org/foomatic2.9/download.cgi?filename=foomatic-rip&show=1">http://www.linuxprinting.org/foomatic2.9/download.cgi?filename=foomatic-rip&show=1</ulink>),
+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... ;-)</para></listitem>
+
+<listitem><para>Save foomatic-rip either directly in
+<filename>/usr/lib/cups/filter/foomatic-rip</filename> 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.</para></listitem>
+
+<listitem><para>If you save foomatic-rip in your $PATH, create a symlink:
+<command>cd /usr/lib/cups/filter/ ; ln -s `which
+foomatic-rip`</command>. For CUPS to discover this new
+available filter at startup, you need to re-start
+cupsd.</para></listitem>
+</itemizedlist>
+
+<para>
+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.
+</para>
+
+<highlights><para>
+You need:
+</para>
+
+<itemizedlist>
+
+<listitem><para>A "foomatic+something" PPD -- but it this not enough
+to print with CUPS (it is only <emphasis>one</emphasis> important
+component)</para></listitem>
+
+<listitem><para>The "foomatic-rip" filter script (Perl) in
+/usr/lib/cups/filters/</para></listitem>
+
+<listitem><para>Perl to make foomatic-rip run</para></listitem>
+
+<listitem><para>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</para></listitem>
+
+<listitem><para>Ghostscript <emphasis>must</emphasis> (depending on
+the driver/model) contain support for a certain "device", representing
+the selected "driver" for your model (as shown by "gs
+-h")</para></listitem>
+
+<listitem><para>foomatic-rip needs a new version of PPDs (PPD versions
+produced for cupsomatic don't work with
+foomatic-rip).</para></listitem>
+</itemizedlist>
+</highlights>
+</sect2>
+</sect1>
+
+<sect1>
+<title>Page Accounting with CUPS</title>
+
+<para>
+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 <emphasis>or</emphasis> unfiltered) and hand it over to this
+printing subsystem.
+</para>
+
+<para>
+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.
+</para>
+
+<sect2>
+<title>Setting up Quotas</title>
+
+<para>
+This is an example command how root would set a print quota in CUPS,
+assuming an existing printer named "quotaprinter":
+</para>
+
+<para><screen>
+
+ lpadmin -p quotaprinter -o job-quota-period=604800 -o job-k-limit=1024 -o job-page-limit=100
+
+</screen></para>
+
+<para>
+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).
+</para>
+</sect2>
+
+<sect2>
+<title>Correct and incorrect Accounting</title>
+
+<para>
+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!
+</para>
+
+<para>
+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 <ulink
+url="http://www.linuxprinting.org/printer_list.cgi">http://www.linuxprinting.org/printer_list.cgi</ulink>).
+</para>
+</sect2>
+
+<sect2>
+<title>Adobe and CUPS PostScript Drivers for Windows Clients</title>
+
+<para>
+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).
+</para>
+
+<para>
+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
+<emphasis>not</emphasis> work for Win9x/ME clients. But it guarantees:
+</para>
+
+<itemizedlist>
+
+<listitem><para>to not write an PJL-header</para></listitem>
+
+<listitem><para>to still read and support all PJL-options named in the
+driver PPD with its own means</para></listitem>
+
+<listitem><para> that the file will pass through the "pstops" filter
+on the CUPS/Samba server</para></listitem>
+
+<listitem><para>to page-count correctly the
+printfile</para></listitem>
+</itemizedlist>
+
+<para>
+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).
+</para>
+</sect2>
+
+<sect2>
+<title>The page_log File Syntax</title>
+
+<para>
+These are the items CUPS logs in the "page_log" for every
+single <emphasis>page</emphasis> of a job:
+</para>
+
+<itemizedlist>
+<listitem><para>Printer name</para></listitem>
+
+<listitem><para>User name</para></listitem>
+
+<listitem><para>Job ID</para></listitem>
+
+<listitem><para>Time of printing</para></listitem>
+
+<listitem><para>the page number</para></listitem>
+
+<listitem><para>the number of copies</para></listitem>
+
+<listitem><para>a billing information string
+(optional)</para></listitem>
+
+<listitem><para>the host which sent the job (included since version
+1.1.19)</para></listitem>
+</itemizedlist>
+
+<para>
+Here is an extract of my CUPS server's page_log file to illustrate the
+format and included items:
+</para>
+
+<para><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
+
+</screen></para>
+
+<para>
+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".
+</para>
+</sect2>
+
+<sect2>
+<title>Possible Shortcomings</title>
+
+<para>
+What flaws or shortcomings are there with this quota system?
+</para>
+
+<itemizedlist>
+<listitem><para>the ones named above (wrongly logged job in case of
+printer hardware failure, etc.)</para></listitem>
+
+<listitem><para>in reality, CUPS counts the job pages that are being
+processed in <emphasis>software</emphasis> (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</para></listitem>
+
+<listitem><para>all quotas are the same for all users (no flexibility
+to give the boss a higher quota than the clerk) no support for
+groups</para></listitem>
+
+<listitem><para>no means to read out the current balance or the
+"used-up" number of current quota</para></listitem>
+
+<listitem><para>a user having used up 99 sheets of 100 quota will
+still be able to send and print a 1,000 sheet job</para></listitem>
+
+<listitem><para>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".</para></listitem>
+</itemizedlist>
+</sect2>
+
+<sect2>
+<title>Future Developments</title>
+
+<para>
+This is the best system currently available, and there are huge
+improvements under development for CUPS 1.2:
+</para>
+
+<itemizedlist>
+<listitem><para>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)</para></listitem>
+
+<listitem><para>quotas will be handled more flexibly</para></listitem>
+
+<listitem><para>probably there will be support for users to inquire
+their "accounts" in advance</para></listitem>
+
+<listitem><para>probably there will be support for some other tools
+around this topic</para></listitem>
+</itemizedlist>
+</sect2>
+
+<sect2>
+<title>Other Accounting Tools</title>
+
+<para>
+PrintAnalyzer, pyKota, printbill, LogReport.
+</para>
+</sect2>
+</sect1>
+
+<sect1>
+<title>Additional Material</title>
+
+<para>
+A printer queue with <emphasis>no</emphasis> 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: <filename>lpd://, socket://,
+smb://, ipp://, http://, parallel:/, serial:/, usb:/</filename> etc.)
+</para>
+
+<para>
+"cupsomatic"/Foomatic are <emphasis>not</emphasis> 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:
+</para>
+
+<para><screen>
+
+ *cupsFilter: "application/vnd.cups-postscript 0 cupsomatic"
+
+</screen></para>
+
+<para>
+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
+<filename>/etc/cups/mime.types</filename> in place.
+</para>
+
+<para>
+CUPS is widely configurable and flexible, even regarding its filtering
+mechanism. Another workaround in some situations would be to have in
+<filename>/etc/cups/mime.types</filename> entries as follows:
+</para>
+
+<para><screen>
+
+ application/postscript application/vnd.cups-raw 0 -
+ application/vnd.cups-postscript application/vnd.cups-raw 0 -
+
+</screen></para>
+
+<para>
+This would prevent all Postscript files from being filtered (rather,
+they will through the virtual <emphasis>nullfilter</emphasis>
+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:
+</para>
+
+<para><screen>
+
+ */* application/vnd.cups-raw 0 -
+
+</screen></para>
+
+<para>
+and would effectively send <emphasis>all</emphasis> files to the
+backend without further processing.
+</para>
+
+<para>
+Lastly, you could have the following entry:
+</para>
+
+<para><screen>
+
+ application/vnd.cups-postscript application/vnd.cups-raw 0 my_PJL_stripping_filter
+
+</screen></para>
+
+<para>
+You will need to write a <emphasis>my_PJL_stripping_filter</emphasis>
+(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
+<filename>/usr/lib/cups/filters/</filename> and will be called by CUPS
+if it encounters a MIME type "application/vnd.cups-postscript".
+</para>
+
+<para>
+CUPS can handle <emphasis>-o job-hold-until=indefinite</emphasis>.
+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.).
+</para>
+</sect1>
+
+<sect1>
+<title>Auto-Deletion or Preservation of CUPS Spool Files</title>
+
+<para>
+Samba print files pass through two "spool" directories. One is the
+incoming directory managed by Samba, (set in the <emphasis>path =
+/var/spool/samba</emphasis> directive in the
+<emphasis>[printers]</emphasis> section of
+<filename>smb.conf</filename>). The other is the spool directory of
+your UNIX print subsystem. For CUPS it is normally
+<filename>/var/spool/cups/</filename>, as set by the cupsd.conf
+directive <filename>RequestRoot /var/spool/cups</filename>.
+</para>
+
+<sect2>
+<title>CUPS Configuration Settings explained</title>
+
+<para>
+Some important parameter settings in the CUPS configuration file
+<filename>cupsd.conf</filename> are:
+</para>
+
+<variablelist>
+
+<varlistentry><term>PreserveJobHistory Yes</term>
+<listitem><para>
+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.
+</para></listitem></varlistentry>
+
+<varlistentry><term>PreserveJobFiles Yes</term>
+<listitem><para>
+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.
+</para></listitem></varlistentry>
+
+<varlistentry><term><emphasis>"MaxJobs 500"</emphasis></term>
+<listitem><para>
+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.
+</para></listitem></varlistentry>
+</variablelist>
+
+<para>
+(There are also additional settings for "MaxJobsPerUser" and
+"MaxJobsPerPrinter"...)
+</para>
+</sect2>
+
+<sect2>
+<title>Pre-conditions</title>
+
+<para>
+For everything to work as announced, you need to have three
+things:
+</para>
+
+<itemizedlist>
+<listitem><para>a Samba-smbd which is compiled against "libcups" (Check
+on Linux by running "ldd `which smbd`")</para></listitem>
+
+<listitem><para>a Samba-<filename>smb.conf</filename> setting of
+"printing = cups"</para></listitem>
+
+<listitem><para>another Samba-<filename>smb.conf</filename> setting of
+"printcap = cups"</para></listitem>
+</itemizedlist>
+
+<note><para>
+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.
+</para></note>
+</sect2>
+
+<sect2>
+<title>Manual Configuration</title>
+
+<para>
+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.
+</para>
+</sect2>
+</sect1>
+
+<sect1>
+<title>When <emphasis>not</emphasis> to use Samba to print to
+CUPS</title>
+
+<para>
+[TO BE DONE]
+</para>
+</sect1>
+
+<sect1>
+<title>In Case of Trouble.....</title>
+
+<para>
+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):
+</para>
+
+<para><screen>
+
+ grep -v ^# /etc/cups/cupsd.conf | grep -v ^$
+ grep -v ^# /etc/samba/smb.conf | grep -v ^$ | grep -v "^;"
+
+</screen></para>
+
+<para>
+(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?
+;-)
+</para>
+
+<sect2>
+<title>Where to find Documentation</title>
+
+<para>
+[TO BE DONE]
+</para>
+</sect2>
+
+<sect2>
+<title>How to ask for Help</title>
+
+<para>
+[TO BE DONE]
+</para>
+</sect2>
+
+<sect2>
+<title>Where to find Help</title>
+
+<para>
+[TO BE DONE]
+</para>
+</sect2>
+</sect1>
+
+<sect1>
+<title>Appendix</title>
+
+<sect2>
+<title>Printing <emphasis>from</emphasis> CUPS to Windows attached
+Printers</title>
+
+<para>
+From time to time the question arises, how you can print
+<emphasis>to</emphasis> a Windows attached printer
+<emphasis>from</emphasis> 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
+<emphasis>backends</emphasis> to talk to printers and other
+servers. To talk to Windows shared printers you need to use the
+<emphasis>smb</emphasis> (surprise, surprise!) backend. Check if this
+is in the CUPS backend directory. This resides usually in
+<filename>/usr/lib/cups/backend/</filename>. You need to find a "smb"
+file there. It should be a symlink to <filename>smbspool</filename>
+which file must exist and be executable:
+</para>
+
+<para><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
+
+</screen></para>
+
+<para>
+If this symlink doesn't exist, create it:
+</para>
+
+<para><screen>
+
+# ln -s `which smbspool` /usr/lib/cups/backend/smb
+
+</screen></para>
+
+<para>
+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.
+</para>
+
+<para>
+To install a printer with the smb backend on CUPS, use this command:
+</para>
+
+<para><screen>
+
+# lpadmin -p winprinter -v smb://WINDOWSNETBIOSNAME/printersharename -P /path/to/PPD
+
+</screen></para>
+
+<para>
+The <emphasis>PPD</emphasis> 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
+<filename>smb://</filename> device-URI. Like this:
+</para>
+
+<para><screen>
+
+ smb://WORKGROUP/WINDOWSNETBIOSNAME/printersharename
+ smb://username:password@WORKGROUP/WINDOWSNETBIOSNAME/printersharename
+ smb://username:password@WINDOWSNETBIOSNAME/printersharename
+
+</screen></para>
+
+<para>
+Note that the device-URI will be visible in the process list of the
+Samba server (e.g. when someone uses the <command>ps -aux</command>
+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? :-).
+</para>
+</sect2>
+
+<sect2>
+<title>More CUPS filtering Chains</title>
+
+<para>
+The following diagrams reveal how CUPS handles print jobs.
+</para>
+
+<screen>
+#########################################################################
#
-# This is how "cupsomatic" comes into play:
-# =========================================
+# 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):
#
-# <replaceable>SOMETHNG</replaceable>-FILEFORMAT
+# SOMETHNG-FILEFORMAT
# |
+# V
+# somethingtops
+# |
+# V
+# APPLICATION/POSTSCRIPT
# |
# V
-# <replaceable>something</replaceable>tops
+# pstops
# |
+# V
+# APPLICATION/VND.CUPS-POSTSCRIPT
# |
# V
-# APPLICATION/POSTSCRIPT
+# 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
-# pstops
+# 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.
+#
+#########################################################################
+</screen>
+
+<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=<replaceable>s.th.</replaceable>"
+# APPLICATION/VND.CUPS-RASTER "-sDEVICE=s.th."
# | call...)
-# | |
# V |
-# rasterto<replaceable>something</replaceable> V
+# rastertosomething V
# | (= "raster driver") +-------------------------+
# | | Ghostscript at work.... |
# V | |
# SOMETHING-DEVICE-SPECIFIC *-------------------------+
# | |
-# | |
# V |
-# backend >------------------------------------+
-# |
+# backend <------------------------------------+
# |
# V
# THE PRINTER
#
#
# Note, that cupsomatic "kidnaps" the printfile after the
-# "APPLICATION/VND.CUPS-POSTSCRPT" stage and deviates it through
+# "APPLICATION/VND.CUPS-POSTSCRPT" stage and deviates it gh
# the CUPS-external, systemwide Ghostscript installation, bypassing the
-# "pstoraster" filter (therefor also bypassing the CUPS-raster-drivers
-# "rasterto<replaceable>something</replaceable>", and hands the rasterized file directly to the CUPS
+# "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
# 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 rasterto<replaceable>something</replaceable> is noted.
+# CUPS and ESP PrintPro plug-in where rastertosomething is noted.
#
#########################################################################
-</programlisting>
+</screen>
-<programlisting>
+<screen>
#########################################################################
#
# And this is how it works for ESP PrintPro from 4.3:
# ===================================================
#
-# <replaceable>SOMETHNG</replaceable>-FILEFORMAT
-# |
+# SOMETHNG-FILEFORMAT
# |
# V
-# <replaceable>something</replaceable>tops
-# |
+# somethingtops
# |
# V
# APPLICATION/POSTSCRIPT
# |
-# |
# V
# pstops
# |
-# |
# V
# APPLICATION/VND.CUPS-POSTSCRIPT
# |
-# |
# V
# gsrip
# | (= "postscipt interpreter")
-# |
# V
# APPLICATION/VND.CUPS-RASTER
# |
-# |
# V
-# rasterto<replaceable>something</replaceable> (f.e. Gimp-Print filters may be plugged in here)
+# 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 rasterto<replaceable>something</replaceable> is noted.
+# CUPS and ESP PrintPro plug-in where rastertosomething is noted.
#
#########################################################################
-</programlisting>
+</screen>
-<programlisting>
+<screen>
#########################################################################
#
# This is how "cupsomatic" would come into play with ESP PrintPro:
# ================================================================
#
#
-# <replaceable>SOMETHNG</replaceable>-FILEFORMAT
-# |
+# SOMETHNG-FILEFORMAT
# |
# V
-# <replaceable>something</replaceable>tops
-# |
+# 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=<replaceable>s.th.</replaceable>"
+# APPLICATION/VND.CUPS-RASTER "-sDEVICE=s.th."
# | call...)
-# | |
# V |
-# rasterto<replaceable>something</replaceable> V
+# rastertosomething V
# | (= "raster driver") +-------------------------+
# | | Ghostscript at work.... |
# V | |
# SOMETHING-DEVICE-SPECIFIC *-------------------------+
# | |
-# | |
# V |
-# backend >------------------------------------+
-# |
+# backend <------------------------------------+
# |
# V
# THE PRINTER
#
# NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
-# CUPS and ESP PrintPro plug-in where rasterto<replaceable>something</replaceable> is noted.
+# CUPS and ESP PrintPro plug-in where rastertosomething is noted.
#
#########################################################################
-</programlisting>
+</screen>
-<programlisting>
+<screen>
#########################################################################
#
# And this is how it works for CUPS from 1.1.15:
# ==============================================
#
-# <replaceable>SOMETHNG</replaceable>-FILEFORMAT
-# |
+# SOMETHNG-FILEFORMAT
# |
# V
-# <replaceable>something</replaceable>tops
-# |
+# somethingtops
# |
# V
# APPLICATION/POSTSCRIPT
# |
-# |
# V
# pstops
# |
-# |
# V
# APPLICATION/VND.CUPS-POSTSCRIPT-----+
-# |
# +------------------v------------------------------+
# | Ghostscript |
# | at work... |
# | |
# +------------------v------------------------------+
# |
-# |
# APPLICATION/VND.CUPS-RASTER >-------+
# |
-# |
# V
-# rasterto<replaceable>something</replaceable>
+# rastertosomething
# | (= "raster driver")
-# |
# V
# SOMETHING-DEVICE-SPECIFIC
# |
-# |
# V
# backend
#
# "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 "rasterto<replaceable>something</replaceable>"
-# Note the difference to "cupsomatic", which will *not* output
+# be finally processed by a CUPS raster driver "rastertosomething"
+# Note the difference to "cupsomatic", which will <emphasis>not</emphasis> 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 rasterto<replaceable>something</replaceable> is noted.
+# CUPS and ESP PrintPro plug-in where rastertosomething is noted.
#
#########################################################################
-</programlisting>
+</screen>
-<programlisting>
+<screen>
#########################################################################
#
# And this is how it works for CUPS from 1.1.15, with cupsomatic included:
# ========================================================================
#
-# <replaceable>SOMETHNG</replaceable>-FILEFORMAT
-# |
+# SOMETHNG-FILEFORMAT
# |
# V
-# <replaceable>something</replaceable>tops
-# |
+# somethingtops
# |
# V
# APPLICATION/POSTSCRIPT
# |
-# |
# V
# pstops
# |
-# |
# V
# APPLICATION/VND.CUPS-POSTSCRIPT-----+
-# |
# +------------------v------------------------------+
# | Ghostscript . Ghostscript at work.... |
# | at work... . (with "-sDEVICE= |
-# | (with . <replaceable>s.th.</replaceable>" |
+# | (with . s.th." |
# | "-sDEVICE=cups") . |
# | . |
# | (CUPS standard) . (cupsomatic) |
# | . |
# +------------------v--------------v---------------+
# | |
-# | |
# APPLICATION/VND.CUPS-RASTER >-------+ |
# | |
-# | |
# V |
-# rasterto<replaceable>something</replaceable> |
+# 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 rasterto<replaceable>something</replaceable> is noted.
+# CUPS and ESP PrintPro plug-in where rastertosomething is noted.
#
##########################################################################
-</programlisting>
-
-</sect1>
-
-
-<sect1>
-<title>CUPS Print Drivers and Devices</title>
-
-<para>
-CUPS ships with good support for HP LaserJet type printers. You can install
-the driver as follows:
-
-<itemizedlist>
- <listitem><para>
- lpadmin -p laserjet4plus -v parallel:/dev/lp0 -E -m laserjet.ppd
- </para></listitem>
-</itemizedlist>
-
-(The "-m" switch will retrieve the "laserjet.ppd" from the standard repository
-for not-yet-installed-PPDs, which CUPS typically stores in
-<filename>/usr/share/cups/model</filename>. Alternatively, you may use
-"-P /absolute/filesystem/path/to/where/there/is/PPD/your.ppd").
-</para>
+</screen>
+</sect2>
<sect2>
-<title>Further printing steps</title>
-
-<para>
-Always also consult the database on linuxprinting.org for all recommendations
-about which driver is best used for each printer:
-</para>
-
-<para><ulink url="http://www.linuxprinting.org/printer_list.cgi">http://www.linuxprinting.org/printer_list.cgi</ulink></para>
-
-<para>
-There select your model and click on "Show". You'll arrive at a page listing
-all drivers working with your model. There will always be *one*
-<emphasis>recommended</emphasis> one. Try this one first. In your case
-("HP LaserJet 4 Plus"), you'll arrive here:
-</para>
-
-<para><ulink url="http://www.linuxprinting.org/show_printer.cgi?recnum=75104">http://www.linuxprinting.org/show_printer.cgi?recnum=75104</ulink></para>
-
-<para>
-The recommended driver is "ljet4". It has a link to the page for the ljet4
-driver too:
-</para>
-
-<para><ulink url="http://www.linuxprinting.org/show_driver.cgi?driver=ljet4">http://www.linuxprinting.org/show_driver.cgi?driver=ljet4</ulink></para>
-
-<para>
-On the driver's page, you'll find important and detailed info about how to use
-that driver within the various available spoolers. You can generate a PPD for
-CUPS. The PPD contains all the info about how to use your model and the driver;
-this is, once installed, working transparently for the user -- 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...
-</para>
-
-<para>
-On the driver's page, choose to use the "PPD-O-Matic" online PPD generator
-program. Select your model and click "Generate PPD file". When you safe the
-appearing ASCII text file, don't use "cut'n'past" (as it could possiblly corrupt
-line endings and tabs), but use "Save as..." in your browser's menu. Save it
-at "/some/path/on/your/filesystem/somewhere/my-name-for-my-printer.ppd"
-</para>
-
-<para>
-Then install the printer:
-</para>
-<para><programlisting>
- "lpadmin -p laserjet4plus -v parallel:/dev/lp0 -E \
- -P /some/path/on/your/filesystem/somewhere/my-name-for-my-printer.ppd"
-</programlisting></para>
+<title>Trouble Shooting Guidelines to fix typical Samba printing
+Problems</title>
<para>
-Note, that for all the "Foomatic-PPDs" from Linuxprinting.org, you also need
-a special "CUPS filter" named "cupsomatic". Get the latest version of
-"cupsomatic" from:
+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.
</para>
-<para><ulink url="http://www.linuxprinting.org/cupsomatic">http://www.linuxprinting.org/cupsomatic</ulink></para>
-
-<para>
-This needs to be copied to <filename>/usr/lib/cups/filter/cupsomatic</filename>
-and be made world executable. This filter is needed to read and act upon the
-specially encoded Foomatic comments, embedded in the printfile, which in turn
-are used to construct (transparently for you, the user) the complicated
-ghostscript command line needed for your printer/driver combo.
+<variablelist>
+<varlistentry><term>Win9x client can't install driver</term>
+<listitem><para>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.</para></listitem></varlistentry>
+
+<varlistentry><term>testparm</term>
+<listitem><para>Run <command>testparm</command>: It will tell you if
+<filename>smb.conf</filename> parameters are in the wrong
+section. Many people have had the "printer admin" parameter in the
+<parameter>[printers]</parameter> section and experienced
+problems. "testparm" will tell you if it sees
+this.</para></listitem></varlistentry>
+
+<varlistentry><term>"cupsaddsmb" keeps asking for a root password in a
+neverending loop</term>
+<listitem><para>Have you <parameter>security = user</parameter>? Have
+you used <command>smbpasswd</command> to give root a Samba account?
+You can do 2 things: open another terminal and execute
+<command>smbpasswd -a root</command> 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).</para></listitem></varlistentry>
+
+<varlistentry><term>"cupsaddsmb" gives "No PPD file for printer..."
+message (but I swear there is one!)</term>
+
+<listitem>
+<itemizedlist>
+<listitem><para>Have you enabled printer sharing on CUPS? This means:
+do you have a <parameter><Location
+/printers>....</Location></parameter> section in CUPS
+server's <filename>cupsd.conf</filename> which doesn't deny access to
+the host you run "cupsaddsmb" from? It <emphasis>could</emphasis> be
+an issue if you use cupsaddsmb remotely, or if you use it with a
+<parameter>-h</parameter> parameter: <command>cupsaddsmb -H
+sambaserver -h cupsserver -v printername</command>.
+</para></listitem>
+<listitem><para>Is your
+"TempDir" directive in
+<emphasis>cupsd.conf</emphasis>
+set to a valid value and is it writeable?
+</para></listitem></itemizedlist>
+</listitem></varlistentry>
+
+<varlistentry><term>I can't connect client to Samba printer.</term>
+<listitem><para>Use <command>smbstatus</command> to check which user
+you are from Samba's point of view. Do you have the privileges to
+write into the <parameter>[print$]</parameter>
+share?</para></listitem></varlistentry>
+
+<varlistentry><term>I can't reconnect to Samba under a new account
+from Win2K/XP</term>
+<listitem><para>Once you are connected as the "wrong" user (for
+example as "nobody", which often occurs if you have <parameter>map to
+guest = bad user</parameter>), 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
+<command>smbstatus</command> to check for active connections. Kill the
+PIDs. You still can't re-connect and get the dreaded
+<computeroutput>You can't connect with a second account from the same
+machine</computeroutput> 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 <emphasis>first</emphasis>
+do <command>net use z: \\SAMBAHOST\print$ /user:root</command>. Check
+with <command>smbstatus</command> that you are connected under a
+different account. Now open the "Printers" folder (on the Samba server
+in the <emphasis>Network Neighbourhood</emphasis>), right-click the
+printer in question and select
+<emphasis>Connect...</emphasis></para></listitem></varlistentry>
+
+<varlistentry><term>Avoid being connected to the Samba server as the
+"wrong" user</term>
+<listitem><para>You see per <command>smbstatus</command> that you are
+connected as user "nobody"; while you wanted to be "root" or
+"printeradmin"? This is probably due to <parameter>map to guest = bad
+user</parameter>, which silently connects you under the guest account,
+when you gave (maybe by accident) an incorrect username. Remove
+<parameter>map to guest</parameter>, if you want to prevent
+this.</para></listitem></varlistentry>
+
+<varlistentry><term>Upgrading to CUPS drivers from Adobe drivers on
+NT/2K/XP clients gives problems</term>
+<listitem><para>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).</para></listitem></varlistentry>
+
+<varlistentry><term>I can't use "cupsaddsmb"on a Samba server which is
+a PDC</term>
+<listitem><para>Do you use the "naked" root user name? Try to do it
+this way: <emphasis>cupsaddsmb -U DOMAINNAME\\root -v
+printername</emphasis> (note the two backslashes: the first one is
+required to "escape" the second one).</para></listitem></varlistentry>
+
+<varlistentry><term>I deleted a printer on Win2K; but I still see
+its driver</term>
+<listitem><para>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.</para></listitem></varlistentry>
+
+<varlistentry><term>Win2K/XP "Local Security
+Policies"</term>
+<listitem><para><emphasis>Local Security Policies</emphasis> may not
+allow the installation of unsigned drivers. "Local Security Policies"
+may not allow the installation of printer drivers at
+all.</para></listitem></varlistentry>
+
+<varlistentry><term>WinXP clients: "Administrator can not install
+printers for all local users"</term>
+<listitem><para>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
+<emphasis>http://cupsserver:631/printers/printername</emphasis>.
+Still looking into this one: maybe a "logon script" could
+automatically install printers for all
+users.</para></listitem></varlistentry>
+
+<varlistentry><term>"Print Change Notify" functions on
+NT-clients</term>
+<listitem><para>For "print change notify" functions on NT++ clients,
+these need to run the "Server" service first (re-named to
+<emphasis>File & Print Sharing for MS Networks</emphasis> in
+XP).</para></listitem></varlistentry>
+
+<varlistentry><term>WinXP-SP1</term>
+<listitem><para>WinXP-SP1 introduced a <emphasis>Point and Print
+Restriction Policy</emphasis> (this restriction doesn't apply to
+"Administrator" or "Power User" groups of users). In Group Policy
+Object Editor: go to <emphasis>User Configuration -->
+Administrative Templates --> Control Panel -->
+Printers</emphasis>. The policy is automatically set to
+<emphasis>Enabled</emphasis> and the <emphasis>Users can only Point
+and Print to machines in their Forest</emphasis> . You probably need
+to change it to <emphasis>Disabled</emphasis> or <emphasis>Users can
+only Point and Print to these servers</emphasis> in order to make
+driver downloads from Samba possible.</para></listitem></varlistentry>
+
+<varlistentry><term>I can't set and save default print options for all
+users on Win2K/XP</term>
+
+<listitem><para>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 <emphasis>seems</emphasis> to set everything. All
+three dialogs <emphasis>look</emphasis> the same. Only one of them
+<emphasis>does</emphasis> 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:
</para>
-<para>
-You can have a look at all the options for the Ghostscript commandline supported
-by your printer and the ljet4 driver by going to the section "Execution details",
-selecting your model (Laserjet 4 Plus) and clicking on "Show execution details".
-This will bring up this web page:
-</para>
+<orderedlist numeration="upperalpha">
-<para><ulink url="http://www.linuxprinting.org/execution.cgi?driver=ljet4;printer=75104;.submit=Show+execution+details">http://www.linuxprinting.org/execution.cgi?driver=ljet4;printer=75104;.submit=Show+execution+details</ulink></para>
+<listitem><para>The first "wrong" way:
-<para>
-The ingenious thing is that the database is kept current. If there
-is a bug fix and an improvement somewhere in the database, you will
-always get the most current and stable and feature-rich driver by following
-the steps described above.
-</para>
+<orderedlist numeration="arabic">
+<listitem><para>Open the <emphasis>Printers</emphasis>
+folder.</para></listitem>
-<note><para>
-Till Kamppeter from MandrakeSoft is doing an excellent job here that too few
-people are aware of. (So if you use it often, please send him a note showing
-your appreciation).</para></note>
+<listitem><para>Right-click on the printer
+(<emphasis>remoteprinter on cupshost</emphasis>) and
+select in context menu <emphasis>Printing
+Preferences...</emphasis></para></listitem>
-<para>
-The latest and greatest improvement now is support for "custom page sizes"
-for all those printers which support it.
+<listitem><para>Look at this dialog closely and remember what it looks
+like.</para></listitem>
+</orderedlist>
</para>
+</listitem>
-<para>
-"cupsomatic" is documented here:
-</para>
+<listitem><para>The second "wrong" way:
-<para><ulink url="http://www.linuxprinting.org/cups-doc.html">http://www.linuxprinting.org/cups-doc.html</ulink></para>
+<orderedlist numeration="arabic">
+<listitem><para>Open the <emphasis>Printers</emphasis>
+folder.</para></listitem>
-<para>
-More printing tutorial info may be found here:
-</para>
+<listitem><para>Right-click on the printer (<emphasis>remoteprinter on
+cupshost</emphasis>) and select in the context menu
+<emphasis>Properties</emphasis></para></listitem>
-<para><ulink url="http://www.linuxprinting.org/kpfeifle/LinuxKongress2002/Tutorial/">http://www.linuxprinting.org/kpfeifle/LinuxKongress2002/Tutorial/</ulink></para>
+<listitem><para>Click on the <emphasis>General</emphasis>
+tab</para></listitem>
-<para>
-Note, that *all* the Foomatic drivers listed on Linuxprinting.org (now
-approaching the "all-time high" number of 1.000 for the supported models)
-are using a special filtering chain involving Ghostscript, as described
-in this document.
-</para>
+<listitem><para>Click on the button <emphasis>Printing
+Preferences...</emphasis></para></listitem>
-<para>
-Summary - You need:
+<listitem><para>A new dialog opens. Keep this dialog open and go back
+to the parent dialog.</para></listitem>
+</orderedlist>
</para>
+</listitem>
-<para>
-<simplelist>
- <member>A "foomatic+<replaceable>something</replaceable>" PPD is not enough to print with CUPS (but it is *one* important component)</member>
- <member>The "cupsomatic" filter script (Perl) in <filename>/usr/lib/cups/filters/</filename></member>
- <member>Perl to make cupsomatic run</member>
- <member>Ghostscript (because it is called and controlled by the PPD/cupsomatic combo in a way to fit your printermodel/driver combo.</member>
- <member>Ghostscript *must*, depending on the driver/model, contain support for a certain "device" (as shown by "gs -h")</member>
-</simplelist>
-</para>
+<listitem><para>The third, the "correct" way: (should you do
+this from the beginning, just carry out steps 1. and 2. from second
+"way" above)
-<para>
-In the case of the "hpijs" driver, you need a Ghostscript version, which
-has "ijs" amongst its supported devices in "gs -h". In the case of
-"hpijs+foomatic", a valid ghostscript commandline would be reading like this:
-</para>
+<orderedlist numeration="arabic">
+<listitem><para>Click on the <emphasis>Advanced</emphasis>
+tab. (Hmmm... if everything is "Grayed Out", then you are not logged
+in as a user with enough privileges).</para></listitem>
-<para><programlisting>
- gs -q -dBATCH -dPARANOIDSAFER -dQUIET -dNOPAUSE -sDEVICE=ijs \
- -sIjsServer=hpijs<replaceable>PageSize</replaceable> -dDuplex=<replaceable>Duplex</replaceable> <replaceable>Model</replaceable> \
- -r<replaceable>Resolution</replaceable>,PS:MediaPosition=<replaceable>InputSlot</replaceable> -dIjsUseOutputFD \
- -sOutputFile=- -
-</programlisting></para>
+<listitem><para>Click on the <emphasis>Printing
+Defaults...</emphasis> button.</para></listitem>
-<note><para>
-Note, that with CUPS and the "hpijs+foomatic" PPD (plus Perl and cupsomatic)
-you don't need to remember this. You can choose the available print options
-thru a GUI print command (like "glp" from ESP's commercially supported
-PrintPro software, or KDE's "kprinter", or GNOME's "gtklp" or the independent
-"xpp") or the CUPS web interface via human-readable drop-down selection
-menus.
-</para></note>
+<listitem><para>On any of the two new tabs, click on the
+<emphasis>Advanced...</emphasis>
+button.</para></listitem>
-<para>
-If you use "ESP Ghostscript" (also under the GPL, provided by Easy Software
-Products, the makers of CUPS, downloadable from
-<ulink url="http://www.cups.org/software.html">http://www.cups.org/software.html</ulink>,
-co-maintained by the developers of linuxprinting.org), you are guaranteed to
-have in use the most uptodate, bug-fixed, enhanced and stable version of a Free
-Ghostscript. It contains support for ~300 devices, whereas plain vanilla
-GNU Ghostscript 7.05 only has ~200.
+<listitem><para>A new dialog opens. Compare this one to the other,
+identical looking one from "B.5" or A.3".</para></listitem>
+</orderedlist>
</para>
+</listitem>
+</orderedlist>
<para>
-If you print only one CUPS test page, from the web interface and when you try to
-print a windows test page, it acts like the job was never sent:
-
-<simplelist>
- <member>Can you print "standard" jobs from the CUPS machine?</member>
- <member>Are the jobs from Windows visible in the Web interface on CUPS (http://localhost:631/)?</member>
- <member><emphasis>Most important:</emphasis> What kind of printer driver are you using on the Windows clients?</member>
-</simplelist>
-
-You can try to get a more detailed debugging info by setting "LogLevel debug" in
-<filename>/etc/cups/cupsd.conf</filename>, re-start cupsd and investigate <filename>/var/log/cups/error_log</filename>
-for the whereabouts of your Windows-originating printjobs:
-</para>
-
-<simplelist>
- <member>what does the "auto-typing" line say? which is the "MIME type" CUPS thinks is arriving from the Windows clients?</member>
- <member>are there "filter" available for this MIME type?</member>
- <member>are there "filter rules" defined in "/etc/cups/mime.convs" for this MIME type?</member>
-</simplelist>
-
+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 <emphasis>as
+Administrator</emphasis> (<parameter>printer admin</parameter> in
+<filename>smb.conf</filename>) <emphasis>before</emphasis> a client
+downloads the driver (the clients can later set their own
+<emphasis>per-user defaults</emphasis> by following the
+procedures <emphasis>A.</emphasis> or <emphasis>B.</emphasis>
+above).</para></listitem></varlistentry>
+
+<varlistentry><term>What are the most common blunders in driver
+settings on Windows clients?</term>
+<listitem><para>Don't use <emphasis>Optimize for
+Speed</emphasis>: use <emphasis>Optimize for
+Portability</emphasis> instead (Adobe PS Driver) Don't use
+<emphasis>Page Independence: No</emphasis>: always
+settle with <emphasis>Page Independence:
+Yes</emphasis> (Microsoft PS Driver and CUPS PS Driver for
+WinNT/2K/XP) If there are problems with fonts: use
+<emphasis>Download as Softfont into
+printer</emphasis> (Adobe PS Driver). For
+<emphasis>TrueType Download Options</emphasis>
+choose <emphasis>Outline</emphasis>. Use PostScript
+Level 2, if you are having trouble with a non-PS printer, and if
+there is a choice.</para></listitem></varlistentry>
+
+<varlistentry><term>I can't make <command>cupsaddsmb</command> work
+with newly installed printer</term>
+<listitem><para>Symptom: the last command of
+<command>cupsaddsmb</command> doesn't complete successfully:
+<command>cmd = setdriver printername printername</command> result was
+NT_STATUS_UNSUCCESSFUL then possibly the printer was not yet
+"recognized" by Samba. Did it show up in <emphasis>Network
+Neighbourhood</emphasis>? Did it show up in <command>rpcclient
+hostname -c 'enumprinters'</command>? Restart smbd (or send a
+<command>kill -HUP</command> to all processes listed by
+<command>smbstatus</command> and try
+again.</para></listitem></varlistentry>
+
+<varlistentry><term>My permissions on
+<filename>/var/spool/samba/</filename> get reset after each
+reboot</term>
+<listitem><para>Have you by accident set the CUPS spool directory to
+the same location? (<parameter>RequestRoot
+/var/spool/samba/</parameter> in <filename>cupsd.conf</filename> or
+the other way round: <filename>/var/spool/cups/</filename> is set as
+<parameter>path</parameter> in the <parameter>[printers]</parameter>
+section). These <emphasis>must</emphasis> be different. Set
+<parameter>RequestRoot /var/spool/cups/</parameter> in
+<filename>cupsd.conf</filename> and <parameter>path =
+/var/spool/samba</parameter> in the <parameter>[printers]</parameter>
+section of <filename>smb.conf</filename>. Otherwise cupsd will
+sanitize permissions to its spool directory with each restart, and
+printing will not work reliably.</para></listitem></varlistentry>
+
+<varlistentry><term>My printers work fine: just the printer named "lp"
+intermittently swallows jobs and spits out completely different
+ones</term>
+<listitem><para>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 <parameter>BrowseShortNames
+No</parameter>. It will present any printer as "printername@cupshost"
+then, giving you a better control over what may happen in a large
+networked environment.</para></listitem></varlistentry>
+
+<varlistentry><term>How do I "watch" my Samba server?</term>
+<listitem><para>You can use <command>tail -f
+/var/log/samba/log.smbd</command> (you may need a different path) to
+see a live scrolling of all log messages. <command>smbcontrol smbd
+debuglevel</command> tells you which verbosity goes into the
+logs. <command>smbcontrol smbd debug 3</command> 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.</para></listitem></varlistentry>
+
+<varlistentry><term>I can't use Samba from my WinXP Home box, while
+access from WinXP Prof works flawlessly</term>
+<listitem><para>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).</para></listitem></varlistentry>
+
+<varlistentry><term>Where do I find the Adobe PostScript driver files
+I need for "cupsaddsmb"?</term>
+<listitem><para>Use <command>smbclient</command> to connect to any
+Windows box with a shared PostScript printer: <command>smbclient
+//windowsbox/print\$ -U guest</command>. You can navigate to the
+<filename>W32X86/2</filename> subdir to <command>mget ADOBE*</command>
+and other files or to <filename>WIN40/0</filename> to do the same. --
+Another option is to download the <filename>*.exe</filename> packaged
+files from the Adobe website.</para></listitem></varlistentry>
+</variablelist>
</sect2>
-</sect1>
-
-
-<sect1>
-<title>Limiting the number of pages users can print</title>
-
-<para>
-The feature you want is dependent on the real print subsystem you're using.
-Samba's part is always to receive the job files from the clients (filtered
-*or* unfiltered) and hand it over to this printing subsystem.
-</para>
-
-<para>
-Of course one could "hack" things with one's own scripts.
-</para>
-
-<para>
-But there is CUPS (Common Unix Printing System). CUPS supports "quotas".
-Quotas can be based on sizes of jobs or on the number of pages or both,
-and are spanning any time period you want.
-</para>
-
-<para>
-This is an example command how root would set a print quota in CUPS,
-assuming an existing printer named "quotaprinter":
-</para>
-
-<programlisting>
- lpadmin -p quotaprinter -o job-quota-period=604800 -o job-k-limit=1024 \
- -o job-page-limit=100
-</programlisting>
-
-<para>
-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).
-</para>
-
-<para>
-For CUPS to count correctly, the printfile needs to pass the CUPS "pstops" filter,
-otherwise it uses a "dummy" count of "1". Some printfiles don't pass it
-(eg: image files) but then those are mostly 1 page jobs anyway. This also means,
-proprietary drivers for the target printer running on the client computers and
-CUPS/Samba then spooling these files as "raw" (i.e. leaving them untouched, not
-filtering them), will be counted as "1-pagers" too!
-</para>
-
-<para>
-You need to send PostScript from the clients (i.e. run a PostScript driver there)
-for having the chance to get accounting done. If the printer is a non-PostScript model,
-you need to let CUPS do the job to convert the file to a print-ready format for the
-target printer. This will be working for currently ~1.000 different printer models, see
-</para>
-
-<programlisting>
- http://www.linuxprinting.org/printer_list.cgi
-</programlisting>
-
-<para>
-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 thru the "pstops" filter on the CUPS/Samba side, and therefor was
-not counted correctly (the reason is that it often --- depending on the
-"PPD" being used --- did write a "PJL"-header in front of the real
-PostScript which made CUPS to skip the pstops and go directy to
-the "pstoraster" stage).
-</para>
-
-<para>
-From CUPS-1.1.16 onward you can use the "CUPS PostScript Driver
-for Windows NT/2K/XP clients" (it is tagged in the download area of
-http://www.cups.org/ as the "cups-samba-1.1.16.tar.gz" package).
-It is *not* working for Win9x/ME clients. But it:
-</para>
-
-<simplelist>
- <member>it guarantees to not write an PJL-header</member>
- <member>it guarantees to still read and support all PJL-options named in the driver PPD with its own means</member>
- <member>it guarantees the file going thru the "pstops" filter on the CUPS/Samba server</member>
- <member>it guarantees to page-count correctly the printfile</member>
-</simplelist>
-
-<para>
-You can read more about the setup of this combination in the
-manpage for "cupsaddsmb" (only present with CUPS installed, only
-current with CUPS 1.1.16).
-</para>
-
-<para>
-These are the items CUPS logs in the "page_log" for every single *page* of a job:
-</para>
-
-<para><simplelist>
-<member>Printer name</member>
-<member>User name</member>
-<member>Job ID</member>
-<member>Time of printing</member>
-<member>the page number</member>
-<member>the number of copies</member>
-<member>a billing info string (optional)</member>
-</simplelist>
-</para>
-
-<para>
-Here is an extract of my CUPS server's page_log file to illustrate
-the format and included items:
-</para>
-
-<para><computeroutput>
- infotec_IS2027 kurt 40 [22/Nov/2002:13:18:03 +0100] 1 2 #marketing
- infotec_IS2027 kurt 40 [22/Nov/2002:13:18:03 +0100] 2 2 #marketing
- infotec_IS2027 kurt 40 [22/Nov/2002:13:18:03 +0100] 3 2 #marketing
- infotec_IS2027 kurt 40 [22/Nov/2002:13:18:03 +0100] 4 2 #marketing
- infotec_IS2027 kurt 40 [22/Nov/2002:13:18:03 +0100] 5 2 #marketing
- infotec_IS2027 kurt 40 [22/Nov/2002:13:18:03 +0100] 6 2 #marketing
-</computeroutput></para>
-
-<para>
-This was Job ID "40", printed on "infotec_IS2027" by user "kurt", a 6-page job
-printed in 2 copies and billed to "#marketing"...
-</para>
-
-<para>
-What flaws or shortcomings are there?
-</para>
-
-<simplelist>
- <member>the ones named above</member>
-
- <member>
- CUPS really counts the job pages being *processsed in software*
- (going thru the "RIP") rather than the physical sheets successfully
- leaving the printing device -- 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
- </member>
-
- <member>
- all quotas are the same for all users (no flexibility to give the
- boss a higher quota than the clerk) no support for groups
- </member>
-
- <member>
- no means to read out the current balance or "used-up" number of current quota
- </member>
-
- <member>
- a user having used up 99 sheets of 100 quota will still be able to send and print a 1.000 sheet job
- </member>
-
- <member>
- 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".
- </member>
-</simplelist>
-
-<para>
-But this is the best system out there currently. And there are
-huge improvements under development:
-</para>
-
-<simplelist>
- <member>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 -- a jam at the 5th sheet will lead to a stop in the counting)</member>
-
- <member>quotas will be handled more flexibly</member>
-
- <member>probably there will be support for users to inquire their "accounts" in advance</member>
-
- <member>probably there will be support for some other tools around this topic</member>
-</simplelist>
-
-<para>
-Other than the current stage of the CUPS development, I don't
-know any other ready-to-use tool which you could consider.
-</para>
-
-<para>
-You can download the driver files from
-<ulink url="http://www.cups.org/software.html">http://www.cups.org/software.html</ulink>.
-It is a separate package from the CUPS base software files, tagged as "CUPS 1.1.16
-Windows NT/2k/XP Printer Driver for SAMBA (tar.gz, 192k)". The filename to
-download is "cups-samba-1.1.16.tar.gz". Upon untar-/unzip-ping it will reveal
-the files:
-</para>
-
-<para>
-<computeroutput>
- cups-samba.install
- cups-samba.license
- cups-samba.readme
- cups-samba.remove
- cups-samba.ss
-</computeroutput>
-</para>
-
-<para>
-These have been packaged with the ESP meta packager software "EPM". The
-*.install and *.remove files are simple shell script, which untars the
-*.ss (which is nothing else than a tar-archive) and puts its contents
-into <filename>/usr/share/cups/drivers/</filename>. Its contents are 3 files:
-</para>
-
-<para>
-<computeroutput>
- cupsdrvr.dll
- cupsui.dll
- cups.hlp
-</computeroutput>
-</para>
-
-<caution><para>
-Due to a bug one CUPS release puts the <filename>cups.hlp</filename>
-into <filename>/usr/share/drivers/</filename> instead of
-<filename>/usr/share/cups/drivers/</filename>. To work around this, copy/move
-the file after running the "./cups-samba.install" script manually to the right place:
-</para>
-
- <para>
-<userinput> cp /usr/share/drivers/cups.hlp /usr/share/cups/drivers/
-</userinput>
- </para></caution>
-
-<note>
-<para>
-This new CUPS PostScript driver is currently binary-only, but free
-no source code is provided (yet). The reason is this: it has
-been developed with the help of the Microsoft Driver Developer Kit (DDK)
-and compiled with Microsoft Visual Studio 6. It is not clear to the driver
-developers if they are allowed to distribute the whole of the source code
-as Free Software. However, they will likely release 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.
-</para>
-
-<para>
-Once you have run the install script (and possibly manually moved the
-"cups.hlp" file to "/usr/share/cups/drivers/"), the driver is ready to be
-put into Samba's [print$] share (which often maps to "/etc/samba/drivers/"
-and contains a subdir tree with WIN40 and W32X86 branches), by running
-"cupsaddsmb" (see also "man cupsaddsmb" for CUPS 1.1.16). [Don't forget to
-put root into the smbpasswd file by running "smbpasswd" should you run
-this whole procedure for the first time.] Once the driver files are in the
-[print$] share, they are ready to be downloaded and installed by the
-Win NT/2k/XP clients.
-</para></note>
-
-
- <note><para>
- Win 9x/ME clients won't work with this driver. For these you'd
- still need to use the ADOBE*.* drivers as previously.
- </para></note>
-
- <note><para>
- It is not harming if you've still the ADOBE*.* driver files from
- previous installations in the "/usr/share/cups/drivers/" directory.
- The new cupsaddsmb (from 1.1.16) will automatically use the
- "newest" installed driver (which here then is the CUPS drivers).
- </para></note>
-
- <note><para>
- Should your Win clients have had the old ADOBE*.* files and the
- Adobe PostScript drivers installed, the download and installation
- of the new CUPS PostScript driver for Windows NT/2k/XP will fail
- at first.
- </para>
- <para>
- It is not enough to "delete" the printer (as the driver files
- will still be kept by the clients and re-used if you try to
- re-install the printer). To really get rid of the Adobe driver
- files on the clients, open the "Printers" folder (possibly via
- "Start --> Settings --> Control Panel --> Printers"), right-click
- onto the folder background and select "Server Properties". A
- new dialog opens; select the "Drivers" tab; on the list select
- the driver you want to delete and click on the "Delete" button.
- (This will only work if there is no single printer left which
- uses that particular driver -- you need to "delete" all printers
- using this driver in the "Printers" folder first.)
- </para>
- </note>
-
- <note><para>
- 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" to change a driver for an existing printer.
- </para></note>
-
-<para>
-What are the benefits with the "CUPS PostScript driver for Windows NT/2k/XP"
-as compared to the Adobe drivers?
-</para>
-
-<para>
-<simplelist>
- <member><para>
- no hassle with the Adobe EULA
- </para></member>
-
- <member><para>
- no hassle with the question "where do I get the ADOBE*.* driver files from?"
- </para></member>
-
- <member><para>
- the Adobe drivers (depending on the printer PPD associated with them)
- often put a PJL header in front of the core PostScript part of the print
- file (thus the file starts with "<replaceable>1B</replaceable>%-12345X"
- or "<replaceable>escape</replaceable>%-12345X"
- instead of "%!PS"). This leads to the CUPS daemon autotyping the
- arriving file as a print-ready file, not requiring a pass thru the
- "pstops" filter (to speak more technical, it is not regarded as the
- generic MIME type "application/postscript", but as the more special
- MIME type "application/cups.vnd-postscript"), which therefore also
- leads to the page accounting in "/var/log/cups/page_log" not receiving
- the exact mumber of pages; instead the dummy page number of "1" is
- logged in a standard setup)
- </para></member>
-
- <member><para>
- the Adobe driver has more options to "mis-configure" the PostScript
- generated by it (like setting it inadvertedly to "Optimize for Speed",
- instead of "Optimize for Portability", which could lead to CUPS being
- unable to process it)
- </para></member>
-
- <member><para>
- the CUPS PostScript driver output sent by Windows clients to the CUPS
- server will be guaranteed to be auto-typed as generic MIME type
- "application/postscript", thusly passing thru the CUPS "pstops" filter
- and logging the correct number of pages in the page_log for accounting
- and quota purposes
- </para></member>
-
- <member><para>
- the CUPS PostScript driver supports the sending of additional print
- options by the Win NT/2k/XP clients, such as naming the CUPS standard
- banner pages (or the custom ones, should they be installed at the time
- of driver download), using the CUPS "page-label" option, setting a
- job-priority and setting the scheduled time of printing (with the option
- to support additional useful IPP job attributes in the future).
- </para></member>
-
- <member><para>
- the CUPS PostScript driver supports the inclusion of the new
- "*cupsJobTicket" comments at the beginnig 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 application as those
- will regard it as a comment and simply ignore it).
- </para></member>
-
- <member><para>
- 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).
- </para></member>
-
-</simplelist>
-</para>
-</sect1>
-
-<sect1>
-<title>Advanced Postscript Printing from MS Windows</title>
-
-<para>
-Let the Windows Clients use a PostScript driver to deliver poistscript to
-the samba print server (just like any Linux or Unix Client would also use
-PostScript to send to the server)
-</para>
-
-<para>
-Make the Unix printing subsystem to which Samba sends the job convert the
-incoming PostScript files to the native print format of the target printers
-(would be PCL if you have an HP printer)
-</para>
-
-<para>
-Now if you are afraid that this would just mean using a *Generic* PostScript
-driver for the clients that has no Simplex/Duplex selection, and no paper tray
-choice, but you need them to be able to set up print jobs, with all the bells
-and whistles of your printers:-
-</para>
-
-<simplelist>
- <member>Not possible with traditional spooling systems</member>
-
- <member>
- But perfectly supported by CUPS (which uses "PPD" files to
- describe how to control the print options for PostScript and
- non-PostScript devices alike...
- </member>
-</simplelist>
-
-<para>
-CUPS PPDs are working perfectly on Windows clients who use Adobe PostScript
-drivers (or the new CUPS PostScript driver for Windows NT/2K/XP). Clients can use
-them to setup the job to their liking and CUPS will use the received job options
-to make the (PCL-, ESC/P- or PostScript-) printer behave as required.
-</para>
-
-<para>
-If you want to have the additional benefit of page count logging and accounting
-then the CUPS PostScript driver is the best choice (better than the Adobe one).
-</para>
-
-<para>
-If you want to make the drivers downloadable for the clients then "cupsaddsmb" is
-your friend. It will setup the [print$] share on the Samba host to be ready to serve
-the clients for a "point and print" driver installation.
-</para>
-
-<warning>
-<para>What strings are attached?</para></warning>
-
-<para>
-There are some. But, given the sheer CPU power you can buy nowadays,
-these can be overcome easily. The strings:
-</para>
+<sect2>
+<title>An Overview of the CUPS Printing Processes</title>
<para>
-Well, if the CUPS/Samba side will have to print to many printers serving many users,
-you probably will need to set up a second server (which can do automatic load balancing
-with the first one, plus a degree of fail-over mechanism). Converting the incoming
-PostScript jobs, "interpreting" them for non-PostScript printers, amounts to the work
-of a "RIP" (Raster Image Processor) done in software. This requires more CPU and RAM
-than for the mere "raw spooling" task your current setup is solving. It all depends
-on the avarage and peak printing load the server should be able to handle.
+<figure><title>CUPS Printing Overview</title>
+<graphic fileref="projdoc/imagefiles/a_small.png"/>
+</figure>
</para>
-
+</sect2>
</sect1>
-<sect1>
-<title>Auto-Deletion of CUPS spool files</title>
-
-<para>
-Samba print files pass thru two "spool" directories. One the incoming directory
-managed by Samba, (set eg: in the <command>path = /var/spool/samba</command> directive in the [printers]
-section of &smb.conf;). Second is the spool directory of your UNIX print subsystem.
-For CUPS it is normally "/var/spool/cups/", as set by the cupsd.conf directive
-"RequestRoot /var/spool/cups".
-</para>
-
-<para>
-I am not sure, which one of your directories keeps the files. From what you say,
-it is most likely the Samba part.
-</para>
-
-<para>
-For the CUPS part, you may want to consult:
-</para>
-
-<simplelist>
-<member>http://localhost:631/sam.html#PreserveJobFiles</member>
-<member>http://localhost:631/sam.html#PreserveJobHistory</member>
-<member>http://localhost:631/sam.html#MaxJobs</member>
-</simplelist>
-
-<para>
-There are the settings described for your CUPS daemon, which could lead to completed
-job files not being deleted.
-</para>
-
-<para>
-"PreserveJobHistory Yes" -- 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.
-</para>
-
-<para>
-"PreserveJobFiles Yes" -- 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.
-</para>
-
-<para>
-"MaxJobs 500" -- 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.
-</para>
-
-<para>
-(There are also additional settings for "MaxJobsPerUser" and
-"MaxJobsPerPrinter"...)
-</para>
-
-<para>
-For everything to work as announced, you need to have three things:
-</para>
-
-<simplelist>
-
- <member>
- a Samba-&smbd; which is compiled against "libcups" (Check on Linux by running <userinput>ldd `which smbd`</userinput>)
- </member>
-
- <member>
- a Samba-&smb.conf; setting of <command>printing = cups</command>
- </member>
-
- <member>
- another Samba-&smb.conf; setting of <command>printcap = cups</command>
- </member>
-
-</simplelist>
-
-<note><para>
-Note, that 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.
-</para></note>
-
-<para>
-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.
-</para>
-
-<para>
-You forgot to mention the CUPS version you're using. If you did
-set things up as described in the man pages, then the Samba
-spool files should be deleted. Otherwise it may be a bug. On
-the CUPS side, you can control the behaviour as described
-above.
-</para>
-
-<para>
-If you have more problems, post the output of these commands:
-</para>
-
-<para>
-<userinput>
- grep -v ^# /etc/cups/cupsd.conf | grep -v ^$
- grep -v ^# /etc/samba/smb.conf | grep -v ^$ | grep -v "^;"
-</userinput>
-</para>
-
-<para>
-(adapt paths as needed). These commands sanitize the files
-and cut out the empty lines and lines with comments, providing
-the "naked settings" in a compact way.
-</para>
-</sect1>
</chapter>
git.samba.org / gd / samba / .git / commitdiff
