1 Date: Sun, 22 Sep 2002 15:38:02 +0200
2 From: "Kurt Pfeifle" <kpfeifle@danka.de>
3 Reply-To: kpfeifle@danka.de
4 Organization: Danka Deutschland GmbH
5 To: samba@lists.samba.org
6 Subject: CUPS filtering mechanism explained, was: [cups raw mode, was Re: [Samba] unlink data file in cups_job_submit]
8 Paul Janzen wrote on Samba digest:
11 > To: Gerald Carter <jerry@samba.org>
12 > Cc: samba@lists.samba.org
13 > From: Paul Janzen <pcj@samba.sez.to>
14 > Subject: cups raw mode, was Re: [Samba] unlink data file in cups_job_submit
15 > Date: 21 Sep 2002 12:09:23 -0700
18 > Gerald Carter <jerry@samba.org> writes:
20 > > Looks right to me [:-)] Applying it now. Thanks. I've been meaning to
21 > > track this one down.
26 > While we are on the subject... [:-)]
28 > If I am using native printer drivers on Windows clients, I would like
29 > the "raw" option to get propagated to CUPS. Otherwise cups does not
30 > pass the data on to the printer.
34 I see you know about what you call the "raw data passthrough feature".
35 I guess you mean the lines in "/etc/cups/mime.types" and
36 "/etc/cups/mime.convs" which need to be uncommented to allow "raw"
39 Here is some clarification (likely not very useful for you, but
40 possibly for some other readers of the Samba list):
42 ### If you have "printing = cups" and "printcap = cups" enabled,
43 --- everything is handled by Samba accessing the CUPS API. (And any
44 "print command" directive in Samba will be ignored.) If the CUPS
45 API is not available (because Samba might not be compiled against
46 libcups), it automatically maps to the "System V" command set, with
47 "-oraw" enabled automatically.
49 > (If I enable cups's application/
50 > octet-stream raw-data passthrough feature, both cupsomatic and the
51 > Windows driver add PJL headers and footers, which is not what I want
54 ### According to my experience, cupsomatic on the Samba/CUPS server
55 --- does *not* add any features if a file is really printed "raw".
56 However, if you have loaded the driver for the Windows client
57 from the CUPS server, using the "cupsaddsmb" utility, and if this
58 driver is one using a "Foomatic" PPD, the PJL header in question is
59 already added on the Windows client, at the time when the driver
60 initially generated the PostScript data -- and CUPS in true "-oraw"
61 manner doesn't remove this PJL header and passes the file "as is"
62 to its printer communication backend.
64 NOTE, please, that the editing in the "mime.convs" and the
65 ----- "mime.types" file does not *enforce* "raw" printing, it
66 only *allows* it. Any file arriving from Windows is
67 "auto-typed" by CUPS, which might consecutively lead to its
68 treatment by various filters automatically (depending on the
69 actual outcome of the auto-typing and the configuration of the
70 printqueue in question):
72 --> Files generated by PCL drivers and destined to PCL
73 printers get auto-typed "application/octet-stream"
74 and are indeed printed "raw". Also, unknown file
75 types are getting tagged as "application/octet-stream".
77 --> Files generated by a PostScript driver (and destined
78 for any target printer type) are auto-typed. Depending
79 on the driver, the discovered MIME type may be
81 * application/postscript or
82 * application/vnd.cups-postscript
84 "application/postscript" goes first thru the "pstops" filter
85 (where also the page counting and accounting takes place
86 currently), and the outcome will be of MIME type
87 "application/vnd.cups-postscript". The pstopsfilter reads and
88 uses information from the PPD and inserts user-provided options
89 into the PostScript file. As a consequence, the filtered file
90 will possibly have the PJL header you don't want.
92 "application/postscript" will be all files with a ".ps", ".ai",
93 ".eps" suffix or which have as their first character string one
96 "application/vnd.cups-postscript" will be those files which do both,
98 ...carry a string "LANGUAGE=POSTSCRIPT" (or similar variations
99 with different capitalization) amongst the first 512 bytes,
101 ...contain the "PJL super escape code" amongst the first 128
102 bytes ("<1B>%-12345X"). Very likely, most PostScript files
103 generated on Windows using a CUPS- or other PPD, will have
104 to be auto-typed as "vnd.cups-postscript".
105 Probably a file produced with a "Generic PostScript driver"
106 will be just "application/postscript" (have not checked).
108 Once the file is in "application/vnd.cups-postscript" format,
109 either "pstoraster" or "cupsomatic" will take over (depending
110 on the printer configuration, as determined by the PPD in use).
112 NOTE: a printer queue with *no* PPD associated to it is a "raw"
113 ----- printer and all files will go directly there as received
114 by the spooler; the exeption are file types
115 "application/octet-stream" which need the mentioned "passthrough
116 feature" enabled. "Raw" queues don't do any filtering at all, they
117 hand the file directly to the CUPS backend. This backend is
118 responsible for the sending of the data to the device (as visible
119 in the "device URI" notation as lpd://, socket://, smb://, ipp://,
120 http://, parallel:/, serial:/, usb:/ etc.)
122 NOTE, please, also the following fact: "cupsomatic"/Foomatic are
123 ----- *not* native CUPS drivers and they don't ship with CUPS.
124 They are a Third Party add-on, developed at Linuxprinting.org.
125 As such, they are a brilliant hack to make all models (driven by
126 Ghostscript drivers/filters in traditional spoolers) also work via
127 CUPS, with the same (good or bad!) quality as in these other
128 spoolers. "cupsomatic" is only a vehicle to execute a ghostscript
129 commandline at that stage in the CUPS filtering chain, where
130 "normally" the native CUPS "pstoraster" filter would kick in.
131 cupsomatic by-passes pstoraster, "kidnaps" the printfile from CUPS
132 away and re-directs it to go through Ghostscipt. CUPS accepts this,
133 because the associated CUPS-O-Matic-/Foomatic-PPD carries a line
136 *cupsFilter: "application/vnd.cups-postscript 0 cupsomatic"
138 This line persuades CUPS to hand the file to cupsomatic, once it
139 has successfully converted it to the MIME type
140 "application/vnd.cups-postscript". This conversion will not
141 happen for Jobs arriving from Windows which are autotyped
142 "application/octet-stream", with the according changes in
143 "/etc/cups/mime.types" in place.
145 See small drawings at the end...
147 I am not a programmer, so please correct me if I am wrong.
149 > With traditional lpr, you can just add "-oraw" to the "print command"
150 > line in smb.conf. With cups, you don't have that alternative.
152 You *do* have it, I think.
154 But you need to disable the settings "printing = cups" and "printcap =
155 = cups" and use "printing = bsd" and "printcap = /etc/printcap"
156 instead. [Additionally, you will probably have to enable and configure
157 the CUPS mini-LPD daemon ("cups-lpd") run from inetd... but I have not
158 checked, so take this item with a grain of salt and a proper dose of
161 > The result is that to support both unix printing and native-driver
162 > Windows printing from CUPS, you have to have two logical printers per
163 > physical printer: one ("cooked") for Unix clients and one ("raw") for
166 Yes, that is one current workaround, if you don't want the auto-typing
167 of CUPS influencing Samba/Windows client PostScript jobs.
169 CUPS is widely configurable and flexible, even regarding its filtering
170 mechanism. Another workaround in some situations would be to have
171 lines in "/etc/cups/mime.types" saying
173 application/postscript application/vnd.cups-raw 0 -
174 application/vnd.cups-postscript application/vnd.cups-raw 0 -
176 This would prevent all Postscript files to be filtered (or rather, they
177 will go thru the virtual "nullfilter" denoted with "-". (This could only
178 be useful for PS printers, or if you want to print PS code on non-PS
183 */* application/vnd.cups-raw 0 -
185 would effectively send *all* files towards the backend immediately
188 Last, you could have the following (without the need for a Samba
191 application/vnd.cups-postscript application/vnd.cups-raw 0 my_PJL_stripping_filter
193 You'd need to write a "my_PJL_stripping_filter" (could be a shellscript)
194 which parses the PostScript and removes the undesired PJL. This would
195 need to conform to CUPS filter design (mainly, receive and pass the
196 parameters printername, job-id, username, jobtitle, copies, printoptions
197 and possibly the filename). It would just go as world executably into
198 "/usr/lib/cups/filters/" and work from there, called by cups if it
199 encounters a MIME type "application/vnd.cups-postscript"
201 > The attached patch allows you to specify an option string for cups
202 > printers in smb.conf.
204 I think your patch is in any case very useful (if it works as
205 advertised ;-). It is the most generic, simple and flexible
206 approach to complement CUPS.
208 > So, if you want to use native Windows drivers,
211 > cups printer options = raw
213 > in smb.conf. You can add any other options that cups and the printer
216 Now this last sentence makes me very curious. Do you mean you can add
217 *multiple* options to this directive? Which syntax would be required
218 for this ? (Some CUPS options are specified by an "-o option=value"
219 pair on the commandline, some are single values, like the "-o raw"
222 I am thinking on one specific usage now:
224 -----------------------------------------------------------------------
225 -> passing any available IPP job attribute to the printer / the spooler
226 -----------------------------------------------------------------------
228 For example, CUPS can handle "-o job-hold-until=indefinite". This
229 keeps the job in the queue "on hold". It will only be printed upon
230 manual release by the printer operator. This is a requirement in
231 many "central reproduction departments", where a few operators
232 manage the jobs of hundreds of users on some big machine, where no
233 user is allowed to have direct access. (The operators often need to
234 load the proper paper type before running the 10.000 page job
235 requested by marketing for the mailing, etc.).
237 A lot more useful applications come to mind, if I could pass
238 "any other options that cups and the printer understand" via
239 the smb.conf directive!!
246 P.S.: List, please give me some feedback, if you think this type of
247 explanation could be useful in the Samba HOWTO Collection. In
248 that case, I'll try to write it up in a nicer form.
251 #########################################################################
253 # CUPS in and of itself has this (general) filter chain (CAPITAL
254 # letters are FILE-FORMATS or MIME types, other are filters (this is
255 # true for pre-1.1.15 of pre-4.3 versions of CUPS and ESP PrintPro):
257 # <SOMETHNG>-FILEFORMAT
265 # APPLICATION/POSTSCRIPT
273 # APPLICATION/VND.CUPS-POSTSCRIPT
277 # pstoraster # as shipped with CUPS, independent from any Ghostscipt
278 # | # installation on the system
279 # | (= "postscipt interpreter")
282 # APPLICATION/VND.CUPS-RASTER
286 # rasterto<something> (f.e. Gimp-Print filters may be plugged in here)
287 # | (= "raster driver")
290 # SOMETHING-DEVICE-SPECIFIC
297 # ESP PrintPro has some enhanced "rasterto<something>" filters as compared to
298 # CUPS, and also a somewhat improved "pstoraster" filter.
300 # NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
301 # CUPS and ESP PrintPro plug-in where rasterto<something> is noted.
304 #########################################################################
306 # This is how "cupsomatic" comes into play:
307 # =========================================
309 # <SOMETHNG>-FILEFORMAT
317 # APPLICATION/POSTSCRIPT
325 # APPLICATION/VND.CUPS-POSTSCRIPT ----------------+
329 # pstoraster (constructs complicated
330 # | (= "postscipt interpreter") Ghostscript commandline
331 # | to let the file be
333 # APPLICATION/VND.CUPS-RASTER "-sDEVICE=<s.th.>"
337 # rasterto<something> V
338 # | (= "raster driver") +-------------------------+
339 # | | Ghostscript at work.... |
341 # SOMETHING-DEVICE-SPECIFIC *-------------------------+
345 # backend <------------------------------------+
353 # Note, that cupsomatic "kidnaps" the printfile after the
354 # "APPLICATION/VND.CUPS-POSTSCRPT" stage and deviates it through
355 # the CUPS-external, systemwide Ghostscript installation, bypassing the
356 # "pstoraster" filter (therefor also bypassing the CUPS-raster-drivers
357 # "rasterto<something>", and hands the rasterized file directly to the CUPS
360 # cupsomatic is not made by the CUPS developers. It is an independent
361 # contribution to printing development, made by people from
362 # Linuxprinting.org. (see also http://www.cups.org/cups-help.html)
364 # NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
365 # CUPS and ESP PrintPro plug-in where rasterto<something> is noted.
368 #########################################################################
370 # And this is how it works for ESP PrintPro from 4.3:
371 # ===================================================
373 # <SOMETHNG>-FILEFORMAT
381 # APPLICATION/POSTSCRIPT
389 # APPLICATION/VND.CUPS-POSTSCRIPT
394 # | (= "postscipt interpreter")
397 # APPLICATION/VND.CUPS-RASTER
401 # rasterto<something> (f.e. Gimp-Print filters may be plugged in here)
402 # | (= "raster driver")
405 # SOMETHING-DEVICE-SPECIFIC
411 # NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
412 # CUPS and ESP PrintPro plug-in where rasterto<something> is noted.
415 #########################################################################
417 # This is how "cupsomatic" would come into play with ESP PrintPro:
418 # ================================================================
421 # <SOMETHNG>-FILEFORMAT
429 # APPLICATION/POSTSCRIPT
437 # APPLICATION/VND.CUPS-POSTSCRIPT ----------------+
441 # gsrip (constructs complicated
442 # | (= "postscipt interpreter") Ghostscript commandline
443 # | to let the file be
445 # APPLICATION/VND.CUPS-RASTER "-sDEVICE=<s.th.>"
449 # rasterto<something> V
450 # | (= "raster driver") +-------------------------+
451 # | | Ghostscript at work.... |
453 # SOMETHING-DEVICE-SPECIFIC *-------------------------+
457 # backend <------------------------------------+
463 # NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
464 # CUPS and ESP PrintPro plug-in where rasterto<something> is noted.
466 #########################################################################
468 # And this is how it works for CUPS from 1.1.15:
469 # ==============================================
471 # <SOMETHNG>-FILEFORMAT
479 # APPLICATION/POSTSCRIPT
487 # APPLICATION/VND.CUPS-POSTSCRIPT-----+
489 # +------------------v------------------------------+
493 # | "-sDEVICE=cups") |
495 # | (= "postscipt interpreter") |
497 # +------------------v------------------------------+
500 # APPLICATION/VND.CUPS-RASTER <-------+
504 # rasterto<something>
505 # | (= "raster driver")
508 # SOMETHING-DEVICE-SPECIFIC
515 # NOTE: since version 1.1.15 CUPS "outsourced" the pstoraster process to
516 # Ghostscript. GNU Ghostscript needs to be patched to handle the
517 # CUPS requirement; ESP Ghostscript has this builtin. In any case,
518 # "gs -h" needs to show up a "cups" device. pstoraster is now a
519 # calling an appropriate "gs -sDEVICE=cups..." commandline to do
520 # the job. It will output "application/vnd.cup-raster", which will
521 # be finally processed by a CUPS raster driver "rasterto<something>"
522 # Note the difference to "cupsomatic", which will *not* output
523 # CUPS-raster, but a final version of the printfile, ready to be
524 # sent to the printer. cupsomatic also doesn't use the "cups"
525 # devicemode in Ghostscript, but one of the classical devicemodes....
527 # NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
528 # CUPS and ESP PrintPro plug-in where rasterto<something> is noted.
530 #########################################################################
532 # And this is how it works for CUPS from 1.1.15, with cupsomatic included:
533 # ========================================================================
535 # <SOMETHNG>-FILEFORMAT
543 # APPLICATION/POSTSCRIPT
551 # APPLICATION/VND.CUPS-POSTSCRIPT-----+
553 # +------------------v------------------------------+
554 # | Ghostscript . Ghostscript at work.... |
555 # | at work... . (with "-sDEVICE= |
556 # | (with . <s.th.>" |
557 # | "-sDEVICE=cups") . |
559 # | (CUPS standard) . (cupsomatic) |
561 # | (= "postscript interpreter") |
563 # +------------------v--------------v---------------+
566 # APPLICATION/VND.CUPS-RASTER <-------+ |
570 # rasterto<something> |
571 # | (= "raster driver") |
574 # SOMETHING-DEVICE-SPECIFIC <------------------------+
581 # NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
582 # CUPS and ESP PrintPro plug-in where rasterto<something> is noted.
584 ##########################################################################
586 I hope this helps more people understand how CUPS works and how they
587 can possibly tweak it to their needs.