Kurt Pfeifle
2002-Sep-22 13:49 UTC
CUPS filtering mechanism explained, was: [cups raw mode, was Re: [Samba] unlink data file in cups_job_submit]
Paul Janzen wrote on Samba digest:
> Message: 7
> To: Gerald Carter <jerry@samba.org>
> Cc: samba@lists.samba.org
> From: Paul Janzen <pcj@samba.sez.to>
> Subject: cups raw mode, was Re: [Samba] unlink data file in
cups_job_submit
> Date: 21 Sep 2002 12:09:23 -0700
>
>
> Gerald Carter <jerry@samba.org> writes:
>
> > Looks right to me [:-)] Applying it now. Thanks. I've been
meaning to
> > track this one down.
>
>
> Thanks!
>
> While we are on the subject... [:-)]
>
> If I am using native printer drivers on Windows clients, I would like
> the "raw" option to get propagated to CUPS. Otherwise cups does
not
> pass the data on to the printer.
Paul,
I see you know about what you call the "raw data passthrough feature".
I guess you mean the lines in "/etc/cups/mime.types" and
"/etc/cups/mime.convs" which need to be uncommented to allow
"raw"
printing ?
Here is some clarification (likely not very useful for you, but
possibly for some other readers of the Samba list):
### If you have "printing = cups" and "printcap = cups"
enabled,
--- everything is handled by Samba accessing the CUPS API. (And any
"print command" directive in Samba will be ignored.) If the CUPS
API is not available (because Samba might not be compiled against
libcups), it automatically maps to the "System V" command set, with
"-oraw" enabled automatically.
> (If I enable cups's application/
> octet-stream raw-data passthrough feature, both cupsomatic and the
> Windows driver add PJL headers and footers, which is not what I want
> either.)
### According to my experience, cupsomatic on the Samba/CUPS server
--- does *not* add any features if a file is really printed "raw".
However, if you have loaded the driver for the Windows client
from the CUPS server, using the "cupsaddsmb" utility, and if this
driver is one using a "Foomatic" PPD, the PJL header in question is
already added on the Windows client, at the time when the driver
initially generated the PostScript data -- and CUPS in true "-oraw"
manner doesn't remove this PJL header and passes the file "as is"
to its printer communication backend.
NOTE, please, that the editing in the "mime.convs" and the
----- "mime.types" file does not *enforce* "raw" printing,
it
only *allows* it. Any file arriving from Windows is
"auto-typed" by CUPS, which might consecutively lead to its
treatment by various filters automatically (depending on the
actual outcome of the auto-typing and the configuration of the
printqueue in question):
--> Files generated by PCL drivers and destined to PCL
printers get auto-typed "application/octet-stream"
and are indeed printed "raw". Also, unknown file
types are getting tagged as "application/octet-stream".
--> Files generated by a PostScript driver (and destined
for any target printer type) are auto-typed. Depending
on the driver, the discovered MIME type may be
* application/postscript or
* application/vnd.cups-postscript
"application/postscript" goes first thru the "pstops" filter
(where also the page counting and accounting takes place
currently), and the outcome will be of MIME type
"application/vnd.cups-postscript". The pstopsfilter reads and
uses information from the PPD and inserts user-provided options
into the PostScript file. As a consequence, the filtered file
will possibly have the PJL header you don't want.
"application/postscript" will be all files with a ".ps",
".ai",
".eps" suffix or which have as their first character string one
of "%!" or "<04>%".
"application/vnd.cups-postscript" will be those files which do both,
first...
...carry a string "LANGUAGE=POSTSCRIPT" (or similar variations
with different capitalization) amongst the first 512 bytes,
*plus*...
...contain the "PJL super escape code" amongst the first 128
bytes ("<1B>%-12345X"). Very likely, most PostScript
files
generated on Windows using a CUPS- or other PPD, will have
to be auto-typed as "vnd.cups-postscript".
Probably a file produced with a "Generic PostScript driver"
will be just "application/postscript" (have not checked).
Once the file is in "application/vnd.cups-postscript" format,
either "pstoraster" or "cupsomatic" will take over
(depending
on the printer configuration, as determined by the PPD in use).
NOTE: a printer queue with *no* PPD associated to it is a "raw"
----- printer and all files will go directly there as received
by the spooler; the exeption are file types
"application/octet-stream" which need the mentioned "passthrough
feature" enabled. "Raw" queues don't do any filtering at all,
they
hand the file directly to the CUPS backend. This backend is
responsible for the sending of the data to the device (as visible
in the "device URI" notation as lpd://, socket://, smb://, ipp://,
http://, parallel:/, serial:/, usb:/ etc.)
NOTE, please, also the following fact: "cupsomatic"/Foomatic are
----- *not* native CUPS drivers and they don't ship with CUPS.
They are a Third Party add-on, developed at Linuxprinting.org.
As such, they are a brilliant hack to make all models (driven by
Ghostscript drivers/filters in traditional spoolers) also work via
CUPS, with the same (good or bad!) quality as in these other
spoolers. "cupsomatic" is only a vehicle to execute a ghostscript
commandline at that stage in the CUPS filtering chain, where
"normally" the native CUPS "pstoraster" filter would kick
in.
cupsomatic by-passes pstoraster, "kidnaps" the printfile from CUPS
away and re-directs it to go through Ghostscipt. CUPS accepts this,
because the associated CUPS-O-Matic-/Foomatic-PPD carries a line
reading
*cupsFilter: "application/vnd.cups-postscript 0 cupsomatic"
This line persuades CUPS to hand the file to cupsomatic, once it
has successfully converted it to the MIME type
"application/vnd.cups-postscript". This conversion will not
happen for Jobs arriving from Windows which are autotyped
"application/octet-stream", with the according changes in
"/etc/cups/mime.types" in place.
See small drawings at the end...
I am not a programmer, so please correct me if I am wrong.
> With traditional lpr, you can just add "-oraw" to the
"print command"
> line in smb.conf. With cups, you don't have that alternative.
You *do* have it, I think.
But you need to disable the settings "printing = cups" and
"printcap = cups" and use "printing = bsd" and
"printcap = /etc/printcap"
instead. [Additionally, you will probably have to enable and configure
the CUPS mini-LPD daemon ("cups-lpd") run from inetd... but I have not
checked, so take this item with a grain of salt and a proper dose of
caution, please.]
> The result is that to support both unix printing and native-driver
> Windows printing from CUPS, you have to have two logical printers per
> physical printer: one ("cooked") for Unix clients and one
("raw") for
> Samba to use.
Yes, that is one current workaround, if you don't want the auto-typing
of CUPS influencing Samba/Windows client PostScript jobs.
CUPS is widely configurable and flexible, even regarding its filtering
mechanism. Another workaround in some situations would be to have
lines in "/etc/cups/mime.types" saying
application/postscript application/vnd.cups-raw 0 -
application/vnd.cups-postscript application/vnd.cups-raw 0 -
This would prevent all Postscript files to be filtered (or rather, they
will go thru the virtual "nullfilter" denoted with "-".
(This could only
be useful for PS printers, or if you want to print PS code on non-PS
printers ;-)
A single line of
*/* application/vnd.cups-raw 0 -
would effectively send *all* files towards the backend immediately
(good luck!)
Last, you could have the following (without the need for a Samba
patch):
application/vnd.cups-postscript application/vnd.cups-raw 0
my_PJL_stripping_filter
You'd need to write a "my_PJL_stripping_filter" (could be a
shellscript)
which parses the PostScript and removes the undesired PJL. This would
need to conform to CUPS filter design (mainly, receive and pass the
parameters printername, job-id, username, jobtitle, copies, printoptions
and possibly the filename). It would just go as world executably into
"/usr/lib/cups/filters/" and work from there, called by cups if it
encounters a MIME type "application/vnd.cups-postscript"
> The attached patch allows you to specify an option string for cups
> printers in smb.conf.
I think your patch is in any case very useful (if it works as
advertised ;-). It is the most generic, simple and flexible
approach to complement CUPS.
> So, if you want to use native Windows drivers,
> all you need is
>
> cups printer options = raw
>
> in smb.conf. You can add any other options that cups and the printer
> understand.
Now this last sentence makes me very curious. Do you mean you can add
*multiple* options to this directive? Which syntax would be required
for this ? (Some CUPS options are specified by an "-o option=value"
pair on the commandline, some are single values, like the "-o raw"
one...)
I am thinking on one specific usage now:
-----------------------------------------------------------------------
-> passing any available IPP job attribute to the printer / the spooler
-----------------------------------------------------------------------
For example, CUPS can handle "-o job-hold-until=indefinite". This
keeps the job in the queue "on hold". It will only be printed upon
manual release by the printer operator. This is a requirement in
many "central reproduction departments", where a few operators
manage the jobs of hundreds of users on some big machine, where no
user is allowed to have direct access. (The operators often need to
load the proper paper type before running the 10.000 page job
requested by marketing for the mailing, etc.).
A lot more useful applications come to mind, if I could pass
"any other options that cups and the printer understand" via
the smb.conf directive!!
Thanks a lot!
Cheers,
Kurt
P.S.: List, please give me some feedback, if you think this type of
explanation could be useful in the Samba HOWTO Collection. In
that case, I'll try to write it up in a nicer form.
#########################################################################
#
# CUPS in and of itself has this (general) filter chain (CAPITAL
# letters are FILE-FORMATS or MIME types, other are filters (this is
# true for pre-1.1.15 of pre-4.3 versions of CUPS and ESP PrintPro):
#
# <SOMETHNG>-FILEFORMAT
# |
# |
# V
# <something>tops
# |
# |
# V
# APPLICATION/POSTSCRIPT
# |
# |
# V
# pstops
# |
# |
# V
# APPLICATION/VND.CUPS-POSTSCRIPT
# |
# |
# V
# pstoraster # as shipped with CUPS, independent from any Ghostscipt
# | # installation on the system
# | (= "postscipt interpreter")
# |
# V
# APPLICATION/VND.CUPS-RASTER
# |
# |
# V
# rasterto<something> (f.e. Gimp-Print filters may be plugged in
here)
# | (= "raster driver")
# |
# V
# SOMETHING-DEVICE-SPECIFIC
# |
# |
# V
# backend
#
#
# ESP PrintPro has some enhanced "rasterto<something>" filters
as compared to
# CUPS, and also a somewhat improved "pstoraster" filter.
#
# NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
# CUPS and ESP PrintPro plug-in where rasterto<something> is noted.
#
#
#########################################################################
#
# This is how "cupsomatic" comes into play:
# ========================================#
# <SOMETHNG>-FILEFORMAT
# |
# |
# V
# <something>tops
# |
# |
# V
# APPLICATION/POSTSCRIPT
# |
# |
# V
# pstops
# |
# |
# V
# APPLICATION/VND.CUPS-POSTSCRIPT ----------------+
# | |
# | V
# V cupsomatic
# pstoraster (constructs complicated
# | (= "postscipt interpreter") Ghostscript
commandline
# | to let the file be
# V processed by a
# APPLICATION/VND.CUPS-RASTER
"-sDEVICE=<s.th.>"
# | call...)
# | |
# V |
# rasterto<something> V
# | (= "raster driver") +-------------------------+
# | | Ghostscript at work.... |
# V | |
# SOMETHING-DEVICE-SPECIFIC *-------------------------+
# | |
# | |
# V |
# backend <------------------------------------+
# |
# |
# V
# THE PRINTER
#
#
#
# Note, that cupsomatic "kidnaps" the printfile after the
# "APPLICATION/VND.CUPS-POSTSCRPT" stage and deviates it through
# the CUPS-external, systemwide Ghostscript installation, bypassing the
# "pstoraster" filter (therefor also bypassing the CUPS-raster-drivers
# "rasterto<something>", and hands the rasterized file directly
to the CUPS
# backend...
#
# cupsomatic is not made by the CUPS developers. It is an independent
# contribution to printing development, made by people from
# Linuxprinting.org. (see also http://www.cups.org/cups-help.html)
#
# NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
# CUPS and ESP PrintPro plug-in where rasterto<something> is noted.
#
#
#########################################################################
#
# And this is how it works for ESP PrintPro from 4.3:
# ==================================================#
# <SOMETHNG>-FILEFORMAT
# |
# |
# V
# <something>tops
# |
# |
# V
# APPLICATION/POSTSCRIPT
# |
# |
# V
# pstops
# |
# |
# V
# APPLICATION/VND.CUPS-POSTSCRIPT
# |
# |
# V
# gsrip
# | (= "postscipt interpreter")
# |
# V
# APPLICATION/VND.CUPS-RASTER
# |
# |
# V
# rasterto<something> (f.e. Gimp-Print filters may be plugged in
here)
# | (= "raster driver")
# |
# V
# SOMETHING-DEVICE-SPECIFIC
# |
# |
# V
# backend
#
# NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
# CUPS and ESP PrintPro plug-in where rasterto<something> is noted.
#
#
#########################################################################
#
# This is how "cupsomatic" would come into play with ESP PrintPro:
# ===============================================================#
#
# <SOMETHNG>-FILEFORMAT
# |
# |
# V
# <something>tops
# |
# |
# V
# APPLICATION/POSTSCRIPT
# |
# |
# V
# pstops
# |
# |
# V
# APPLICATION/VND.CUPS-POSTSCRIPT ----------------+
# | |
# | V
# V cupsomatic
# gsrip (constructs complicated
# | (= "postscipt interpreter") Ghostscript
commandline
# | to let the file be
# V processed by a
# APPLICATION/VND.CUPS-RASTER
"-sDEVICE=<s.th.>"
# | call...)
# | |
# V |
# rasterto<something> V
# | (= "raster driver") +-------------------------+
# | | Ghostscript at work.... |
# V | |
# SOMETHING-DEVICE-SPECIFIC *-------------------------+
# | |
# | |
# V |
# backend <------------------------------------+
# |
# |
# V
# THE PRINTER
#
# NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
# CUPS and ESP PrintPro plug-in where rasterto<something> is noted.
#
#########################################################################
#
# And this is how it works for CUPS from 1.1.15:
# =============================================#
# <SOMETHNG>-FILEFORMAT
# |
# |
# V
# <something>tops
# |
# |
# V
# APPLICATION/POSTSCRIPT
# |
# |
# V
# pstops
# |
# |
# V
# APPLICATION/VND.CUPS-POSTSCRIPT-----+
# |
# +------------------v------------------------------+
# | Ghostscript |
# | at work... |
# | (with |
# | "-sDEVICE=cups") |
# | |
# | (= "postscipt interpreter") |
# | |
# +------------------v------------------------------+
# |
# |
# APPLICATION/VND.CUPS-RASTER <-------+
# |
# |
# V
# rasterto<something>
# | (= "raster driver")
# |
# V
# SOMETHING-DEVICE-SPECIFIC
# |
# |
# V
# backend
#
#
# NOTE: since version 1.1.15 CUPS "outsourced" the pstoraster process
to
# Ghostscript. GNU Ghostscript needs to be patched to handle the
# CUPS requirement; ESP Ghostscript has this builtin. In any case,
# "gs -h" needs to show up a "cups" device. pstoraster
is now a
# calling an appropriate "gs -sDEVICE=cups..." commandline to do
# the job. It will output "application/vnd.cup-raster", which
will
# be finally processed by a CUPS raster driver
"rasterto<something>"
# Note the difference to "cupsomatic", which will *not* output
# CUPS-raster, but a final version of the printfile, ready to be
# sent to the printer. cupsomatic also doesn't use the
"cups"
# devicemode in Ghostscript, but one of the classical devicemodes....
#
# NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
# CUPS and ESP PrintPro plug-in where rasterto<something> is noted.
#
#########################################################################
#
# And this is how it works for CUPS from 1.1.15, with cupsomatic included:
# =======================================================================#
# <SOMETHNG>-FILEFORMAT
# |
# |
# V
# <something>tops
# |
# |
# V
# APPLICATION/POSTSCRIPT
# |
# |
# V
# pstops
# |
# |
# V
# APPLICATION/VND.CUPS-POSTSCRIPT-----+
# |
# +------------------v------------------------------+
# | Ghostscript . Ghostscript at work.... |
# | at work... . (with "-sDEVICE= |
# | (with . <s.th.>"
|
# | "-sDEVICE=cups") . |
# | . |
# | (CUPS standard) . (cupsomatic) |
# | . |
# | (= "postscript interpreter") |
# | . |
# +------------------v--------------v---------------+
# | |
# | |
# APPLICATION/VND.CUPS-RASTER <-------+ |
# | |
# | |
# V |
# rasterto<something> |
# | (= "raster driver") |
# | |
# V |
# SOMETHING-DEVICE-SPECIFIC <------------------------+
# |
# |
# V
# backend
#
#
# NOTE: Gimp-Print and some other 3rd-Party-Filters (like TurboPrint) to
# CUPS and ESP PrintPro plug-in where rasterto<something> is noted.
#
##########################################################################
I hope this helps more people understand how CUPS works and how they
can possibly tweak it to their needs.
Possibly Parallel Threads
Wisdom of the Ancients
