Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Mail Systems
Eclipse Documentation

How To Guides
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Problem Solutions
Privacy Policy




Samba HowTo Guide
Prev Home Next

Additional Material

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 exceptions are file types application/octet-stream that need the pass-through feature enabled. “Raw” queues do not do any filtering at all; they hand the file directly to the CUPS backend. This backend is responsible for sending the data to the device (as in the “device URI” notation: lpd://, socket://, smb://, ipp://, https://, parallel:/, serial:/, usb:/, and so on).

cupsomatic/Foomatic are not native CUPS drivers and they do not ship with CUPS. They are a third-party add-on developed at 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 command line at that stage in the CUPS filtering chain where normally the native CUPS pstoraster filter would kick in. cupsomatic bypasses pstoraster , kidnaps the print file from CUPS, and redirects it to go through Ghostscript. CUPS accepts this because the associated cupsomatic/foomatic-PPD specifies:

*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 that are autotyped application/octet-stream , with the according changes in /etc/cups/mime.types in place.

CUPS is widely configurable and flexible, even regarding its filtering mechanism. Another workaround in some situations would be to have in /etc/cups/mime.types entries as follows:

application/postscript           application/vnd.cups-raw  0  -
application/vnd.cups-postscript  application/vnd.cups-raw  0  -

This would prevent all PostScript files from being filtered (rather, they will through the virtual nullfilter denoted with “-”). This could only be useful for PostScript printers. If you want to print PostScript code on non-PostScript printers (provided they support ASCII text printing), an entry as follows could be useful:

*/*           application/vnd.cups-raw  0  -

and would effectively send all files to the backend without further processing.

You could have the following entry:

application/vnd.cups-postscript application/vnd.cups-raw 0 \

You will need to write a my_PJL_stripping_filter (which could be a shell script) that parses the PostScript and removes the unwanted PJL. This needs to conform to CUPS filter design (mainly, receive and pass the parameters printername, job-id, username, jobtitle, copies, print options, and possibly the filename). It is installed as world executable into /usr/lib/cups/filters/ and is called by CUPS if it encounters a MIME type application/vnd.cups-postscript .

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 (such as when the operators often need to load the proper paper type before running the 10,000 page job requested by marketing for the mailing, and so on).

Samba HowTo Guide
Prev Home Next

  Published under the terms fo the GNU General Public License Design by Interspire