16.4 Objective 4: Install and Configure Local and Remote Printers

If you've been able to run the commands listed in Objectives 2 and 3, you already have the printing system installed on your system. However, if you don't have the package, you can get the source code from MetaLab (ftp://ibiblio.org/pub/linux/system/printing), along with the other software mentioned later in this Objective. You should be able to build the software simply using make followed by make install.

The printing system implemented by the lpd suite is primitive by today's standards. It provides for queuing, administrative control, and some handling of special file formats but doesn't directly address the recent trend away from character-oriented printers to more programmable machines. Fortunately, the software is modular, making its foundation easy to build upon, making it sufficient for most printing situations.

16.4.1 /etc/printcap

The printing process on Linux systems is governed by the "printer capability" file /etc/printcap . This text file defines all of the system's available print queues and their characteristics. The file is parsed by lpd, which ignores blank lines and comments beginning with a pound sign (#). Each printer definition in the file comprises one logical line, which is often broken up among multiple physical lines in the file using the \ line-continuation character. The definition itself is made up of fields delimited by colons. The first field, which begins in the first column of the file, holds the system name for the printer, such as lp. This field may contain aliases for the printer name separated by vertical bars. The rest of the fields in the definition hold mnemonics providing control flags and printer parameters. A basic printcap file defining a single printer is shown in Example 16-1.

Example 16-1. A Basic /etc/printcap File

# A basic /etc/printcap
#
lp|ljet:\
        :sd=/var/spool/lpd/lp:\
        :mx#0:\
        :sh:\
        :lp=/dev/lp0:\
        :if=/var/spool/lpd/lp/filter:
        :lf=/var/spool/lpd/lp/log:

In this example, printer lp is defined with the alias ljet. Either name could be used to print with this printer, using lpr -Plp or lpr -Pljet. lp is the default printer unless the user overrides it by placing a different name in the PRINTER environment variable. Note that the name of the printer has a trailing colon, followed by the line-continuation character. The subsequent lines contain printer attributes inside colon pairs. Some of the frequently used attributes are:

if=input_ filter

Input filter (see Section 16.2.2 for additional information).

lp=printer_device

Local printer device, such as /dev/lp0.

lf=log_ file

Error message log file.

mx=max_size

Maximum size of a print job in blocks. A maximum size of #0 indicates no limit.

sd=spool_directory

Spool directory under /var/spool/lpd.

sh

Suppress header pages for a single printer definition.

Both locally attached and remote printers will have queues defined in /etc/printcap.

On the Exam Familiarize yourself with the /etc/printcap file and the attribute variables. Remember that a single printer definition can have multiple names and that multiple printer definitions can refer to the same hardware.

16.4.2 Filters

The printing process involves the rendering of various data formats by a single hardware device. Considering the wide range of possible formats (plain text, HTML, PostScript, troff, TeX, and graphics files such as JPEG and TIFF, just to name a few), affordable printers can't be expected to natively handle them all. Instead, Linux systems use a two-step transformation process:

This translation process and its intermediate data formats are depicted in Figure 16-1.

Figure 16-1. Print data translation steps

Each print queue found in /etc/printcap can use a different input filter, as directed by the if=filter specification.

This data translation process sometimes isn't necessary. For example, plain text can be printed directly by most printers, making the translation to PostScript and subsequent Ghostscript invocation unnecessary for basic output. Many printers, particularly laser printers, have a built-in PostScript interpreter, making Ghostscript unnecessary. These situations are detected and controlled by the filter program.

A filter can be very simple. For example, you may have implemented a filter yourself by using a utility like pr to add a margin to a plain text print job before piping it into lpr. In practice, filters are conceptually similar, but are more complex and capable than this and usually handle multiple input formats. They do this by looking at the magic number at the beginning of the data file to be printed.^[6] As a result, the filters are referred to as magic filters. Two such filters are APSfilter and magicfilter. Your familiarity with both filters is required for Exam 102.

^[6] See the file command's manpage for more information on magic and magic numbers.

16.4.2.1 APSfilter

This popular filter program accepts files in the PostScript, TeX DVI, ASCII, PCL, GIF, TIFF, Sun Raster files, FIG, PNM (pbmplus), HTML, and PDF formats. As mentioned earlier, APSfilter and the other software discussed here can be found at MetaLab. After downloading APSfilter, the compressed tarball should be unpacked in /usr/lib. Then, simply invoke cd apsfilter and run the installer, . /SETUP. This interactive program presents a menu-based installation, where you direct such things as the Ghostscript printer driver selection, the choice of printer interface (such as /dev/lp0), the default print resolution, the use of color, and the output paper format. It then creates new printer entries in /etc/printcap, as well as creates new printer spool directories, and sets file permissions and ownership. It also compiles a few utilities necessary for the proper use of the filter. Once APSfilter is installed, your /etc/printcap will look something like that shown in Example 16-2.^[7]

^[7] SETUP makes a backup copy of /etc/printcap called /etc/printcap.orig before creating its new printcap file.

Example 16-2. The APSfilter /etc/printcap Description

# apsfilter setup Tue Mar 21 02:38:48 EST 2000
#
ascii|lp1|ljet3d-letter-ascii-mono|ljet3d ascii mono:\
        :lp=/dev/lp0:\
        :sd=/var/spool/lpd/ljet3d-letter-ascii-mono:\
        :lf=/var/spool/lpd/ljet3d-letter-ascii-mono/log:\
        :af=/var/spool/lpd/ljet3d-letter-ascii-mono/acct:\
        :if=/usr/lib/apsfilter/filter/\
aps-ljet3d-letter-ascii-mono:\
        :mx#0:\
        :sh:
#
lp|lp2|ljet3d-letter-auto-mono|ljet3d auto mono:\
        :lp=/dev/lp0:\
        :sd=/var/spool/lpd/ljet3d-letter-auto-mono:\
        :lf=/var/spool/lpd/ljet3d-letter-auto-mono/log:\
        :af=/var/spool/lpd/ljet3d-letter-auto-mono/acct:\
        :if=/usr/lib/apsfilter/filter/\
aps-ljet3d-letter-auto-mono:\
        :mx#0:\
        :sh:
#
raw|lp3|ljet3d-letter-raw|ljet3d auto raw:\
        :lp=/dev/lp0:\
        :sd=/var/spool/lpd/ljet3d-raw:\
        :lf=/var/spool/lpd/ljet3d-raw/log:\
        :af=/var/spool/lpd/ljet3d-raw/acct:\
        :if=/usr/lib/apsfilter/filter/\
aps-ljet3d-letter-raw:\
        :mx#0:\
        :sh:

As you can see, the installation creates three printer definitions, each with multiple aliases and each using the same output device. This allows some degree of control over the filter, because the selection of the queue implies specific print parameters. The first definition (ascii) is intended to allow the user to force the printing of plain text even if the data is a PostScript program. The second entry (lp, the default) is the standard magic APSfilter, which tries to identify the data type itself. The last definition allows users to force APSfilter to send raw data directly to the printer with no intervention. This can be useful, for example, if you wish to print a PostScript file's programming instructions. APSfilter also configures logging and accounting for each printer queue. Finally, the setup routine optionally prints a graphical test page to verify your installation.

After APSfilter is installed, you must restart lpd to enable the new print queues:

# lpc restart all

or:

# /etc/rc.d/init.d/lpd stop
# /etc/rc.d/init.d/lpd start

APSfilter allows for some controls in /etc/apsfilterrc (and the user file ~/.apsfilterrc). Examples of these controls are configuration for Ghostscript features, special control sequences for printers, and configuration for the use of a particular filter method. While this file is beyond the scope of LPIC Level 1 Objectives, you should be familiar with it and its purpose.

On the Exam You should install APSfilter to become familiar with the software and its setup.

16.4.2.2 Magicfilter

Another filter you may wish to try is magicfilter, which can also be obtained from MetaLab. Unlike APSfilter, which is implemented as scripts, magicfilter is compiled from C and comes with a traditional configure, make, make install procedure.^[8] Building and installing magicfilter is straightforward and shouldn't cause any difficulty. However, the installation does not automatically create print queues in /etc/printcap, although you can easily define one by setting the input filter to /usr/local/bin/magicfilter, as shown in Example 16-3.

^[8] See Section 14.3 for additional information on how to install software.

Example 16-3. The magicfilter Print Queue

lp|lpmagic:\
        :sd=/var/spool/lpd/lp:\
        :mx#0:\
        :sh:\
        :lp=/dev/lp0:\
        :if=/usr/local/bin/magicfilter:

16.4.2.3 Multiple filters

When a filter is installed, it is placed in a directory where it can be called from as needed. The printer definitions in /etc/printcap put the filter into service. Because you can create as many printer definitions as you like, it is possible to have multiple filters in place at the same time.

On the Exam You should have a working knowledge of the printing process, the role of filters, the role of Ghostscript, and where PostScript data is used. Also remember that PostScript is rendered directly on some printers, eliminating the need for Ghostscript.

16.4.3 Remote lpd and Samba Printers

Configuring your system to use a remote Linux printer (or other lpd device, such as a network-attached printer) can be as simple as adding a local printer. Two additional configuration variables are added to the printer definition in /etc/printcap to specify the remote host and the queue name on that host. For example:

rlp:\
        :sd=/var/spool/lpd/rlp:\
        :rm=lphost:\
        :rp=rlp:\
        :mx#0:\
        :sh:\
        :if=/usr/local/bin/magicfilter:

Here, this local print queue will send jobs to printer rlp residing on lphost. Since remote printers still have local queues, you must create the spool directory, in this example, /var/spool/lpd/rlp.

Configuring a remote printer that's on a Windows network is also straightforward. (The Windows printer must be properly shared and you must have Samba installed and running.) First, a local spool directory is created as usual -- for example, /var/spool/lpd/winpr. Next, an /etc/printcap entry is added that looks something like this:

winpr:\
        :sd=/var/spool/lpd/winpr:\
        :mx#0:\
        :sh:\
        :if=/usr/bin/smbprint:

The input filter for this printer is smbprint, a utility from the Samba software suite. Finally, a .config file is created in the spool directory, which contains:

• The NetBIOS name of the Windows machine with the printer

• The service name that represents the printer

• The password used to access that service

The service name and password are set in the Sharing dialog box on the Windows machine. The .config file might look similar to the following:

server=WINBOX
service=WINPR
password=""

After restarting lpd, you should be able to print text documents to the Windows printer.

On the Exam Remember the rm and rp printer configuration variables for remote lpd printers. For Samba printing on Windows clients, remember to use the smbprint input filter and to create the .config file in the local spool directory.