1 <chapter id="CUPS-printing">
6 <firstname>Kurt</firstname><surname>Pfeifle</surname>
8 <orgname> Danka Deutschland GmbH </orgname>
9 <address><email>kpfeifle@danka.de</email></address>
12 <pubdate> (3 June 2003) </pubdate>
15 <title>CUPS Printing Support in Samba 3.0</title>
19 <title>Introduction</title>
22 <title>Features and Benefits</title>
25 The Common Unix Print System (<ulink
26 url="http://www.cups.org/">CUPS</ulink>) has become very popular. All
27 big Linux distributions now ship it as their default printing
28 system. But to many it is still a very mystical tool. Normally it
29 "just works" (TM). People tend to regard it as a sort of "black box",
30 which they don't want to look into, as long as it works OK. But once
31 there is a little problem, they are in trouble to find out where to
32 start debugging it. Also, even the most recent and otherwise excellent
33 printed Samba documentation has only limited attention paid to CUPS
34 printing, leaving out important pieces or even writing plain wrong
35 things about it. This demands rectification. But before you dive into
36 this chapter, make sure that you don't forget to refer to the
37 "Classical Printing" chapter also. It contains a lot of information
38 that is relevant for CUPS too.
42 CUPS sports quite a few unique and powerful features. While their
43 basic functions may be grasped quite easily, they are also
44 new. Because they are different from other, more traditional printing
45 systems, it is best to try and not apply any prior knowledge about
46 printing upon this new system. Rather try to start understand CUPS
47 from the beginning. This documentation will lead you here to a
48 complete understanding of CUPS, if you study all of the material
49 contained. But lets start with the most basic things first. Maybe this
50 is all you need for now. Then you can skip most of the other
57 <title>Overview</title>
60 CUPS is more than just a print spooling system. It is a complete
61 printer management system that complies with the new IPP
62 (<emphasis>Internet Printing Protocol</emphasis>). IPP is an industry
63 and IETF (<emphasis>Internet Engineering Task Force</emphasis>)
64 standard for network printing. Many of its functions can be managed
65 remotely (or locally) via a web browser (giving you a
66 platform-independent access to the CUPS print server). In addition it
67 has the traditional commandline and several more modern GUI interfaces
68 (GUI interfaces developed by 3rd parties, like KDE's
70 url="http://printing.kde.org/">KDEPrint</ulink>).
74 CUPS allows creation of "raw" printers (ie: NO print file
75 format translation) as well as "smart" printers (i.e. CUPS does
76 file format conversion as required for the printer). In many ways
77 this gives CUPS similar capabilities to the MS Windows print
78 monitoring system. Of course, if you are a CUPS advocate, you would
79 argue that CUPS is better! In any case, let us now move on to
80 explore how one may configure CUPS for interfacing with MS Windows
81 print clients via Samba.
87 <title>Basic Configuration of CUPS support</title>
90 Printing with CUPS in the most basic <filename>smb.conf</filename>
91 setup in Samba 3.0 (as was true for 2.2.x) only needs two
92 settings: <parameter>printing = cups</parameter> and <parameter>printcap
93 = cups</parameter>. CUPS itself doesn't need a printcap file
94 anymore. However, the <filename>cupsd.conf</filename> configuration
95 file knows two related directives: they control if such a file should
96 be automatically created and maintained by CUPS for the convenience of
97 third party applications (example: <parameter>Printcap
98 /etc/printcap</parameter> and <parameter>PrintcapFormat
99 BSD</parameter>). These legacy programs often require the existence of
100 printcap file containing printernames or they will refuse to
101 print. Make sure CUPS is set to generate and maintain a printcap! For
102 details see <command>man cupsd.conf</command> and other CUPS-related
103 documentation, like the wealth of documents on your CUPS server
105 url="http://localhost:631/documentation.html">http://localhost:631/documentation.html</ulink>.
109 <title>Linking of smbd with <filename>libcups.so</filename></title>
112 Samba has a very special relationship to CUPS. The reason is: Samba
113 can be compiled with CUPS library support. Most recent installations
114 have this support enabled, and per default CUPS linking is compiled
115 into smbd and other Samba binaries. Of course, you can use CUPS even
116 if Samba is not linked against <filename>libcups.so</filename> -- but
117 there are some differences in required or supported configuration
122 If SAMBA is compiled against libcups, then <parameter>printcap =
123 cups</parameter> uses the CUPS API to list printers, submit jobs,
124 query queues, etc. Otherwise it maps to the System V commands with an
125 additional <command>-oraw</command> option for printing. On a Linux
126 system, you can use the <command>ldd</command> utility to find out
127 details (ldd may not be present on other OS platforms, or its function
128 may be embodied by a different command):
132 transmeta:/home/kurt # ldd `which smbd`
133 libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x4002d000)
134 libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x4005a000)
135 libcups.so.2 => /usr/lib/libcups.so.2 (0x40123000)
140 The line <computeroutput>libcups.so.2 => /usr/lib/libcups.so.2
141 (0x40123000)</computeroutput> shows there is CUPS support compiled
142 into this version of Samba. If this is the case, and printing = cups
143 is set, then <emphasis>any otherwise manually set print command in
144 <filename>smb.conf</filename> is ignored</emphasis>. This is an
145 important point to remember!
148 <tip><para> Should you require -- for any reason -- to set your own
149 print commands, you can still do this by setting <parameter>printing =
150 sysv</parameter>. However, you'll loose all the benefits from the
151 close CUPS/Samba integration. You are on your own then to manually
152 configure the rest of the printing system commands (most important:
153 <parameter>print command</parameter>; other commands are
154 <parameter>lppause command, lpresume command, lpq command, lprm
155 command, queuepause command </parameter> and <parameter>queue resume
156 command</parameter>).</para></tip>
160 <title>Simple <filename>smb.conf</filename> Settings for CUPS</title>
163 To summarize, here is the simplest printing-related setup
164 for<filename>smb.conf</filename> to enable basic CUPS support:
175 comment = All Printers
176 path = /var/spool/samba
182 printer admin = root, @ntadmins
187 This is all you need for basic printing setup for CUPS. It will print
188 all Graphic, Text, PDF and PostScript file submitted from Windows
189 clients. However, most of your Windows users would not know how to
190 send these kind of files to print without opening a GUI
191 application. Windows clients tend to have local printer drivers
192 installed. And the GUI application's print buttons start a printer
193 driver. Your users also very rarely send files from the command
194 line. Unlike UNIX clients, they hardly submit graphic, text or PDF
195 formatted files directly to the spooler. They nearly exclusively print
196 from GUI applications, with a "printer driver" hooked in between the
197 applications native format and the print data stream. If the backend
198 printer is not a PostScript device, the print data stream is "binary",
199 sensible only for the target printer. Read on to learn which problem
200 this may cause and how to avoid it.
205 <title>More complex <filename>smb.conf</filename> Settings for
209 Here is a slightly more complex printing-related setup
210 for<filename>smb.conf</filename>. It enables general CUPS printing
211 support for all printers, but defines one printer share which is set
223 comment = All Printers
224 path = /var/spool/samba
229 printer admin = root, @ntadmins
232 comment = A special printer with his own settings
233 path = /var/spool/samba-special
236 print command = echo "NEW: `date`: printfile %f" >> /tmp/smbprn.log ;\
237 echo " `date`: p-%p s-%s f-%f" >> /tmp/smbprn.log ;\
238 echo " `date`: j-%j J-%J z-%z c-%c" >> /tmp/smbprn.log :\
246 hosts allow = turbo_xp, 10.160.50.23, 10.160.51.60
251 This special share is only there for my testing purposes. It doesn't
252 even write the printjob to a file. It just logs the job parameters
253 known to Samba into the <filename>/tmp/smbprn.log</filename> file and
254 deletes the jobfile. Moreover, the <parameter>printer
255 admin</parameter> of this share is "kurt" (not the "@ntadmins" group);
256 guest access is not allowed; the share isn't announced in Network
257 Neighbourhood (so you need to know it is there), and it is only
258 allowing access from three hosts. To prevent CUPS kicking in and
259 taking over the print jobs for that share, we need to set
260 <parameter>printing = sysv</parameter> and <parameter>printcap =
267 <title>Advanced Configuration</title>
270 Before we dive into all the configuration options, let's clarify a few
271 points. <emphasis>Network printing needs to be organized and setup
272 correctly</emphasis>. Often this is not done correctly. Legacy systems
273 or small LANs in business environments often lack a clear design and
278 <title>Central spooling vs. "Peer-to-Peer" printing</title>
281 Many small office or home networks, as well as badly organized larger
282 environments, allow each client a direct access to available network
283 printers. Generally, this is a bad idea. It often blocks one client's
284 access to the printer when another client's job is printing. It also
285 might freeze the first client's application while it is waiting to get
286 rid of the job. Also, there are frequent complaints about various jobs
287 being printed with their pages mixed with each other. A better concept
288 is the usage of a "print server": it routes all jobs through one
289 central system, which responds immediately, takes jobs from multiple
290 concurrent clients at the same time and in turn transfers them to the
291 printer(s) in the correct order.
296 <title>CUPS/Samba as a "spooling-only" Print Server; "raw" printing
297 with Vendor Drivers on Windows Clients</title>
300 Most traditionally configured Unix print servers acting on behalf of
301 Samba's Windows clients represented a really simple setup. Their only
302 task was to manage the "raw" spooling of all jobs handed to them by
303 Samba. This approach meant that the Windows clients were expected to
304 prepare the printjob file in such a way that it became fit to be fed to
305 the printing device. Here a native (vendor-supplied) Windows printer
306 driver for the target device needed to be installed on each and every
311 Of course you can setup CUPS, Samba and your Windows clients in the
312 same, traditional and simple way. When CUPS printers are configured
313 for RAW print-through mode operation it is the responsibility of the
314 Samba client to fully render the print job (file). The file must be
315 sent in a format that is suitable for direct delivery to the
316 printer. Clients need to run the vendor-provided drivers to do
317 this. In this case CUPS will NOT do any print file format conversion
323 <title>Driver Installation Methods on Windows Clients</title>
326 The printer drivers on the Windows clients may be installed
327 in two functionally different ways:
331 <listitem><para>manually install the drivers locally on each client,
332 one by one; this yields the old <emphasis>LanMan</emphasis> style
333 printing; it uses a <filename>\\sambaserver\printershare</filename>
334 type of connection.</para></listitem>
336 <listitem><para>deposit and prepare the drivers (for later download) on
337 the print server (Samba); this enables the clients to use
338 "Point'n'Print" to get drivers semi-automatically installed the
339 first time they access the printer; with this method NT/2K/XP
340 clients use the <emphasis>SPOOLSS/MS-RPC</emphasis>
341 type printing calls.</para></listitem>
345 The second method is recommended for use over the first.
350 <title>Explicitly enable "raw" printing for
351 <emphasis>application/octet-stream</emphasis>!</title>
354 If you use the first option (drivers are installed on the client
355 side), there is one setting to take care of: CUPS needs to be told
356 that it should allow "raw" printing of deliberate (binary) file
357 formats. The CUPS files that need to be correctly set for RAW mode
358 printers to work are:
362 <listitem><para>/etc/cups/mime.types
365 <listitem><para>/etc/cups/mime.convs</para></listitem>
369 Both contain entries (at the end of the respective files) which must
370 be uncommented to allow RAW mode operation.
371 In<filename>/etc/cups/mime.types</filename> make sure this line is
377 application/octet-stream
382 In <filename>/etc/cups/mime.convs</filename>,
388 application/octet-stream application/vnd.cups-raw 0 -
393 If these two files are not set up correctly for raw Windows client
394 printing, you may encounter the dreaded <computeroutput>Unable to
395 convert file 0</computeroutput> in your CUPS error_log file.
398 <note><para>editing the <filename>mime.convs</filename> and the
399 <filename>mime.types</filename> file does not
400 <emphasis>enforce</emphasis> "raw" printing, it only
401 <emphasis>allows</emphasis> it.
404 <formalpara><title>Background</title>
407 CUPS being a more security-aware printing system than traditional ones
408 does not by default allow a user to send deliberate (possibly binary)
409 data to printing devices. This could be easily abused to launch a
410 "Denial of Service" attack on your printer(s), causing at the least
411 the loss of a lot of paper and ink. "Unknown" data are tagged by CUPS
412 as <emphasis>MIME type: application/octet-stream</emphasis> and not
413 allowed to go to the printer. By default, you can only send other
414 (known) MIME types "raw". Sending data "raw" means that CUPS does not
415 try to convert them and passes them to the printer untouched (see next
416 chapter for even more background explanations).
421 This is all you need to know to get the CUPS/Samba combo printing
422 "raw" files prepared by Windows clients, which have vendor drivers
423 locally installed. If you are not interested in background information about
424 more advanced CUPS/Samba printing, simply skip the remaining sections
430 <title>Three familiar Methods for driver upload plus a new one</title>
433 If you want to use the MS-RPC type printing, you must upload the
434 drivers onto the Samba server first (<parameter>[print$]</parameter>
435 share). For a discussion on how to deposit printer drivers on the
436 Samba host (so that the Windows clients can download and use them via
437 "Point'n'Print") please also refer to the previous chapter of this
438 HOWTO Collection. There you will find a description or reference to
439 three methods of preparing the client drivers on the Samba server:
443 <listitem><para>the GUI, "Add Printer Wizard"
444 <emphasis>upload-from-a-Windows-client</emphasis>
445 method;</para></listitem>
447 <listitem><para>the commandline, "smbclient/rpcclient"
448 <emphasis>upload-from-a-UNIX-workstation</emphasis>
449 method;</para></listitem>
451 <listitem><para>the <emphasis>Imprints</emphasis> Toolset
452 method.</para></listitem>
456 These 3 methods apply to CUPS all the same. A new and more
457 convenient way to load the Windows drivers into Samba is provided
458 provided if you use CUPS:
462 <listitem><para>the <emphasis>cupsaddsmb</emphasis>
463 utility.</para></listitem>
467 cupsaddsmb is discussed in much detail further below. But we will
468 first explore the CUPS filtering system and compare the Windows and
469 UNIX printing architectures.
475 <title>Using CUPS/Samba in an advanced Way -- intelligent printing
476 with PostScript Driver Download</title>
479 Still reading on? Good. Let's go into more detail then. We now know
480 how to set up a "dump" printserver, that is, a server which is spooling
481 printjobs "raw", leaving the print data untouched.
485 Possibly you need to setup CUPS in a more smart way. The reasons could
490 <listitem><para>Maybe your boss wants to get monthly statistics: Which
491 printer did how many pages? What was the average data size of a job?
492 What was the average print run per day? What are the typical hourly
493 peaks in printing? Which departments prints how
494 much?</para></listitem>
496 <listitem><para>Maybe you are asked to setup a print quota system:
497 users should not be able to print more jobs, once they have surpassed
498 a given limit per period?</para></listitem>
500 <listitem><para>Maybe your previous network printing setup is a mess
501 and shall be re-organized from a clean beginning?</para></listitem>
503 <listitem><para>Maybe you have experiencing too many "Blue Screens",
504 originating from poorly debugged printer drivers running in NT "kernel
505 mode"?</para></listitem>
509 These goals cannot be achieved by a raw print server. To build a
510 server meeting these requirements, you'll first need to learn about
511 how CUPS works and how you can enable its features.
515 What follows is the comparison of some fundamental concepts for
516 Windows and Unix printing; then is the time for a description of the
517 CUPS filtering system, how it works and how you can tweak it.
521 <title>GDI on Windows -- PostScript on Unix</title>
524 Network printing is one of the most complicated and error-prone
525 day-to-day tasks any user or an administrator may encounter. This is
526 true for all OS platforms. And there are reasons for this.
530 You can't expect for most file formats to just throw them towards
531 printers and they get printed. There needs to be a file format
532 conversion in between. The problem is: there is no common standard for
533 print file formats across all manufacturers and printer types. While
534 <emphasis>PostScript</emphasis> (trademark held by Adobe), and to an
535 extend<emphasis>PCL</emphasis> (trademark held by HP), have developed
536 into semi-official "standards", by being the most widely used PDLs
537 (<emphasis>Page Description Languages</emphasis>), there are still
538 many manufacturers who "roll their own" (their reasons may be
539 unacceptable license fees for using printer-embedded PostScript
545 <title>Windows Drivers, GDI and EMF</title>
548 In Windows OS, the format conversion job is done by the printer
549 drivers. On MS Windows OS platforms all application programmers have
550 at their disposal a built-in API, the GDI (<emphasis>Graphical Device
551 Interface</emphasis>), as part and parcel of the OS itself, to base
552 themselves on. This GDI core is used as one common unified ground, for
553 all Windows programs, to draw pictures, fonts and documents
554 <emphasis>on screen</emphasis> as well as <emphasis>on
555 paper</emphasis> (=print). Therefore printer driver developers can
556 standardize on a well-defined GDI output for their own driver
557 input. Achieving WYSIWYG ("What You See Is What You Get") is
558 relatively easy, because the on-screen graphic primitives, as well as
559 the on-paper drawn objects, come from one common source. This source,
560 the GDI, produces often a file format called EMF (<emphasis>Enhanced
561 MetaFile</emphasis>). The EMF is processed by the printer driver and
562 converted to the printer-specific file format.
566 To the GDI foundation in MS Windows, Apple has chosen to
567 put paper and screen output on a common foundation for their
568 (BSD-Unix-based, did you know??) Mac OS X and Darwin Operating
569 Systems.Their <emphasis>Core Graphic Engine</emphasis> uses a
570 <emphasis>PDF</emphasis> derivate for all display work.
575 <figure><title>Windows Printing to a local Printer</title>
577 <imageobject role="latex"><imagedata fileref="projdoc/imagefiles/1small"/></imageobject>
578 <imageobject><imagedata fileref="projdoc/imagefiles/1small.png"/></imageobject>
585 <title>Unix Printfile Conversion and GUI Basics</title>
588 In Unix and Linux, there is no comparable layer built into the OS
589 kernel(s) or the X (screen display) server. Every application is
590 responsible for itself to create its print output. Fortunately, most
591 use PostScript. That gives at least some common ground. Unfortunately,
592 there are many different levels of quality for this PostScript. And
593 worse: there is a huge difference (and no common root) in the way how
594 the same document is displayed on screen and how it is presented on
595 paper. WYSIWYG is more difficult to achieve. This goes back to the
596 time decades ago, when the predecessors of <emphasis>X.org</emphasis>,
597 designing the UNIX foundations and protocols for Graphical User
598 Interfaces refused to take over responsibility for "paper output"
599 also, as some had demanded at the time, and restricted itself to
600 "on-screen only". (For some years now, the "Xprint" project has been
601 under development, attempting to build printing support into the X
602 framework, including a PostScript and a PCL driver, but it is not yet
603 ready for prime time.) You can see this unfavorable inheritance up to
604 the present day by looking into the various "font" directories on your
605 system; there are separate ones for fonts used for X display and fonts
610 <title>Background</title>
613 The PostScript programming language is an "invention" by Adobe Inc.,
614 but its specifications have been published to the full. Its strength
615 lies in its powerful abilities to describe graphical objects (fonts,
616 shapes, patterns, lines, curves, dots...), their attributes (color,
617 linewidth...) and the way to manipulate (scale, distort, rotate,
618 shift...) them. Because of its open specification, anybody with the
619 skill can start writing his own implementation of a PostScript
620 interpreter and use it to display PostScript files on screen or on
621 paper. Most graphical output devices are based on the concept of
622 "raster images" or "pixels" (one notable exception are pen
623 plotters). Of course, you can look at a PostScript file in its textual
624 form and you will be reading its PostScript code, the language
625 instructions which need to be interpreted by a rasterizer. Rasterizers
626 produce pixel images, which may be displayed on screen by a viewer
627 program or on paper by a printer.
633 <title>PostScript and Ghostscript</title>
636 So, Unix is lacking a common ground for printing on paper and
637 displaying on screen. Despite this unfavorable legacy for Unix, basic
638 printing is fairly easy: if you have PostScript printers at your
639 disposal! The reason is: these devices have a built-in PostScript
640 language "interpreter", also called a <emphasis>Raster Image
641 Processor</emphasis> (RIP), (which makes them more expensive than
642 other types of printers); throw PostScript towards them, and they will
643 spit out your printed pages. Their RIP is doing all the hard work of
644 converting the PostScript drawing commands into a bitmap picture as
645 you see it on paper, in a resolution as done by your printer. This is
646 no different to PostScript printing of a file from a Windows origin.
649 <note><para>Traditional Unix programs and printing systems -- while
650 using PostScript -- are largely not PPD-aware. PPDs are "PostScript
651 Printer Description" files. They enable you to specify and control all
652 options a printer supports: duplexing, stapling, punching... Therefore
653 Unix users for a long time couldn't choose many of the supported
654 device and job options, unlike Windows or Apple users. But now there
660 <figure><title>Printing to a Postscript Printer</title>
662 <imageobject role="latex"><imagedata fileref="projdoc/imagefiles/2small"/></imageobject>
663 <imageobject><imagedata fileref="projdoc/imagefiles/2small.png"/></imageobject>
669 However, there are other types of printers out there. These don't know
670 how to print PostScript. They use their own <emphasis>Page Description
671 Language</emphasis> (PDL, often proprietary). To print to them is much
672 more demanding. Since your Unix applications mostly produce
673 PostScript, and since these devices don't understand PostScript, you
674 need to convert the printfiles to a format suitable for your printer
675 on the host, before you can send it away.
680 <title>Ghostscript -- the Software RIP for non-PostScript Printers</title>
683 Here is where<emphasis>Ghostscript</emphasis> kicks in. Ghostscript is
684 the traditional (and quite powerful) PostScript interpreter used on
685 Unix platforms. It is a RIP in software, capable to do a
686 <emphasis>lot</emphasis> of file format conversions, for a very broad
687 spectrum of hardware devices as well as software file formats.
688 Ghostscript technology and drivers is what enables PostScript printing
689 to non-PostScript hardware.
693 <figure><title>Ghostscript as a RIP for non-postscript printers</title>
695 <imageobject role="latex"><imagedata fileref="projdoc/imagefiles/3small"/></imageobject>
696 <imageobject><imagedata fileref="projdoc/imagefiles/3small.png"/></imageobject>
702 Use the "gs -h" command to check for all built-in "devices" of your
703 Ghostscript version. If you specify e.g. a parameter of
704 <parameter>-sDEVICE=png256</parameter> on your Ghostscript command
705 line, you are asking Ghostscript to convert the input into a PNG
706 file. Naming a "device" on the commandline is the most important
707 single parameter to tell Ghostscript how exactly it should render the
708 input. New Ghostscript versions are released at fairly regular
709 intervals, now by artofcode LLC. They are initially put under the
710 "AFPL" license, but re-released under the GNU GPL as soon as the next
711 AFPL version appears. GNU Ghostscript is probably the version
712 installed on most Samba systems. But it has got some
713 deficiencies. Therefore ESP Ghostscript was developed as an
714 enhancement over GNU Ghostscript, with lots of bug-fixes, additional
715 devices and improvements. It is jointly maintained by developers from
716 CUPS, Gimp-Print, MandrakeSoft, SuSE, RedHat and Debian. It includes
717 the "cups" device (essential to print to non-PS printers from CUPS).
722 <title>PostScript Printer Description (PPD) Specification</title>
725 While PostScript in essence is a <emphasis>Page Description
726 Language</emphasis> (PDL) to represent the page layout in a
727 <emphasis>device independent</emphasis> way, real world print jobs are
728 always ending up to be output on a hardware with device-specific
729 features. To take care of all the differences in hardware, and to
730 allow for innovations, Adobe has specified a syntax and file format
731 for <emphasis>PostScript Printer Description</emphasis> (PPD)
732 files. Every PostScript printer ships with one of these files.
736 PPDs contain all information about general and special features of the
737 given printer model: Which different resolutions can it handle? Does
738 it have a Duplexing Unit? How many paper trays are there? What media
739 types and sizes does it take? For each item it also names the special
740 command string to be sent to the printer (mostly inside the PostScript
741 file) in order to enable it.
745 Information from these PPDs is meant to be taken into account by the
746 printer drivers. Therefore, installed as part of the Windows
747 PostScript driver for a given printer is the printer's PPD. Where it
748 makes sense, the PPD features are presented in the drivers' UI dialogs
749 to display to the user as choice of print options. In the end, the
750 user selections are somehow written (in the form of special
751 PostScript, PJL, JCL or vendor-dependent commands) into the PostScript
752 file created by the driver.
756 A PostScript file that was created to contain device-specific commands
757 for achieving a certain print job output (e.g. duplexed, stapled and
758 punched) on a specific target machine, may not print as expected, or
759 may not be printable at all on other models; it also may not be fit
760 for further processing by software (e.g. by a PDF distilling program).
765 <title>CUPS can use all Windows-formatted Vendor PPDs</title>
768 CUPS can handle all spec-compliant PPDs as supplied by the
769 manufacturers for their PostScript models. Even if a
770 Unix/Linux-illiterate vendor might not have mentioned our favorite
771 OS in his manuals and brochures -- you can safely trust this:
772 <emphasis>if you get hold of the Windows NT version of the PPD, you
773 can use it unchanged in CUPS</emphasis> and thus access the full
774 power of your printer just like a Windows NT user could!
778 To check the spec compliance of any PPD online, go to <ulink
779 url="http://www.cups.org/testppd.php">http://www.cups.org/testppd.php</ulink>
780 and upload your PPD. You will see the results displayed
781 immediately. CUPS in all versions after 1.1.19 has a much more strict
782 internal PPD parsing and checking code enabled; in case of printing
783 trouble this online resource should be one of your first pitstops.
787 For real PostScript printers <emphasis>don't</emphasis> use the
788 <emphasis>Foomatic</emphasis> or <emphasis>cupsomatic</emphasis>
789 PPDs from Linuxprinting.org. With these devices the original
790 vendor-provided PPDs are always the first choice!
794 If you are looking for an original vendor-provided PPD of a specific
795 device, and you know that an NT4 box (or any other Windows box) on
796 your LAN has the PostScript driver installed, just use
797 <command>smbclient //NT4-box/print\$ -U username</command> to
798 access the Windows directory where all printer driver files are
799 stored. First look in the <filename>W32X86/2</filename> subdir for
800 the PPD you are seeking.
805 <title>CUPS also uses PPDs for non-PostScript Printers</title>
808 CUPS also uses specially crafted PPDs to handle non-PostScript
809 printers. These PPDs are usually not available from the vendors (and
810 no, you can't just take the PPD of a Postscript printer with the same
811 model name and hope it works for the non-PostScript version too). To
812 understand how these PPDs work for non-PS printers we first need to
813 dive deeply into the CUPS filtering and file format conversion
814 architecture. Stay tuned.
820 <title>The CUPS Filtering Architecture</title>
823 The core of the CUPS filtering system is based on
824 <emphasis>Ghostscript</emphasis>. In addition to Ghostscript, CUPS
825 uses some other filters of its own. You (or your OS vendor) may have
826 plugged in even more filters. CUPS handles all data file formats under
827 the label of various <emphasis>MIME types</emphasis>. Every incoming
828 printfile is subjected to an initial
829 <emphasis>auto-typing</emphasis>. The auto-typing determines its given
830 MIME type. A given MIME type implies zero or more possible filtering
831 chains relevant to the selected target printer. This section discusses
832 how MIME types recognition and conversion rules interact. They are
833 used by CUPS to automatically setup a working filtering chain for any
834 given input data format.
838 If CUPS rasterizes a PostScript file <emphasis>natively</emphasis> to
839 a bitmap, this is done in 2 stages:
843 <listitem><para>the first stage uses a Ghostscript device named "cups"
844 (this is since version 1.1.15) and produces a generic raster format
845 called "CUPS raster".
848 <listitem><para>the second stage uses a "raster driver" which converts
849 the generic CUPS raster to a device specific raster.</para></listitem>
853 Make sure your Ghostscript version has the "cups" device compiled in
854 (check with <command>gs -h | grep cups</command>). Otherwise you
855 may encounter the dreaded <computeroutput>Unable to convert file
856 0</computeroutput> in your CUPS error_log file. To have "cups" as a
857 device in your Ghostscript, you either need to <emphasis>patch GNU
858 Ghostscript</emphasis> and re-compile or use <ulink
859 url="http://www.cups.org/ghostscript.php">ESP Ghostscript</ulink>. The
860 superior alternative is ESP Ghostscript: it supports not just CUPS,
861 but 300 other devices too (while GNU Ghostscript supports only about
862 180). Because of this broad output device support, ESP Ghostscript is
863 the first choice for non-CUPS spoolers too. It is now recommended by
864 Linuxprinting.org for all spoolers.
868 CUPS printers may be setup to use <emphasis>external</emphasis>
869 rendering paths. One of the most common ones is provided by the
870 <emphasis>Foomatic/cupsomatic</emphasis> concept, from <ulink
871 url="http://www.linuxprinting.org/">Linuxprinting.org</ulink>. This
872 uses the classical Ghostscript approach, doing everything in one
873 step. It doesn't use the "cups" device, but one of the many
874 others. However, even for Foomatic/cupsomatic usage, best results and
875 broadest printer model support is provided by ESP Ghostscript (more
876 about cupsomatic/Foomatic, particularly the new version called now
877 <emphasis>foomatic-rip</emphasis>, follows below).
881 <title>MIME types and CUPS Filters</title>
884 CUPS reads the file <filename>/etc/cups/mime.types</filename>
885 (and all other files carrying a <filename>*.types</filename> suffix
886 in the same directory) upon startup. These files contain the MIME
887 type recognition rules which are applied when CUPS runs its
888 auto-typing routines. The rule syntax is explained in the man page
889 for <filename>mime.types</filename> and in the comments section of the
890 <filename>mime.types</filename> file itself. A simple rule reads
896 application/pdf pdf string(0,%PDF)
901 This means: if a filename has either a
902 <filename>.pdf</filename> suffix, or if the magic
903 string <emphasis>%PDF</emphasis> is right at the
904 beginning of the file itself (offset 0 from the start), then it is
905 a PDF file (<emphasis>application/pdf</emphasis>).
906 Another rule is this:
911 application/postscript ai eps ps string(0,%!) string(0,<04>%!)
916 Its meaning: if the filename has one of the suffixes
917 <filename>.ai</filename>, <filename>.eps</filename>,
918 <filename>.ps</filename> or if the file itself starts with one of the
919 strings <emphasis>%!</emphasis> or <emphasis><![CDATA[<04>%!]]></emphasis>, it
920 is a generic PostScript file
921 (<emphasis>application/postscript</emphasis>).
925 There is a very important difference between two similar MIME type in
926 CUPS: one is <emphasis>application/postscript</emphasis>, the other is
927 <emphasis>application/vnd.cups-postscript</emphasis>. While
928 <emphasis>application/postscript</emphasis> is meant to be device
929 independent (job options for the file are still outside the PS file
930 content, embedded in commandline or environment variables by CUPS),
931 <emphasis>application/vnd.cups-postscript</emphasis> may have the job
932 options inserted into the PostScript data itself (were
933 applicable). The transformation of the generic PostScript
934 (application/postscript) to the device-specific version
935 (application/vnd.cups-postscript) is the responsibility of the
936 CUPS <emphasis>pstops</emphasis> filter. pstops uses information
937 contained in the PPD to do the transformation.
941 Don't confuse the other mime.types file your system might be using
942 with the one in the <filename>/etc/cups/</filename> directory.
946 CUPS can handle ASCII text, HP-GL, PDF, PostScript, DVI and a
947 lot of image formats (GIF. PNG, TIFF, JPEG, Photo-CD, SUN-Raster,
948 PNM, PBM, SGI-RGB and some more) and their associated MIME types
954 <title>MIME type Conversion Rules</title>
957 CUPS reads the file <filename>/etc/cups/mime.convs</filename>
958 (and all other files named with a <filename>*.convs</filename>
959 suffix in the same directory) upon startup. These files contain
960 lines naming an input MIME type, an output MIME type, a format
961 conversion filter which can produce the output from the input type
962 and virtual costs associated with this conversion. One example line
968 application/pdf application/postscript 33 pdftops
973 This means that the <emphasis>pdftops</emphasis> filter will take
974 <emphasis>application/pdf</emphasis> as input and produce
975 <emphasis>application/postscript</emphasis> as output, the virtual
976 cost of this operation is 33 CUPS-$. The next filter is more
977 expensive, costing 66 CUPS-$:
982 application/vnd.hp-HPGL application/postscript 66 hpgltops
987 This is the <emphasis>hpgltops</emphasis>, which processes HP-GL
988 plotter files to PostScript.
993 application/octet-stream
998 Here are two more examples:
1003 application/x-shell application/postscript 33 texttops
1004 text/plain application/postscript 33 texttops
1009 The last two examples name the <emphasis>texttops</emphasis> filter
1010 to work on "text/plain" as well as on "application/x-shell". (Hint:
1011 this differentiation is needed for the syntax highlighting feature of
1017 <title>Filter Requirements</title>
1020 There are many more combinations named in mime.convs. However, you
1021 are not limited to use the ones pre-defined there. You can plug in any
1022 filter you like into the CUPS framework. It must meet, or must be made
1023 to meet some minimal requirements. If you find (or write) a cool
1024 conversion filter of some kind, make sure it complies to what CUPS
1025 needs, and put in the right lines in <filename>mime.types</filename>
1026 and <filename>mime.convs</filename>, then it will work seamlessly
1031 The mentioned "CUPS requirements" for filters are simple. Take
1032 filenames or <filename>stdin</filename> as input and write to
1033 <filename>stdout</filename>. They should take these 5 or 6 arguments:
1034 <emphasis>printer job user title copies options [filename]</emphasis>
1038 <varlistentry><term>Printer</term>
1039 <listitem><para>The name of the printer queue (normally this is the
1040 name of the filter being run)</para></listitem>
1043 <varlistentry><term>job</term>
1044 <listitem><para>The numeric job ID for the job being
1045 printed</para></listitem>
1048 <varlistentry><term>Printer</term>
1049 <listitem><para>The string from the originating-user-name
1050 attribute</para></listitem>
1053 <varlistentry><term>Printer</term>
1054 <listitem><para>The string from the job-name attribute</para></listitem>
1057 <varlistentry><term>Printer</term>
1058 <listitem><para>The numeric value from the number-copies
1059 attribute</para></listitem>
1062 <varlistentry><term>Printer</term>
1063 <listitem><para>The job options</para></listitem>
1066 <varlistentry><term>Printer</term>
1067 <listitem><para>(Optionally) The print request file (if missing,
1068 filters expected data fed through <filename>stdin</filename>). In most
1069 cases it is very easy to write a simple wrapper script around existing
1070 filters to make them work with CUPS.</para></listitem>
1077 <title>Prefilters</title>
1080 As was said, PostScript is the central file format to any Unix based
1081 printing system. From PostScript, CUPS generates raster data to feed
1082 non-PostScript printers.
1086 But what is happening if you send one of the supported non-PS formats
1087 to print? Then CUPS runs "pre-filters" on these input formats to
1088 generate PostScript first. There are pre-filters to create PS from
1089 ASCII text, PDF, DVI or HP-GL. The outcome of these filters is always
1090 of MIME type <emphasis>application/postscript</emphasis> (meaning that
1091 any device-specific print options are not yet embedded into the
1092 PostScript by CUPS, and that the next filter to be called is
1093 pstops). Another pre-filter is running on all supported image formats,
1094 the <emphasis>imagetops</emphasis> filter. Its outcome is always of
1095 MIME type <emphasis>application/vnd.cups-postscript</emphasis>
1096 (<emphasis>not</emphasis> application/postscript), meaning it has the
1097 print options already embedded into the file.
1101 <figure><title>Prefiltering in CUPS to form Postscript</title>
1103 <imageobject role="latex"><imagedata fileref="projdoc/imagefiles/4small"/></imageobject>
1104 <imageobject><imagedata fileref="projdoc/imagefiles/4small.png"/></imageobject>
1111 <title>pstops</title>
1114 <emphasis>pstops</emphasis>is the filter to convert
1115 <emphasis>application/postscript</emphasis> to
1116 <emphasis>application/vnd.cups-postscript</emphasis>. It was said
1117 above that this filter inserts all device-specific print options
1118 (commands to the printer to ask for the duplexing of output, or
1119 stapling an punching it, etc.) into the PostScript file.
1123 <figure><title>Adding Device-specific Print Options</title>
1125 <imageobject role="latex"><imagedata fileref="projdoc/imagefiles/5small"/></imageobject>
1126 <imageobject><imagedata fileref="projdoc/imagefiles/5small.png"/></imageobject>
1132 This is not all: other tasks performed by it are:
1137 selecting the range of pages to be printed (if you choose to
1138 print only pages "3, 6, 8-11, 16, 19-21", or only the odd numbered
1143 putting 2 or more logical pages on one sheet of paper (the
1144 so-called "number-up" function)
1147 <listitem><para>counting the pages of the job to insert the accounting
1148 information into the <filename>/var/log/cups/page_log</filename>
1154 <title>pstoraster</title>
1157 <emphasis>pstoraster</emphasis> is at the core of the CUPS filtering
1158 system. It is responsible for the first stage of the rasterization
1159 process. Its input is of MIME type application/vnd.cups-postscript;
1160 its output is application/vnd.cups-raster. This output format is not
1161 yet meant to be printable. Its aim is to serve as a general purpose
1162 input format for more specialized <emphasis>raster drivers</emphasis>,
1163 that are able to generate device-specific printer data.
1167 <figure><title>Postscript to intermediate Raster format</title>
1169 <imageobject role="latex"><imagedata fileref="projdoc/imagefiles/6small"/></imageobject>
1170 <imageobject><imagedata fileref="projdoc/imagefiles/6small.png"/></imageobject>
1176 CUPS raster is a generic raster format with powerful features. It is
1177 able to include per-page information, color profiles and more to be
1178 used by the following downstream raster drivers. Its MIME type is
1179 registered with IANA and its specification is of course completely
1180 open. It is designed to make it very easy and inexpensive for
1181 manufacturers to develop Linux and Unix raster drivers for their
1182 printer models, should they choose to do so. CUPS always takes care
1183 for the first stage of rasterization so these vendors don't need to care
1184 about Ghostscript complications (in fact, there is currently more
1185 than one vendor financing the development of CUPS raster drivers).
1189 <figure><title>CUPS-raster production using Ghostscript</title>
1191 <imageobject role="latex"><imagedata fileref="projdoc/imagefiles/7small"/></imageobject>
1192 <imageobject><imagedata fileref="projdoc/imagefiles/7small.png"/></imageobject>
1198 CUPS versions before version 1.1.15 were shipping a binary (or source
1199 code) standalone filter, named "pstoraster". pstoraster was derived
1200 from GNU Ghostscript 5.50, and could be installed besides and in
1201 addition to any GNU or AFPL Ghostscript package without conflicting.
1205 From version 1.1.15, this has changed. The functions for this has been
1206 integrated back into Ghostscript (now based on GNU Ghostscript version
1207 7.05). The "pstoraster" filter is now a simple shell script calling
1208 <command>gs</command> with the <command>-sDEVICE=cups</command>
1209 parameter. If your Ghostscript doesn't show a success on asking for
1210 <command>gs -h |grep cups</command>, you might not be able to
1211 print. Update your Ghostscript then!
1216 <title>imagetops and imagetoraster</title>
1219 Above in the section about prefilters, we mentioned the prefilter
1220 that generates PostScript from image formats. The imagetoraster
1221 filter is used to convert directly from image to raster, without the
1222 intermediate PostScript stage. It is used more often than the above
1223 mentioned prefilters. Here is a summarizing flowchart of image file
1228 <figure><title>Image format to CUPS-raster format conversion</title>
1230 <imageobject role="latex"><imagedata fileref="projdoc/imagefiles/8small"/></imageobject>
1231 <imageobject><imagedata fileref="projdoc/imagefiles/8small.png"/></imageobject>
1239 <title>rasterto [printerspecific]</title>
1242 CUPS ships with quite some different raster drivers processing CUPS
1243 raster. On my system I find in /usr/lib/cups/filter/ these:
1244 <parameter>rastertoalps, rastertobj, rastertoepson, rastertoescp,
1245 rastertopcl, rastertoturboprint, rastertoapdk, rastertodymo,
1246 rastertoescp, rastertohp</parameter> and
1247 <parameter>rastertoprinter</parameter>. Don't worry if you have less
1248 than this; some of these are installed by commercial add-ons to CUPS
1249 (like <parameter>rastertoturboprint</parameter>), others (like
1250 <parameter>rastertoprinter</parameter>) by 3rd party driver
1251 development projects (such as Gimp-Print) wanting to cooperate as
1252 closely as possible with CUPS.
1256 <figure><title>Raster to Printer Specific formats</title>
1258 <imageobject role="latex"><imagedata fileref="projdoc/imagefiles/9small"/></imageobject>
1259 <imageobject><imagedata fileref="projdoc/imagefiles/9small.png"/></imageobject>
1266 <title>CUPS Backends</title>
1269 The last part of any CUPS filtering chain is a "backend". Backends
1270 are special programs that send the print-ready file to the final
1271 device. There is a separate backend program for any transfer
1272 "protocol" of sending printjobs over the network, or for every local
1273 interface. Every CUPS printqueue needs to have a CUPS "device-URI"
1274 associated with it. The device URI is the way to encode the backend
1275 used to send the job to its destination. Network device-URIs are using
1276 two slashes in their syntax, local device URIs only one, as you can
1277 see from the following list. Keep in mind that local interface names
1278 may vary much from my examples, if your OS is not Linux:
1282 <varlistentry><term>usb</term>
1284 This backend sends printfiles to USB-connected printers. An
1285 example for the CUPS device-URI to use is:
1286 <filename>usb:/dev/usb/lp0</filename>
1287 </para></listitem></varlistentry>
1289 <varlistentry><term>serial</term>
1291 This backend sends printfiles to serially connected printers.
1292 An example for the CUPS device-URI to use is:
1293 <filename>serial:/dev/ttyS0?baud=11500</filename>
1294 </para></listitem></varlistentry>
1296 <varlistentry><term>parallel</term>
1298 This backend sends printfiles to printers connected to the
1299 parallel port. An example for the CUPS device-URI to use is:
1300 <filename>parallel:/dev/lp0</filename>
1301 </para></listitem></varlistentry>
1303 <varlistentry><term>scsi</term>
1305 This backend sends printfiles to printers attached to the
1306 SCSI interface. An example for the CUPS device-URI to use is:
1307 <filename>scsi:/dev/sr1</filename>
1308 </para></listitem></varlistentry>
1310 <varlistentry><term>lpd</term>
1312 This backend sends printfiles to LPR/LPD connected network
1313 printers. An example for the CUPS device-URI to use is:
1314 <filename>lpd://remote_host_name/remote_queue_name</filename>
1315 </para></listitem></varlistentry>
1317 <varlistentry><term>AppSocket/HP JetDirect</term>
1319 This backend sends printfiles to AppSocket (a.k.a. "HP
1320 JetDirect") connected network printers. An example for the CUPS
1321 device-URI to use is:
1322 <filename>socket://10.11.12.13:9100</filename>
1323 </para></listitem></varlistentry>
1325 <varlistentry><term>ipp</term>
1327 This backend sends printfiles to IPP connected network
1328 printers (or to other CUPS servers). Examples for CUPS device-URIs
1330 <filename>ipp:://192.193.194.195/ipp</filename>
1331 (for many HP printers) or
1332 <filename>ipp://remote_cups_server/printers/remote_printer_name</filename>
1333 </para></listitem></varlistentry>
1335 <varlistentry><term>http</term>
1337 This backend sends printfiles to HTTP connected printers.
1338 (The http:// CUPS backend is only a symlink to the ipp:// backend.)
1339 Examples for the CUPS device-URIs to use are:
1340 <filename>http:://192.193.194.195:631/ipp</filename>
1341 (for many HP printers) or
1342 <filename>http://remote_cups_server:631/printers/remote_printer_name</filename>
1343 </para></listitem></varlistentry>
1345 <varlistentry><term>smb</term>
1347 This backend sends printfiles to printers shared by a Windows
1348 host. An example for CUPS device-URIs to use are:
1349 <filename>smb://workgroup/server/printersharename</filename>
1351 <filename>Smb://server/printersharename</filename>
1353 <filename>smb://username:password@workgroup/server/printersharename</filename>
1355 <filename>smb://username:password@server/printersharename</filename>.
1356 The smb:// backend is a symlink to the Samba utility
1357 <emphasis>smbspool</emphasis> (doesn't ship with CUPS). If the
1358 symlink is not present in your CUPS backend directory, have your
1359 root user create it: <command>ln -s `which smbspool`
1360 /usr/lib/cups/backend/smb</command>.
1361 </para></listitem></varlistentry>
1365 It is easy to write your own backends as Shell or Perl scripts, if you
1366 need any modification or extension to the CUPS print system. One
1367 reason could be that you want to create "special" printers which send
1368 the printjobs as email (through a "mailto:/" backend), convert them to
1369 PDF (through a "pdfgen:/" backend) or dump them to "/dev/null" (In
1370 fact I have the system-wide default printer set up to be connected to
1371 a "devnull:/" backend: there are just too many people sending jobs
1372 without specifying a printer, or scripts and programs which don't name
1373 a printer. The system-wided default deletes the job and sends a polite
1374 mail back to the $USER asking him to alsways specify a correct
1379 Not all of the mentioned backends may be present on your system or
1380 usable (depending on your hardware configuration). One test for all
1381 available CUPS backends is provided by the <emphasis>lpinfo</emphasis>
1382 utility. Used with the <parameter>-v</parameter> parameter, it lists
1383 all available backends:
1394 <title>cupsomatic/Foomatic -- how do they fit into the Picture?</title>
1397 "cupsomatic" filters may be the most widely used on CUPS
1398 installations. You must be clear about the fact that these were not
1399 developed by the CUPS people. They are a "Third Party" add-on to
1400 CUPS. They utilize the traditional Ghostscript devices to render jobs
1401 for CUPS. When troubleshooting, you should know about the
1402 difference. Here the whole rendering process is done in one stage,
1403 inside Ghostscript, using an appropriate "device" for the target
1404 printer. cupsomatic uses PPDs which are generated from the "Foomatic"
1405 Printer & Driver Database at Linuxprinting.org.
1409 You can recognize these PPDs from the line calling the
1410 <emphasis>cupsomatic</emphasis> filter:
1415 *cupsFilter: "application/vnd.cups-postscript 0 cupsomatic"
1420 This line you may find amongst the first 40 or so lines of the PPD
1421 file. If you have such a PPD installed, the printer shows up in the
1422 CUPS web interface with a <emphasis>foomatic</emphasis> namepart for
1423 the driver description. cupsomatic is a Perlscript that runs
1424 Ghostscript, with all the complicated commandline options
1425 auto-constructed from the selected PPD and commandline options give to
1430 However, cupsomatic is now deprecated. Its PPDs (especially the first
1431 generation of them, still in heavy use out there) are not meeting the
1432 Adobe specifications. You might also suffer difficulties when you try
1433 to download them with "Point'n'Print" to Windows clients. A better,
1434 and more powerful successor is now in a very stable Beta-version
1435 available: it is called <emphasis>foomatic-rip</emphasis>. To use
1436 foomatic-rip as a filter with CUPS, you need the new-type PPDs. These
1437 have a similar, but different line:
1442 *cupsFilter: "application/vnd.cups-postscript 0 foomatic-rip"
1447 The PPD generating engine at Linuxprinting.org has been revamped.
1448 The new PPDs comply to the Adobe spec. On top, they also provide a
1449 new way to specify different quality levels (hi-res photo, normal
1450 color, grayscale, draft...) with a single click (whereas before you
1451 could have required 5 or more different selections (media type,
1452 resolution, inktype, dithering algorithm...). There is support for
1453 custom-size media built in. There is support to switch
1454 print-options from page to page, in the middle of a job. And the
1455 best thing is: the new foomatic-rip now works seamlessly with all
1456 legacy spoolers too (like LPRng, BSD-LPD, PDQ, PPR etc.), providing
1457 for them access to use PPDs for their printing!
1462 <title>The Complete Picture</title>
1465 If you want to see an overview over all the filters and how they
1466 relate to each other, the complete picture of the puzzle is at the end
1472 <title><filename>mime.convs</filename></title>
1475 CUPS auto-constructs all possible filtering chain paths for any given
1476 MIME type, and every printer installed. But how does it decide in
1477 favor or against a specific alternative? (There may often be cases,
1478 where there is a choice of two or more possible filtering chains for
1479 the same target printer). Simple: you may have noticed the figures in
1480 the 3rd column of the mime.convs file. They represent virtual costs
1481 assigned to this filter. Every possible filtering chain will sum up to
1482 a total "filter cost". CUPS decides for the most "inexpensive" route.
1486 The setting of <parameter>FilterLimit 1000</parameter> in
1487 <filename>cupsd.conf</filename> will not allow more filters to
1488 run concurrently than will consume a total of 1000 virtual filter
1489 cost. This is a very efficient way to limit the load of any CUPS
1490 server by setting an appropriate "FilterLimit" value. A FilterLimit of
1491 200 allows roughly 1 job at a time, while a FilterLimit of 1000 allows
1492 approximately 5 jobs maximum at a time.
1497 <title>"Raw" printing</title>
1500 You can tell CUPS to print (nearly) any file "raw". "Raw" means it
1501 will not be filtered. CUPS will send the file to the printer "as is"
1502 without bothering if the printer is able to digest it. Users need to
1503 take care themselves that they send sensible data formats only. Raw
1504 printing can happen on any queue if the "-o raw" option is specified
1505 on the command line. You can also set up raw-only queues by simply not
1506 associating any PPD with it. This command:
1511 lpadmin -P rawprinter -v socket://11.12.13.14:9100 -E
1516 sets up a queue named "rawprinter", connected via the "socket"
1517 protocol (a.k.a. "HP JetDirect") to the device at IP address
1518 11.12.1.3.14, using port 9100. (If you had added a PPD with
1519 <command>-P /path/to/PPD</command> to this command line, you would
1520 have installed a "normal" printqueue.
1524 CUPS will automatically treat each job sent to a queue as a "raw" one,
1525 if it can't find a PPD associated with the queue. However, CUPS will
1526 only send known MIME types (as defined in its own mime.types file) and
1532 <title>"application/octet-stream" printing</title>
1535 Any MIME type with no rule in the
1536 <filename>/etc/cups/mime.types</filename> file is regarded as unknown
1537 or <emphasis>application/octet-stream</emphasis> and will not be
1538 sent. Because CUPS refuses to print unknown MIME types per default,
1539 you will probably have experienced the fact that printjobs originating
1540 from Windows clients were not printed. You may have found an error
1541 message in your CUPS logs like:
1546 Unable to convert file 0 to printable format for job
1551 To enable the printing of "application/octet-stream" files, edit
1556 <listitem><para><filename>/etc/cups/mime.convs</filename></para></listitem>
1558 <listitem><para><filename>/etc/cups/mime.types</filename></para></listitem>
1562 Both contain entries (at the end of the respective files) which must
1563 be uncommented to allow RAW mode operation for
1564 application/octet-stream. In <filename>/etc/cups/mime.types</filename>
1565 make sure this line is present:
1570 application/octet-stream
1575 This line (with no specific auto-typing rule set) makes all files
1576 not otherwise auto-typed a member of application/octet-stream. In
1577 <filename>/etc/cups/mime.convs</filename>, have this
1583 application/octet-stream application/vnd.cups-raw 0 -
1588 This line tells CUPS to use the <emphasis>Null Filter</emphasis>
1589 (denoted as "-", doing... nothing at all) on
1590 <emphasis>application/octet-stream</emphasis>, and tag the result as
1591 <emphasis>application/vnd.cups-raw</emphasis>. This last one is
1592 always a green light to the CUPS scheduler to now hand the file over
1593 to the "backend" connecting to the printer and sending it over.
1596 <note><para> Editing the <filename>mime.convs</filename> and the
1597 <filename>mime.types</filename> file does not
1598 <emphasis>enforce</emphasis> "raw" printing, it only
1599 <emphasis>allows</emphasis> it.
1603 <title>Background</title>
1606 CUPS being a more security-aware printing system than traditional ones
1607 does not by default allow one to send deliberate (possibly binary)
1608 data to printing devices. (This could be easily abused to launch a
1609 Denial of Service attack on your printer(s), causing at least the loss
1610 of a lot of paper and ink...) "Unknown" data are regarded by CUPS
1611 as<emphasis>MIME type</emphasis>
1612 <emphasis>application/octet-stream</emphasis>. While you
1613 <emphasis>can</emphasis> send data "raw", the MIME type for these must
1614 be one that is known to CUPS and an allowed one. The file
1615 <filename>/etc/cups/mime.types</filename> defines the "rules" how CUPS
1616 recognizes MIME types. The file
1617 <filename>/etc/cups/mime.convs</filename> decides which file
1618 conversion filter(s) may be applied to which MIME types.
1624 <title>PostScript Printer Descriptions (PPDs) for non-PS Printers</title>
1627 Originally PPDs were meant to be used for PostScript printers
1628 only. Here, they help to send device-specific commands and settings
1629 to the RIP which processes the jobfile. CUPS has extended this
1630 scope for PPDs to cover non-PostScript printers too. This was not
1631 very difficult, because it is a standardized file format. In a way
1632 it was logical too: CUPS handles PostScript and uses a PostScript
1633 RIP (=Ghostscript) to process the jobfiles. The only difference is:
1634 a PostScript printer has the RIP built-in, for other types of
1635 printers the Ghostscript RIP runs on the host computer.
1639 PPDs for a non-PS printer have a few lines that are unique to
1640 CUPS. The most important one looks similar to this:
1645 *cupsFilter: application/vnd.cups-raster 66 rastertoprinter
1650 It is the last piece in the CUPS filtering puzzle. This line tells the
1651 CUPS daemon to use as a last filter "rastertoprinter". This filter
1652 should be served as input an "application/vnd.cups-raster" MIME type
1653 file. Therefore CUPS should auto-construct a filtering chain, which
1654 delivers as its last output the specified MIME type. This is then
1655 taken as input to the specified "rastertoprinter" filter. After this
1656 the last filter has done its work ("rastertoprinter" is a Gimp-Print
1657 filter), the file should go to the backend, which sends it to the
1662 CUPS by default ships only a few generic PPDs, but they are good for
1663 several hundred printer models. You may not be able to control
1664 different paper trays, or you may get larger margins than your
1665 specific model supports):
1669 <varlistentry><term>deskjet.ppd</term>
1670 <listitem><para>older HP inkjet printers and compatible
1674 <varlistentry><term>deskjet2.ppd</term>
1675 <listitem><para>newer HP inkjet printers and compatible
1679 <varlistentry><term>dymo.ppd</term>
1680 <listitem><para>label printers
1684 <varlistentry><term>epson9.ppd</term>
1685 <listitem><para>Epson 24pin impact printers and compatible
1689 <varlistentry><term>epson24.ppd</term>
1690 <listitem><para>Epson 24pin impact printers and compatible
1694 <varlistentry><term>okidata9.ppd</term>
1695 <listitem><para>Okidata 9pin impact printers and compatible
1699 <varlistentry><term>okidat24.ppd</term>
1700 <listitem><para>Okidata 24pin impact printers and compatible
1704 <varlistentry><term>stcolor.ppd</term>
1705 <listitem><para>older Epson Stylus Color printers
1709 <varlistentry><term>stcolor2.ppd</term>
1710 <listitem><para>newer Epson Stylus Color printers
1714 <varlistentry><term>stphoto.ppd</term>
1715 <listitem><para>older Epson Stylus Photo printers
1719 <varlistentry><term>stphoto2.ppd</term>
1720 <listitem><para>newer Epson Stylus Photo printers
1724 <varlistentry><term>laserjet.ppd</term>
1725 <listitem><para>all PCL printersFurther below is a discussion
1726 of several other driver/PPD-packages suitable fur use with CUPS.
1733 <title>Difference between <emphasis>cupsomatic/foomatic-rip</emphasis> and
1734 <emphasis>native CUPS</emphasis> printing</title>
1737 Native CUPS rasterization works in two steps.
1742 First is the "pstoraster" step. It uses the special "cups"
1743 device from ESP Ghostscript 7.05.x as its tool
1747 Second comes the "rasterdriver" step. It uses various
1748 device-specific filters; there are several vendors who provide good
1749 quality filters for this step, some are Free Software, some are
1750 Shareware/Non-Free, some are proprietary.</para></listitem>
1754 Often this produces better quality (and has several more
1755 advantages) than other methods.
1759 <figure><title>cupsomatic/foomatic processing versus Native CUPS</title>
1761 <imageobject role="latex"><imagedata fileref="projdoc/imagefiles/10small"/></imageobject>
1762 <imageobject><imagedata fileref="projdoc/imagefiles/10small.png"/></imageobject>
1768 One other method is the <emphasis>cupsomatic/foomatic-rip</emphasis>
1769 way. Note that cupsomatic is <emphasis>not</emphasis> made by the CUPS
1770 developers. It is an independent contribution to printing development,
1771 made by people from Linuxprinting.org (see also <ulink
1772 url="http://www.cups.org/cups-help.html">http://www.cups.org/cups-help.html</ulink>).
1773 cupsomatic is no longer developed and maintained and is no longer
1774 supported. It has now been replaced by
1775 <emphasis>foomatic-rip</emphasis>. foomatic-rip is a complete re-write
1776 of the old cupsomatic idea, but very much improved and generalized to
1777 other (non-CUPS) spoolers. An upgrade to foomatic-rip is strongly
1778 adviced, especially if you are upgrading to a recent version of CUPS
1783 Both the cupsomatic (old) and the foomatic-rip (new) methods from
1784 Linuxprinting.org use the traditional Ghostscript print file
1785 processing, doing everything in a single step. It therefore relies on
1786 all the other devices built-in into Ghostscript. The quality is as
1787 good (or bad) as Ghostscript rendering is in other spoolers. The
1788 advantage is that this method supports many printer models not
1789 supported (yet) by the more modern CUPS method.
1793 Of course, you can use both methods side by side on one system (and
1794 even for one printer, if you set up different queues), and find out
1795 which works best for you.
1799 cupsomatic "kidnaps" the printfile after the
1800 <emphasis>application/vnd.cups-postscript</emphasis> stage and
1801 deviates it through the CUPS-external, systemwide Ghostscript
1802 installation: Therefore the printfile bypasses the "pstoraster" filter
1803 (and thus also bypasses the CUPS-raster-drivers
1804 "rastertosomething"). After Ghostscript finished its rasterization,
1805 cupsomatic hands the rendered file directly to the CUPS backend. The
1806 flowchart above illustrates the difference between native CUPS
1807 rendering and the Foomatic/cupsomatic method.
1812 <title>Examples for filtering Chains</title>
1815 Here are a few examples of commonly occurring filtering chains to
1816 illustrate the workings of CUPS.
1820 Assume you want to print a PDF file to a HP JetDirect-connected
1821 PostScript printer, but you want to print the pages 3-5, 7, 11-13
1822 only, and you want to print them "2-up" and "duplex":
1826 <listitem><para>your print options (page selection as required, 2-up,
1827 duplex) are passed to CUPS on the commandline;</para></listitem>
1829 <listitem><para>the (complete) PDF file is sent to CUPS and autotyped as
1830 <emphasis>application/pdf</emphasis>;</para></listitem>
1832 <listitem><para>the file therefore first must pass the
1833 <emphasis>pdftops</emphasis> pre-filter, which produces PostScript
1834 MIME type <emphasis>application/postscript</emphasis> (a preview here
1835 would still show all pages of the original PDF);</para></listitem>
1837 <listitem><para>the file then passes the <emphasis>pstops</emphasis>
1838 filter which applies the commandline options: it selects the pages
1839 2-5, 7 and 11-13, creates and imposed layout "2 pages on 1 sheet" and
1840 inserts the correct "duplex" command (as is defined in the printer's
1841 PPD) into the new PostScript file; the file now is of PostScript MIME
1843 <emphasis>application/vnd.cups-postscript</emphasis>;</para></listitem>
1845 <listitem><para>the file goes to the <emphasis>socket</emphasis>
1846 backend, which transfers the job to the printers.</para></listitem>
1850 The resulting filter chain therefore is:
1854 pdftops --> pstops --> socket
1858 Assume your want to print the same filter to an USB-connected
1859 Epson Stylus Photo printer, installed with the CUPS
1860 <filename>stphoto2.ppd</filename>. The first few filtering stages
1861 are nearly the same:
1865 <listitem><para>your print options (page selection as required, 2-up,
1866 duplex) are passed to CUPS on the commandline;</para></listitem>
1868 <listitem><para>the (complete) PDF file is sent to CUPS and autotyped as
1869 <emphasis>application/pdf</emphasis>;</para></listitem>
1871 <listitem><para>the file therefore first must pass the
1872 <emphasis>pdftops</emphasis> pre-filter, which produces PostScript
1873 MIME type <emphasis>application/postscript</emphasis> (a preview here
1874 would still show all pages of the original PDF);</para></listitem>
1876 <listitem><para>the file then passes the "pstops" filter which applies
1877 the commandline options: it selects the pages 2-5, 7 and 11-13,
1878 creates and imposed layout "2 pages on 1 sheet" and inserts the
1879 correct "duplex" command... (OOoops -- this printer and his PPD
1880 don't support duplex printing at all -- this option will be ignored
1881 then) into the new PostScript file; the file now is of PostScript
1883 <emphasis>application/vnd.cups-postscript</emphasis>;</para></listitem>
1885 <listitem><para>the file then passes the
1886 <emphasis>pstoraster</emphasis> stage and becomes MIME type
1887 <emphasis>application/cups-raster</emphasis>;</para></listitem>
1889 <listitem><para>finally, the <emphasis>rastertoepson</emphasis> filter
1890 does its work (as is indicated in the printer's PPD), creating the
1891 printer-specific raster data and embedding any user-selected
1892 print-options into the print data stream;</para></listitem>
1894 <listitem><para>the file goes to the <emphasis>usb</emphasis> backend,
1895 which transfers the job to the printers.</para></listitem>
1899 The resulting filter chain therefore is:
1903 pdftops --> pstops --> pstoraster --> rastertoepson --> usb
1908 <title>Sources of CUPS drivers / PPDs</title>
1911 On the internet you can find now many thousand CUPS-PPD files
1912 (with their companion filters), in many national languages,
1913 supporting more than 1000 non-PostScript models.
1917 <listitem><para><ulink url="http://wwwl.easysw.com/printpro/">ESP
1918 PrintPro (http://wwwl.easysw.com/printpro/)</ulink> (commercial,
1919 non-Free) is packaged with more than 3000 PPDs, ready for
1920 successful use "out of the box" on Linux, Mac OS X, IBM-AIX,
1921 HP-UX, Sun-Solaris, SGI-IRIX, Compaq Tru64, Digital Unix and some
1922 more commercial Unices (it is written by the CUPS developers
1923 themselves and its sales help finance the further development of
1924 CUPS, as they feed their creators).</para></listitem>
1926 <listitem><para>the <ulink
1927 url="http://gimp-print.sourceforge.net/">Gimp-Print-Project
1928 (http://gimp-print.sourceforge.net/)</ulink> (GPL, Free Software)
1929 provides around 140 PPDs (supporting nearly 400 printers, many driven
1930 to photo quality output), to be used alongside the Gimp-Print CUPS
1931 filters;</para></listitem>
1933 <listitem><para><ulink url="http://www.turboprint.com/">TurboPrint
1934 (http://www.turboprint.com/)</ulink> (Shareware, non-Free) supports
1935 roughly the same amount of printers in excellent
1936 quality;</para></listitem>
1938 <listitem><para><ulink
1939 url="http://www-124.ibm.com/developerworks/oss/linux/projects/omni/">OMNI
1940 (http://www-124.ibm.com/developerworks/oss/linux/projects/omni/)</ulink>
1941 (LPGL, Free) is a package made by IBM, now containing support for more
1942 than 400 printers, stemming from the inheritance of IBM OS/2 KnowHow
1943 ported over to Linux (CUPS support is in a Beta-stage at
1944 present);</para></listitem>
1946 <listitem><para><ulink url="http://hpinkjet.sourceforge.net/">HPIJS
1947 (http://hpinkjet.sourceforge.net/)</ulink> (BSD-style licenses, Free)
1948 supports around 150 of HP's own printers and is also providing
1949 excellent print quality now (currently available only via the Foomatic
1950 path);</para></listitem>
1952 <listitem><para><ulink
1953 url="http://www.linuxprinting.org/">Foomatic/cupsomatic
1954 (http://www.linuxprinting.org/)</ulink> (LPGL, Free) from
1955 Linuxprinting.org are providing PPDs for practically every Ghostscript
1956 filter known to the world (including Omni, Gimp-Print and
1957 HPIJS).</para></listitem>
1961 The cupsomatic/Foomatic trick from Linuxprinting.org works
1962 differently from the other drivers. This is explained elsewhere in this
1968 <title>Printing with Interface Scripts</title>
1971 CUPS also supports the usage of "interface scripts" as known from
1972 System V AT&T printing systems. These are often used for PCL
1973 printers, from applications that generate PCL print jobs. Interface
1974 scripts are specific to printer models. They have a similar role as
1975 PPDs for PostScript printers. Interface scripts may inject the Escape
1976 sequences as required into the print data stream, if the user has
1977 chosen to select a certain paper tray, or print landscape, or use A3
1978 paper, etc. Interfaces scripts are practically unknown in the Linux
1979 realm. On HP-UX platforms they are more often used. You can use any
1980 working interface script on CUPS too. Just install the printer with
1981 the <command>-i</command> option:
1986 lpadmin -p pclprinter -v socket://11.12.13.14:9100 -i /path/to/interface-script
1991 Interface scripts might be the "unknown animal" to many. However,
1992 with CUPS they provide the most easy way to plug in your own
1993 custom-written filtering script or program into one specific print
1994 queue (some information about the traditional usage of interface scripts is
1995 to be found at <ulink
1996 url="http://playground.sun.com/printing/documentation/interface.html">http://playground.sun.com/printing/documentation/interface.html</ulink>).
2002 <title>Network printing (purely Windows)</title>
2005 Network printing covers a lot of ground. To understand what exactly
2006 goes on with Samba when it is printing on behalf of its Windows
2007 clients, let's first look at a "purely Windows" setup: Windows clients
2008 with a Windows NT print server.
2012 <title>From Windows Clients to an NT Print Server</title>
2015 Windows clients printing to an NT-based print server have two
2020 <listitem><para>execute the driver locally and render the GDI output
2021 (EMF) into the printer specific format on their own,
2022 or</para></listitem>
2024 <listitem><para>send the GDI output (EMF) to the server, where the
2025 driver is executed to render the printer specific
2026 output.</para></listitem>
2030 Both print paths are shown in the flowcharts below.
2035 <title>Driver Execution on the Client</title>
2038 In the first case the print server must spool the file as "raw",
2039 meaning it shouldn't touch the jobfile and try to convert it in any
2040 way. This is what traditional Unix-based print server can do too; and
2041 at a better performance and more reliably than NT print server. This
2042 is what most Samba administrators probably are familiar with. One
2043 advantage of this setup is that this "spooling-only" print server may
2044 be used even if no driver(s) for Unix are available it is sufficient
2045 to have the Windows client drivers available and installed on the
2050 <figure><title>Print Driver execution on the Client</title>
2052 <imageobject role="latex"><imagedata fileref="projdoc/imagefiles/11small"/></imageobject>
2053 <imageobject><imagedata fileref="projdoc/imagefiles/11small.png"/></imageobject>
2060 <title>Driver Execution on the Server</title>
2063 The other path executes the printer driver on the server. The clients
2064 transfers print files in EMF format to the server. The server uses the
2065 PostScript, PCL, ESC/P or other driver to convert the EMF file into
2066 the printer-specific language. It is not possible for Unix to do the
2067 same. Currently there is no program or method to convert a Windows
2068 client's GDI output on a Unix server into something a printer could
2073 <figure><title>Print Driver execution on the Server</title>
2075 <imageobject role="latex"><imagedata fileref="projdoc/imagefiles/12small"/></imageobject>
2076 <imageobject><imagedata fileref="projdoc/imagefiles/12small.png"/></imageobject>
2082 However, there is something similar possible with CUPS. Read on...
2088 <title>Network Printing (Windows clients -- UNIX/Samba Print
2092 Since UNIX print servers <emphasis>cannot</emphasis> execute the Win32
2093 program code on their platform, the picture is somewhat
2094 different. However, this doesn't limit your options all that
2095 much. In the contrary, you may have a way here to implement printing
2096 features which are not possible otherwise.
2100 <title>From Windows Clients to a CUPS/Samba Print Server</title>
2103 Here is a simple recipe showing how you can take advantage of CUPS
2104 powerful features for the benefit of your Windows network printing
2110 <listitem><para>Let the Windows clients send PostScript to the CUPS
2111 server.</para></listitem>
2113 <listitem><para>Let the CUPS server render the PostScript into device
2114 specific raster format.</para></listitem>
2118 This requires the clients to use a PostScript driver (even if the
2119 printer is a non-PostScript model. It also requires that you have a
2120 "driver" on the CUPS server.
2124 Firstly, to enable CUPS based printing through Samba the
2125 following options should be set in your <filename>smb.conf</filename> file [globals]
2130 <listitem><para><parameter>printing = CUPS</parameter></para></listitem>
2132 <listitem><para><parameter>printcap = CUPS</parameter></para></listitem>
2136 When these parameters are specified, all manually set print directives
2137 (like <parameter>print command =...</parameter>, or <parameter>lppause
2138 command =...</parameter>) in <filename>smb.conf</filename> (as well as
2139 in samba itself) will be ignored. Instead, Samba will directly
2140 interface with CUPS through it's application program interface (API) -
2141 as long as Samba has been compiled with CUPS library (libcups)
2142 support. If Samba has NOT been compiled with CUPS support, and if no
2143 other print commands are set up, then printing will use the
2144 <emphasis>System V</emphasis> AT&T command set, with the -oraw
2145 option automatically passing through (if you want your own defined
2146 print commands to work with a Samba that has CUPS support compiled in,
2147 simply use <parameter>printing = sysv</parameter>).
2151 <figure><title>Printing via CUPS/samba server</title>
2153 <imageobject role="latex"><imagedata fileref="projdoc/imagefiles/13small"/></imageobject>
2154 <imageobject><imagedata fileref="projdoc/imagefiles/13small.png"/></imageobject>
2161 <title>Samba receiving Jobfiles and passing them to CUPS</title>
2164 Samba<emphasis>must</emphasis> use its own spool directory (it is set
2165 by a line similar to <parameter>path = /var/spool/samba</parameter>,
2166 in the <parameter>[printers]</parameter> or
2167 <parameter>[printername]</parameter> section of
2168 <filename>smb.conf</filename>). Samba receives the job in its own
2169 spool space and passes it into the spool directory of CUPS (the CUPS
2170 spooling directory is set by the <parameter>RequestRoot</parameter>
2171 directive, in a line that defaults to <parameter>RequestRoot
2172 /var/spool/cups</parameter>). CUPS checks the access rights of its
2173 spool dir and resets it to healthy values with every re-start. We have
2174 seen quite some people who had used a common spooling space for Samba
2175 and CUPS, and were struggling for weeks with this "problem".
2179 A Windows user authenticates only to Samba (by whatever means is
2180 configured). If Samba runs on the same host as CUPS, you only need to
2181 allow "localhost" to print. If they run on different machines, you
2182 need to make sure the Samba host gets access to printing on CUPS.
2188 <title>Network PostScript RIP: CUPS Filters on Server -- clients use
2189 PostScript Driver with CUPS-PPDs</title>
2192 PPDs can control all print device options. They are usually provided
2193 by the manufacturer; if you own a PostScript printer, that is. PPD
2194 files (PostScript Printer Descriptions) are always a component of
2195 PostScript printer drivers on MS Windows or Apple Mac OS systems. They
2196 are ASCII files containing user-selectable print options, mapped to
2197 appropriate PostScript, PCL or PJL commands for the target
2198 printer. Printer driver GUI dialogs translate these options
2199 "on-the-fly" into buttons and drop-down lists for the user to select.
2203 CUPS can load, without any conversions, the PPD file from any Windows
2204 (NT is recommended) PostScript driver and handle the options. There is
2205 a web browser interface to the print options (select <ulink
2206 url="http://localhost:631/printers/">http://localhost:631/printers/</ulink>
2207 and click on one <emphasis>Configure Printer</emphasis> button to see
2208 it), or a commandline interface (see <command>man lpoptions</command>
2209 or see if you have lphelp on your system). There are also some
2210 different GUI frontends on Linux/UNIX, which can present PPD options
2211 to users. PPD options are normally meant to be evaluated by the
2212 PostScript RIP on the real PostScript printer.
2216 <title>PPDs for non-PS Printers on UNIX</title>
2219 CUPS doesn't limit itself to "real" PostScript printers in its usage
2220 of PPDs. The CUPS developers have extended the scope of the PPD
2221 concept, to also describe available device and driver options for
2222 non-PostScript printers through CUPS-PPDs.
2226 This is logical, as CUPS includes a fully featured PostScript
2227 interpreter (RIP). This RIP is based on Ghostscript. It can process
2228 all received PostScript (and additionally many other file formats)
2229 from clients. All CUPS-PPDs geared to non-PostScript printers contain
2230 an additional line, starting with the keyword
2231 <parameter>*cupsFilter</parameter> . This line tells the CUPS print
2232 system which printer-specific filter to use for the interpretation of
2233 the supplied PostScript. Thus CUPS lets all its printers appear as
2234 PostScript devices to its clients, because it can act as a PostScript
2235 RIP for those printers, processing the received PostScript code into a
2236 proper raster print format.
2241 <title>PPDs for non-PS Printers on Windows</title>
2244 CUPS-PPDs can also be used on Windows-Clients, on top of a
2245 "core" PostScript driver (now recommended is the "CUPS PostScript
2246 Driver for WindowsNT/2K/XP"; you can also use the Adobe one, with
2247 limitations). This feature enables CUPS to do a few tricks no other
2253 <listitem><para>act as a networked PostScript RIP (Raster Image
2254 Processor), handling printfiles from all client platforms in a uniform
2255 way;</para></listitem>
2257 <listitem><para>act as a central accounting and billing server, since
2258 all files are passed through the pstops filter and are therefore
2259 logged in the CUPS <filename>page_log</filename> file.
2260 <emphasis>NOTE:</emphasis> this can not happen with "raw" print jobs,
2261 which always remain unfiltered per definition;</para></listitem>
2263 <listitem><para>enable clients to consolidate on a single PostScript
2264 driver, even for many different target printers.</para></listitem>
2268 Using CUPS PPDs on Windows clients enables these to control
2269 all print job settings just as a UNIX client can do too.
2275 <title>Windows Terminal Servers (WTS) as CUPS Clients</title>
2278 This setup may be of special interest to people experiencing major
2279 problems in WTS environments. WTS need often a multitude of
2280 non-PostScript drivers installed to run their clients' variety of
2281 different printer models. This often imposes the price of much
2282 increased instability.
2286 <title>Printer Drivers running in "Kernel Mode" cause many
2290 The reason is that in Win NT printer drivers run in "Kernel
2291 Mode", this introduces a high risk for the stability of the system
2292 if the driver is not really stable and well-tested. And there are a
2293 lot of bad drivers out there! Especially notorious is the example
2294 of the PCL printer driver that had an additional sound module
2295 running, to notify users via soundcard of their finished jobs. Do I
2296 need to say that this one was also reliably causing "Blue Screens
2297 of Death" on a regular basis?
2301 PostScript drivers generally are very well tested. They are not known
2302 to cause any problems, even though they run in Kernel Mode too. This
2303 might be because there have so far only been 2 different PostScript
2304 drivers the ones from Adobe and the one from Microsoft. Both are
2305 very well tested and are as stable as you ever can imagine on
2306 Windows. The CUPS driver is derived from the Microsoft one.
2311 <title>Workarounds impose Heavy Limitations</title>
2314 In many cases, in an attempt to work around this problem, site
2315 administrators have resorted to restrict the allowed drivers installed
2316 on their WTS to one generic PCL- and one PostScript driver. This
2317 however restricts the clients in the amount of printer options
2318 available for them; often they can't get out more than simplex
2319 prints from one standard paper tray, while their devices could do much
2320 better, if driven by a different driver! )
2325 <title>CUPS: a "Magical Stone"?</title>
2328 Using a PostScript driver, enabled with a CUPS-PPD, seems to be a very
2329 elegant way to overcome all these shortcomings. There are, depending
2330 on the version of Windows OS you use, up to 3 different PostScript
2331 drivers available: Adobe, Microsoft and CUPS PostScript drivers. None
2332 of them is known to cause major stability problems on WTS (even if
2333 used with many different PPDs). The clients will be able to (again)
2334 chose paper trays, duplex printing and other settings. However, there
2335 is a certain price for this too: a CUPS server acting as a PostScript
2336 RIP for its clients requires more CPU and RAM than when just acting as
2337 a "raw spooling" device. Plus, this setup is not yet widely tested,
2338 although the first feedbacks look very promising.
2343 <title>PostScript Drivers with no major problems -- even in Kernel
2347 More recent printer drivers on W2K and XP don't run in Kernel mode
2348 (unlike Win NT) any more. However, both operating systems can still
2349 use the NT drivers, running in Kernel mode (you can roughly tell which
2350 is which as the drivers in subdirectory "2" of "W32X86" are "old"
2351 ones). As was said before, the Adobe as well as the Microsoft
2352 PostScript drivers are not known to cause any stability problems. The
2353 CUPS driver is derived from the Microsoft one. There is a simple
2354 reason for this: The MS DDK (Device Development Kit) for Win NT (which
2355 used to be available at no cost to licensees of Visual Studio)
2356 includes the source code of the Microsoft driver, and licensees of
2357 Visual Studio are allowed to use and modify it for their own driver
2358 development efforts. This is what the CUPS people have done. The
2359 license doesn't allow them to publish the whole of the source code.
2360 However, they have released the "diff" under the GPL, and if you are
2361 owner of an "MS DDK for Win NT", you can check the driver yourself.
2367 <title> Setting up CUPS for driver Download</title>
2370 As we have said before: all previously known methods to prepare client
2371 printer drivers on the Samba server for download and "Point'n'Print"
2372 convenience of Windows workstations are working with CUPS too. These
2373 methods were described in the previous chapter. In reality, this is a
2374 pure Samba business, and only relates to the Samba/Win client
2379 <title><emphasis>cupsaddsmb</emphasis>: the unknown Utility</title>
2382 The cupsaddsmb utility (shipped with all current CUPS versions) is an
2383 alternative method to transfer printer drivers into the Samba
2384 <parameter>[print$]</parameter> share. Remember, this share is where
2385 clients expect drivers deposited and setup for download and
2386 installation. It makes the sharing of any (or all) installed CUPS
2387 printers very easy. cupsaddsmb can use the Adobe PostScript driver as
2388 well as the newly developed <emphasis>CUPS PostScript Driver for
2389 WinNT/2K/XP</emphasis>. Note, that cupsaddsmb does
2390 <emphasis>not</emphasis> work with arbitrary vendor printer drivers,
2391 but only with the <emphasis>exact</emphasis> driver files that are
2392 named in its man page.
2396 The CUPS printer driver is available from the CUPS download site. Its
2397 package name is <filename>cups-samba-[version].tar.gz</filename> . It
2398 is prefered over the Adobe drivers since it has a number of
2403 <listitem><para>it supports a much more accurate page
2404 accounting;</para></listitem>
2406 <listitem><para>it supports banner pages, and page labels on all
2407 printers;</para></listitem>
2409 <listitem><para>it supports the setting of a number of job IPP
2410 attributes (such as job-priority, page-label and
2411 job-billing)</para></listitem>
2415 However, currently only Windows NT, 2000, and XP are supported by the
2416 CUPS drivers. You will need to get the respective part of Adobe driver
2417 too if you need to support Windows 95, 98, and ME clients.
2422 <title>Prepare your <filename>smb.conf</filename> for
2426 Prior to running cupsaddsmb, you need the following settings in
2427 <filename>smb.conf</filename>:
2435 printcap name = cups
2438 comment = All Printers
2439 path = /var/spool/samba
2442 guest ok = yes # setting depends on your requirements
2445 printer admin = root
2448 comment = Printer Drivers
2449 path = /etc/samba/drivers
2459 <title>CUPS Package of "PostScript Driver for WinNT/2k/XP"</title>
2462 CUPS users may get the exactly same packages from<ulink
2463 url="http://www.cups.org/software.html"><emphasis>http://www.cups.org/software.html</emphasis></ulink>.
2464 It is a separate package from the CUPS base software files, tagged as
2465 <emphasis>CUPS 1.1.x Windows NT/2k/XP Printer Driver for SAMBA
2466 (tar.gz, 192k)</emphasis>. The filename to download is
2467 <filename>cups-samba-1.1.x.tar.gz</filename>. Upon untar-/unzip-ing,
2468 it will reveal these files:
2473 # tar xvzf cups-samba-1.1.19.tar.gz
2484 These have been packaged with the ESP meta packager software
2485 "EPM". The <filename>*.install</filename> and
2486 <filename>*.remove</filename> files are simple shell scripts, which
2487 untars the <filename>*.ss</filename> (the <filename>*.ss</filename> is
2488 nothing else but a tar-archive, which can be untar-ed by "tar"
2489 too). Then it puts the content into
2490 <filename>/usr/share/cups/drivers/</filename>. This content includes 3
2496 # tar tv cups-samba.ss
2505 The <emphasis>cups-samba.install</emphasis> shell scripts is easy to
2511 # ./cups-samba.install
2514 Installing software...
2515 Updating file permissions...
2516 Running post-install commands...
2517 Installation is complete.
2522 The script should automatically put the driver files into the
2523 <filename>/usr/share/cups/drivers/</filename> directory.
2527 Due to a bug, one recent CUPS release puts the
2528 <filename>cups.hlp</filename> driver file
2529 into<filename>/usr/share/drivers/</filename> instead of
2530 <filename>/usr/share/cups/drivers/</filename>. To work around this,
2531 copy/move the file (after running the
2532 <command>./cups-samba.install</command> script) manually to the
2538 cp /usr/share/drivers/cups.hlp /usr/share/cups/drivers/
2543 This new CUPS PostScript driver is currently binary-only, but free of
2544 charge. No complete source code is provided (yet). The reason is this:
2545 it has been developed with the help of the <emphasis>Microsoft Driver
2546 Developer Kit</emphasis> (DDK) and compiled with Microsoft Visual
2547 Studio 6. Driver developers are not allowed to distribute the whole of
2548 the source code as Free Software. However, CUPS developers released
2549 the "diff" in source code under the GPL, so anybody with a license of
2550 Visual Studio and a DDK will be able to compile for him/herself.
2555 <title>Recognize the different Driver Files</title>
2558 The CUPS drivers don't support the "older" Windows 95/98/ME, but only
2559 the Windows NT/2000/XP client:
2564 [Windows NT, 2000, and XP are supported by:]
2572 Adobe drivers are available for the older Windows 95/98/ME as well as
2573 the Windows NT/2000/XP clients. The set of files is different for the
2574 different platforms.
2579 [Windows 95, 98, and Me are supported by:]
2587 [Windows NT, 2000, and XP are supported by:]
2595 If both, the Adobe driver files and the CUPS driver files for the
2596 support of WinNT/2k/XP are present in , the Adobe ones will be ignored
2597 and the CUPS ones will be used. If you prefer -- for whatever reason
2598 -- to use Adobe-only drivers, move away the 3 CUPS driver files. The
2599 Win95/98/ME clients use the Adobe drivers in any case.
2604 <title>Acquiring the Adobe Driver Files</title>
2607 Acquiring the Adobe driver files seems to be unexpectedly difficult
2608 for many users. They are not available on the Adobe website as single
2609 files and the self-extracting and/or self-installing Windows-exe is
2610 not easy to locate either. Probably you need to use the included
2611 native installer and run the installation process on one client
2612 once. This will install the drivers (and one Generic PostScript
2613 printer) locally on the client. When they are installed, share the
2614 Generic PostScript printer. After this, the client's
2615 <parameter>[print$]</parameter> share holds the Adobe files, from
2616 where you can get them with smbclient from the CUPS host. A more
2617 detailed description about this is in the next (the CUPS printing)
2623 <title>ESP Print Pro Package of "PostScript Driver for
2624 WinNT/2k/XP"</title>
2627 Users of the ESP Print Pro software are able to install their "Samba
2628 Drivers" package for this purpose with no problem. Retrieve the driver
2629 files from the normal download area of the ESP Print Pro software
2631 url="http://www.easysw.com/software.html">http://www.easysw.com/software.html</ulink>.
2632 You need to locate the link labelled "SAMBA" amongst the
2633 <emphasis>Download Printer Drivers for ESP Print Pro 4.x</emphasis>
2634 area and download the package. Once installed, you can prepare any
2635 driver by simply highlighting the printer in the Printer Manager GUI
2636 and select <emphasis>Export Driver...</emphasis> from the menu. Of
2637 course you need to have prepared Samba beforehand too to handle the
2638 driver files; i.e. mainly setup the <parameter>[print$]</parameter>
2639 share, etc. The ESP Print Pro package includes the CUPS driver files
2640 as well as a (licensed) set of Adobe drivers for the Windows 95/98/ME
2646 <title>Caveats to be considered</title>
2649 Once you have run the install script (and possibly manually
2650 moved the <filename>cups.hlp</filename> file to
2651 <filename>/usr/share/cups/drivers/</filename>), the driver is
2652 ready to be put into Samba's <parameter>[print$]</parameter> share (which often maps to
2653 <filename>/etc/samba/drivers/</filename> and contains a subdir
2654 tree with <emphasis>WIN40</emphasis> and
2655 <emphasis>W32X86</emphasis> branches): You do this by running
2656 "cupsaddsmb" (see also <command>man cupsaddsmb</command> for
2657 CUPS since release 1.1.16).
2661 You may need to put root into the smbpasswd file by running
2662 <command>smbpasswd</command>; this is especially important if you
2663 should run this whole procedure for the first time, and are not
2664 working in an environment where everything is configured for
2665 <emphasis>Single Sign On</emphasis> to a Windows Domain Controller.
2669 Once the driver files are in the <parameter>[print$]</parameter> share
2670 and are initialized, they are ready to be downloaded and installed by
2671 the Win NT/2k/XP clients.
2677 Win 9x/ME clients won't work with the CUPS PostScript driver. For
2678 these you'd still need to use the <filename>ADOBE*.*</filename>
2679 drivers as previously.
2683 It is not harmful if you still have the
2684 <filename>ADOBE*.*</filename> driver files from previous
2685 installations in the <filename>/usr/share/cups/drivers/</filename>
2686 directory. The new <emphasis>cupsaddsmb</emphasis> (from 1.1.16) will
2687 automatically prefer "its own" drivers if it finds both.
2691 Should your Win clients have had the old <filename>ADOBE*.*</filename>
2692 files for the Adobe PostScript driver installed, the download and
2693 installation of the new CUPS PostScript driver for Windows NT/2k/XP
2694 will fail at first. You need to wipe the old driver from the clients
2695 first. It is not enough to "delete" the printer, as the driver files
2696 will still be kept by the clients and re-used if you try to re-install
2697 the printer. To really get rid of the Adobe driver files on the
2698 clients, open the "Printers" folder (possibly via <emphasis>Start
2699 --> Settings --> Control Panel --> Printers</emphasis>),
2700 right-click onto the folder background and select <emphasis>Server
2701 Properties</emphasis>. When the new dialog opens, select the
2702 <emphasis>Drivers</emphasis> tab. On the list select the driver you
2703 want to delete and click on the <emphasis>Delete</emphasis>
2704 button. This will only work if there is not one single printer left
2705 which uses that particular driver. You need to "delete" all printers
2706 using this driver in the "Printers" folder first. You will need
2707 Administrator privileges to do this.
2711 Once you have successfully downloaded the CUPS PostScript driver to a
2712 client, you can easily switch all printers to this one by proceeding
2713 as described elsewhere in the "Samba HOWTO Collection": either change
2714 a driver for an existing printer by running the "Printer Properties"
2715 dialog, or use <command>rpcclient</command> with the
2716 <command>setdriver</command> sub-command.
2723 <title>What are the Benefits of using the "CUPS PostScript Driver for
2724 Windows NT/2k/XP" as compared to the Adobe Driver?</title>
2727 You are interested in a comparison between the CUPS and the Adobe
2728 PostScript drivers? For our purposes these are the most important
2729 items which weigh in favor of the CUPS ones:
2733 <listitem><para>no hassle with the Adobe EULA</para></listitem>
2735 <listitem><para>no hassle with the question <quote>Where do I
2736 get the ADOBE*.* driver files from?</quote></para></listitem>
2738 <listitem><para>the Adobe drivers (on request of the printer PPD
2739 associated with them) often put a PJL header in front of the main
2740 PostScript part of the print file. Thus the printfile starts with
2741 <parameter><1B >%-12345X</parameter> or
2742 <parameter><escape>%-12345X</parameter> instead
2743 of <parameter>%!PS</parameter>). This leads to the
2744 CUPS daemon auto-typing the incoming file as a print-ready file,
2745 not initiating a pass through the "pstops" filter (to speak more
2746 technically, it is not regarded as the generic MIME type
2747 <emphasis>application/postscript</emphasis>, but as
2748 the more special MIME type
2749 <emphasis>application/cups.vnd-postscript</emphasis>),
2750 which therefore also leads to the page accounting in
2751 <emphasis>/var/log/cups/page_log</emphasis> not
2752 receiving the exact mumber of pages; instead the dummy page number
2753 of "1" is logged in a standard setup)</para></listitem>
2755 <listitem><para>the Adobe driver has more options to "mis-configure" the
2756 PostScript generated by it (like setting it inadvertedly to
2757 <emphasis>Optimize for Speed</emphasis>, instead of
2758 <emphasis>Optimize for Portability</emphasis>, which
2759 could lead to CUPS being unable to process it)</para></listitem>
2761 <listitem><para>the CUPS PostScript driver output sent by Windows
2762 clients to the CUPS server will be guaranteed to be auto-typed always
2763 as generic MIME type <emphasis>application/postscript</emphasis>,
2764 thusly passing through the CUPS "pstops" filter and logging the
2765 correct number of pages in the <filename>page_log</filename> for
2766 accounting and quota purposes</para></listitem>
2768 <listitem><para>the CUPS PostScript driver supports the sending of
2769 additional standard (IPP) print options by Win NT/2k/XP clients. Such
2770 additional print options are: naming the CUPS standard
2771 <emphasis>banner pages</emphasis> (or the custom ones, should they be
2772 installed at the time of driver download), using the CUPS
2773 <emphasis>page-label</emphasis> option, setting a
2774 <emphasis>job-priority</emphasis> and setting the <emphasis>scheduled
2775 time of printing</emphasis> (with the option to support additional
2776 useful IPP job attributes in the future).</para></listitem>
2778 <listitem><para>the CUPS PostScript driver supports the inclusion of
2779 the new <emphasis>*cupsJobTicket</emphasis> comments at the
2780 beginning of the PostScript file (which could be used in the future
2781 for all sort of beneficial extensions on the CUPS side, but which will
2782 not disturb any other applications as they will regard it as a comment
2783 and simply ignore it).</para></listitem>
2785 <listitem><para>the CUPS PostScript driver will be the heart of the
2786 fully fledged CUPS IPP client for Windows NT/2K/XP to be released soon
2787 (probably alongside the first Beta release for CUPS
2788 1.2).</para></listitem>
2794 <title>Run "cupsaddsmb" (quiet Mode)</title>
2797 The cupsaddsmb command copies the needed files into your
2798 <parameter>[print$]</parameter> share. Additionally, the PPD
2799 associated with this printer is copied from
2800 <filename>/etc/cups/ppd/</filename> to
2801 <parameter>[print$]</parameter>. There the files wait for convenient
2802 Windows client installations via Point'n'Print. Before we can run the
2803 command successfully, we need to be sure that we can authenticate
2804 towards Samba. If you have a small network you are probably using user
2805 level security (<parameter>security = user</parameter>). Probably your
2806 root has already a Samba account. Otherwise, create it now, using
2807 <command>smbpasswd</command>:
2813 New SMB password: [type in password 'secret']
2814 Retype new SMB password: [type in password 'secret']
2819 Here is an example of a successfully run cupsaddsmb command.
2824 # cupsaddsmb -U root infotec_IS2027
2825 Password for root required to access localhost via SAMBA: [type in password 'secret']
2830 To share<emphasis>all</emphasis> printers and drivers, use the
2831 <parameter>-a</parameter> parameter instead of a printer name. Since
2832 cupsaddsmb "exports" the printer drivers to Samba, it should be
2833 obvious that it only works for queues with a CUPS driver associated.
2838 <title>Run "cupsaddsmb" with verbose Output</title>
2841 Probably you want to see what's going on. Use the
2842 <parameter>-v</parameter> parameter to get a more verbose output. The
2843 output below was edited for better readability: all "\" at the end of
2844 a line indicate that I inserted an artificial line break plus some
2849 You will see the root password for the Samba account printed on
2850 screen. If you use remote access, the password will go over the wire
2856 # cupsaddsmb -U root -v infotec_2105
2857 Password for root required to access localhost via SAMBA:
2858 Running command: smbclient //localhost/print\$ -N -U'root%secret' -c 'mkdir W32X86;put \
2859 /var/spool/cups/tmp/3e98bf2d333b5 W32X86/infotec_2105.ppd;put \
2860 /usr/share/cups/drivers/cupsdrvr.dll W32X86/cupsdrvr.dll;put \
2861 /usr/share/cups/drivers/cupsui.dll W32X86/cupsui.dll;put \
2862 /usr/share/cups/drivers/cups.hlp W32X86/cups.hlp'
2863 added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0
2864 Domain=[CUPS-PRINT] OS=[Unix] Server=[Samba 2.2.7a]
2865 NT_STATUS_OBJECT_NAME_COLLISION making remote directory \W32X86
2866 putting file /var/spool/cups/tmp/3e98bf2d333b5 as \W32X86/infotec_2105.ppd (2328.8 kb/s) \
2867 (average 2328.8 kb/s)
2868 putting file /usr/share/cups/drivers/cupsdrvr.dll as \W32X86/cupsdrvr.dll (9374.3 kb/s) \
2869 (average 5206.6 kb/s)
2870 putting file /usr/share/cups/drivers/cupsui.dll as \W32X86/cupsui.dll (8107.2 kb/s) \
2871 (average 5984.1 kb/s)
2872 putting file /usr/share/cups/drivers/cups.hlp as \W32X86/cups.hlp (3475.0 kb/s) \
2873 (average 5884.7 kb/s)
2875 Running command: rpcclient localhost -N -U'root%secret' -c 'adddriver "Windows NT x86" \
2876 "infotec_2105:cupsdrvr.dll:infotec_2105.ppd:cupsui.dll:cups.hlp:NULL: \
2878 cmd = adddriver "Windows NT x86" "infotec_2105:cupsdrvr.dll:infotec_2105.ppd:cupsui.dll: \
2879 cups.hlp:NULL:RAW:NULL"
2880 Printer Driver infotec_2105 successfully installed.
2882 Running command: smbclient //localhost/print\$ -N -U'root%secret' -c 'mkdir WIN40;put \
2883 /var/spool/cups/tmp/3e98bf2d333b5 WIN40/infotec_2105.PPD; put \
2884 /usr/share/cups/drivers/ADFONTS.MFM WIN40/ADFONTS.MFM;put \
2885 /usr/share/cups/drivers/ADOBEPS4.DRV WIN40/ADOBEPS4.DRV;put \
2886 /usr/share/cups/drivers/ADOBEPS4.HLP WIN40/ADOBEPS4.HLP;put \
2887 /usr/share/cups/drivers/DEFPRTR2.PPD WIN40/DEFPRTR2.PPD;put \
2888 /usr/share/cups/drivers/ICONLIB.DLL
2889 WIN40/ICONLIB.DLL;put /usr/share/cups/drivers/PSMON.DLL WIN40/PSMON.DLL;'
2890 added interface ip=10.160.51.60 bcast=10.160.51.255 nmask=255.255.252.0
2891 Domain=[CUPS-PRINT] OS=[Unix] Server=[Samba 2.2.7a]
2892 NT_STATUS_OBJECT_NAME_COLLISION making remote directory \WIN40
2893 putting file /var/spool/cups/tmp/3e98bf2d333b5 as \WIN40/infotec_2105.PPD (2328.8 kb/s) \
2894 (average 2328.8 kb/s)
2895 putting file /usr/share/cups/drivers/ADFONTS.MFM as \WIN40/ADFONTS.MFM (9368.0 kb/s) \
2896 (average 6469.6 kb/s)
2897 putting file /usr/share/cups/drivers/ADOBEPS4.DRV as \WIN40/ADOBEPS4.DRV (9958.2 kb/s) \
2898 (average 8404.3 kb/s)
2899 putting file /usr/share/cups/drivers/ADOBEPS4.HLP as \WIN40/ADOBEPS4.HLP (8341.5 kb/s) \
2900 (average 8398.6 kb/s)
2901 putting file /usr/share/cups/drivers/DEFPRTR2.PPD as \WIN40/DEFPRTR2.PPD (2195.9 kb/s) \
2902 (average 8254.3 kb/s)
2903 putting file /usr/share/cups/drivers/ICONLIB.DLL as \WIN40/ICONLIB.DLL (8239.9 kb/s) \
2904 (average 8253.6 kb/s)
2905 putting file /usr/share/cups/drivers/PSMON.DLL as \WIN40/PSMON.DLL (6222.2 kb/s) \
2906 (average 8188.5 kb/s)
2908 Running command: rpcclient localhost -N -U'root%secret' -c 'adddriver "Windows 4.0" \
2909 "infotec_2105:ADOBEPS4.DRV:infotec_2105.PPD:NULL:ADOBEPS4.HLP: \
2910 PSMON.DLL:RAW:ADOBEPS4.DRV,infotec_2105.PPD,ADOBEPS4.HLP,PSMON.DLL, \
2911 ADFONTS.MFM,DEFPRTR2.PPD,ICONLIB.DLL"'
2912 cmd = adddriver "Windows 4.0" "infotec_2105:ADOBEPS4.DRV:infotec_2105.PPD:NULL: \
2913 ADOBEPS4.HLP:PSMON.DLL:RAW:ADOBEPS4.DRV,infotec_2105.PPD,ADOBEPS4.HLP, \
2914 PSMON.DLL,ADFONTS.MFM,DEFPRTR2.PPD,ICONLIB.DLL"
2915 Printer Driver infotec_2105 successfully installed.
2917 Running command: rpcclient localhost -N -U'root%secret' \
2918 -c 'setdriver infotec_2105 infotec_2105'
2919 cmd = setdriver infotec_2105 infotec_2105
2920 Succesfully set infotec_2105 to driver infotec_2105.
2925 If you look closely, you'll discover your root password was transfered
2926 unencrypted over the wire, so beware! Also, if you look further her,
2927 you'll discover error messages like NT_STATUS_OBJECT_NAME_COLLISION in
2928 between. They occur, because the directories WIN40 and W32X86 already
2929 existed in the <parameter>[print$]</parameter> driver download share
2930 (from a previous driver installation). They are harmless here.
2935 <title>Understanding cupsaddsmb</title>
2938 What has happened? What did cupsaddsmb do? There are five stages of
2944 <listitem><para>call the CUPS server via IPP and request the
2945 driver files and the PPD file for the named printer;</para></listitem>
2947 <listitem><para>store the files temporarily in the local
2948 TEMPDIR (as defined in
2949 <filename>cupsd.conf</filename>);</para></listitem>
2951 <listitem><para>connect via smbclient to the Samba server's
2952 <parameter>[print$]</parameter> share and put the files into the
2953 share's WIN40 (for Win95/98/ME) and W32X86/ (for WinNT/2k/XP) sub
2954 directories;</para></listitem>
2956 <listitem><para>connect via rpcclient to the Samba server and
2957 execute the "adddriver" command with the correct
2958 parameters;</para></listitem>
2960 <listitem><para>connect via rpcclient to the Samba server a second
2961 time and execute the "setdriver" command.</para></listitem>
2965 Note, that you can run the cupsaddsmb utility with parameters to
2966 specify one remote host as Samba host and a second remote host as CUPS
2967 host. Especially if you want to get a deeper understanding, it is a
2968 good idea try it and see more clearly what is going on (though in real
2969 life most people will have their CUPS and Samba servers run on the
2975 # cupsaddsmb -H sambaserver -h cupsserver -v printername
2981 <title>How to recognize if cupsaddsm completed successfully</title>
2984 You <emphasis>must</emphasis> always check if the utility completed
2985 successfully in all fields. You need as a minimum these 3 messages
2991 <listitem><para><emphasis>Printer Driver infotec_2105 successfully
2992 installed.</emphasis> # (for the W32X86 == WinNT/2K/XP
2993 architecture...)</para></listitem>
2995 <listitem><para><emphasis>Printer Driver infotec_2105 successfully
2996 installed.</emphasis> # (for the WIN40 == Win9x/ME
2997 architecture...)</para></listitem>
2999 <listitem><para><emphasis>Succesfully set [printerXPZ] to driver
3000 [printerXYZ].</emphasis></para></listitem>
3004 These messages probably not easily recognized in the general
3005 output. If you run cupsaddsmb with the <parameter>-a</parameter>
3006 parameter (which tries to prepare <emphasis>all</emphasis> active CUPS
3007 printer drivers for download), you might miss if individual printers
3008 drivers had problems to install properly. Here a redirection of the
3009 output will help you analyze the results in retrospective.
3013 It is impossible to see any diagnostic output if you don't run
3014 cupsaddsmb in verbose mode. Therefore we strongly recommend to not
3015 use the default quiet mode. It will hide any problems from you which
3021 <title>cupsaddsmb with a Samba PDC</title>
3024 You can't get the standard cupsaddsmb command to run on a Samba PDC?
3025 You are asked for the password credential all over again and again and
3026 the command just will not take off at all? Try one of these
3032 # cupsaddsmb -U DOMAINNAME\\root -v printername
3033 # cupsaddsmb -H SAMBA-PDC -U DOMAINNAME\\root -v printername
3034 # cupsaddsmb -H SAMBA-PDC -U DOMAINNAME\\root -h cups-server -v printername
3039 (Note the two backslashes: the first one is required to
3040 "escape" the second one).
3045 <title>cupsaddsmb Flowchart</title>
3048 Here is a chart about the procedures, commandflows and
3049 dataflows of the "cupaddsmb" command. Note again: cupsaddsmb is
3050 not intended to, and does not work with, "raw" queues!
3054 <figure><title>cupsaddsmb flowchart</title>
3056 <imageobject role="latex"><imagedata fileref="projdoc/imagefiles/1small"/></imageobject>
3057 <imageobject><imagedata fileref="projdoc/imagefiles/1small.png"/></imageobject>
3064 <title>Installing the PostScript Driver on a Client</title>
3067 After cupsaddsmb completed, your driver is prepared for the clients to
3068 use. Here are the steps you must perform to download and install it
3069 via "Point'n'Print". From a Windows client, browse to the CUPS/Samba
3075 <listitem><para>open the <emphasis>Printers</emphasis>
3076 share of Samba in Network Neighbourhood;</para></listitem>
3078 <listitem><para>right-click on the printer in
3079 question;</para></listitem>
3081 <listitem><para>from the opening context-menu select
3082 <emphasis>Install...</emphasis> or
3083 <emphasis>Connect...</emphasis> (depending on the Windows version you
3084 use).</para></listitem>
3088 After a few seconds, there should be a new printer in your
3089 client's <emphasis>local</emphasis> "Printers" folder: On Windows
3090 XP it will follow a naming convention of <emphasis>PrinterName on
3091 SambaServer</emphasis>. (In my current case it is "infotec_2105 on
3092 kde-bitshop"). If you want to test it and send your first job from
3093 an application like Winword, the new printer will appears in a
3094 <filename>\\SambaServer\PrinterName</filename> entry in the
3095 dropdown list of available printers.
3099 cupsaddsmb will only reliably work with CUPS version 1.1.15 or higher
3100 and Samba from 2.2.4. If it doesn't work, or if the automatic printer
3101 driver download to the clients doesn't succeed, you can still manually
3102 install the CUPS printer PPD on top of the Adobe PostScript driver on
3103 clients. Then point the client's printer queue to the Samba printer
3104 share for a UNC type of connection:
3109 net use lpt1: \\sambaserver\printershare /user:ntadmin
3114 should you desire to use the CUPS networked PostScript RIP
3115 functions. (Note that user "ntadmin" needs to be a valid Samba user
3116 with the required privileges to access the printershare) This would
3117 set up the printer connection in the traditional
3118 <emphasis>LanMan</emphasis> way (not using MS-RPC).
3123 <title>Avoiding critical PostScript Driver Settings on the
3127 Soooo: printing works, but there are still problems. Most jobs print
3128 well, some don't print at all. Some jobs have problems with fonts,
3129 which don't look very good. Some jobs print fast, and some are
3130 dead-slow. Many of these problems can be greatly reduced or even
3131 completely eliminated if you follow a few guidelines. Remember, if
3132 your print device is not PostScript-enabled, you are treating your
3133 Ghostscript installation on your CUPS host with the output your client
3134 driver settings produce. Treat it well:
3138 <listitem><para>Avoid the <emphasis>PostScript Output Option: Optimize
3139 for Speed</emphasis> settting. Rather use the <emphasis>Optimize for
3140 Portability</emphasis> instead (Adobe PostScript
3141 driver).</para></listitem>
3143 <listitem><para>Don't use the <emphasis>Page Independence:
3144 NO</emphasis> setting. Instead use <emphasis>Page Independence
3145 YES</emphasis> (CUPS PostScript Driver)</para></listitem>
3147 <listitem><para>Recommended is the <emphasis>True Type Font
3148 Downloading Option: Native True Type</emphasis> over
3149 <emphasis>Automatic</emphasis> and <emphasis>Outline</emphasis>; you
3150 should by all means avoid <emphasis>Bitmap</emphasis> (Adobe
3151 PostScript Driver)</para></listitem>
3153 <listitem><para>Choose <emphasis>True Type Font: Download as Softfont
3154 into Printer</emphasis> over the default <emphasis>Replace by Device
3155 Font</emphasis> (for exotic fonts you may need to change it back to
3156 get a printout at all) (Adobe)</para></listitem>
3158 <listitem><para>Sometimes you can choose <emphasis>PostScript Language
3159 Level</emphasis>: in case of problems try <emphasis>2</emphasis>
3160 instead of <emphasis>3</emphasis> (the latest ESP Ghostscript package
3161 handels Level 3 PostScript very well) (Adobe).</para></listitem>
3163 <listitem><para>Say <emphasis>Yes</emphasis> to <emphasis>PostScript
3164 Error Handler</emphasis> (Adobe)</para></listitem>
3170 <title>Installing PostScript Driver Files manually (using
3174 Of course you can run all the commands which are embedded into the
3175 cupsaddsmb convenience utility yourself, one by one, and hereby upload
3176 and prepare the driver files for future client downloads.
3180 <listitem><para>prepare Samba (a CUPS printqueue with the name of the
3181 printer should be there. We are providing the driver
3182 now);</para></listitem>
3184 <listitem><para>copy all files to
3185 <parameter>[print$]:</parameter></para></listitem>
3187 <listitem><para>run <command>rpcclient adddriver</command>
3188 (for each client architecture you want to support):</para></listitem>
3190 <listitem><para>run <command>rpcclient
3191 setdriver.</command></para></listitem>
3195 We are going to do this now. First, read the man page on "rpcclient"
3196 to get a first idea. Look at all the printing related
3197 sub-commands. <command>enumprinters</command>,
3198 <command>enumdrivers</command>, <command>enumports</command>,
3199 <command>adddriver</command>, <command>setdriver</command> are amongst
3200 the most interesting ones. rpcclient implements an important part of
3201 the MS-RPC protocol. You can use it to query (and command) a Win NT
3202 (or 2K/XP) PC too. MS-RPC is used by Windows clients, amongst other
3203 things, to benefit from the "Point'n' Print" features. Samba can now
3208 <title>A Check of the rpcclient man Page</title>
3211 First let's have a little check of the rpcclient man page. Here are
3212 two relevant passages:
3216 <command>adddriver <arch> <config></command> Execute an
3217 AddPrinterDriver() RPC to install the printer driver information on
3218 the server. Note that the driver files should already exist in the
3219 directory returned by <command>getdriverdir</command>. Possible
3220 values for <parameter>arch</parameter> are the same as those for the
3221 <command>getdriverdir</command> command. The
3222 <parameter>config</parameter> parameter is defined as follows:
3231 Language Monitor Name:\
3233 Comma Separated list of Files
3236 <para>Any empty fields should be enter as the string "NULL". </para>
3238 <para>Samba does not need to support the concept of Print Monitors
3239 since these only apply to local printers whose driver can make use of
3240 a bi-directional link for communication. This field should be "NULL".
3241 On a remote NT print server, the Print Monitor for a driver must
3242 already be installed prior to adding the driver or else the RPC will
3247 <command>setdriver <printername> <drivername></command>
3248 Execute a <command>SetPrinter()</command> command to update the
3249 printer driver associated with an installed printer. The printer
3250 driver must already be correctly installed on the print server.
3253 <para> See also the enumprinters and enumdrivers commands for
3254 obtaining a list of installed printers and drivers.
3260 <title>Understanding the rpcclient man Page</title>
3263 The <emphasis>exact</emphasis> format isn't made too clear by the man
3264 page, since you have to deal with some parameters containing
3265 spaces. Here is a better description for it. We have line-broken the
3266 command and indicated the breaks with "\". Usually you would type the
3267 command in one line without the linebreaks:
3272 adddriver "Architecture" \
3273 "LongPrinterName:DriverFile:DataFile:ConfigFile:HelpFile:\
3274 LanguageMonitorFile:DataType:ListOfFiles,Comma-separated"
3279 What the man pages denotes as a simple <config>
3280 keyword, does in reality consist of 8 colon-separated fields. The
3281 last field may take multiple (in some, very insane, cases, even
3282 20 different additional files. This might sound confusing at first.
3283 Note, that what the man pages names the "LongPrinterName" in
3284 reality should rather be called the "Driver Name". You can name it
3285 anything you want, as long as you use this name later in the
3286 <emphasis>rpcclient ... setdriver</emphasis> command. For
3287 practical reasons, many name the driver the same as the
3292 True: it isn't simple at all. I hear you asking:
3293 <emphasis>How do I know which files are "Driver
3294 File", "Data File", "Config File", "Help File" and "Language
3295 Monitor File" in each case?</emphasis> -- For an answer you may
3296 want to have a look at how a Windows NT box with a shared printer
3297 presents the files to us. Remember, that this whole procedure has
3298 to be developed by the Samba Team by overhearing the traffic caused
3299 by Windows computers on the wire. We may as well turn to a Windows
3300 box now, and access it from a UNIX workstation. We will query it
3301 with <command>rpcclient</command> to see what it tells us and
3302 try to understand the man page more clearly which we've read just
3308 <title>Producing an Example by querying a Windows Box</title>
3311 We could run <command>rpcclient</command> with a
3312 <command>getdriver</command> or a <command>getprinter</command>
3313 subcommand (in level 3 verbosity) against it. Just sit down at UNIX or
3314 Linux workstation with the Samba utilities installed. Then type the
3320 rpcclient -U'USERNAME%PASSWORD' NT-SERVER-NAME -c 'getdriver printername 3'
3325 From the result it should become clear which is which. Here is an
3326 example from my installation:
3331 # rpcclient -U'Danka%xxxx' W2KSERVER -c'getdriver "DANKA InfoStream Virtual Printer" 3'
3332 cmd = getdriver "DANKA InfoStream Virtual Printer" 3
3335 Printer Driver Info 3:
3337 Driver Name: [DANKA InfoStream]
3338 Architecture: [Windows NT x86]
3339 Driver Path: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\PSCRIPT.DLL]
3340 Datafile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\INFOSTRM.PPD]
3341 Configfile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\PSCRPTUI.DLL]
3342 Helpfile: [C:\WINNT\System32\spool\DRIVERS\W32X86\2\PSCRIPT.HLP]
3358 Some printer drivers list additional files under the label
3359 "Dependentfiles": these would go into the last field
3360 <emphasis>ListOfFiles,Comma-separated</emphasis>. For the CUPS
3361 PostScript drivers we don't need any (nor would we for the Adobe
3362 PostScript driver): therefore the field will get a "NULL" entry.
3367 <title>What is required for adddriver and setdriver to succeed</title>
3370 From the manpage (and from the quoted output
3371 of<emphasis>cupsaddsmb</emphasis>, above) it becomes clear that you
3372 need to have certain conditions in order to make the manual uploading
3373 and initializing of the driver files succeed. The two rpcclient
3374 subcommands (<command>adddriver</command> and
3375 <command>setdriver</command>) need to encounter the following
3376 pre-conditions to complete successfully:
3380 <listitem><para>you are connected as "printer admin", or root (note,
3381 that this is <emphasis>not</emphasis> the "Printer Operators" group in
3382 NT, but the <emphasis>printer admin</emphasis> group, as defined in
3383 the <parameter>[global]</parameter> section of
3384 <filename>smb.conf</filename>);</para></listitem>
3386 <listitem><para>copy all required driver files to
3387 <filename>\\sambaserver\print$\w32x86</filename> and
3388 <filename>\\sambaserver\print$\win40</filename> as appropriate. They
3389 will end up in the "0" respective "2" subdirectories later -- for now
3390 <emphasis>don't</emphasis> put them there, they'll be automatically
3391 used by the <command>adddriver</command> subcommand.! (if you use
3392 "smbclient" to put the driver files into the share, note that you need
3393 to escape the "$": <command>smbclient //sambaserver/print\$ -U
3394 root</command>);</para></listitem>
3396 <listitem><para>the user you're connecting as must be able to write to
3397 the <parameter>[print$]</parameter> share and create
3398 subdirectories;</para></listitem>
3400 <listitem><para>the printer you are going to setup for the Windows
3401 clients, needs to be installed in CUPS already;</para></listitem>
3403 <listitem><para>the CUPS printer must be known to Samba, otherwise the
3404 <command>setdriver</command> subcommand fails with an
3405 NT_STATUS_UNSUCCESSFUL error. To check if the printer is known by
3406 Samba you may use the <command>enumprinters</command> subcommand to
3407 rpcclient. A long-standing bug prevented a proper update of the
3408 printer list until every smbd process had received a SIGHUP or was
3409 restarted. Remember this in case you've created the CUPS printer just
3410 shortly ago and encounter problems: try restarting
3411 Samba.</para></listitem>
3416 <title>Manual Commandline Driver Installation in 15 little Steps</title>
3419 We are going to install a printer driver now by manually executing all
3420 required commands. As this may seem a rather complicated process at
3421 first, we go through the procedure step by step, explaining every
3422 single action item as it comes up.
3426 <title>First Step: Install the Printer on CUPS</title>
3430 # lpadmin -p mysmbtstprn -v socket://10.160.51.131:9100 -E -P /home/kurt/canonIR85.ppd
3435 This installs printer with the name <emphasis>mysmbtstprn</emphasis>
3436 to the CUPS system. The printer is accessed via a socket
3437 (a.k.a. JetDirect or Direct TCP/IP) connection. You need to be root
3443 <title>Second Step (optional): Check if the Printer is recognized by
3448 # rpcclient -Uroot%xxxx -c 'enumprinters' localhost | grep -C2 mysmbtstprn
3451 name:[\\kde-bitshop\mysmbtstprn]
3452 description:[\\kde-bitshop\mysmbtstprn,,mysmbtstprn]
3453 comment:[mysmbtstprn]
3458 This should show the printer in the list. If not, stop and re-start
3459 the Samba daemon (smbd), or send a HUP signal: <command>kill -HUP
3460 `pidof smbd`</command>. Check again. Troubleshoot and repeat until
3461 success. Note the "empty" field between the two commas in the
3462 "description" line. Here would the driver name appear if there was one
3463 already. You need to know root's Samba password (as set by the
3464 <command>smbpasswd</command> command) for this step and most of the
3465 following steps. Alternatively you can authenticate as one of the
3466 users from the "write list" as defined in <filename>smb.conf</filename> for
3467 <parameter>[print$]</parameter>.
3472 <title>Third Step (optional): Check if Samba knows a Driver for the
3477 # rpcclient -Uroot%xxxx -c 'getprinter mysmbtstprn 2' localhost | grep driver
3480 # rpcclient -Uroot%xxxx -c 'getprinter mysmbtstprn 2' localhost | grep -C4 driv
3481 servername:[\\kde-bitshop]
3482 printername:[\\kde-bitshop\mysmbtstprn]
3483 sharename:[mysmbtstprn]
3484 portname:[Samba Printer Port]
3486 comment:[mysmbtstprn]
3489 printprocessor:[winprint]
3491 # rpcclient -U root%xxxx -c 'getdriver mysmbtstprn' localhost
3492 result was WERR_UNKNOWN_PRINTER_DRIVER
3497 Neither method of the three commands shown above should show a driver.
3498 This step was done for the purpose of demonstrating this condition. An
3499 attempt to connect to the printer at this stage will prompt the
3500 message along the lines: "The server has not the required printer
3506 <title>Fourth Step: Put all required Driver Files into Samba's
3511 # smbclient //localhost/print\$ -U 'root%xxxx' \
3513 put /etc/cups/ppd/mysmbtstprn.ppd mysmbtstprn.PPD; \
3514 put /usr/share/cups/drivers/cupsui.dll cupsui.dll; \
3515 put /usr/share/cups/drivers/cupsdrvr.dll cupsdrvr.dll; \
3516 put /usr/share/cups/drivers/cups.hlp cups.hlp'
3521 (Note that this command should be entered in one long single
3522 line. Line-breaks and the line-end indicating "\" has been inserted
3523 for readability reasons.) This step is <emphasis>required</emphasis>
3524 for the next one to succeed. It makes the driver files physically
3525 present in the <parameter>[print$]</parameter> share. However, clients
3526 would still not be able to install them, because Samba does not yet
3527 treat them as driver files. A client asking for the driver would still
3528 be presented with a "not installed here" message.
3533 <title>Fifth Step: Verify where the Driver Files are now</title>
3537 # ls -l /etc/samba/drivers/W32X86/
3539 drwxr-sr-x 2 root ntadmin 532 May 25 23:08 2
3540 drwxr-sr-x 2 root ntadmin 670 May 16 03:15 3
3541 -rwxr--r-- 1 root ntadmin 14234 May 25 23:21 cups.hlp
3542 -rwxr--r-- 1 root ntadmin 278380 May 25 23:21 cupsdrvr.dll
3543 -rwxr--r-- 1 root ntadmin 215848 May 25 23:21 cupsui.dll
3544 -rwxr--r-- 1 root ntadmin 169458 May 25 23:21 mysmbtstprn.PPD
3549 The driver files now are in the W32X86 architecture "root" of
3550 <parameter>[print$]</parameter>.
3555 <title>Sixth Step: Tell Samba that these are
3556 <emphasis>Driver</emphasis> Files
3557 (<command>adddriver</command>)</title>
3561 # rpcclient -Uroot%xxxx -c `adddriver "Windows NT x86" "mydrivername: \
3562 cupsdrvr.dll:mysmbtstprn.PPD: \
3563 cupsui.dll:cups.hlp:NULL:RAW<citation>:</citation>NULL" \
3566 Printer Driver mydrivername successfully installed.
3571 Note that your cannot repeat this step if it fails. It could fail even
3572 as a result of a simple typo. It will most likely have moved a part of
3573 the driver files into the "2" subdirectory. If this step fails, you
3574 need to go back to the fourth step and repeat it, before you can try
3575 this one again. In this step you need to choose a name for your
3576 driver. It is normally a good idea to use the same name as is used for
3577 the printername; however, in big installations you may use this driver
3578 for a number of printers which have obviously different names. So the
3579 name of the driver is not fixed.
3584 <title>Seventh Step: Verify where the Driver Files are now</title>
3588 # ls -l /etc/samba/drivers/W32X86/
3590 drwxr-sr-x 2 root ntadmin 532 May 25 23:22 2
3591 drwxr-sr-x 2 root ntadmin 670 May 16 03:15 3
3594 # ls -l /etc/samba/drivers/W32X86/2
3597 -rwxr--r-- 1 root ntadmin 14234 May 25 23:21 cups.hlp
3598 -rwxr--r-- 1 root ntadmin 278380 May 13 13:53 cupsdrvr.dll
3599 -rwxr--r-- 1 root ntadmin 215848 May 13 13:53 cupsui.dll
3600 -rwxr--r-- 1 root ntadmin 169458 May 25 23:21 mysmbtstprn.PPD
3605 Notice how step 6 did also move the driver files to the appropriate
3606 subdirectory. Compare with the situation after step 5.
3611 <title>Eighth Step (optional): Verify if Samba now recognizes the
3616 # rpcclient -Uroot%xxxx -c 'enumdrivers 3' localhost | grep -B2 -A5 mydrivername
3618 Printer Driver Info 3:
3620 Driver Name: [mydrivername]
3621 Architecture: [Windows NT x86]
3622 Driver Path: [\\kde-bitshop\print$\W32X86\2\cupsdrvr.dll]
3623 Datafile: [\\kde-bitshop\print$\W32X86\2\mysmbtstprn.PPD]
3624 Configfile: [\\kde-bitshop\print$\W32X86\2\cupsui.dll]
3625 Helpfile: [\\kde-bitshop\print$\W32X86\2\cups.hlp]
3630 Remember, this command greps for the name you did choose for the
3631 driver in step Six. This command must succeed before you can proceed.
3636 <title>Ninth Step: Tell Samba which Printer should use these Driver
3637 Files (<command>setdriver</command>)</title>
3641 # rpcclient -Uroot%xxxx -c 'setdriver mysmbtstprn mydrivername' localhost
3643 Successfully set mysmbtstprn to driver mydrivername
3648 Since you can bind any printername (=printqueue) to any driver, this
3649 is a very convenient way to setup many queues which use the same
3650 driver. You don't need to repeat all the previous steps for the
3651 setdriver command to succeed. The only pre-conditions are:
3652 <command>enumdrivers</command> must find the driver and
3653 <command>enumprinters</command> must find the printer.
3658 <title>Tenth Step (optional): Verify if Samba has this Association
3663 # rpcclient -Uroot%xxxx -c 'getprinter mysmbtstprn 2' localhost | grep driver
3664 drivername:[mydrivername]
3666 # rpcclient -Uroot%xxxx -c 'getprinter mysmbtstprn 2' localhost | grep -C4 driv
3667 servername:[\\kde-bitshop]
3668 printername:[\\kde-bitshop\mysmbtstprn]
3669 sharename:[mysmbtstprn]
3671 drivername:[mydrivername]
3672 comment:[mysmbtstprn]
3675 printprocessor:[winprint]
3677 # rpcclient -U root%xxxx -c 'getdriver mysmbtstprn' localhost
3679 Printer Driver Info 3:
3681 Driver Name: [mydrivername]
3682 Architecture: [Windows NT x86]
3683 Driver Path: [\\kde-bitshop\print$\W32X86\2\cupsdrvr.dll]
3684 Datafile: [\\kde-bitshop\print$\W32X86\2\mysmbtstprn.PPD]
3685 Configfile: [\\kde-bitshop\print$\W32X86\2\cupsui.dll]
3686 Helpfile: [\\kde-bitshop\print$\W32X86\2\cups.hlp]
3688 Defaultdatatype: [RAW]
3690 Defaultdatatype: [RAW]
3692 # rpcclient -Uroot%xxxx -c 'enumprinters' localhost | grep mysmbtstprn
3693 name:[\\kde-bitshop\mysmbtstprn]
3694 description:[\\kde-bitshop\mysmbtstprn,mydrivername,mysmbtstprn]
3695 comment:[mysmbtstprn]
3700 Compare these results with the ones from steps 2 and 3. Note that
3701 every single of these commands show the driver is installed. Even
3702 the <command>enumprinters</command> command now lists the driver
3703 on the "description" line.
3708 <title>Eleventh Step (optional): Tickle the Driver into a correct
3712 You certainly know how to install the driver on the client. In case
3713 you are not particularly familiar with Windows, here is a short
3714 recipe: browse the Network Neighbourhood, go to the Samba server, look
3715 for the shares. You should see all shared Samba printers.
3716 Double-click on the one in question. The driver should get
3717 installed, and the network connection set up. An alternative way is to
3718 open the "Printers (and Faxes)" folder, right-click on the printer in
3719 question and select "Connect" or "Install". As a result, a new printer
3720 should have appeared in your client's local "Printers (and Faxes)"
3721 folder, named something like "printersharename on Sambahostname".
3725 It is important that you execute this step as a Samba printer admin
3726 (as defined in <filename>smb.conf</filename>). Here is another method
3727 to do this on Windows XP. It uses a commandline, which you may type
3728 into the "DOS box" (type root's smbpassword when prompted):
3733 C:\> runas /netonly /user:root "rundll32 printui.dll,PrintUIEntry /in /n \\sambacupsserver\mysmbtstprn"
3738 Change any printer setting once (like <emphasis>"portrait"
3739 --> "landscape"</emphasis>), click "Apply"; change the setting
3745 <title>Twelveth Step: Install the Printer on a Client
3746 ("Point'n'Print")</title>
3750 C:\> rundll32 printui.dll,PrintUIEntry /in /n "\\sambacupsserver\mysmbtstprn"
3755 If it doesn't work it could be a permission problem with the
3756 <parameter>[print$]</parameter> share.
3761 <title>Thirteenth Step (optional): Print a Test Page</title>
3765 C:\> rundll32 printui.dll,PrintUIEntry /p /n "\\sambacupsserver\mysmbtstprn"
3770 Then hit [TAB] 5 times, [ENTER] twice, [TAB] once and [ENTER] again
3771 and march to the printer.
3776 <title>Fourteenth Step (recommended): Study the Test Page</title>
3779 Hmmm.... just kidding! By now you know everything about printer
3780 installations and you don't need to read a word. Just put it in a
3781 frame and bolt it to the wall with the heading "MY FIRST
3782 RPCCLIENT-INSTALLED PRINTER" - why not just throw it away!
3787 <title>Fifteenth Step (obligatory): Enjoy. Jump. Celebrate your
3792 # echo "Cheeeeerioooooo! Success..." >> /var/log/samba/log.smbd
3799 <title>Troubleshooting revisited</title>
3802 The setdriver command will fail, if in Samba's mind the queue is not
3803 already there. You had promising messages about the:
3808 Printer Driver ABC successfully installed.
3813 after the "adddriver" parts of the procedure? But you are also seeing
3814 a disappointing message like this one beneath?
3819 result was NT_STATUS_UNSUCCESSFUL
3824 It is not good enough that <emphasis>you</emphasis>
3825 can see the queue <emphasis>in CUPS</emphasis>, using
3826 the <command>lpstat -p ir85wm</command> command. A
3827 bug in most recent versions of Samba prevents the proper update of
3828 the queuelist. The recognition of newly installed CUPS printers
3829 fails unless you re-start Samba or send a HUP to all smbd
3830 processes. To verify if this is the reason why Samba doesn't
3831 execute the setdriver command successfully, check if Samba "sees"
3837 # rpcclient transmeta -N -U'root%secret' -c 'enumprinters 0'| grep ir85wm
3838 printername:[ir85wm]
3843 An alternative command could be this:
3848 # rpcclient transmeta -N -U'root%secret' -c 'getprinter ir85wm'
3849 cmd = getprinter ir85wm
3851 name:[\\transmeta\ir85wm]
3852 description:[\\transmeta\ir85wm,ir85wm,DPD]
3853 comment:[CUPS PostScript-Treiber for WinNT/2K/XP]
3858 BTW, you can use these commands, plus a few more, of course,
3859 to install drivers on remote Windows NT print servers too!
3865 <title>The printing <filename>*.tdb</filename> Files</title>
3868 Some mystery is associated with the series of files with a
3869 tdb-suffix appearing in every Samba installation. They are
3870 <filename>connections.tdb</filename>,
3871 <filename>printing.tdb</filename>,
3872 <filename>share_info.tdb</filename> ,
3873 <filename>ntdrivers.tdb</filename>,
3874 <filename>unexpected.tdb</filename>,
3875 <filename>brlock.tdb</filename> ,
3876 <filename>locking.tdb</filename>,
3877 <filename>ntforms.tdb</filename>,
3878 <filename>messages.tdb</filename> ,
3879 <filename>ntprinters.tdb</filename>,
3880 <filename>sessionid.tdb</filename> and
3881 <filename>secrets.tdb</filename>. What is their purpose?
3885 <title>Trivial DataBase Files</title>
3888 A Windows NT (Print) Server keeps track of all information needed to serve
3889 its duty toward its clients by storing entries in the Windows
3890 "Registry". Client queries are answered by reading from the registry,
3891 Administrator or user configuration settings are saved by writing into
3892 the Registry. Samba and Unix obviously don't have such a kind of
3893 Registry. Samba instead keeps track of all client related information in a
3894 series of <filename>*.tdb</filename> files. (TDB = Trivial Data
3895 Base). These are often located in <filename>/var/lib/samba/</filename>
3896 or <filename>/var/lock/samba/</filename> . The printing related files
3897 are <filename>ntprinters.tdb</filename>,
3898 <filename>printing.tdb</filename>,<filename>ntforms.tdb</filename> and
3899 <filename>ntdrivers.tdb</filename>.
3904 <title>Binary Format</title>
3907 <filename>*.tdb</filename> files are not human readable. They are
3908 written in a binary format. "Why not ASCII?", you may ask. "After all,
3909 ASCII configuration files are a good and proofed tradition on UNIX."
3910 -- The reason for this design decision by the Samba Team is mainly
3911 performance. Samba needs to be fast; it runs a separate
3912 <command>smbd</command> process for each client connection, in some
3913 environments many thousand of them. Some of these smbds might need to
3914 write-access the same <filename>*.tdb</filename> file <emphasis>at the
3915 same time</emphasis>. The file format of Samba's
3916 <filename>*.tdb</filename> files allows for this provision. Many smbd
3917 processes may write to the same <filename>*.tdb</filename> file at the
3918 same time. This wouldn't be possible with pure ASCII files.
3923 <title>Losing <filename>*.tdb</filename> Files</title>
3926 It is very important that all <filename>*.tdb</filename> files remain
3927 consistent over all write and read accesses. However, it may happen
3928 that these files <emphasis>do</emphasis> get corrupted. (A
3929 <command>kill -9 `pidof smbd`</command> while a write access is in
3930 progress could do the damage as well as a power interruption,
3931 etc.). In cases of trouble, a deletion of the old printing-related
3932 <filename>*.tdb</filename> files may be the only option. You need to
3933 re-create all print related setup after that. Or you have made a
3934 backup of the <filename>*.tdb</filename> files in time.
3939 <title>Using <emphasis>tdbbackup</emphasis></title>
3942 Samba ships with a little utility which helps the root user of your
3943 system to back up your <filename>*.tdb</filename> files. If you run it
3944 with no argument, it prints a little usage message:
3950 Usage: tdbbackup [options] <fname...>
3953 -h this help message
3954 -s suffix set the backup suffix
3955 -v veryify mode (restore if corrupt)
3960 Here is how I backed up my printing.tdb file:
3966 . browse.dat locking.tdb ntdrivers.tdb printing.tdb share_info.tdb
3967 .. connections.tdb messages.tdb ntforms.tdb printing.tdbkp unexpected.tdb
3968 brlock.tdb gmon.out namelist.debug ntprinters.tdb sessionid.tdb
3970 kde-bitshop:/var/lock/samba # tdbbackup -s .bak printing.tdb
3971 printing.tdb : 135 records
3973 kde-bitshop:/var/lock/samba # ls -l printing.tdb*
3974 -rw------- 1 root root 40960 May 2 03:44 printing.tdb
3975 -rw------- 1 root root 40960 May 2 03:44 printing.tdb.bak
3982 <title>CUPS Print Drivers from Linuxprinting.org</title>
3985 CUPS ships with good support for HP LaserJet type printers. You can
3986 install the generic driver as follows:
3991 lpadmin -p laserjet4plus -v parallel:/dev/lp0 -E -m laserjet.ppd
3996 The <parameter>-m</parameter> switch will retrieve the
3997 <filename>laserjet.ppd</filename> from the standard repository for
3998 not-yet-installed-PPDs, which CUPS typically stores in
3999 <filename>/usr/share/cups/model</filename>. Alternatively, you may use
4000 <parameter>-P /path/to/your.ppd</parameter>.
4004 The generic laserjet.ppd however does not support every special option
4005 for every LaserJet-compatible model. It constitutes a sort of "least
4006 denominator" of all the models. If for some reason it is ruled out to
4007 you to pay for the commercially available ESP Print Pro drivers, your
4008 first move should be to consult the database on <ulink
4009 url="http://www.linuxprinting.org/printer_list.cgi">http://www.linuxprinting.org/printer_list.cgi</ulink>.
4010 Linuxprinting.org has excellent recommendations about which driver is
4011 best used for each printer. Its database is kept current by the
4012 tireless work of Till Kamppeter from MandrakeSoft, who is also the
4013 principal author of the foomatic-rip utility.
4017 The former "cupsomatic" concept is now be replaced by the new, much
4018 more powerful "foomatic-rip". foomatic-rip is the successor of
4019 cupsomatic. cupsomatic is no longer maintained. Here is the new URL
4020 to the Foomatic-3.0 database:<ulink
4021 url="http://www.linuxprinting.org/driver_list.cgi">http://www.linuxprinting.org/driver_list.cgi</ulink>.
4022 If you upgrade to foomatic-rip, don't forget to also upgrade to the
4023 new-style PPDs for your foomatic-driven printers. foomatic-rip will
4024 not work with PPDs generated for the old cupsomatic. The new-style
4025 PPDs are 100% compliant to the Adobe PPD specification. They are
4026 intended to be used by Samba and the cupsaddsmb utility also, to
4027 provide the driver files for the Windows clients also!
4031 <title>foomatic-rip and Foomatic explained</title>
4034 Nowadays most Linux distros rely on the utilities of Linuxprinting.org
4035 to create their printing related software (which, BTW, works on all
4036 UNIXes and on Mac OS X or Darwin too). It is not known as well as it
4037 should be, that it also has a very end-user friendly interface which
4038 allows for an easy update of drivers and PPDs, for all supported
4039 models, all spoolers, all operatings systems and all package formats
4040 (because there is none). Its history goes back a few years.
4044 Recently Foomatic has achieved the astonishing milestone of <ulink
4045 url="http://www.linuxprinting.org/printer_list.cgi?make=Anyone">1000
4046 listed</ulink> printer models. Linuxprinting.org keeps all the
4047 important facts about printer drivers, supported models and which
4048 options are available for the various driver/printer combinations in
4050 url="http://www.linuxprinting.org/foomatic.html">Foomatic</ulink>
4051 database. Currently there are <ulink
4052 url="http://www.linuxprinting.org/driver_list.cgi">245 drivers</ulink>
4053 in the database: many drivers support various models, and many models
4054 may be driven by different drivers; it's your choice!
4058 <title>690 "perfect" Printers</title>
4061 At present there are 690 devices dubbed as working "perfectly", 181
4062 "mostly", 96 "partially" and 46 are "Paperweights". Keeping in mind
4063 that most of these are non-PostScript models (PostScript printers are
4064 automatically supported supported by CUPS to perfection, by using
4065 their own manufacturer-provided Windows-PPD...), and that a
4066 multifunctional device never qualifies as working "perfectly" if it
4067 doesn't also scan and copy and fax under GNU/Linux: then this is a
4068 truely astonishing achievement. Three years ago the number was not
4069 more than 500, and Linux or UNIX "printing" at the time wasn't
4070 anywhere near the quality it is today!
4075 <title>How the "Printing HOWTO" started it all</title>
4078 A few years ago <ulink
4079 url="http://www2.picante.com:81/~gtaylor/">Grant Taylor</ulink>
4080 started it all. The roots of today's Linuxprinting.org are in the
4082 url="http://www.linuxprinting.org/foomatic2.9/howto/">Linux Printing
4083 HOWTO</ulink> which he authored. As a side-project to this document,
4084 which served many Linux users and admins to guide their first steps in
4085 this complicated and delicate setup (to a scientist, printing is
4086 "applying a structured deposition of distinct patterns of ink or toner
4087 particles on paper substrates" <emphasis>;-)</emphasis>, he started to
4088 build in a little Postgres database with information about the
4089 hardware and driver zoo that made up Linux printing of the time. This
4090 database became the core component of today's Foomatic collection of
4091 tools and data. In the meantime it has moved to an XML representation
4097 <title>Foomatic's strange Name</title>
4100 "Why the funny name?", you ask. When it really took off, around spring
4101 2000, CUPS was far less popular than today, and most systems used LPD,
4102 LPRng or even PDQ to print. CUPS shipped with a few generic "drivers"
4103 (good for a few hundred different printer models). These didn't
4104 support many device-specific options. CUPS also shipped with its own
4105 built-in rasterization filter ("pstoraster", derived from
4106 Ghostscript). On the other hand, CUPS provided brilliant support for
4107 <emphasis>controlling</emphasis> all printer options through
4108 standardized and well-defined "PPD files" (PostScript Printers
4109 Description files). Plus, CUPS was designed to be easily extensible.
4113 Grant already had in his database a respectable compilation
4114 of facts about a many more printers, and the Ghostscript "drivers"
4115 they run with. His idea, to generate PPDs from the database info
4116 and use them to make standard Ghostscript filters work within CUPS,
4117 proved to work very well. It also "killed several birds with one
4122 <listitem><para>It made all current and future Ghostscript filter
4123 developments available for CUPS;</para></listitem>
4125 <listitem><para>It made available a lot of additional printer models
4126 to CUPS users (because often the "traditional" Ghostscript way of
4127 printing was the only one available);</para></listitem>
4129 <listitem><para>It gave all the advanced CUPS options (web interface,
4130 GUI driver configurations) to users wanting (or needing) to use
4131 Ghostscript filters.</para></listitem>
4136 <title>cupsomatic, pdqomatic, lpdomatic, directomatic</title>
4139 CUPS worked through a quickly-hacked up filter script named <ulink
4140 url="http://www.linuxprinting.org/download.cgi?filename=cupsomatic&show=0">cupsomatic</ulink>.
4141 cupsomatic ran the printfile through Ghostscript, constructing
4142 automatically the rather complicated command line needed. It just
4143 required to be copied into the CUPS system to make it work. To
4144 "configure" the way cupsomatic controls the Ghostscript rendering
4145 process, it needs a CUPS-PPD. This PPD is generated directly from the
4146 contents of the database. For CUPS and the respective printer/filter
4147 combo another Perl script named "CUPS-O-Matic" did the PPD
4148 generation. After that was working, Grant implemented within a few
4149 days a similar thing for two other spoolers. Names chosen for the
4150 config-generator scripts were <ulink
4151 url="http://www.linuxprinting.org/download.cgi?filename=lpdomatic&show=0">PDQ-O-Matic</ulink>
4152 (for PDQ) and <ulink
4153 url="http://www.linuxprinting.org/download.cgi?filename=lpdomatic&show=0">LPD-O-Matic</ulink>
4154 (for - you guessed it - LPD); the configuration here didn't use PPDs
4155 but other spooler-specific files.
4159 From late summer of that year, <ulink
4160 url="http://www.linuxprinting.org/till/">Till Kamppeter</ulink>
4161 started to put work into the database. Till had been newly employed by
4162 <ulink url="http://www.mandrakesoft.com/">MandrakeSoft</ulink> to
4163 convert their printing system over to CUPS, after they had seen his
4164 <ulink url="http://www.fltk.org/">FLTK</ulink>-based <ulink
4165 url="http://cups.sourceforge.net/xpp/">XPP</ulink> (a GUI frontend to
4166 the CUPS lp-command). He added a huge amount of new information and new
4167 printers. He also developed the support for other spoolers, like
4168 <ulink url="http://ppr.sourceforge.net/">PPR</ulink> (via ppromatic),
4169 <ulink url="http://sourceforge.net/projects/lpr/">GNUlpr</ulink> and
4170 <ulink url="http://www.lprng.org/">LPRng</ulink> (both via an extended
4171 lpdomatic) and "spoolerless" printing (<ulink
4172 url="http://www.linuxprinting.org/download.cgi?filename=directomatic&show=0">directomatic</ulink>)....
4176 So, to answer your question: "Foomatic" is the general name for all
4177 the overlapping code and data behind the "*omatic" scripts.... --
4178 Foomatic up to versions 2.0.x required (ugly) Perl data structures
4179 attached the Linuxprinting.org PPDs for CUPS. It had a different
4180 "*omatic" script for every spooler, as well as different printer
4181 configuration files..
4186 <title>7.13.1.5.The <emphasis>Grand Unification</emphasis>
4190 This all has changed in Foomatic versions 2.9 (Beta) and released as
4191 "stable" 3.0. This has now achieved the convergence of all *omatic
4192 scripts: it is called the <ulink
4193 url="http://www.linuxprinting.org/foomatic2.9/download.cgi?filename=foomatic-rip&show=0">foomatic-rip</ulink>.
4194 This single script is the unification of the previously different
4195 spooler-specific *omatic scripts. foomatic-rip is used by all the
4196 different spoolers alike. Because foomatic-rip can read PPDs (both the
4197 original PostScript printer PPDs and the Linuxprinting.org-generated
4198 ones), all of a sudden all supported spoolers can have the power of
4199 PPDs at their disposal; users only need to plug "foomatic-rip" into
4200 their system.... For users there is improved media type and source
4201 support; paper sizes and trays are easier to configure.
4205 Also, the New Generation of Linuxprinting.org PPDs doesn't contain
4206 Perl data structures any more. If you are a distro maintainer and have
4207 used the previous version of Foomatic, you may want to give the new
4208 one a spin: but don't forget to generate a new-version set of PPDs,
4210 url="http://www.linuxprinting.org/download/foomatic/foomatic-db-engine-3.0.0beta1.tar.gz">foomatic-db-engine</ulink>!
4211 Individual users just need to generate a single new PPD specific to
4212 their model by <ulink
4213 url="http://www.linuxprinting.org/kpfeifle/LinuxKongress2002/Tutorial/II.Foomatic-User/II.tutorial-handout-foomatic-user.html">following
4214 the steps</ulink> outlined in the Foomatic tutorial or further
4215 below. This new development is truly amazing.
4219 foomatic-rip is a very clever wrapper around the need to run
4220 Ghostscript with a different syntax, different options, different
4221 device selections and/or different filters for each different printer
4222 or different spooler. At the same time it can read the PPD associated
4223 with a print queue and modify the print job according to the user
4224 selections. Together with this comes the 100% compliance of the new
4225 Foomatic PPDs with the Adobe spec. Some really innovative features of
4226 the Foomatic concept will surprise users: it will support custom paper
4227 sizes for many printers; and it will support printing on media drawn
4228 from different paper trays within the same job (in both cases: even
4229 where there is no support for this from Windows-based vendor printer
4235 <title>Driver Development outside</title>
4238 Most driver development itself does not happen within
4239 Linuxprinting.org. Drivers are written by independent maintainers.
4240 Linuxprinting.org just pools all the information, and stores it in its
4241 database. In addition, it also provides the Foomatic glue to integrate
4242 the many drivers into any modern (or legacy) printing system known to
4247 Speaking of the different driver development groups: most of
4248 the work is currently done in three projects. These are:
4252 <listitem><para><ulink
4253 url="http://www-124.ibm.com/developerworks/oss/linux/projects/omni/">Omni</ulink>
4254 -- a Free Software project by IBM which tries to convert their printer
4255 driver knowledge from good-ol' OS/2 times into a modern, modular,
4256 universal driver architecture for Linux/Unix (still Beta). This
4257 currently supports 437 models.</para></listitem>
4259 <listitem><para><ulink url="http://hpinkjet.sf.net/">HPIJS</ulink> --
4260 a Free Software project by HP to provide the support for their own
4261 range of models (very mature, printing in most cases is perfect and
4262 provides true photo quality). This currently supports 369
4263 models.</para></listitem>
4265 <listitem><para><ulink
4266 url="http://gimp-print.sf.net/">Gimp-Print</ulink> -- a Free software
4267 effort, started by Michael Sweet (also lead developer for CUPS), now
4268 directed by Robert Krawitz, which has achieved an amazing level of
4269 photo print quality (many Epson users swear that its quality is
4270 better than the vendor drivers provided by Epson for the Microsoft
4271 platforms). This currently supports 522 models.</para></listitem>
4276 <title>Forums, Downloads, Tutorials, Howtos -- also for Mac OS X and
4277 commercial Unix</title>
4280 Linuxprinting.org today is the one-stop "shop" to download printer
4281 drivers. Look for printer information and <ulink
4282 url="http://www.linuxprinting.org//kpfeifle/LinuxKongress2002/Tutorial/">tutorials</ulink>
4283 or solve printing problems in its popular <ulink
4284 url="http://www.linuxprinting.org/newsportal/">forums</ulink>. But
4285 it's not just for GNU/Linux: users and admins of <ulink
4286 url="http://www.linuxprinting.org/macosx/">commercial UNIX
4287 systems</ulink> are also going there, and the relatively new <ulink
4288 url="http://www.linuxprinting.org/newsportal/thread.php3?name=linuxprinting.macosx.general">Mac
4289 OS X forum</ulink> has turned out to be one of the most frequented
4290 fora after only a few weeks.
4294 Linuxprinting.org and the Foomatic driver wrappers around Ghostscript
4295 are now a standard toolchain for printing on all the important
4296 distros. Most of them also have CUPS underneath. While in recent years
4297 most printer data had been added by Till (who works at Mandrake), many
4298 additional contributions came from engineers with SuSE, RedHat,
4299 Connectiva, Debian and others. Vendor-neutrality is an important goal
4300 of the Foomatic project.
4304 Till Kamppeter from MandrakeSoft is doing an excellent job in his
4305 spare time to maintain Linuxprinting.org and Foomatic. So if you use
4306 it often, please send him a note showing your appreciation.
4311 <title>Foomatic Database generated PPDs</title>
4314 The Foomatic database is an amazing piece of ingenuity in itself. Not
4315 only does it keep the printer and driver information, but it is
4316 organized in a way that it can generate "PPD" files "on the fly" from
4317 its internal XML-based datasets. While these PPDs are modelled to the
4318 Adobe specification of "PostScript Printer Descriptions" (PPDs), the
4319 Linuxprinting.org/Foomatic-PPDs don't normally drive PostScript
4320 printers: they are used to describe all the bells and whistles you
4321 could ring or blow on an Epson Stylus inkjet, or a HP Photosmart or
4322 what-have-you. The main "trick" is one little additional line, not
4323 envisaged by the PPD specification, starting with the "*cupsFilter"
4324 keyword: it tells the CUPS daemon how to proceed with the PostScript
4325 print file (old-style Foomatic-PPDs named the
4326 <emphasis>cupsomatic</emphasis> filter script, while the new-style
4327 PPDs now call <emphasis>foomatic-rip</emphasis>). This filter
4328 script calls Ghostscript on the host system (the recommended variant
4329 is ESP Ghostscript) to do the rendering work. foomatic-rip knows which
4330 filter or internal device setting it should ask from Ghostscript to
4331 convert the PostScript printjob into a raster format ready for the
4332 target device. This usage of PPDs to describe the options of non-PS
4333 printers was the invention of the CUPS developers. The rest is easy:
4334 GUI tools (like KDE's marvellous <ulink
4335 url="http://printing.kde.org/overview/kprinter.phtml">"kprinter"</ulink>,
4337 url="http://gtklp.sourceforge.net/">"gtklp"</ulink>, "xpp" and the CUPS
4338 web interface) read the PPD too and use this information to present
4339 the available settings to the user as an intuitive menu selection.
4345 <title>foomatic-rip and Foomatic-PPD Download and Installation</title>
4348 Here are the steps to install a foomatic-rip driven "LaserJet 4 Plus"
4349 compatible printer in CUPS (note that recent distributions of SuSE,
4350 UnitedLinux and Mandrake may ship with a complete package of
4351 Foomatic-PPDs plus the foomatic-rip utility. going directly to
4352 Linuxprinting.org ensures you to get the latest driver/PPD files):
4355 <listitem><para>Surf to <ulink
4356 url="http://www.linuxprinting.org/printer_list.cgi">http://www.linuxprinting.org/printer_list.cgi</ulink>
4359 <listitem><para>Check the complete list of printers in the database:
4361 url="http://www.linuxprinting.org/printer_list.cgi?make=Anyone">http://www.linuxprinting.org/printer_list.cgi?make=Anyone</ulink>
4364 <listitem><para>There select your model and click on the
4365 link.</para></listitem>
4367 <listitem><para>You'll arrive at a page listing all drivers working
4368 with this model (for all printers, there will always be
4369 <emphasis>one</emphasis> recommended driver. Try this one
4370 first).</para></listitem>
4372 <listitem><para>In our case ("HP LaserJet 4 Plus"), we'll arrive here:
4374 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>
4377 <listitem><para>The recommended driver is "ljet4".</para></listitem>
4379 <listitem><para>There are several links provided here. You should
4380 visit them all, if you are not familiar with the Linuxprinting.org
4381 database.</para></listitem>
4383 <listitem><para>There is a link to the database page for the "ljet4":
4385 url="http://www.linuxprinting.org/show_driver.cgi?driver=ljet4">http://www.linuxprinting.org/show_driver.cgi?driver=ljet4</ulink>
4386 On the driver's page, you'll find important and detailed information
4387 about how to use that driver within the various available
4388 spoolers.</para></listitem>
4390 <listitem><para>Another link may lead you to the homepage of the
4391 driver author or the driver.</para></listitem>
4393 <listitem><para>Important links are the ones which provide hints with
4394 setup instructions for CUPS (<ulink
4395 url="http://www.linuxprinting.org/cups-doc.html">http://www.linuxprinting.org/cups-doc.html</ulink>),
4397 url="http://www.linuxprinting.org/pdq-doc.html">http://www.linuxprinting.org/pdq-doc.html</ulink>),
4398 LPD, LPRng and GNUlpr (<ulink
4399 url="http://www.linuxprinting.org/lpd-doc.html">http://www.linuxprinting.org/lpd-doc.html</ulink>)
4400 as well as PPR (<ulink
4401 url="http://www.linuxprinting.org/ppr-doc.html">http://www.linuxprinting.org/ppr-doc.html)</ulink>
4402 or "spooler-less" printing (<ulink
4403 url="http://www.linuxprinting.org/direct-doc.html">http://www.linuxprinting.org/direct-doc.html</ulink>
4404 ).</para></listitem>
4406 <listitem><para>You can view the PPD in your browser through this
4408 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>
4409 </para></listitem> <listitem><para>You can also (most importantly)
4410 generate and download the PPD: <ulink
4411 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>
4414 <listitem><para>The PPD contains all the information needed to use our
4415 model and the driver; this is, once installed, working transparently
4416 for the user. Later you'll only need to choose resolution, paper size
4417 etc. from the web-based menu, or from the print dialog GUI, or from
4418 the commandline.</para></listitem>
4420 <listitem><para>Should you have ended up on the driver's page (<ulink
4421 url="http://www.linuxprinting.org/show_driver.cgi?driver=ljet4">http://www.linuxprinting.org/show_driver.cgi?driver=ljet4</ulink>),
4422 you can choose to use the "PPD-O-Matic" online PPD generator
4423 program.</para></listitem>
4425 <listitem><para>Select the exact model and check either "download" or
4426 "display PPD file" and click on "Generate PPD file".</para></listitem>
4428 <listitem><para>If you save the PPD file from the browser view, please
4429 don't use "cut'n'past" (since it could possibly damage line endings
4430 and tabs, which makes the PPD likely to fail its duty), but use "Save
4431 as..." in your browser's menu. (Best is to use the "download" option
4432 from the web page directly).</para></listitem>
4434 <listitem><para>Another very interesting part on each driver page is
4435 the <emphasis>Show execution details</emphasis> button. If you
4436 select your printer model and click that button, you will get
4437 displayed a complete Ghostscript command line, enumerating all options
4438 available for that driver/printermodel combo. This is a great way to
4439 "Learn Ghostscript By Doing". It is also an excellent "cheat sheet"
4440 for all experienced users who need to re-construct a good command line
4441 for that damn printing script, but can't remember the exact
4442 syntax. ;-)</para></listitem>
4444 <listitem><para>Some time during your visit to Linuxprinting.org, save
4445 the PPD to a suitable place on your harddisk, say
4446 <filename>/path/to/my-printer.ppd</filename> (if you prefer to install
4447 your printers with the help of the CUPS web interface, save the PPD to
4448 the <filename>/usr/share/cups/model/</filename> path and re-start
4449 cupsd).</para></listitem>
4451 <listitem><para>Then install the printer with a suitable commandline,
4457 lpadmin -p laserjet4plus -v parallel:/dev/lp0 -E -P path/to/my-printer.ppd
4459 </screen></para></listitem>
4461 <listitem><para>Note again this: for all the new-style "Foomatic-PPDs"
4462 from Linuxprinting.org, you also need a special "CUPS filter" named
4463 "foomatic-rip".Get the latest version of "foomatic-rip" from: <ulink
4464 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>
4467 <listitem><para>The foomatic-rip Perlscript itself also makes some
4468 interesting reading (<ulink
4469 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>),
4470 because it is very well documented by Till's inline comments (even
4471 non-Perl hackers will learn quite a bit about printing by reading
4472 it... ;-)</para></listitem>
4474 <listitem><para>Save foomatic-rip either directly in
4475 <filename>/usr/lib/cups/filter/foomatic-rip</filename> or somewhere in
4476 your $PATH (and don't forget to make it world-executable). Again,
4477 don't save by "copy'n'paste" but use the appropriate link, or the
4478 "Save as..." menu item in your browser.</para></listitem>
4480 <listitem><para>If you save foomatic-rip in your $PATH, create a symlink:
4481 <command>cd /usr/lib/cups/filter/ ; ln -s `which
4482 foomatic-rip`</command>. For CUPS to discover this new
4483 available filter at startup, you need to re-start
4484 cupsd.</para></listitem>
4488 Once you print to a printqueue set up with the Foomatic-PPD, CUPS will
4489 insert the appropriate commands and comments into the resulting
4490 PostScript jobfile. foomatic-rip is able to read and act upon
4491 these. foomatic-rip uses some specially encoded Foomatic comments,
4492 embedded in the jobfile. These in turn are used to construct
4493 (transparently for you, the user) the complicated ghostscript command
4494 line telling for the printer driver how exactly the resulting raster
4495 data should look like and which printer commands to embed into the
4505 <listitem><para>A "foomatic+something" PPD -- but it this not enough
4506 to print with CUPS (it is only <emphasis>one</emphasis> important
4507 component)</para></listitem>
4509 <listitem><para>The "foomatic-rip" filter script (Perl) in
4510 /usr/lib/cups/filters/</para></listitem>
4512 <listitem><para>Perl to make foomatic-rip run</para></listitem>
4514 <listitem><para>Ghostscript (because it is doing the main work,
4515 controlled by the PPD/foomatic-rip combo) to produce the raster data
4516 fit for your printermodel's consumption</para></listitem>
4518 <listitem><para>Ghostscript <emphasis>must</emphasis> (depending on
4519 the driver/model) contain support for a certain "device", representing
4520 the selected "driver" for your model (as shown by "gs
4521 -h")</para></listitem>
4523 <listitem><para>foomatic-rip needs a new version of PPDs (PPD versions
4524 produced for cupsomatic don't work with
4525 foomatic-rip).</para></listitem>
4531 <title>Page Accounting with CUPS</title>
4534 Often there are questions regarding "print quotas" wherein Samba users
4535 (that is, Windows clients) should not be able to print beyond a
4536 certain amount of pages or data volume per day, week or month. This
4537 feature is dependent on the real print subsystem you're using.
4538 Samba's part is always to receive the job files from the clients
4539 (filtered <emphasis>or</emphasis> unfiltered) and hand it over to this
4544 Of course one could "hack" things with one's own scripts. But then
4545 there is CUPS. CUPS supports "quotas" which can be based on sizes of
4546 jobs or on the number of pages or both, and are spanning any time
4551 <title>Setting up Quotas</title>
4554 This is an example command how root would set a print quota in CUPS,
4555 assuming an existing printer named "quotaprinter":
4560 lpadmin -p quotaprinter -o job-quota-period=604800 -o job-k-limit=1024 -o job-page-limit=100
4565 This would limit every single user to print 100 pages or 1024 KB of
4566 data (whichever comes first) within the last 604,800 seconds ( = 1
4572 <title>Correct and incorrect Accounting</title>
4575 For CUPS to count correctly, the printfile needs to pass the CUPS
4576 "pstops" filter, otherwise it uses a "dummy" count of "1". Some
4577 printfiles don't pass it (eg: image files) but then those are mostly 1
4578 page jobs anyway. This also means that proprietary drivers for the
4579 target printer running on the client computers and CUPS/Samba, which
4580 then spool these files as "raw" (i.e. leaving them untouched, not
4581 filtering them), will be counted as "1-pagers" too!
4585 You need to send PostScript from the clients (i.e. run a PostScript
4586 driver there) to have the chance to get accounting done. If the
4587 printer is a non-PostScript model, you need to let CUPS do the job to
4588 convert the file to a print-ready format for the target printer. This
4589 will be working for currently about 1,000 different printer models,
4591 url="http://www.linuxprinting.org/printer_list.cgi">http://www.linuxprinting.org/printer_list.cgi</ulink>).
4596 <title>Adobe and CUPS PostScript Drivers for Windows Clients</title>
4599 Before CUPS-1.1.16 your only option was to use the Adobe PostScript
4600 Driver on the Windows clients. The output of this driver was not
4601 always passed through the "pstops" filter on the CUPS/Samba side, and
4602 therefore was not counted correctly (the reason is that it often,
4603 depending on the "PPD" being used, wrote a "PJL"-header in front of
4604 the real PostScript which caused CUPS to skip pstops and go directly
4605 to the "pstoraster" stage).
4609 From CUPS-1.1.16 onward you can use the "CUPS PostScript Driver for
4610 Windows NT/2K/XP clients" (which is tagged in the download area of
4611 http://www.cups.org/ as the "cups-samba-1.1.16.tar.gz" package). It does
4612 <emphasis>not</emphasis> work for Win9x/ME clients. But it guarantees:
4617 <listitem><para>to not write an PJL-header</para></listitem>
4619 <listitem><para>to still read and support all PJL-options named in the
4620 driver PPD with its own means</para></listitem>
4622 <listitem><para> that the file will pass through the "pstops" filter
4623 on the CUPS/Samba server</para></listitem>
4625 <listitem><para>to page-count correctly the
4626 printfile</para></listitem>
4630 You can read more about the setup of this combination in the manpage
4631 for "cupsaddsmb" (which is only present with CUPS installed, and only
4632 current from CUPS 1.1.16).
4637 <title>The page_log File Syntax</title>
4640 These are the items CUPS logs in the "page_log" for every
4641 single <emphasis>page</emphasis> of a job:
4645 <listitem><para>Printer name</para></listitem>
4647 <listitem><para>User name</para></listitem>
4649 <listitem><para>Job ID</para></listitem>
4651 <listitem><para>Time of printing</para></listitem>
4653 <listitem><para>the page number</para></listitem>
4655 <listitem><para>the number of copies</para></listitem>
4657 <listitem><para>a billing information string
4658 (optional)</para></listitem>
4660 <listitem><para>the host which sent the job (included since version
4661 1.1.19)</para></listitem>
4665 Here is an extract of my CUPS server's page_log file to illustrate the
4666 format and included items:
4671 infotec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 1 3 #marketing 10.160.50.13
4672 infotec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 2 3 #marketing 10.160.50.13
4673 infotec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 3 3 #marketing 10.160.50.13
4674 infotec_IS2027 kurt 401 [22/Apr/2003:10:28:43 +0100] 4 3 #marketing 10.160.50.13
4675 DigiMaster9110 boss 402 [22/Apr/2003:10:33:22 +0100] 1 440 finance-dep 10.160.51.33
4680 This was job ID "401", printed on "infotec_IS2027" by user "kurt", a
4681 64-page job printed in 3 copies and billed to "#marketing", sent
4682 from IP address 10.160.50.13. The next job had ID "402", was sent by
4683 user "boss" from IP address 10.160.51.33,printed from one page 440
4684 copies and is set to be billed to "finance-dep".
4689 <title>Possible Shortcomings</title>
4692 What flaws or shortcomings are there with this quota system?
4696 <listitem><para>the ones named above (wrongly logged job in case of
4697 printer hardware failure, etc.)</para></listitem>
4699 <listitem><para>in reality, CUPS counts the job pages that are being
4700 processed in <emphasis>software</emphasis> (that is, going through the
4701 "RIP") rather than the physical sheets successfully leaving the
4702 printing device. Thus if there is a jam while printing the 5th sheet out
4703 of 1000 and the job is aborted by the printer, the "page count" will
4704 still show the figure of 1000 for that job</para></listitem>
4706 <listitem><para>all quotas are the same for all users (no flexibility
4707 to give the boss a higher quota than the clerk) no support for
4708 groups</para></listitem>
4710 <listitem><para>no means to read out the current balance or the
4711 "used-up" number of current quota</para></listitem>
4713 <listitem><para>a user having used up 99 sheets of 100 quota will
4714 still be able to send and print a 1,000 sheet job</para></listitem>
4716 <listitem><para>a user being denied a job because of a filled-up quota
4717 doesn't get a meaningful error message from CUPS other than
4718 "client-error-not-possible".</para></listitem>
4723 <title>Future Developments</title>
4726 This is the best system currently available, and there are huge
4727 improvements under development for CUPS 1.2:
4731 <listitem><para>page counting will go into the "backends" (these talk
4732 directly to the printer and will increase the count in sync with the
4733 actual printing process: thus a jam at the 5th sheet will lead to a
4734 stop in the counting)</para></listitem>
4736 <listitem><para>quotas will be handled more flexibly</para></listitem>
4738 <listitem><para>probably there will be support for users to inquire
4739 their "accounts" in advance</para></listitem>
4741 <listitem><para>probably there will be support for some other tools
4742 around this topic</para></listitem>
4747 <title>Other Accounting Tools</title>
4750 PrintAnalyzer, pyKota, printbill, LogReport.
4756 <title>Additional Material</title>
4759 A printer queue with <emphasis>no</emphasis> PPD associated to it is a
4760 "raw" printer and all files will go directly there as received by the
4761 spooler. The exceptions are file types "application/octet-stream"
4762 which need "passthrough feature" enabled. "Raw" queues don't do any
4763 filtering at all, they hand the file directly to the CUPS backend.
4764 This backend is responsible for the sending of the data to the device
4765 (as in the "device URI" notation: <filename>lpd://, socket://,
4766 smb://, ipp://, http://, parallel:/, serial:/, usb:/</filename> etc.)
4770 "cupsomatic"/Foomatic are <emphasis>not</emphasis> native CUPS drivers
4771 and they don't ship with CUPS. They are a Third Party add-on,
4772 developed at Linuxprinting.org. As such, they are a brilliant hack to
4773 make all models (driven by Ghostscript drivers/filters in traditional
4774 spoolers) also work via CUPS, with the same (good or bad!) quality as
4775 in these other spoolers. "cupsomatic" is only a vehicle to execute a
4776 ghostscript commandline at that stage in the CUPS filtering chain,
4777 where "normally" the native CUPS "pstoraster" filter would kick
4778 in. cupsomatic by-passes pstoraster, "kidnaps" the printfile from CUPS
4779 away and re-directs it to go through Ghostscript. CUPS accepts this,
4780 because the associated CUPS-O-Matic-/Foomatic-PPD specifies:
4785 *cupsFilter: "application/vnd.cups-postscript 0 cupsomatic"
4790 This line persuades CUPS to hand the file to cupsomatic, once it has
4791 successfully converted it to the MIME type
4792 "application/vnd.cups-postscript". This conversion will not happen for
4793 Jobs arriving from Windows which are auto-typed
4794 "application/octet-stream", with the according changes in
4795 <filename>/etc/cups/mime.types</filename> in place.
4799 CUPS is widely configurable and flexible, even regarding its filtering
4800 mechanism. Another workaround in some situations would be to have in
4801 <filename>/etc/cups/mime.types</filename> entries as follows:
4806 application/postscript application/vnd.cups-raw 0 -
4807 application/vnd.cups-postscript application/vnd.cups-raw 0 -
4812 This would prevent all Postscript files from being filtered (rather,
4813 they will through the virtual <emphasis>nullfilter</emphasis>
4814 denoted with "-"). This could only be useful for PS printers. If you
4815 want to print PS code on non-PS printers (provided they support ASCII
4816 text printing) an entry as follows could be useful:
4821 */* application/vnd.cups-raw 0 -
4826 and would effectively send <emphasis>all</emphasis> files to the
4827 backend without further processing.
4831 Lastly, you could have the following entry:
4836 application/vnd.cups-postscript application/vnd.cups-raw 0 my_PJL_stripping_filter
4841 You will need to write a <emphasis>my_PJL_stripping_filter</emphasis>
4842 (could be a shellscript) that parses the PostScript and removes the
4843 unwanted PJL. This would need to conform to CUPS filter design
4844 (mainly, receive and pass the parameters printername, job-id,
4845 username, jobtitle, copies, print options and possibly the
4846 filename). It would be installed as world executable into
4847 <filename>/usr/lib/cups/filters/</filename> and will be called by CUPS
4848 if it encounters a MIME type "application/vnd.cups-postscript".
4852 CUPS can handle <emphasis>-o job-hold-until=indefinite</emphasis>.
4853 This keeps the job in the queue "on hold". It will only be printed
4854 upon manual release by the printer operator. This is a requirement in
4855 many "central reproduction departments", where a few operators manage
4856 the jobs of hundreds of users on some big machine, where no user is
4857 allowed to have direct access (such as when the operators often need
4858 to load the proper paper type before running the 10,000 page job
4859 requested by marketing for the mailing, etc.).
4864 <title>Auto-Deletion or Preservation of CUPS Spool Files</title>
4867 Samba print files pass through two "spool" directories. One is the
4868 incoming directory managed by Samba, (set in the <emphasis>path =
4869 /var/spool/samba</emphasis> directive in the
4870 <emphasis>[printers]</emphasis> section of
4871 <filename>smb.conf</filename>). The other is the spool directory of
4872 your UNIX print subsystem. For CUPS it is normally
4873 <filename>/var/spool/cups/</filename>, as set by the cupsd.conf
4874 directive <filename>RequestRoot /var/spool/cups</filename>.
4878 <title>CUPS Configuration Settings explained</title>
4881 Some important parameter settings in the CUPS configuration file
4882 <filename>cupsd.conf</filename> are:
4887 <varlistentry><term>PreserveJobHistory Yes</term>
4889 This keeps some details of jobs in cupsd's mind (well it keeps the
4890 "c12345", "c12346" etc. files in the CUPS spool directory, which do a
4891 similar job as the old-fashioned BSD-LPD control files). This is set
4892 to "Yes" as a default.
4893 </para></listitem></varlistentry>
4895 <varlistentry><term>PreserveJobFiles Yes</term>
4897 This keeps the job files themselves in cupsd's mind
4898 (well it keeps the "d12345", "d12346" etc. files in the CUPS spool
4899 directory...). This is set to "No" as the CUPS
4901 </para></listitem></varlistentry>
4903 <varlistentry><term><emphasis>"MaxJobs 500"</emphasis></term>
4905 This directive controls the maximum number of jobs
4906 that are kept in memory. Once the number of jobs reaches the limit,
4907 the oldest completed job is automatically purged from the system to
4908 make room for the new one. If all of the known jobs are still
4909 pending or active then the new job will be rejected. Setting the
4910 maximum to 0 disables this functionality. The default setting is
4912 </para></listitem></varlistentry>
4916 (There are also additional settings for "MaxJobsPerUser" and
4917 "MaxJobsPerPrinter"...)
4922 <title>Pre-conditions</title>
4925 For everything to work as announced, you need to have three
4930 <listitem><para>a Samba-smbd which is compiled against "libcups" (Check
4931 on Linux by running "ldd `which smbd`")</para></listitem>
4933 <listitem><para>a Samba-<filename>smb.conf</filename> setting of
4934 "printing = cups"</para></listitem>
4936 <listitem><para>another Samba-<filename>smb.conf</filename> setting of
4937 "printcap = cups"</para></listitem>
4941 In this case all other manually set printing-related commands (like
4942 "print command", "lpq command", "lprm command", "lppause command" or
4943 "lpresume command") are ignored and they should normally have no
4944 influence what-so-ever on your printing.
4949 <title>Manual Configuration</title>
4952 If you want to do things manually, replace the "printing =
4953 cups" by "printing = bsd". Then your manually set commands may work
4954 (haven't tested this), and a "print command = lp -d %P %s; rm %s"
4955 may do what you need.
4961 <title>When <emphasis>not</emphasis> to use Samba to print to
4970 <title>In Case of Trouble.....</title>
4973 If you have more problems, post the output of these commands
4974 to the CUPS or Samba mailing lists (choose the one which seems more
4975 relevant to your problem):
4980 grep -v ^# /etc/cups/cupsd.conf | grep -v ^$
4981 grep -v ^# /etc/samba/smb.conf | grep -v ^$ | grep -v "^;"
4986 (adapt paths as needed). These commands leave out the empty
4987 lines and lines with comments, providing the "naked settings" in a
4988 compact way. Don't forget to name the CUPS and Samba versions you
4989 are using! This saves bandwidth and makes for easier readability
4990 for experts (and you are expecting experts to read them, right?
4995 <title>Where to find Documentation</title>
5003 <title>How to ask for Help</title>
5011 <title>Where to find Help</title>
5020 <title>Appendix</title>
5023 <title>Printing <emphasis>from</emphasis> CUPS to Windows attached
5027 From time to time the question arises, how you can print
5028 <emphasis>to</emphasis> a Windows attached printer
5029 <emphasis>from</emphasis> Samba. Normally the local connection
5030 "Windows host <--> printer" would be done by USB or parallel
5031 cable, but this doesn't matter to Samba. From here only an SMB
5032 connection needs to be opened to the Windows host. Of course, this
5033 printer must be "shared" first. As you have learned by now, CUPS uses
5034 <emphasis>backends</emphasis> to talk to printers and other
5035 servers. To talk to Windows shared printers you need to use the
5036 <emphasis>smb</emphasis> (surprise, surprise!) backend. Check if this
5037 is in the CUPS backend directory. This resides usually in
5038 <filename>/usr/lib/cups/backend/</filename>. You need to find a "smb"
5039 file there. It should be a symlink to <filename>smbspool</filename>
5040 which file must exist and be executable:
5045 # ls -l /usr/lib/cups/backend/
5047 drwxr-xr-x 3 root root 720 Apr 30 19:04 .
5048 drwxr-xr-x 6 root root 125 Dec 19 17:13 ..
5049 -rwxr-xr-x 1 root root 10692 Feb 16 21:29 canon
5050 -rwxr-xr-x 1 root root 10692 Feb 16 21:29 epson
5051 lrwxrwxrwx 1 root root 3 Apr 17 22:50 http -> ipp
5052 -rwxr-xr-x 1 root root 17316 Apr 17 22:50 ipp
5053 -rwxr-xr-x 1 root root 15420 Apr 20 17:01 lpd
5054 -rwxr-xr-x 1 root root 8656 Apr 20 17:01 parallel
5055 -rwxr-xr-x 1 root root 2162 Mar 31 23:15 pdfdistiller
5056 lrwxrwxrwx 1 root root 25 Apr 30 19:04 ptal -> /usr/local/sbin/ptal-cups
5057 -rwxr-xr-x 1 root root 6284 Apr 20 17:01 scsi
5058 lrwxrwxrwx 1 root root 17 Apr 2 03:11 smb -> /usr/bin/smbspool
5059 -rwxr-xr-x 1 root root 7912 Apr 20 17:01 socket
5060 -rwxr-xr-x 1 root root 9012 Apr 20 17:01 usb
5062 # ls -l `which smbspool`
5063 -rwxr-xr-x 1 root root 563245 Dec 28 14:49 /usr/bin/smbspool
5068 If this symlink doesn't exist, create it:
5073 # ln -s `which smbspool` /usr/lib/cups/backend/smb
5078 smbspool has been written by Mike Sweet from the CUPS folks. It is
5079 included and ships with Samba. It may also be used with print
5080 subsystems other than CUPS, to spool jobs to Windows printer shares. To
5081 set up printer "winprinter" on CUPS, you need to have a "driver" for
5082 it. Essentially this means to convert the print data on the CUPS/Samba
5083 host to a format that the printer can digest (the Windows host is
5084 unable to convert any files you may send). This also means you should
5085 be able to print to the printer if it were hooked directly at your
5086 Samba/CUPS host. For troubleshooting purposes, this is what you
5087 should do, to determine if that part of the process chain is in
5088 order. Then proceed to fix the network connection/authentication to
5089 the Windows host, etc.
5093 To install a printer with the smb backend on CUPS, use this command:
5098 # lpadmin -p winprinter -v smb://WINDOWSNETBIOSNAME/printersharename -P /path/to/PPD
5103 The <emphasis>PPD</emphasis> must be able to direct CUPS to generate
5104 the print data for the target model. For PostScript printers just use
5105 the PPD that would be used with the Windows NT PostScript driver. But
5106 what can you do if the printer is only accessible with a password? Or
5107 if the printer's host is part of another workgroup? This is provided
5108 for: you can include the required parameters as part of the
5109 <filename>smb://</filename> device-URI. Like this:
5114 smb://WORKGROUP/WINDOWSNETBIOSNAME/printersharename
5115 smb://username:password@WORKGROUP/WINDOWSNETBIOSNAME/printersharename
5116 smb://username:password@WINDOWSNETBIOSNAME/printersharename
5121 Note that the device-URI will be visible in the process list of the
5122 Samba server (e.g. when someone uses the <command>ps -aux</command>
5123 command on Linux), even if the username and passwords are sanitized
5124 before they get written into the log files. So this is an inherently
5125 insecure option. However it is the only one. Don't use it if you want
5126 to protect your passwords. Better share the printer in a way that
5127 doesn't require a password! Printing will only work if you have a
5128 working netbios name resolution up and running. Note that this is a
5129 feature of CUPS and you don't necessarily need to have smbd running
5130 (but who wants that? :-).
5135 <title>More CUPS filtering Chains</title>
5138 The following diagrams reveal how CUPS handles print jobs.
5142 #########################################################################
5144 # CUPS in and of itself has this (general) filter chain (CAPITAL
5145 # letters are FILE-FORMATS or MIME types, other are filters (this is
5146 # true for pre-1.1.15 of pre-4.3 versions of CUPS and ESP PrintPro):
5148 # SOMETHNG-FILEFORMAT
5154 # APPLICATION/POSTSCRIPT
5160 # APPLICATION/VND.CUPS-POSTSCRIPT
5163 # pstoraster # as shipped with CUPS, independent from any Ghostscipt
5164 # | # installation on the system
5165 # | (= "postscipt interpreter")
5167 # APPLICATION/VND.CUPS-RASTER
5170 # rastertosomething (e.g. Gimp-Print filters may be plugged in here)
5171 # | (= "raster driver")
5173 # SOMETHING-DEVICE-SPECIFIC
5179 # ESP PrintPro has some enhanced "rastertosomething" filters as compared to
5180 # CUPS, and also a somewhat improved "pstoraster" filter.
5182 # NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
5183 # CUPS and ESP PrintPro plug-in where rastertosomething is noted.
5185 #########################################################################
5189 #########################################################################
5191 # This is how "cupsomatic" comes into play:
5192 # =========================================
5194 # SOMETHNG-FILEFORMAT
5200 # APPLICATION/POSTSCRIPT
5206 # APPLICATION/VND.CUPS-POSTSCRIPT ----------------+
5209 # pstoraster (constructs complicated
5210 # | (= "postscipt interpreter") Ghostscript commandline
5211 # | to let the file be
5213 # APPLICATION/VND.CUPS-RASTER "-sDEVICE=s.th."
5216 # rastertosomething V
5217 # | (= "raster driver") +-------------------------+
5218 # | | Ghostscript at work.... |
5220 # SOMETHING-DEVICE-SPECIFIC *-------------------------+
5223 # backend <------------------------------------+
5229 # Note, that cupsomatic "kidnaps" the printfile after the
5230 # "APPLICATION/VND.CUPS-POSTSCRPT" stage and deviates it gh
5231 # the CUPS-external, systemwide Ghostscript installation, bypassing the
5232 # "pstoraster" filter (therefore also bypassing the CUPS-raster-drivers
5233 # "rastertosomething", and hands the rasterized file directly to the CUPS
5236 # cupsomatic is not made by the CUPS developers. It is an independent
5237 # contribution to printing development, made by people from
5238 # Linuxprinting.org. (see also http://www.cups.org/cups-help.html)
5240 # NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
5241 # CUPS and ESP PrintPro plug-in where rastertosomething is noted.
5243 #########################################################################
5247 #########################################################################
5249 # And this is how it works for ESP PrintPro from 4.3:
5250 # ===================================================
5252 # SOMETHNG-FILEFORMAT
5258 # APPLICATION/POSTSCRIPT
5264 # APPLICATION/VND.CUPS-POSTSCRIPT
5268 # | (= "postscipt interpreter")
5270 # APPLICATION/VND.CUPS-RASTER
5273 # rastertosomething (e.g. Gimp-Print filters may be plugged in here)
5274 # | (= "raster driver")
5276 # SOMETHING-DEVICE-SPECIFIC
5281 # NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
5282 # CUPS and ESP PrintPro plug-in where rastertosomething is noted.
5284 #########################################################################
5288 #########################################################################
5290 # This is how "cupsomatic" would come into play with ESP PrintPro:
5291 # ================================================================
5294 # SOMETHNG-FILEFORMAT
5300 # APPLICATION/POSTSCRIPT
5306 # APPLICATION/VND.CUPS-POSTSCRIPT ----------------+
5309 # gsrip (constructs complicated
5310 # | (= "postscipt interpreter") Ghostscript commandline
5311 # | to let the file be
5313 # APPLICATION/VND.CUPS-RASTER "-sDEVICE=s.th."
5316 # rastertosomething V
5317 # | (= "raster driver") +-------------------------+
5318 # | | Ghostscript at work.... |
5320 # SOMETHING-DEVICE-SPECIFIC *-------------------------+
5323 # backend <------------------------------------+
5328 # NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
5329 # CUPS and ESP PrintPro plug-in where rastertosomething is noted.
5331 #########################################################################
5335 #########################################################################
5337 # And this is how it works for CUPS from 1.1.15:
5338 # ==============================================
5340 # SOMETHNG-FILEFORMAT
5346 # APPLICATION/POSTSCRIPT
5352 # APPLICATION/VND.CUPS-POSTSCRIPT-----+
5353 # +------------------v------------------------------+
5357 # | "-sDEVICE=cups") |
5359 # | (= "postscipt interpreter") |
5361 # +------------------v------------------------------+
5363 # APPLICATION/VND.CUPS-RASTER >-------+
5367 # | (= "raster driver")
5369 # SOMETHING-DEVICE-SPECIFIC
5375 # NOTE: since version 1.1.15 CUPS "outsourced" the pstoraster process to
5376 # Ghostscript. GNU Ghostscript needs to be patched to handle the
5377 # CUPS requirement; ESP Ghostscript has this builtin. In any case,
5378 # "gs -h" needs to show up a "cups" device. pstoraster is now a
5379 # calling an appropriate "gs -sDEVICE=cups..." commandline to do
5380 # the job. It will output "application/vnd.cup-raster", which will
5381 # be finally processed by a CUPS raster driver "rastertosomething"
5382 # Note the difference to "cupsomatic", which will <emphasis>not</emphasis> output
5383 # CUPS-raster, but a final version of the printfile, ready to be
5384 # sent to the printer. cupsomatic also doesn't use the "cups"
5385 # devicemode in Ghostscript, but one of the classical devicemodes....
5387 # NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
5388 # CUPS and ESP PrintPro plug-in where rastertosomething is noted.
5390 #########################################################################
5394 #########################################################################
5396 # And this is how it works for CUPS from 1.1.15, with cupsomatic included:
5397 # ========================================================================
5399 # SOMETHNG-FILEFORMAT
5405 # APPLICATION/POSTSCRIPT
5411 # APPLICATION/VND.CUPS-POSTSCRIPT-----+
5412 # +------------------v------------------------------+
5413 # | Ghostscript . Ghostscript at work.... |
5414 # | at work... . (with "-sDEVICE= |
5415 # | (with . s.th." |
5416 # | "-sDEVICE=cups") . |
5418 # | (CUPS standard) . (cupsomatic) |
5420 # | (= "postscript interpreter") |
5422 # +------------------v--------------v---------------+
5424 # APPLICATION/VND.CUPS-RASTER >-------+ |
5427 # rastertosomething |
5428 # | (= "raster driver") |
5430 # SOMETHING-DEVICE-SPECIFIC >------------------------+
5436 # NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
5437 # CUPS and ESP PrintPro plug-in where rastertosomething is noted.
5439 ##########################################################################
5444 <title>Trouble Shooting Guidelines to fix typical Samba printing
5448 This is a short description of how to debug printing problems
5449 with Samba. This describes how to debug problems with printing from
5450 a SMB client to a Samba server, not the other way around.
5454 <varlistentry><term>Win9x client can't install driver</term>
5455 <listitem><para>For Win9x clients require the printer names to be 8
5456 chars (or "8 plus 3 chars suffix") max; otherwise the driver files
5457 won't get transferred when you want to download them from
5458 Samba.</para></listitem></varlistentry>
5460 <varlistentry><term>testparm</term>
5461 <listitem><para>Run <command>testparm</command>: It will tell you if
5462 <filename>smb.conf</filename> parameters are in the wrong
5463 section. Many people have had the "printer admin" parameter in the
5464 <parameter>[printers]</parameter> section and experienced
5465 problems. "testparm" will tell you if it sees
5466 this.</para></listitem></varlistentry>
5468 <varlistentry><term>"cupsaddsmb" keeps asking for a root password in a
5469 neverending loop</term>
5470 <listitem><para>Have you <parameter>security = user</parameter>? Have
5471 you used <command>smbpasswd</command> to give root a Samba account?
5472 You can do 2 things: open another terminal and execute
5473 <command>smbpasswd -a root</command> to create the account, and
5474 continue with entering the password into the first terminal. Or break
5475 out of the loop by hitting ENTER twice (without trying to type a
5476 password).</para></listitem></varlistentry>
5478 <varlistentry><term>"cupsaddsmb" gives "No PPD file for printer..."
5479 message (but I swear there is one!)</term>
5483 <listitem><para>Have you enabled printer sharing on CUPS? This means:
5484 do you have a <parameter><Location
5485 /printers>....</Location></parameter> section in CUPS
5486 server's <filename>cupsd.conf</filename> which doesn't deny access to
5487 the host you run "cupsaddsmb" from? It <emphasis>could</emphasis> be
5488 an issue if you use cupsaddsmb remotely, or if you use it with a
5489 <parameter>-h</parameter> parameter: <command>cupsaddsmb -H
5490 sambaserver -h cupsserver -v printername</command>.
5492 <listitem><para>Is your
5493 "TempDir" directive in
5494 <emphasis>cupsd.conf</emphasis>
5495 set to a valid value and is it writeable?
5496 </para></listitem></itemizedlist>
5497 </listitem></varlistentry>
5499 <varlistentry><term>I can't connect client to Samba printer.</term>
5500 <listitem><para>Use <command>smbstatus</command> to check which user
5501 you are from Samba's point of view. Do you have the privileges to
5502 write into the <parameter>[print$]</parameter>
5503 share?</para></listitem></varlistentry>
5505 <varlistentry><term>I can't reconnect to Samba under a new account
5506 from Win2K/XP</term>
5507 <listitem><para>Once you are connected as the "wrong" user (for
5508 example as "nobody", which often occurs if you have <parameter>map to
5509 guest = bad user</parameter>), Windows Explorer will not accept an
5510 attempt to connect again as a different user. There won't be any byte
5511 transfered on the wire to Samba, but still you'll see a stupid error
5512 message which makes you think that Samba has denied access. Use
5513 <command>smbstatus</command> to check for active connections. Kill the
5514 PIDs. You still can't re-connect and get the dreaded
5515 <computeroutput>You can't connect with a second account from the same
5516 machine</computeroutput> message, as soon as you are trying? And you
5517 don't see any single byte arriving at Samba (see logs; use "ethereal")
5518 indicating a renewed connection attempt? Shut all Explorer Windows.
5519 This makes Windows forget what it has cached in its memory as
5520 established connections. Then re-connect as the right user. Best
5521 method is to use a DOS terminal window and <emphasis>first</emphasis>
5522 do <command>net use z: \\SAMBAHOST\print$ /user:root</command>. Check
5523 with <command>smbstatus</command> that you are connected under a
5524 different account. Now open the "Printers" folder (on the Samba server
5525 in the <emphasis>Network Neighbourhood</emphasis>), right-click the
5526 printer in question and select
5527 <emphasis>Connect...</emphasis></para></listitem></varlistentry>
5529 <varlistentry><term>Avoid being connected to the Samba server as the
5531 <listitem><para>You see per <command>smbstatus</command> that you are
5532 connected as user "nobody"; while you wanted to be "root" or
5533 "printeradmin"? This is probably due to <parameter>map to guest = bad
5534 user</parameter>, which silently connects you under the guest account,
5535 when you gave (maybe by accident) an incorrect username. Remove
5536 <parameter>map to guest</parameter>, if you want to prevent
5537 this.</para></listitem></varlistentry>
5539 <varlistentry><term>Upgrading to CUPS drivers from Adobe drivers on
5540 NT/2K/XP clients gives problems</term>
5541 <listitem><para>First delete all "old" Adobe-using printers. Then
5542 delete all "old" Adobe drivers. (On Win2K/XP, right-click in
5543 background of "Printers" folder, select "Server Properties...", select
5544 tab "Drivers" and delete here).</para></listitem></varlistentry>
5546 <varlistentry><term>I can't use "cupsaddsmb"on a Samba server which is
5548 <listitem><para>Do you use the "naked" root user name? Try to do it
5549 this way: <emphasis>cupsaddsmb -U DOMAINNAME\\root -v
5550 printername</emphasis> (note the two backslashes: the first one is
5551 required to "escape" the second one).</para></listitem></varlistentry>
5553 <varlistentry><term>I deleted a printer on Win2K; but I still see
5555 <listitem><para>Deleting a printer on the client won't delete the
5556 driver too (to verify, right-click on the white background of the
5557 "Printers" folder, select "Server Properties" and click on the
5558 "Drivers" tab). These same old drivers will be re-used when you try to
5559 install a printer with the same name. If you want to update to a new
5560 driver, delete the old ones first. Deletion is only possible if no
5561 other printer uses the same driver.</para></listitem></varlistentry>
5563 <varlistentry><term>Win2K/XP "Local Security
5565 <listitem><para><emphasis>Local Security Policies</emphasis> may not
5566 allow the installation of unsigned drivers. "Local Security Policies"
5567 may not allow the installation of printer drivers at
5568 all.</para></listitem></varlistentry>
5570 <varlistentry><term>WinXP clients: "Administrator can not install
5571 printers for all local users"</term>
5572 <listitem><para>Windows XP handles SMB printers on a "per-user" basis.
5573 This means every user needs to install the printer himself. To have a
5574 printer available for everybody, you might want to use the built-in
5575 IPP client capabilities of WinXP. Add a printer with the print path of
5576 <emphasis>http://cupsserver:631/printers/printername</emphasis>.
5577 Still looking into this one: maybe a "logon script" could
5578 automatically install printers for all
5579 users.</para></listitem></varlistentry>
5581 <varlistentry><term>"Print Change Notify" functions on
5583 <listitem><para>For "print change notify" functions on NT++ clients,
5584 these need to run the "Server" service first (re-named to
5585 <emphasis>File & Print Sharing for MS Networks</emphasis> in
5586 XP).</para></listitem></varlistentry>
5588 <varlistentry><term>WinXP-SP1</term>
5589 <listitem><para>WinXP-SP1 introduced a <emphasis>Point and Print
5590 Restriction Policy</emphasis> (this restriction doesn't apply to
5591 "Administrator" or "Power User" groups of users). In Group Policy
5592 Object Editor: go to <emphasis>User Configuration -->
5593 Administrative Templates --> Control Panel -->
5594 Printers</emphasis>. The policy is automatically set to
5595 <emphasis>Enabled</emphasis> and the <emphasis>Users can only Point
5596 and Print to machines in their Forest</emphasis> . You probably need
5597 to change it to <emphasis>Disabled</emphasis> or <emphasis>Users can
5598 only Point and Print to these servers</emphasis> in order to make
5599 driver downloads from Samba possible.</para></listitem></varlistentry>
5601 <varlistentry><term>I can't set and save default print options for all
5602 users on Win2K/XP</term>
5604 <listitem><para>How are you doing it? I bet the wrong way (it is not
5605 very easy to find out, though). There are 3 different ways to bring
5606 you to a dialog that <emphasis>seems</emphasis> to set everything. All
5607 three dialogs <emphasis>look</emphasis> the same. Only one of them
5608 <emphasis>does</emphasis> what you intend. You need to be
5609 Administrator or Print Administrator to do this for all users. Here
5610 is how I do in on XP:
5613 <orderedlist numeration="upperalpha">
5615 <listitem><para>The first "wrong" way:
5617 <orderedlist numeration="arabic">
5618 <listitem><para>Open the <emphasis>Printers</emphasis>
5619 folder.</para></listitem>
5621 <listitem><para>Right-click on the printer
5622 (<emphasis>remoteprinter on cupshost</emphasis>) and
5623 select in context menu <emphasis>Printing
5624 Preferences...</emphasis></para></listitem>
5626 <listitem><para>Look at this dialog closely and remember what it looks
5627 like.</para></listitem>
5632 <listitem><para>The second "wrong" way:
5634 <orderedlist numeration="arabic">
5635 <listitem><para>Open the <emphasis>Printers</emphasis>
5636 folder.</para></listitem>
5638 <listitem><para>Right-click on the printer (<emphasis>remoteprinter on
5639 cupshost</emphasis>) and select in the context menu
5640 <emphasis>Properties</emphasis></para></listitem>
5642 <listitem><para>Click on the <emphasis>General</emphasis>
5643 tab</para></listitem>
5645 <listitem><para>Click on the button <emphasis>Printing
5646 Preferences...</emphasis></para></listitem>
5648 <listitem><para>A new dialog opens. Keep this dialog open and go back
5649 to the parent dialog.</para></listitem>
5654 <listitem><para>The third, the "correct" way: (should you do
5655 this from the beginning, just carry out steps 1. and 2. from second
5658 <orderedlist numeration="arabic">
5659 <listitem><para>Click on the <emphasis>Advanced</emphasis>
5660 tab. (Hmmm... if everything is "Grayed Out", then you are not logged
5661 in as a user with enough privileges).</para></listitem>
5663 <listitem><para>Click on the <emphasis>Printing
5664 Defaults...</emphasis> button.</para></listitem>
5666 <listitem><para>On any of the two new tabs, click on the
5667 <emphasis>Advanced...</emphasis>
5668 button.</para></listitem>
5670 <listitem><para>A new dialog opens. Compare this one to the other,
5671 identical looking one from "B.5" or A.3".</para></listitem>
5678 Do you see any difference? I don't either... However, only the last
5679 one, which you arrived at with steps "C.1.-6." will save any settings
5680 permanently and be the defaults for new users. If you want all clients
5681 to get the same defaults, you need to conduct these steps <emphasis>as
5682 Administrator</emphasis> (<parameter>printer admin</parameter> in
5683 <filename>smb.conf</filename>) <emphasis>before</emphasis> a client
5684 downloads the driver (the clients can later set their own
5685 <emphasis>per-user defaults</emphasis> by following the
5686 procedures <emphasis>A.</emphasis> or <emphasis>B.</emphasis>
5687 above).</para></listitem></varlistentry>
5689 <varlistentry><term>What are the most common blunders in driver
5690 settings on Windows clients?</term>
5691 <listitem><para>Don't use <emphasis>Optimize for
5692 Speed</emphasis>: use <emphasis>Optimize for
5693 Portability</emphasis> instead (Adobe PS Driver) Don't use
5694 <emphasis>Page Independence: No</emphasis>: always
5695 settle with <emphasis>Page Independence:
5696 Yes</emphasis> (Microsoft PS Driver and CUPS PS Driver for
5697 WinNT/2K/XP) If there are problems with fonts: use
5698 <emphasis>Download as Softfont into
5699 printer</emphasis> (Adobe PS Driver). For
5700 <emphasis>TrueType Download Options</emphasis>
5701 choose <emphasis>Outline</emphasis>. Use PostScript
5702 Level 2, if you are having trouble with a non-PS printer, and if
5703 there is a choice.</para></listitem></varlistentry>
5705 <varlistentry><term>I can't make <command>cupsaddsmb</command> work
5706 with newly installed printer</term>
5707 <listitem><para>Symptom: the last command of
5708 <command>cupsaddsmb</command> doesn't complete successfully:
5709 <command>cmd = setdriver printername printername</command> result was
5710 NT_STATUS_UNSUCCESSFUL then possibly the printer was not yet
5711 "recognized" by Samba. Did it show up in <emphasis>Network
5712 Neighbourhood</emphasis>? Did it show up in <command>rpcclient
5713 hostname -c 'enumprinters'</command>? Restart smbd (or send a
5714 <command>kill -HUP</command> to all processes listed by
5715 <command>smbstatus</command> and try
5716 again.</para></listitem></varlistentry>
5718 <varlistentry><term>My permissions on
5719 <filename>/var/spool/samba/</filename> get reset after each
5721 <listitem><para>Have you by accident set the CUPS spool directory to
5722 the same location? (<parameter>RequestRoot
5723 /var/spool/samba/</parameter> in <filename>cupsd.conf</filename> or
5724 the other way round: <filename>/var/spool/cups/</filename> is set as
5725 <parameter>path</parameter> in the <parameter>[printers]</parameter>
5726 section). These <emphasis>must</emphasis> be different. Set
5727 <parameter>RequestRoot /var/spool/cups/</parameter> in
5728 <filename>cupsd.conf</filename> and <parameter>path =
5729 /var/spool/samba</parameter> in the <parameter>[printers]</parameter>
5730 section of <filename>smb.conf</filename>. Otherwise cupsd will
5731 sanitize permissions to its spool directory with each restart, and
5732 printing will not work reliably.</para></listitem></varlistentry>
5734 <varlistentry><term>My printers work fine: just the printer named "lp"
5735 intermittently swallows jobs and spits out completely different
5737 <listitem><para>It is a very bad idea to name any printer "lp". This
5738 is the traditional Unix name for the default printer. CUPS may be set
5739 up to do an automatic creation of "Implicit Classes". This means, to
5740 group all printers with the same name to a pool of devices, and
5741 loadbalancing the jobs across them in a round-robin fashion. Chances
5742 are high that someone else has an "lp" named printer too. You may
5743 receive his jobs and send your own to his device unwittingly. To have
5744 tight control over the printer names, set <parameter>BrowseShortNames
5745 No</parameter>. It will present any printer as "printername@cupshost"
5746 then, giving you a better control over what may happen in a large
5747 networked environment.</para></listitem></varlistentry>
5749 <varlistentry><term>How do I "watch" my Samba server?</term>
5750 <listitem><para>You can use <command>tail -f
5751 /var/log/samba/log.smbd</command> (you may need a different path) to
5752 see a live scrolling of all log messages. <command>smbcontrol smbd
5753 debuglevel</command> tells you which verbosity goes into the
5754 logs. <command>smbcontrol smbd debug 3</command> sets the verbosity to
5755 a quite high level (you can choose from 0 to 10 or 100). This works
5756 "on the fly", without the need to restart the smbd daemon. Don't use
5757 more than 3 initially; or you'll drown in an ocean of
5758 messages.</para></listitem></varlistentry>
5760 <varlistentry><term>I can't use Samba from my WinXP Home box, while
5761 access from WinXP Prof works flawlessly</term>
5762 <listitem><para>You have our condolences! WinXP home has been
5763 completely neutered by Microsoft as compared to WinXP Prof: you can
5764 not log into a WinNT domain. It cannot join a Win NT domain as a
5765 member server. While it is possible to access domain resources, users
5766 don't have "single sign-on". They need to supply username and password
5767 each time they connect to a resource. Logon scripts and roaming
5768 profiles are not supported. It can serve file and print shares; but
5769 only in "share-mode security" level. It can not use "user-mode
5770 security" (what Windows 95/98/ME still can
5771 do).</para></listitem></varlistentry>
5773 <varlistentry><term>Where do I find the Adobe PostScript driver files
5774 I need for "cupsaddsmb"?</term>
5775 <listitem><para>Use <command>smbclient</command> to connect to any
5776 Windows box with a shared PostScript printer: <command>smbclient
5777 //windowsbox/print\$ -U guest</command>. You can navigate to the
5778 <filename>W32X86/2</filename> subdir to <command>mget ADOBE*</command>
5779 and other files or to <filename>WIN40/0</filename> to do the same. --
5780 Another option is to download the <filename>*.exe</filename> packaged
5781 files from the Adobe website.</para></listitem></varlistentry>
5786 <title>An Overview of the CUPS Printing Processes</title>
5789 <figure><title>CUPS Printing Overview</title>
5791 <imageobject role="latex"><imagedata fileref="projdoc/imagefiles/a_small"/></imageobject>
5792 <imageobject><imagedata fileref="projdoc/imagefiles/a_small.png"/></imageobject>