For common configurations, you can probably ignore this section entirely - instead, you should jump straight to the Vendor Solutions section below, or better yet, your vendor's documentation. Most Linux distributions supply one or more "idiot-proof" tools to do everything described here for common printers.
If your vendor's tool's results are not satisfactory, or you'd like the ability to interactively control printing options when you print, then you should use PDQ; I recommend PDQ in most cases.
PDQ can be configured by either the superuser or by a joeuser. Root's changes are made to /etc/printrc, and affect everyone, while joeuser can only modify his personal .printrc. Everything applies to both types of configuration.
If PDQ is not available prepackaged for your distribution, you should obtain the source distribution from the PDQ web page and compile it yourself. It is an easy compile, but you must first be sure to have installed the various GTK development library packages, the C library development package, the gcc compiler, make, and possibly a few other development things.
PDQ lets users select a printer to print to. A printer is defined in PDQ as the combination of a "driver" and an "interface". Both drivers and interfaces are, in fact, merely snippets of text in the PDQ configuration file.
A PDQ interface says everything about how to ship data out to a printer. The most common interfaces, which are predefined in the PDQ distribution's example printrc file, are:
A local port interface speaks to a parallel or serial port on the machine PDQ is running on. Using this interface, PDQ can print directly to your parallel port. Note that if you have a multiuser system this can cause confusion, and if you have a network the local-port interface will only apply to one system. In those cases, you can define a raw unfiltered lpd queue for the port and print to the system's lpd daemon exactly the same way from all systems and accounts without any troubles. This interface has a device name argument; the typical value would be /dev/lp0.
A bsd lpd interface speaks over the network to an LPD daemon or LPD-speaking networked printer. PDQ supports job submission, cancellation, and queries to LPD interfaces. This interface has hostname and queuename arguments.
The appletalk interface allows you to print to printers over the Appletalk network; if you have a printer plugged into your Mac this is the way to go. This interface needs to have the Netatalk package installed to work.
A PDQ driver says everything about how to massage print data into a format that a particular printer can handle. For Postscript printers, this will include conversion from ascii into Postscript; for non-Postscript printers this will include conversion from Postscript into the printer's language with Ghostscript.
If one of PDQ's included driver specifications doesn't fit your printer, then read the section below on how to write your own.
To define a printer in PDQ:
Here I'll walk through an example of how to make a PDQ driver declaration. Before you try that, though, there are several places to look for existing driver specs:
ppdtopdq which takes a
Postscript Printer Definition file and converts it into a PDQ
driver specification. This is the obvious path if you have a
Postscript printer. Mail me for a copy.
There are several places to look for the information needed to write your own PDQ driver:
If you have to create your own driver specification, or if you enhance
one from the PDQ distribution or one of the PDQ driver generator
programs mentioned above, please share your creation with the
world! Send it to me (gtaylor+pht@picante.com), and I'll
make sure that it gets found by future PDQ users with your type of
printer.
Now, let's walk through the writing of a driver specification for a printer listed in the Printing HOWTO's database as working, but for which you can't find a PDQ driver spec. I'll use the Canon BJC-210 as the example printer.
First, we look at the database entry for this printer. Note that it is supported "perfectly", so we can expect to get comparable results (or better) to Windows users. The important information is in three places in the entry:
The last line in the Works?/Language/Driver column tells us one driver that works with this printer. More importantly, this name is a link to the driver's home page.
The human-readable notes will often contain useful information. For some printers, there is a More Info link, which usually refers to a web page run by a user with this printer, or to the driver's home page.
Most printers have a list of driver command data. This is the most important part.
These define what options the user can set, and declare PDQ variables for later parts of the driver to use.
These process the print job from whatever format it arrived in (typically Postscript or ASCII) into a language the printer can understand (for example, PCL). Option values are available here, as well as in the output filter.
This final filter bundles up the printer data regardless of input type; often printer options are set here.
The driver list for this printer looks like this:
Driver: Ghostscript: -sDEVICE=bj200 -r360x360 # (360x360 BW)
Driver: Ghostscript: -sDEVICE=bjc600 -r360x360 # (360x360 Color)
The database's documentation tells us that a "Ghostscript" driver
type's text is a set of options for Ghostscript, less the "usual"
options like -q or the file specifying options.
So, as far as the user is concerned, the BJC-210 supports one useful option: the user should pick color or black-and-white. Let's declare that as choice option called "MODE":
option {
var = "MODE"
desc = "Print Mode"
# default_choice "Color" # uncomment to default to color
choice "BW" {
# The value part assigns to the variable MODE whatever you
# want. Here we'll assign the text that varies between the
# two Ghostscript option sets for the two modes.
value = "bj200"
help = "Fast black printing with the black cartridge."
desc = "Black-only"
}
choice "Color" {
value = "bjc600"
help = "Full-color printing."
desc = "Color"
}
}
-oBW or
-oColor. The default can be set from xpdq, or declared above
with the default_choice keyword.
PDQ normally identifies its input with the file(1) command. For each
type returned by file that you want to handle, you provide a
language_driver clause. The clause consists mostly of a
script to process the printjob language, in any (!) scripting language
you wish (the default is the usual Bourne shell).
In our case, we want to print Postscript and ASCII on our BJC-210. This needs two language drivers: one to run Ghostscript for Postscript jobs, and one to add carriage returns to ASCII jobs:
# The first language_driver in the file that matches what file(1)
# says is what gets used.
language_driver ps {
# file(1) returns "PostScript document text conforming at..."
filetype_regx = "postscript"
convert_exec = {
gs -sDEVICE=$MODE -r360x360 \ # gs options from the database
-q -dNOPAUSE -dBATCH -dSAFER \ # the "usual" Ghostscript options
-sOutputFile=$OUTPUT $INPUT # process INPUT into file OUTPUT
# Those last two lines will often be the same for gs-supported
# printers. The gs... line, however, will be different for each
# printer.
}
}
# We declare text after postscript, because the command "file" will
# often describe a postscript file as text (which it is).
language_driver text {
# No filetype_regx; we match the driver's name: "text"
convert_exec = {#!/usr/bin/perl
# a Perl program, just because we can!
my ($in, $out) = ($ENV{'INPUT'}, $ENV{'OUTPUT'});
open INPUT, "$in";
open OUTPUT, ">$out";
while(<INPUT>) {
chomp;
print OUTPUT, "$_\r\n";
}
}
}
That's it! While other printers may need output filtering (as
described in the next section), the above clauses are it for the
BJC-210. We just wrap them all up in a named driver clause:
driver canon-bjc210-0.1 {
option {
var = "MODE"
desc = "Print Mode"
# default_choice "Color" # uncomment to default to color
choice "BW" {
# The value part assigns to the variable MODE whatever you
# want. Here we'll assign the text that varies between the
# two Ghostscript option sets for the two modes.
value = "bj200"
help = "Fast black printing with the black cartridge."
desc = "Black-only"
}
choice "Color" {
value = "bjc600"
help = "Full-color printing."
desc = "Color"
}
}
# The first language_driver in the file that matches what file(1)
# says is what gets used.
language_driver ps {
# file(1) returns "PostScript document text conforming at..."
filetype_regx = "postscript"
convert_exec = {
gs -sDEVICE=$MODE -r360x360 \ # gs options from the database
-q -dNOPAUSE -dBATCH -dSAFER \ # the "usual" Ghostscript options
-sOutputFile=$OUTPUT $INPUT # process INPUT into file OUTPUT
# Those last two lines will often be the same for gs-supported
# printers. The gs... line, however, will be different for each
# printer.
}
}
# We declare text after postscript, because the command "file" will
# often describe a postscript file as text (which it is).
language_driver text {
# No filetype_regx; we match the driver's name: "text"
convert_exec = {#!/usr/bin/perl
# a Perl program, just because we can!
my ($in, $out) = ($ENV{'INPUT'}, $ENV{'OUTPUT'});
open INPUT, "$in";
open OUTPUT, ">$out";
while(<INPUT>) {
chomp;
print OUTPUT, "$_\r\n";
}
}
}
}
If you want to prepend or append something to all printjobs, or do
some sort of transformation on all the data of all types, then it
belongs in the filter_exec clause. Our little Canon doesn't
require such a clause, but just to have an example, here's a
simple illustration showing how to support duplexing and resolution
choice on a Laserjet or clone that speaks PJL:
driver generic-ljet4-with-duplex-0.1 {
# First, two option clauses for the user-selectable things:
option {
var = "DUPLEX_MODE"
desc = "Duplex Mode"
default_choice = "SIMPLEX"
choice "SIMPLEX" {
value = "OFF"
desc = "One-sided prints"
}
choice "DUPLEX" {
value = "ON"
desc = "Two-sided prints"
}
}
option {
var = "GS_RES"
desc = "Resolution"
default_choice = "DPI600"
choice "DPI300" {
value = "-r300x300"
desc = "300 dpi"
}
choice "DPI600" {
value = "-r600x600"
desc = "600 dpi"
}
}
# Now, we handle Postscript input with Ghostscript's ljet4 driver:
language_driver ps {
filetype_regx = "postscript"
convert_exec = {
gs -sDEVICE=ljet4 $GS_RES \
-q -dNOPAUSE -dBATCH -dSAFER \
-sOutputFile=$OUTPUT $INPUT
}
}
# Finally, we wrap the job in PJL commands:
filter_exec {
# requires echo with escape code ability...
echo -ne '\33%-12345X' > $OUTPUT
echo "@PJL SET DUPLEX=$DUPLEX_MODE" >> $OUTPUT
# You can add additional @PJL commands like the above line here.
# Be sure to always append (>>) to the output file!
cat $INPUT >> $OUTPUT
echo -ne '\33%-12345X' >> $OUTPUT
}
}
Most Linux systems ship with LPD. This section describes a very basic setup for LPD; further sections detail the creation of complex filters and network configuration.
The minimal setup for lpd results in a system that can queue files and print them. It will not pay any attention to wether or not your printer will understand them, and will probably not let you produce attractive output. Nevertheless, it is the first step to understanding, so read on!
Basically, to add a print queue to lpd, you must add an entry in /etc/printcap, and make the new spool directory under /var/spool/lpd.
An entry in /etc/printcap looks like:
# LOCAL djet500
lp|dj|deskjet:\
:sd=/var/spool/lpd/dj:\
:mx#0:\
:lp=/dev/lp0:\
:sh:
Go now and read the man page for printcap.
The above looks very simple, but there a catch - unless I send in files a DeskJet 500 can understand, this DeskJet will print strange things. For example, sending an ordinary Unix text file to a deskjet results in literally interpreted newlines, and gets me:
This is line one.
This is line two.
This is line three.
Clearly more is needed, and this is the purpose of filtering. The more observant of you who read the printcap man page might have noticed the spool attributes if and of. Well, if, or the input filter, is just what we need here.
If we write a small shell script called filter that adds carriage returns before newlines, the staircasing can be eliminated. So we have to add in an if line to our printcap entry above:
lp|dj|deskjet:\
:sd=/var/spool/lpd/dj:\
:mx#0:\
:lp=/dev/lp0:\
:if=/var/spool/lpd/dj/filter:\
:sh:
#!perl
# The above line should really have the whole path to perl
# This script must be executable: chmod 755 filter
while(<STDIN>){chop $_; print "$_\r\n";};
# You might also want to end with a form feed: print "\f";
The only remaining problem is that printing plain text is really not too hot - surely it would be better to be able to print PostScript and other formatted or graphic types of output. Well, yes, it would, and it's easy to do. The method is simply an extention of the above linefeed-fixing filter. If you write a filter than can accept arbitrary file types as input and produce DeskJet-kosher output for each case, then you've got a clever print spooler indeed!
Such a filter is called a magic filter. Don't bother writing one yourself unless you print strange things - there are a good many written for you already on the net. APS Filter is among the best, or your Linux distribution may have a printer setup tool that makes this all really easy.
There's one catch to such filters: some older version of lpd don't run the if filter for remote printers, and some do. The version of lpd with modern Linux distributions, and FreeBSD does; most commercial unices that still ship lpd have a version that does not. See the section on network printing later in this document for more information on this.
Some installations need to keep track of who prints how much; this section summarizes methods for doing this.
Regular LPD provides very little to help you with accouting. You can specify the name of an accounting file in the af= printcap attribute, but this is merely passed as an argument to your if= filter. It's up to you to make your if= filter write entries to the accounting file, and up to you to process the accounting file later (the traditional format is mainly useful for line printers, and is nontrivial to parse in Perl, so there's no reason to preserve it).
Ghostscript provides a PageCount operator that you can use to count the number of pages in each job; basically you just tack a few lines of postscript onto the end of the job to write an accounting file entry; for the best example of this see the file unix-lpr.sh in the Ghostscript source distribution.
Note that the unix-lpr implementation of accounting writes to a file from the Ghostscript interpreter, and is thus incompatible with the recommended -dSAFER option. A better solution might be to query the printer with a PJL command after each job, or to write a postscript snippet that prints the pagecount on stdout, where it can be captured without having to write to a file.
The LPRng print spooler includes an HP-specific sample implementation of accounting; I assume that it queries the printer with PJL.
Large installations, by which I mean networks including more than two printers or hosts, have special needs. Here is a description of one possible arrangement.
By popular demand, I include below a listing of the permissions on interesting files on my system. There are a number of better ways to do this, ideally using only SGID binaries and not making everything SUID root, but this is how my system came out of the box, and it works for me. (Quite frankly, if your vendor can't even ship a working lpd you're in for a rough ride).
-r-sr-sr-x 1 root lp /usr/bin/lpr*
-r-sr-sr-x 1 root lp /usr/bin/lprm*
-rwxr--r-- 1 root root /usr/sbin/lpd*
-r-xr-sr-x 1 root lp /usr/sbin/lpc*
drwxrwxr-x 4 root lp /var/spool/lpd/
drwxr-xr-x 2 root lp /var/spool/lpd/lp/
Lpd must currently be run as root so that it can bind to the low-numbered lp service port. It should probably become UID lp.lp or something after binding, but I don't think it does. Bummer.
PDQ uses a different, non-daemon-centric scheme, so it has different
programs. The only SUID root programs are the lpd interface programs
lpd_cancel, lpd_print, and lpd_status;
these are SUID because actual Unix print servers require print
requests to originate from a priviledged port. If the only printers
for which you use PDQ's bsd-lpd interface are networked print servers
(like the HP JetDirect or Lexmark's MarkNet adapters) then you do not
need the suid bit on these programs.