Mboxir is a specialized filtering backend for CUPS, designed specifically to filter jobs into a specified mailbox of Canon imageRUNNER printers.
Mboxir is a specialized filtering backend for CUPS, designed specifically to
filter jobs into a specified mailbox of a Canon imageRUNNER (iR2270 tested).
The second parameter is the mailbox into which the print job will be stuffed.
This backend will only work with postscript. It removes any existing PJL and
adds the necessary PJL header, commands, and footer, for mailbox insertion.
This is a filtering backend, which is not the best place to accomplish
filtering in CUPS. However, if you want to accomodate filtered and raw queues
alike, an interface script will not do.
2) the File::Copy Perl module
3) A printer that accepts Postscript
Download the script and copy it into the CUPS backends directory, which is
typically /usr/lib/cups/backend. Once there, you have to send CUPS a SIGHUP
for it to re-scan all the available backends. Do a 'killall -HUP cupsd', or
use the init script: '/etc/init.d/cups reload'. A restart will work just as
well, but no real need to stop and start the server daemon.
Now check the web interface. When creating or modifying printers, you should
see an option for an "Mailbox (imageRUNNER)" in the dropdown box of available
devices. If not, make sure the permissions on the file are chmodded to 755 and
owned by the correct user:group (check the rest of the files in the directory
and match it).
Variables in the conf hash can be set in script, affecting all queues, or can
be overridden on a per-queue basis through an external configuration file. The
$queues_conf variable determines location, default /etc/cups/queues.conf.
The qconf file is formatted exactly like the printcap file, except that
comments, blank lines, and whitespace between all elements are allowed. All
variables above can be overridden on a per-queue basis. Location is
determined by the queues_conf variable. If this file does not exist,
variable values are simply those set in the script. Example file:
# TEST1 has debugging, saving jobs, and factor four set
# TEST2 is identical
TEST2 | debug : save_jobs
# Some other random configuration
TEST3 | check_user : check_job
You may wish to simply setup a printer and try to fire away test pages and look
at the CUPS log to see what problems exist. Set it up initially with a device
URI like this for mailbox zero:
Check the logs. Try enabling debugging within the script. If it all works,
The mboxir backend assumes it is receving raw postscript, and simply adds
the necessary PJL commands (according to www.developersupport.canon.com)
to stuff a job into a mailbox. Sending lousy postscript, postscript with
existing PJL headers, PCL, binary junk, etc., will usually result in no
output, but can result in a locked up printer. Your mileage may vary.
Unfortunately the official Windows drivers as shipped by Canon fall into this
catetory. They embed all kinds of binary junk in their postscript. Use
something like a LaserJet 4000 driver or a generic PS driver. Or, to retain
full printer features, download their .PPD and package up your own .inf
installer. Pretty simple once you look at it.
mboxir 1.02 (20120421)
- All script variables can be overridden on a per-queue basis using new
"qconf" configuration file format. Most variables renamed in a more
consistent manner to fit with this scheme.
- URI syntax check loosened to accept mboxir:/#/<original uri> as well as
mboxir://#/<original uri>, since the latter will no longer work with
- Integrated perldoc.
mboxir 1.01 (20051223)
- The PJL addition and filtering of the printjob has been made into
a function called filterPrint.
- Now adds a nicely formatted job title into the printer mailbox, in
the form of "username: title" instead of whatever.
- Some cleanup of extraneous code leftover from earlier backends
from which this is derived.
mboxir v1.00 (20051221)
- Quick and dirty, roughly based on accsnmp backend.
- Some enhancements based off of Till Kamppeter's beh backend,
most notably: using the device URI for passing arguments, the more
elegant handling of the device URI generally, and actually
using the CUPS tempdir to spool temp files.