8.2. Configuring LPD
Until recently most GNU/Linux distributions shipped with LPD. This section describes a very
basic setup for LPD; further sections detail the creation of
complex filters and network configuration.
8.2.1. Basic LPD configuration
The minimal setup for lpd results in a system that can queue
files and print them. It will not pay any attention to whether or
not your printer will understand them, and will probably not let
you produce attractive output. But we have to start somewhere.
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:
|
This defines a spool called
lp,
dj, or
deskjet, spooled
in the directory
/var/spool/lpd/dj, with no
per-job maximum size limit, which prints to the device
/dev/lp0, and which does not have a banner
page (with the name of the person who printed, etc) added to the
front of the print job.
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.
|
ad nauseam. Printing a PostScript file to this spool would get a
beautiful listing of the PostScript commands, printed out with
this "staircase effect", but no useful output.
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 andof. 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:
|
A simple filter script might be:
#!perl
# The above line should really have the whole path to perl
# This script must be executable: chmod 755 filter
while(<STDIN>){chomp $_; print "$_\r\n";};
# You might also want to end with a form feed: print "\f";
|
If we were to do the above, we'd have a spool to which we could
print regular Unix text files and get meaningful results. (Yes,
there are four million better ways to write this filter, but few
so illustrative. You are encouraged to do this more
efficiently.)
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
extension of the above linefeed-fixing filter.
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, and most have easy-to-use
interactive configuration tools. You should simply select a
suitable pre-written filter:
-
foomatic-rip
-
foomatic-rip is a filter designed to use data from the
LinuxPrinting.org printer database. It supports essentially
all free software printer drivers, including regular
Ghostscript drivers, Uniprint drivers, and the assorted
filter programs floating around out there. foomatic-rip works with
CUPS, LPRng, LPD, GNUlpr, PPR, PDQ, no spooler.
-
APS Filter
-
apsfilter is a filter designed for use on a wide
variety of Unices. It supports essentially all
Ghostscript drivers. It, too, works with
various strains of LPD, including stock BSD and
LPRng.
-
RHS-Printfilters
-
RHS-Printfilters is a filter system constructed by Red Hat.
It shipped beginning, I think, in version 4 of Red Hat Linux,
as the backend to the easy-to-use printtool GUI printer configuration tool.
The rhs filter system is built on an ASCII database listing
distributed with it. This listing supports many Ghostscript
and Uniprint drivers, but not filter-style drivers. The
filters constructed also do not support much in the way of
user-controllable options at print time.
The printtool places a configuration file
named postscript.cfg in the spool
directory. Inside this Bourne shell-style file, each setting
is a variable. In unusual cases, you can make useful changes
directly to the config file which the printtool won't allow;
typically this would be the specification of an unusual
Ghostscript driver, or a PPD filename for the VA
rhs-printfilters version.
VA Linux has made some enhancements to the rhs-printfilters
system under contract from HP. With the proper versions, it
is possible to select options for Postscript printers
under control of Adobe PPD files. I cover this system inSection 8.2.2.
There's one catch to such filters: older version of lpd don't run
the if filter for remote printers, while
most newer ones do (although often with no arguments). The
version of LPD shipped with modern GNU/Linux and FreeBSD
distributions 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. If
you only have locally-connected printers, then this won't affect
you.
8.2.2. LPD for PostScript Printers
While most versions of LPD don't gracefully handle PostScript
(never mind user options), VA Linux modified LPD and Red
Hat's filtering software to support PostScript printers fairly
well. Because the intention was to donate the code to the gnu project, they called it GNUlpr
8.2.2.1. How it works
VA's system uses Postscript Printer Definition, or PPD,
files. PPD files are provided by printer manufacturers and
declare the available options on a printer, along with the
Postscript code needed to activate them. With the VA system,
the normal LPD scheme works a little differently:
-
The user can specify options with the -o
flag. For example, you might specify -o
MediaType:Transparency if you were about to print on
overhead film. Alternatively, the front-end GPR can
be used to specify options in a dialog box; you can see
screenshots of GPR in Section 3.4.3.
-
LPR passes the options to LPD as an extended attribute in the
LPD control file.
-
A modified version of the rhs-printfilters package is given
the extended options data in an environment variable, and
uses ppdfilt to add these options to the print data.
8.2.2.2. Obtaining and Installing
You can obtain RPM packages, or source tarballs, from the
project's website
on SourceForge. For installation details, consult the
project's installation
micro-HOWTO. In essence, you need to uninstall the Red
Hat version of printtool, lpd, and rhs-printfilters entirely,
and then install the VA versions, plus ppdfilt, gpr, and a few
other utilities.
You will also need PPD files for your Postscript printers.
PPD files are usually fairly easy to find. VA Linux and HP
distribute PPD files for many Laserjet models. Other vendors
provide PPDs for their own printers, and Adobe distributes PPD files for many printers.
At the moment, much of this is a bit difficult to install. But
future installation tools will build upon the printer
configuration library libprinterconf, which
enables both the autodetection and rhs-printfilter configuration
of both networked and local printers.
|
It is possible to use GPR alone, without the modified LPD
or even rhs-printfilters. GPR can be compiled with
all the logic needed to massage Postscript jobs directly.
This may be an easier-to-install option suitable for
people who never really need to print using lpr
directly.
|
8.2.2.3. Controlling Postscript Options
Once you've setup VA's Postscript-capable LPD system (GNUlpr), you can
control your printer's options in two ways:
- With the GUI
-
To use GPR, you first make sure that you've specified the
proper PPD file. Then the printer's options will be
available on the `Advanced' panel. Basic ppdfilt options will be available on the
`Common' panel.
- With the command line
-
This lpr supports the -o
option. You may specify any option/value pair from your
printer's PPD file with -o. For example,
consider this PPD file option clause:
*OpenUI *PrintQuality/Print Quality: PickOne
*DefaultPrintQuality: None
*OrderDependency: 150 AnySetup *PrintQuality
*PrintQuality None/Printer Setting: ""
*PrintQuality Quick/QuickPrint: "<< /DeviceRenderingInfo ...
*PrintQuality Normal/Normal: "<< /DeviceRenderingInfo << /...
*PrintQuality Pres/Presentation: "<< /DeviceRenderingInfo ...
*PrintQuality Image/1200 Image Quality: "<< /DeviceRenderi...
*CloseUI: *PrintQuality
|
For the option PrintQuality, the possible
values are Quick, Normal,Pres, or Image. You might
give a command like:
% lpr -o PrintQuality:Image file.ps
|
There are a number of options common to all printers which
will work in addition to the ones from your PPD. These
include:
-
page-ranges
-
You can specify a range of pages to print. For example,page-ranges:2-3.
-
page-set
-
You can print only odd or even pages. For example,page-set:odd.
-
number-up
-
You can print multiple pages on each piece of paper.
For example, number-up:2.
Other options are detailed in the ppdfilt
man page.
8.2.3. File Permissions
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.
This is simply one more reason to avoid the stock BSD LPD.