Dissecting The CUPS Filtering System:
A Network Postscript RIP For non-PS Printers
by Kurt Pfeifle mailto:kpfeifle@danka.de
Author of the CUPS-FAQ
and the KDEPrint Handbook
CUPS, the Common UNIX Printing System, is thought by many to become an epoch making printing application -- for the Linux and UNIX realms of computing. What is not yet clearly seen: it could also -- in tandem with Samba's new features of RPC-based printer driver downloads -- make a big impact on Windows clients network printing in the future.
This paper dissects the inner workings of the CUPS filtering system and envisages a few ideas about its deployment as a print server of a new kind: not just spooling Windows client print files as "raw" jobs, but also processing them through its internal PostScript RIP (Raster Image Process) -- thusly providing more stability and job accounting features to its environment.
Late-breaking news about Easy Software Products' (the developers of CUPS) license deal with Apple, to supply CUPS to Darwin and Mac OS X, have increased the likelihood of more people giving it a spin. Therefor more knowledge about its architecture is a dire need. CUPS is easy to deal with -- more easy than any other printing system. But it is also new -- and it is different from any of its predecessors. Therefor there are new things to learn and to understand as well... .
One of the first obstacles for newbie users and administrators of CUPS is: to come to grips with its internal filtering system.
Therefor we will spend a major part of this paper on this aspect, which then leads to some practical benefits: how to use a Samba/CUPS print server as a networked Raster Image Processor (RIP), first interpreting PostScript printfiles on behalf of its clients and then sending them off to their final print destinations. We will not deal much with other benefits of CUPS here such as its firm foundation in the new IETF standard Internet Printing Protocol (IPP), its complete support for print job options, its clustering and failover capabilities or its ingeniously simple and effective "printer browsing mechanism", allowing clients to "print without a driver" in a true Plug'n'Play manner.
?/p>
1. Printing via Windows NT print servers
Suppose, a Windows NT client installs a printer. The jobs should be sent via an NT print server. Obviously the client needs a "driver" too. You may choose here, where the "driver" should be installed: either locally or on the print server.Do you have the same choice with UNIX print servers? Install a printer driver to run on the server, with the server processing the files? With the client having the full control over job settings, just as if the driver was installed locally? The answer used to be a plain "No!". With CUPS it's "Yes!". But let's first look at a "purely-Windows" environment...
1.1. Client side driver operation
Choosing the local driver installation for the NT client will process the printfile on the local machine. Basically, the driver will take the output of the Windows GDI (Graphical Device Interface), called an Enhanced MetaFile (EMF) and process it according to the target printer. A PCL driver will generate PCL output from the GDI input, a PostScript driver will output PostScript and so forth. Of course, print options (duplex, punch, staple...) are all available, as provided by the driver. The client will be able to send a printjob off his application, even if the server was temporarily unavailable (spooling the job locally in the meanwhile), but no other client will be able to utilize this driver.
1.2. Server side driver operation
Choosing the driver installation to take place on the server will behave a bit different. It will cause the printing client to send the output of his local GDI largely "as is" (EMF, Enhanced MetaFile) towards the server. The server-installed driver will in turn process it and generate the correct format (PostScript, PCL, Raster...) suitable for the target printer from the client's GDI output upon arrival of the file. Print options to select are available for the client here too; there is hardly any visible difference in the drivers' local GUI for the client as compared to a "direct" client side driver installation. However, the client will not be able to send a printjob off his applications if the server is temporarily unavailable. On the other hand, the server-side printer driver installation is available for other clients to use (provided it is "shared") through a simple "point and print" event.
??/p>
2. Windows client printing via "classical" UNIX print servers
"Traditionally configured" UNIX print server have been available for Windows clients for a long time. They provide one same basic service as Windows print servers: to make sure that the printer is not bogged down by possibly too many concurrent access attempts (as could happen in networks with a purely "peer-to-peer" printing system), by providing a central spooling access point to the printer, that is "always open" to the clients.
2.1. Clients side drivers: "raw" print jobs
Classical UNIX print servers can't offer the file conversion service (server-side printer driver) to Windows clients like Windows NT servers do. Clients need to have a local driver installed, suitable for the target printer, and send their pre-formatted jobs as "raw", telling the server to pass it to the printer untouched. For a long time UNIX servers were even unable to offer printer drivers for download and semi-automatic installation.
2.2. Run server side "drivers": not possible!
UNIX print servers simply don't know how to convert their Windows clients' GDI output, as there are no such "drivers" or filters available for them. Therefor UNIX print servers will normally just play the role of a central spooling device for a lot of clients and printers, storing jobs temporarily and passing them on as the printer(s) become available again after they finished their current job(s).
There occurs not very much CPU- load for a spool-only server. It is common practice to use an otherwise shelved computer as the print server, because all it needs to have is enough hard disk space to take in the arriving jobs and hold them as long as needed. The processing power usually is no bottleneck for a "spool-only" UNIX print server. These setups are re-nowned for their stable and fast service in fulfillment of their duties, in most cases better than their Win NT counterparts (to be fair, however, this never involves the server side processing of printfiles with some major format conversion, as this needs to be done by the clients themselves).
2.3. Storing client drivers for download and automatic installation: yes! (And maybe more?)
However, with the arrival of the Version 2.2.0 of Samba, you can now comfortably store the drivers (even via easy upload from a client) on a UNIX/Samba print server, and offer them to WinNT/2K/XP clients for download and local semi-automatic installation. Due to the complicated nature of this process and the closed source of the involved MS-RPCs (Microsoft Remote Procedure Calls), it took until Version 2.2.4 to get this feature fairly stable and make it work for a lot of different environments. But now it's there -- and this is a huge achievement. It eases administration for large Samba driven client networks a lot. At the same time it is opening up new creative applications for other software, such as discussed here in conjunction with CUPS..
??/p>
3. Windows client printing via a CUPS print server
The different puzzle pieces of Samba printing in the past only offered partial solutions to users and administrators. With the new RPC-based printing functions, Samba can provide a much better service now, even with traditional spoolers.
With CUPS you can arrive at a new peak. There is now a convenient way to provide server-side printjob processing for Windows clients by a CUPS server, similar to what it does in relation to its native CUPS clients.
This model includes some very tempting features to users and administrators:
- You have a fully-fledged "driver" run on the server, processing jobs for clients from all plattforms -- Linux, Windows, UNIX and Mac OS X in much the same way.
- All Windows clients can "install" this driver upon first contact with one simple click, using Samba's new "point and print" feature -- UNIX and Linux clients don't even need to do anything to get the same.
3.1. Client-side drivers: raw print jobs, just like in the past...
Of course, CUPS is not just viable if you need to have (or want) this "server side job processing". Just as with traditional LPD-based print servers, you can also set up CUPS to act as a mere spooling host for its Windows clients. This role it fulfills equally reliably as its outmoded counterparts.
3.2. Server-side "driver": processing client PostScript print files
The really new shot is to set up the CUPS print server as an application that processes the client jobs on the server side. Jobs then don't get rendered print-ready already on the client side (using the vendor printer driver there), but on the server before passing them on to their final print devices.
In difference to a Windows NT print server, this rendering, of course, is not based on GDI. CUPS still can't process any GDI-originated input. What's the deal then?
The secret lies in the use of PostScript. The idea is this: clients on the Windows platform use an Adobe PostScript driver, armed with a CUPS PPD to be able to control all job options. They send these print jobs to the CUPS server. The server takes care to process the files as intended, including the respecting of all set job options.
3.3. CUPS -- a PostScript RIP valid for 1.000++ non-PostScript printers
This is nothing new and revolutionary if the printers themselves understand PostScript: In this case this is a valid option for all spooling systems, not just with CUPS. But with CUPS, you can do this, even if your target printers (or some of them) don't use PostScript. There is only one pre-condition: CUPS itself must be able to print natively onto the printer(s) in question. Given, that there are now more than 3.000 CUPS-driver/PPD-combos available, in several languages, from various sources, including some commercial ones, this is not a big deal.
This setup is a very tempting offer to satisfy at least two different requirements:
- the need to have centralized accounting and billing for all printjobs;
- the need to remove any printer driver induced instabilities stemming from a multitude of non-PostScript printer operating in f.e. a Windows Terminal Server environment
This way you'll have a network transparent PostScript RIP, able to deal with thousands of different printer models, based on Ghostscript. This way, CUPS lets appear all printers to the clients to be PostScript printers. It takes over the task to convert the PostScript into print-ready data on behalf of those printer(s) which don't take PostScript as their native input. CUPS becomes a network PostScript RIP implemented in software, capable to run thousands of models, with the full power of device features under the control of client users and administrators...
3.4. PPDs to propagate print job options
PPDs (PostScript Printer Descriptions) are a well known mechanism in relation to PostScript printers to fully control job options. They allow the user to flexibly change print setting according to his preferences.
PPDs are part and parcel of PostScript printer drivers. They are a de-facto standard, written in pure ASCII. They follow a standard layout and syntax format, defined and published by Adobe. They are also used to dynamically build a GUI driver interface that lets you select print options. Accompanying the user-visible options in human-readable form, they also contain PostScript, PJL (Print Job Language) or PCL (Printer Control Language) code representing the user options to the printer. These commands are sent to the printer, embedded in the PostScript code, following user selections.
CUPS is a fully PPD-aware and -literate printing system. It can use the PPD of any Windows NT PostScript driver to its full capacity. Those PPDs are written and distributed by the printer manufactures as part of their WinNT drivers. There is no need to write them yourself, if you use a PostScript printer..
But CUPS' PPD-support doesn't stop here. Its developers have extended the concept of PPDs to non-PostScript printers. There is only one little decisive addition as compared to the "normal" PPDs: a line starting with the keyword "*cupsFilter" tells the CUPS daemon on the server, which filter should be used to process the accompanying PostScript file. (Other applications coming across such a PPD-file will ignore this directive as it appears to them as a "comment"...)
CUPS-PPDs for non-PostScript-devices were still quite rare two years ago. Now there are several thousand avaliable, from different origins:
- ESP PrintPro (commercial, non-Free) is packaged with more than 3.000 PPDs, ready for successful usage "out of the box" on Linux, HP-UX, Solaris, IRIX, Tru64 and some more commercial Unices (it is written by the CUPS developers themselves and its sales help finance the further development of CUPS, as they feed their creators)
- the Gimp-Print-Project (GPL, Free Software) provides around 120 PPDs (supporting nearly 300 printers, many driven to photo quality output), to be used alongside the Gimp-Print CUPS filters;
- TurboPrint (Shareware, non-Free) supports roughly the same amount of printers in excellent quality;
- OMNI (LPGL, Free) is a package made by IBM, now containing support for more than 400 printers, stemming from the inheritance of IBM OS/2 KnowHow ported over to Linux (CUPS support is in a Beta-stage at present);
- HPIJS (BSD-style licences, Free) supports around 120 of HP's own printers and is also providing excellent print quality now;
- Foomatic/cupsomatic (LPGL, Free) from Linuxprinting.org are providing PPDs for practically every Ghostscript filter known to the world, now usable with CUPS.
More details on some differences between those PPDs (especially the Foomatic/cupsomatic way of doing things) is discussed in the following section.
??/p>
4. The CUPS-internal filtering system
Thanks to its modular software design, CUPS is able to run more than 3.000 printer models, utilizing filters/drivers and PPDs from different origins. Hardware vendors or 3rd party software developers can easily plug their own drivers and filters into the CUPS framework, as is proofed by Foomatic, the Gimp-Print project or the TurboPrint shareware. Its inner mechanism consists of a number of individual filters which can be flexibly chained and concatenated to achieve the projected result.
Let's have a closer look.
Upon receiving, print files are subjected to a "MIME typisation" by the CUPS daemon. (MIME types describe a file format in a non-ambiguous way. MIME types are diverted into different categories, with a scheme like main_category/minor_category. MIME types are registered with IANA, the Internet Assigning Numbers Authority. Vendors may register their own proprietary file formats with IANA provided they explain a method to recognize the format as such by a unambiguous method. CUPS has its MIME type recognition rules deposited in the (editable) file /etc/cups/mime.types.
Should there not arrive PostScript as an initial input format, there will be some pre-filters working on them. These pre-filter convert the input to PostScript (more exactly, into MIME type application/postscript). The filters have "speaking names": texttops, pdftops, hpgltops. (There is also imagetops, but this is, strictly speaking already more than a pre-filter.):
| CUPS pre-filters generate PostScript from various input formats: |
+--------+ +-------+ +--------+
input | Text | | PDF | | HP/GL |
formats: | | | | | |
+--------+ +-------+ +--------+
v v v
text-| pdf-| hpgl-|
pre- to-| to-| to-|
filters: ps | ps | ps |
V V V
+-----------------------------+
| (MIME type: |
| POSTSCRIPT application/ |
| postscript) |
+-----------------------------+
|
Once we have PostScript available (as MIME type application/postscript, which can as well be the initially supplied input format) the next filter in the chain is the pstops one.
Huh? Does this make sense? Generating PostScript output from PostScript input?
Sure. For this filter is doing a sort of "normalization" to the original PostScript. Additionally it is used to count the amount of pages processed, extract an optional page selection (a user might want to have on paper just the page numbers 4, 6-9, 11, 15-17 plus 13 ), or "impose" the document, by scaling and putting 2 or 4 pages on one sheet of paper. while its input is application/postscript, the output is application/vnd.cups-postscript, which indicates a "private" MIME-type vendor (= the CUPS developers) registration with IANA:
| pstops counts pages, imposes multiple pages on one sheet or selects page-ranges for print: |
+-----------------------------+
| (MIME-Type: |
| POSTSCRIPT application/ |
| postscript) |
+-----------------------------+
v
ps- | (*) page metering,
to- | accounting,
ps(*)| ps-n-up,
V psselect...
+-----------------------------+
| CUPS- (MIME-Type: |
| POSTSCRIPT application/ |
| vnd.cups-postscript) |
+-----------------------------+
|
Next call is for pstoraster. This one is at the core of the CUPS RIP. Currently it is still derived off Ghostscript version 5.50. This sounds (and is) quite old, but the CUPS developers have applied many modifications and patches of their own to it an, so that the consecuting raster drivers in the chain still are able to drive many inkjet printers to true photo quality output. Gimp-Print, for instance, is praised by many of its users for producing better quality on Epson printer than the vendor-supplied Windows drivers! (Note: cupsomatic also taps in here, before pstoraster does its work, and "kidnaps" the CUPS-PostScript to channel it through the standard "classical" Ghostscript installation, before returning the resulting raster data back to a CUPs backend.)
pstoraster outputs raster data. This raster data is also registered with IANA as MIME type application/vnd.cups-raster. Its specification is of course open. The raster data describes the printfile as separate pages in the target printers's color space, with print options tagged inside separate page headers:
| pstoraster outputs generic raster, foundation for post-processing by printer specific filters: |
+-----------------------------+
| (MIME-Type: |
| POSTSCRIPT application/ |
| vnd.cups-postscript) |
+-----------------------------+
v (*) CUPS-internal filter
ps- | derived off GNU
to- | Ghostscript 5.50,
raster(*)| 1st "core part" of the
V CUPS [PostScript-]RIP
+-----------------------------+ (independent of a CUPS-
| CUPS- (MIME-Type: | external Ghostscript-
| Raster application/ | installation)
| vnd.cups-raster) |
+-----------------------------+
|
imagetoraster could here be on duty too, if the input file was of MIME type "image/*", heading for non-PostScript printers. This has a similar role to pstoraster for all image input files, being the central CUPS image file RIP. It is used for all non-PostScript printers. Possible input MIME types are a rich variety of formats, spanning from JPEG/JFIF over PNG, GIF, TIFF, SGI-RGB, BMP, PNM (PBM/PGM/PPM), Sun-Raster or Kodak Photo-CD and more:
| imgetoraster outputs generic raster, foundation for post-processing by printer specific filters: |
+-----------------------------+(*) JPEG/JFIF, PNG, GIF,
| (MIME-Type: | SGI-RGB, TIFF, BMP,
| IMAGE(*) image/* ) | PNM (PBM/PGM/PPM),
| | Sun-Raster,Kodak
+-----------------------------+ Photo-CD,...
v
| (**) CUPS-internal filter
image- | derived off GNU
to- | Ghostscript 5.50,
raster(**)| 2nd "core part" of the
V CUPS [Image-]RIP
+-----------------------------+ (independent of a CUPS-
| CUPS- (MIME-Type: | external Ghostscript-
| Raster application/ | installation)
| vnd.cups-raster) |
+-----------------------------+
|
Alternatively, imagetops would do the job here, if the target printer was a PostScript-capable one:
| from image input, imagetops outputs normalized CUPS-PostScript, ready to be passed on to real PostScript printers: |
+-----------------------------+(*) JPEG/JFIF, PNG, GIF,
| (MIME-Type: | SGI-RGB, TIFF, BMP,
| IMAGE(*) image/* ) | PNM (PBM/PGM/PPM),
| | Sun-Raster,Kodak
+-----------------------------+ Photo-CD,...
v
image- |
to- |
ps |
V
+-----------------------------+
| CUPS- (MIME-Type: |
| PostScript application/ |
| vnd.cups-postscript) |
+-----------------------------+
|
4.6. The printer-specific filters
Last, but not least, it's the turn to convert the generic CUPS raster data to a printer-specific format, embedding also all the control commands to get the desired print options from the device. This is done by printer-specific filters, or by calling a more general filter with printer-specific parameters. At this point, other deliberate filters or raster drivers (even proprietary ones) could be bolted onto the system, for example from vendors, who decided to have their models supported on Linux/UNIX or Mac OS X platforms.
| printer specific filters generate printer specific raster data and from generic CUPS raster: |
+-----------------------------+
| (MIME-Type: |
| CUPS-Raster application/ |
| vnd.cups-raster) |
+-----------------------------+
v v v v
(*) raster-| raster-| raster-| raster-|(*) base for f.e. Gimp-Print
to-| to-| to-| to-| filter as well as for
hp | escp | dymo | |
?font size="+1">4.7. Foomatic and the cupsomatic-"filter"
How do "Foomatic" and cupsomatic fit into this picture?
Foomatic is the database of Linuxprinting.org. It contains the most complete info about printer models, eligible Ghostscript drivers, supported print options and "drive execution details". One can online a access all these info and even generate a current PPD for any supported printer/driver-combo, using the "PPD-O-Matic" script running on the web server. [Note: you shouldn't any longer use the PPDs generated by the old script called "CUPS-O-Matic", as these are incompatible with some applications).
The easiest way to do it: select your printer model, read the notes about it, choose the "recommended driver" (sometimes there are as many as 5 drivers available, but there is always a recommended one), click on "Generate PPD", save the resulting PPD file and follow the instructions to install it. PPD-O-Matic-generated PPDs may not only be used with CUPS. They are even digestible for all PPD-aware programs (such as. StarOffice, OpenOffice, WordPerfect or CorelDraw for Linux). The PPD contains all available info about the driver/printer combination. PPD-aware programs can load the PPD to read stuff like needed page margins, available printer fonts from them or learn which PostScript code snippet needs to go into the printfile, if page 5 is to be drawn from paper tray 3, while page 9 needs tray 1, while the rest is from tray 5 (StarOffice).
You can even install those PPDs on any Windows client on top of an Adobe PostScript driver. PostScript print files generated with this combo can then be sent to a CUPS server with the fitting printer installed, which will process the file and let it print.
For the PPD to actually work on the CUPS server, you need to have a few more pre-conditions met:
- you need to have the cupsomatic Perl script installed in /usr/lib/cups/filters/; this mimics to be a CUPS filter and is called from inside the PPD-O-Matic-PPD, but then it hands over the PostScript to an appropriate filter from your "standard" Ghostscript installation;
- you need to have the above mentioned Ghostscript filter (or "DEVICE") installed, which is called by cupsomatic;
- you need to have some Perl modules installed that are needed by cupsomatic to run correctly.
Similar to any other "non-PS-printer-PPD", the PPD-O-Matic generated ones contain a line starting with "*cupsFilter":
*cupsFilter:"application/vnd.cups-postscript 0 cupsomatic"
This tells CUPS to use cupsomatic as the next filter after it has reached the stage of a MIME type of "application/vnd.cups-postscript" through its standard filtering mechanism. cupsomatic then reads the attached PPD options and constructs from them a correct Ghostscript commandline to run the file through the appropriate filter. In the end, it hands the converted file back to a CUPS backend for sending it off to the printer.
This way Foomatic/cupsomatic make all working combinations of printers and Ghostscript filters known to mankind also available for use in CUPS. Of course this produces basically the same quality as other Ghostscript-driven spoolers do for their printers -- be it bad (sometimes) or average (more often) or excellent (rising).
| cupsomatic "kidnapping" CUPS-PostScript, to let it be filtered and converted by Ghostscript: |
+-----------------------------+
| (MIME-Type: |
| POSTSCRIPT application/ | >--- --- --->
| vnd.cups-postscript) | | |
+-----------------------------+ | V
v | #################################
| | # #
| | # CUPS-external Ghostscript #
| cupsomatic (requiring several | # installation (may now also #
| additional Perl modules) | # be AFPL-Ghostscript 7.04(*) #
>--- --- --- --- --- --- --- ---> # #
# +++++++ +++++++ +++++++ +++++ #
# | gs- | | gs- | | gs- | | | #
+--- --- --- --- ---+ # |filter |filter |filter | | #
| | # | ABC | | XYZ | | 123 | | | #
| | # +++++++ +++++++ +++++++ +++++ #
V | # #
******************************* | #################################
* * | v
* CUPS backend (transfer to * | | (*) more than 1.000
* printer via USB, parallel, * | | Ghostscript-
* serial or the network) * + --- --- ---+ supported
* * printer models
*******************************
|
4.8. Overall picture: CUPS-filters with ESP PrintPro, Foomatic, Gimp-Print and TurboPrint plugged in
A complete overview on the CUPS filtering chain is drawn in the following two charts.
- The first chart includes the professional CUPS extension ESP PrintPro, which provides largely improved versions of pstoraster and imagetoraster, plus more than 3.000 printer drivers working "out of the box", and a GUI of its own.
- The second chart shows, were any of the available "3rd party add-ons" to CUPS fit in. They include Gimp-Print, TurboPrint and Foomatic.
| Overall picture for CUPS filters, with plugged-in cupsomatic (from Linuxprinting.org), Gimp-Print & TurboPrint: |
+--------------------------------------------------+
| application programs send |
| files to printing system |
| |
+--------------------------------------------------+
v v v v v
| | | | |
V V | V V
+--------+ +--------+ | +-------+ +--------------------+
input | Text | | PDF | | | HP/GL | | Image(*)(MIME-Type:|(*)JPEG/JFIF, PNG, GIF
formats: | | | | | | | | image/*)| SGI-RGB, TIFF, BMP,
+--------+ +--------+ | +-------+ +--------------------+ PNM (PBM/PGM/PPM),
v v | v v v Sun-Raster,
pre- text-| pdf-| | hpgl-| | |
filters(*) to-| to-| | to-| | |
(PostScript ps(*)| ps(*)| | ps(*)| | |
generation): | | | | | |
V V V V | |image-
+-------------------------------+ |image- |to-
| POSTSCRIPT (MIME-Type: | |to- |raster(*)
| application/ | |ps(*) |(*)used for non-PostScript
| postscript) | |(*)used | printers, based on GS 5.50
+-------------------------------+ | for | -- one core element
v | PostScript- | of CUPS-RIP
ps-|(*)counting | printers |
to | pages, | |
ps(*)| accounting, | |
| ps-n-up, | |
| psselect... | |
V V |
+-----------------------------------------------+ |
| POSTSCRIPT (MIME-Type: | |
| application/ | |
| vnd.cups-postscript) | |
+-----------------------------------------------+ |
v v |
| based on ps-|(*)CUPS- |
| GS 5.50 - one to-| raster |
| core element raster(*)| generation |
| of CUPS-RIP(*) | (device |
| V indep.) V
| +------------------------------------------------+
| | |
| | CUPS-Raster (MIME-Type: |
| | application/ |
| | vnd.cups-raster) |
| | |
| +------------------------------------------------+
| v v v v
| | | | |
| | | | |
PS- | | | |
-printer | | | |
| | | | |
| | | | |
| | | | |
| raster-| raster-| raster-| raster-|
| to-| to-| to-| to-|
| pcl| escp| dymo| [various]|
| | | | |
| V V V V
| +-----+ +-----+ +-----+ 0000000000
| | | | | | | 0 0
| output-| | | | | | 0 ESP 0
| formats:| PCL | |ESC/P| |Dymo | 0 Print 0
| | | | | | | 0 Pro 0
| | | | | | | 0 0
| | | | | | | 0 0
| +-----+ +-----+ +-----+ 0000000000
| v v v v
| | | | |
V V V V V
*************************************************************************
* *
* CUPS backends: transferring final file & commands to printers *
* *
*---------+--------+--------+------------------------------------------ *
* | | | network: *
* pa- | se- | |------------------------------------------ *
* ra- | ri- | USB | | LPR/ | SMB/ | AppSocket/ *
* llel | al | | IPP | LPD | CIFS | HP-JetDirect *
* | | | | | | *
*************************************************************************
| | | | | | |
V V V V V V V
+------------+//// +------------+//// +------------+////
--|+----------+|/// --|+----------+|/// --|+----------+|///
--|| --- ||// --|| --- ||// --|| --- ||//
|+----------+|/ |+----------+|/ |+----------+|/
|| --- || || --- || || --- ||
|+----------+| |+----------+| |+----------+|
+------------+ +------------+ +------------+ |
| Overall picture for CUPS filters, with plugged-in cupsomatic (from Linuxprinting.org), Gimp-Print & TurboPrint: |
+--------------------------------------------------+
| application programs send |
| files to printing system |
| |
+--------------------------------------------------+
v v v v v
| | | | |
V V | V V
+--------+ +--------+ | +-------+ +--------------------+
input | Text | | PDF | | | HP/GL | | Image(*)(MIME-Type:|(*)JPEG/JFIF, PNG, GIF
formats: | | | | | | | | image/*)| SGI-RGB, TIFF, BMP,
+--------+ +--------+ | +-------+ +--------------------+ PNM (PBM/PGM/PPM),
v v | v v v Sun-Raster,
pre- text-| pdf-| | hpgl-| | |
filters(*) to-| to-| | to-| | |
(PostScript ps(*)| ps(*)| | ps(*)| | |
generation): | | | | | |
V V V V | |image-
+-------------------------------+ |image- |to-
| POSTSCRIPT (MIME-Type: | |to- |raster(*)
| application/ | |ps(*) |(*)used for non-PostScript
| postscript) | |(*)used | printers, based on GS 5.50
+-------------------------------+ | for | -- one core element
v | PostScript- | of CUPS-RIP
ps-|(*)counting | printers |
to | pages, | |
ps(*)| accounting, | |
| ps-n-up, | |
| psselect... | |
V V |
+-----------------------------------------------+ | cupsomatic (requires several
| POSTSCRIPT (MIME-Type: | | additional Perl modules)
| application/ |> - - - - | - - - - - - - - - - - - - +
| vnd.cups-postscript) | | (a.k.a. "Foomatic") |
+-----------------------------------------------+ | V
v v | #################################
| based on ps-|(*)CUPS- | # #
| GS 5.50 - one to-| raster | # CUPS-external Ghostscript- #
| core element raster(*)| generation | # installation (also poss.: #
| of CUPS-RIP(*) | (device | # AFPL Ghostscript 7.04)(*) #
| V indep.) V # (*)more than 1.000 models #
| +------------------------------------------------+ # supported #
| | | # #
| | CUPS-Raster (MIME-Type: | # +-----+ +-----+ +-----+ +---+ #
| | application/ | # | gs- | | gs- | | gs- | |...| #
| | vnd.cups-raster) | # |filter |filter |filter |...| #
| | | # | ABC | | XYZ | | 123 | |...| #
| +------------------------------------------------+ # +-----+ +-----+ +-----+ +---+ #
| v v v v v v # +-----+ +-----+ +-----+ #
| | | | | | | # | gs- | | gs- | | gs- | #
| | | | | | | # |filter |filter |filter #
PS- \ \ \ \ \ \ # | abc | | xyz | | 456 | #
-printer \ \ \ \ \ \ # +-----+ +-----+ +-----+ #
| \ \ \ \ \ \ #################################
| \ \ \ \ \ \ v
| | \ \ \ \ +--------+ |
| raster-|raster-|raster-| raster-| raster-| raster-|
| to-| to-| to-| to-| to-| to-| |
| pcl| escp| dymo| [various]| printer| turboprint|
| | | | | | | |
| V V V V V V
| +-----+ +-----+ +-----+ 0000000000 ############# ############# |
| | | | | | | 0 0 # Gimp- # # Turbo- #
| output-| | | | | | 0 ESP 0 # Print # # Print # |
| formats:| PCL | |ESC/P| |Dymo | 0 Print 0 # (writes # # (writes #
| | | | | | | 0 Pro 0 # PCL,ESC/P,# # PCL,ESC/P,# |
| | | | | | | 0 0 # Canon,etc.# # Canon,etc.#
| | | | | | | 0 0 # formats) # # formats) # |
| +-----+ +-----+ +-----+ 0000000000 ############# #############
| v v v v v v |
| | | | | | |
V V V V V V V |
************************************************************************* committal to
* * CUPS-backend |
* CUPS backends: transferring final file & commands to printers * <- - - - - - -+
* * (determined by
*---------+--------+--------+------------------------------------------ * "device URI")
* | | | network: *
* pa- | se- | |------------------------------------------ *
* ra- | ri- | USB | | LPR/ | SMB/ | AppSocket/ *
* llel | al | | IPP | LPD | CIFS | HP-JetDirect *
* | | | | | | *
*************************************************************************
| | | | | | |
V V V V V V V
+------------+//// +------------+//// +------------+////
--|+----------+|/// --|+----------+|/// --|+----------+|///
--|| --- ||// --|| --- ||// --|| --- ||//
|+----------+|/ |+----------+|/ |+----------+|/
|| --- || || --- || || --- ||
|+----------+| |+----------+| |+----------+|
+------------+ +------------+ +------------+ |
There are two important files which determine the guidance of printfiles through the CUPS filtering chain.
5.1. /etc/cups/mime.types -- rules to determine MIME types
In /etc/cups/mime.types there are the "rules" contained which determine the MIME types of any given file and also which ones are recognized by CUPS.
5.2. /etc/cups/mime.convs -- assignment of filters according to MIME types
In /etc/cups/mime.convs the filters to be used for any given MIME type are assigned. CUPS tries to construct a valid filter chain from the beginning to the end, also under the directive of the PPD. Every filter also has a virtual "cost" attached to it. In case there are different possible solutions CUPS takes the one with the "cheapest" sum.
??/p>
To implement a CUPS server as a networked software RIP based on Ghostscript, has several benefits.
6.1. Stabilizing Windows Terminal Servers
Windows Terminal Server (WTS) are notorious for their problems regarding printing. These servers often run MS Office and other applications for dozens of clients (whose workstations serve merely as a TV set providing a "window into the server"). A WTS serving 40 users with a small desktop printer each needs to also run 40 printer drivers (or at least one for each different model). It is estimated that 50 % of Blue Screens are related to printer drivers problems. Many sites have adopted a policy to just allow one PostScript and one basic PCL driver for all models of devices in their realm, thusly reducing their users to merely print "simplex loose sheet collections " (while their hardware could do a lot better, of course).
Here's a possible solution:
- relieve the WTS from their many printer drivers;
- consolidate on an Adobe PostScript driver (not known to cause any problems);
- make the WTS a CUPS print client, using the PS driver;
- empower the PS driver on the WTS with multiple CUPS-PPDs;
- increase WTS uptime again;
- make users happy and give them back the ability to use all functions of their printers.
6.2. Achieving centralized accounting
CUPS maintains a page_log in /var/log/cups/. In there, every processed job is logged, with every page printed, number of copies, time of the day, username, job id, target printer and optional billing information. A typical file looks like this (extract):
| /var/log/cups/page_log (enumerating printername, username, job-id, time, page-no., no of copies and billing info: |
lj5gray_foomatic kde4 87 [27/Apr/2002:01:58:05 +0200] 1 4 Sylvia
lj5gray_foomatic kde4 87 [27/Apr/2002:01:58:05 +0200] 2 4 Sylvia
lj5gray_foomatic kde4 87 [27/Apr/2002:01:58:05 +0200] 3 4 Sylvia
lj5gray_foomatic kde4 87 [27/Apr/2002:01:58:05 +0200] 4 4 Sylvia
lj5gray_foomatic kde4 87 [27/Apr/2002:01:58:05 +0200] 5 4 Sylvia
lj5gray_foomatic kde4 87 [27/Apr/2002:01:58:05 +0200] 6 4 Sylvia
lj5gray_foomatic root 88 [27/Apr/2002:02:04:52 +0200] 1 1
lj5gray_foomatic root 88 [27/Apr/2002:02:04:52 +0200] 2 1
lj5gray_foomatic root 88 [27/Apr/2002:02:04:52 +0200] 3 1
mopi_320_mailbox kurt 89 [27/Apr/2002:16:23:15 +0200] 1 1 marketing
mopi_320_mailbox kurt 89 [27/Apr/2002:16:23:15 +0200] 2 1 marketing
|
??/p>
NOTE: This information is collected and logged while the printjob passes the pstops filter. It therefor contains the "RIP-ped" pages. It may possibly not reflect the actual printed pages: if the job gets lost after the RIP-ping finished, on the way to the printer, or inside the printer. But overall, it is already a good tool to track costs.
This log file contains all data to generate business reports from. It may also be written to a different place (syslog).
If the clients print "raw", CUPS logs the job as containing 1 (one) page. The logfile content in these cases also doesn't reflect the actual printed pages. "Raw" jobs are bypassing the pstops filter, which is doing the tallying at the current stage. During the 1.2.x development cycle of CUPS this accounting task will be assigned to the CUPS backends, talking directly to the printers and querying and logging each sheet as it is printed. These backchannel data will provide much more accuracy and generally also improve feedback to the user.
This information contains the "RIP-ped" pages. It may be incorrect, if the job gets lost on the way to the printer, after the RIP-ping finished. But overall, it is already a good tool to track costs.
??/p>
7. cupsaddsmb -- the easy way to share a CUPS driver to Windows clients
CUPS provides a nice utility to share any given CUPS printer to Windows clients: cupsaddsmb. If you call it with the "-a" parameter, it shares all printers (i.e. it copies the printers' PPDs plus the Adobe driver files to the [print$] share.:
cupsaddsmb -U root -v -a
(-v is for verbose output, -U is to name a user with the access right to do his). To share an individual printer do
cupsaddsmb -U root -v my_printer_name
Of course, you need to prepare the [print$] share (holding the downloadable Adobe PostScript drivers) beforehand. This amounts to change the smb.conf to contain the following entries:
[global]
load printers = yes
printing = cups
printcap name = cups
[printers]
comment = All Printers
path = /var/spool/samba
browseable = no
public = yes
guest ok = yes
writable = no
printable = yes
printer admin = root
[print$]
comment = Printer Drivers
path = /etc/samba/drivers
browseable = yes
guest ok = no
read only = yes
write list = root
In addition you need to download the Adobe Postscript driver files from their website. Once you have extracted the driver files, create a "drivers" directory in the CUPS data directory (usually /usr/share/cups/) and copy the Adobe files using UPPERCASE filenames, as follows:
ADFONTS.MFM
ADOBEPS4.DRV
ADOBEPS4.HLP
ADOBEPS5.DLL
ADOBEPSU.DLL
ADOBEPSU.HLP
DEFPRTR2.PPD
ICONLIB.DLL
Users who bought a ESP PrintPro license have no such work at all. They just tick the "Install Samba driver files" inside the installer window and they are done. "cupsaddsmb" can then also be called from a GUI, by clicking on "Export Printer".
??/p>
8. A few figures about needed resources
Of course, as was hinted to earlier, making CUPS to act as a Software RIP on behalf of its clients and printers, consumes much more CPU than just mere spooling and passing on the jobs. Here are a few figures to help you estimate the size of the machine you'd need. Assume the following facts:
| Assumptions about daily print runs: |
|
First, assume your printers are all PostScript capable. This requires the following computing capacity:on your CUPS server
| 100 PostScript printers, 5.000 jobs/day total, 10 concurrent jobs guaranteed, typical job size 20 MByte: |
燭o enforce the requested limits, set these CUPS configuration directives (in /etc/cups/cupsd.conf)
|
You need more computing power, if you assume all the printers to be non-PostScript models (other assumptions being equal):
| 100 non-PostScript printers, 5.000 jobs/day total, 10 concurrent jobs guaranteed, typical job size 20 MByte: |
燭o enforce the requested limits, set these CUPS configuration directives (in /etc/cups/cupsd.conf):
|
CUPS and Samba can make up a great tandem to serve Windows client networks with unique printing services:
- Loading down printer drivers to the clients via "Point and Print" eases administration a lot.
- Running CUPS as a network software RIP centralizes and eases accounting and billing considerably.
- Consolidating Windows Terminal Servers by reducing them to run a single PostScript printer driver type for multiple clients (instead of many different ones), stabilizes their performance.
CUPS is posed to gain a much more important role in the coming years.
