Section 14.2. Managing Print Services


14.2. Managing Print Services

Linux has a fairly complicated printing system, compared with the printing services most PCs use. Configuring the printing system is usually either very easy (because the semiautomated tools get it right) or very hard (because the semiautomated tools fail or because your printer is poorly supported under Linux). The next few pages describe the Linux printing system, beginning with an overview of the software and moving on to hardware configuration and testing, configuring the Common Unix Printing System (CUPS) to enable its web-based configuration tools and network helpers, defining printers in CUPS, fine-tuning printer definitions, managing printer queues, maintaining LPD compatibility, and troubleshooting printers.

14.2.1. Linux Printing Software

Printing in Linux involves the interactions of several different software packages. The most important of these is the Linux printing daemon, which accepts jobs to be printed, keeps them in one or more queues, and sends the jobs to printers in an orderly manner. Additional software includes Ghostscript, which converts between PostScript and a form the printer can understand; Ghostscript printer definitions; and assorted extra tools that can help you create nicely formatted output. Before you can configure Linux printing, you must install all of these components.

14.2.1.1. Linux printing daemons

A printing daemon's job is to run in the background, accept print jobs from applications, temporarily store those print jobs, and send them to the appropriate printers without interfering with each other. All mainstream Linux distributions ship with at least one printing daemon, and most set them up in at least a minimal way when you install the OS. You may still need to configure your printing daemon so that it knows about your printer, though. This task is described later in this chapter, in "Defining Printers in CUPS."

Traditionally, Linux has used the Berkeley Standard Distribution Line Printer Daemon (BSD LPD) or the updated LPRng package for printing. (For simplicity, both systems are referred to as LPD systems from here on.) Basic LPD systems are fairly simple tools; they accept print jobs, store those jobs in queues, and then send them directly to the printer. These systems can be modified to pipe the print jobs through other programs for additional processing, if desired. Unlike printing systems for Windows, Mac OS, and other OSs, LPD printing systems don't provide a two-way communication path. For instance, an application can't query the LPD system about the page width or color capabilities of a printer. Thus, you must tell each application about a printer's special features. LPD systems are, though, network-enabled, which makes it possible for one computer to share its printers with others, or for a computer to print to a network-capable printer.

In 1999, an experimental new printing system was developed: CUPS. This package uses a new network printing protocol and enables applications to query a printer's capabilities and set printer features in ways that aren't possible with LPD systems. By 2004, all major Linux distributions had either switched to CUPS as the default printing system or offered it as an option on equal footing with BSD LPD or LPRng. For this reason, we describe CUPS in this chapter. Although some of the principles and support software are the same for BSD LPD and LPRng as for CUPS, the details are completely different. If you're using an older printing system, you may want to consider upgrading to CUPS.

In most cases, you can install CUPS (if it's not already installed) by using your distribution's package management tools. Look for a package called cups and install it. If your system is already configured to use BSD LPD or LPRng, you should first remove that package. If you prefer, you can download the original CUPS source code from its web page, http://www.cups.org.

14.2.1.2. Ghostscript

The traditional LPD printing system passes a file from an application to a printer. In its most basic form, this means that the application must know how to create a file that the printer can understand. This contrasts with printing under most other OSs, such as Windows, in which the application can use OS calls to help prepare a document for printing. As a practical matter, Unix and Linux applications almost always generate one of two types of output:


Plain text

Programs can send plain text to the printer, under the assumption that the printer is either a dumb line printer (that is, a fast printer with few fancy formatting capabilities) or can at least accept the plain text.


PostScript

Adobe's PostScript language is one of many printer languages. It became popular on laser printers in the 1980s, and most Linux programs that need to print documents with multiple fonts, graphics, or other special formatting almost always do so by generating PostScript output.

Unfortunately, most printers, and particularly the inexpensive consumer and small business printers that are often paired with Linux, don't understand PostScript. The answer is to pipe output through Ghostscript (http://www.cs.wisc.edu/~ghost/), which is a PostScript interpreter that can reside on the computer rather than in the printer. Ghostscript converts PostScript into formats that most printers can understand. In effect, the combination of PostScript and Ghostscript becomes the Linux equivalent of the Windows printer driver system.

Although CUPS changes many things about the Linux printing system, it still relies on Ghostscript to convert PostScript into printers' native languages. Thus, you must have Ghostscript installed on your system if you expect to print to a non-PostScript printer. Fortunately, all major Linux distributions ship with Ghostscript. You may want to check to be sure it's installed, though; look for a package called ghostscript.

Ghostscript is actually available in two versions. The most recent version of Ghostscript is AFPL Ghostscript, which is available under a license that permits free use for many purposes, but not free redistribution. After a few months, AFPL Ghostscript is released under the GPL as GNU Ghostscript, and it's this version that comes with most Linux distributions. In most cases, being a few months behind the leading edge of Ghostscript development is unimportant. If you absolutely must have the latest version, though, check the Ghostscript home page.

Ghostscript comes with drivers for many common printers , and it can also output many common graphics file formats. You can even generate Adobe Portable Document Format (PDF) files with Ghostscript. (The ps2pdf shell script helps automate this process.) For more flexibility, you can add Ghostscript drivers for assorted printers.

As a point of interest, you should know that Ghostscript treats all printers as graphics devices. That is, if you print a purely textual document, Ghostscript converts that text into a graphics bitmap and sends the bitmap to the printer. This means that Ghostscript cannot take advantage of fonts that are built into the printer. It also means that Ghostscript sometimes prints more slowly than other software, such as Windows drivers, can print to the same printer. (This effect is usually negligible, but it's sometimes dramatic.) On some very old laser printers, another consequence is that Ghostscript (and hence Linux) requires a printer memory upgrade for the printer to print at full resolution. In practice, though, even Windows treats many printers as graphics-only devices, so Ghostscript's doing so may not make any difference.

14.2.1.3. Printer definitions

A standard CUPS installation supports a fairly narrow range of printers, typically PostScript models and some Hewlett-Packard and Epson printers. To support more printers, you must install a printer driver package. (In truth, many of these "drivers" are really just printer descriptions coupled to standard Ghostscript drivers, but in practice they're necessary either way.) Several such driver packages exist:


Foomatic

These drivers, headquartered at http://www.linuxprinting.org/foomatic.html, handle many popular printers. They're a good place to start for many printers.


GIMP Print

The GNU Image Manipulation Program (GIMP) is a popular graphics package that's developed its own set of printer drivers. These have been spun off into a separate printer driver package that can be used with CUPS (or with BSD printing systems). The GIMP Print drivers are often particularly good choices if you want to print graphics. Check http://gimp-print.sourceforge.net for more information.


ESP Print Pro

The original CUPS developers have made a set of printer definitions available on a commercial basis. You can learn more at http://www.easysw.com/printpro.

Most distributions ship with Foomatic or GIMP Print, so check for those packages. Sometimes they're called something else, and occasionally they're bundled with still more printer definitions. If you fail to install any printer definitions, you'll see a very limited set of printers when you configure printing.

Sometimes multiple printer definitions are available for a single printerfor instance, separate definitions in the Foomatic and GIMP Print packages, or even multiple definitions in a single package. In such cases, you may want to try all the available definitions to see which one works best with your printer and the types of documents you print. Sometimes the developers give you a hint by specifying in the configuration menus that one definition is recommended over the others.

14.2.1.4. Additional printing software

CUPS (or an LPD printing system) is a practical necessity for printing from Linux. For most printers, Ghostscript and Ghostscript driver definitions are also practical necessities. Several additional tools are often highly desirable, but may not be necessary in all cases:


enscript or nenscript

These commands were described earlier in this chapter. They help format plain text as PostScript or in other ways, which can be very helpful.


groff

This program is the open source implementation of the roff typesetting system, which enables creation of prettily formatted documents from text-mode files using troff/nroff markup codes. Although many users today prefer GUI word processors for this task, groff is still required by some tools, and can be used more directly, as well.


TEX and LATEX

The TEX package is a high-end document processing system, and LATEX is an extension to this package. These tools are favored by many mathematicians, scientists, computer scientists, and engineers for creating files. Some Linux documentation comes in the form of TEX or LATEX files, although such documents are also usually available in other formats.


Lout

This package is also worthy of consideration as an efficient and compact package to format text documents for PostScript output. It supports Level 2 PostScript and the Adobe Structuring Conventions, takes comparatively little memory, and comes with good enough documentation to learn quickly. Lout doesn't create an intermediate output form; it goes directly from markup input to PostScript output.


netpbm and pbmplus

These programs support a wide variety of graphics file format conversions. (Such formats have to be converted to PostScript before you try to print them.)


Ghostview

This package provides display tools to view PostScript files in an X Window System environment, and also provides PostScript and PDF support for other packages, such as your web browser.


ImageMagick

This program lets you display a large number of graphics formats in an X window and convert many file formats to other file formats. (It uses Ghostview and Ghostscript when it needs to display a PostScript image.) Most of the graphics files that you can print can also be displayed using ImageMagick.


Fax packages

If you want to support fax devices, you can use the tiffg3 utility with Ghostscript to output Group III fax format files. To control a Class 1 or Class 2 fax modem on your Linux host, you can use the efax package, which is provided in many distributions, or you can install and configure the more capable, but more complex, FlexFax or HylaFax packages.

Some of these tools are covered elsewhere in this book. Most require little configuration, and all are primarily user-level tools. Be aware that this list is not comprehensive; Linux printing tools are extremely plentiful, and range from simple text formatting tools to sophisticated word processors and graphics applications.

14.2.2. Configuring Printer Hardware

The first order of business when configuring a printer is configuring the hardware . You must verify that your printer is compatible with Linux, check its physical interface to the computer, and verify that the interface is working. Failure to check these details can lead to problems when you try to actually configure the printer in Linux, leading to a wild goose chase as you try to debug problems in the wrong subsystems.

14.2.2.1. Verifying printer compatibility

The main issue with respect to printer compatibility is the language the printer uses. Several languages are common, but many printers use their own unique languages. The more common printer languages include PostScript, HP's Printer Control Language (PCL) , and Epson's ESC/P2 language. (ESC/P2 is most common on old dot matrix printers.) Many manufacturers make printers that use each of these languages, but sometimes they bury this detail in their descriptions or refer to it in another way. One common example is a laser printer that uses PCL; the manufacturer may refer to the printer as being "HP-compatible" (usually with a reference to a specific HP printer model).

The best hope for Linux compatibility is to get a printer that supports PostScript. Such printers are typically mid-range to high-end laser printers. Few inkjet or low-end laser printers support PostScript. With a PostScript printer, you needn't be concerned about whether a Ghostscript driver exists for your printer; just configure CUPS to pass the raw PostScript straight through to the printer.

Some printers are advertised as supporting PostScript when in fact they don't. Manufacturers may do this when their printers ship with software that's similar to Ghostscript, but such manufacturer-supplied software usually only runs under Windows. Thus, if you have or are looking for a PostScript-capable printer, try to verify that the PostScript support is in the printer itself, not in a Windows driver package.


If you don't have a PostScript printer, your best bet for assessing Linux compatibility is to check the Linux Printing web site, and particularly its printer database, located at http://www.linuxprinting.org/printer_list.cgi. Locate your printer make and model in the drop-down fields on this site and then click the Show button. You'll then see a description of your printer and its Linux compatibility. The description may also tell you where to find drivers or printer descriptions to use with CUPS, so you can check that you have the appropriate support software.

If your printer is listed on the Linux Printing web site as a "paperweight" (meaning it doesn't work at all under Linux), you may want to try doing a web search on the printer's name and Linux. If you're lucky, you'll turn up a new or experimental driver you can try. If not, you may want to look into replacing the printer with one that's more Linux-friendly.

If you have, or are considering buying, a multifunction device (such as one that handles both printing and scanning functions), you should investigate Linux support for all of the device's functions. Sometimes the printer side will work fine but the scanner will be useless, for instance. Typically, support for each function is provided by its own project under Linux, such as Ghostscript for the printer and the Scanner Access Now Easy (SANE ) project for scanner support. Occasionally, a project exists to provide all the necessary drivers in one place, such as the HP Office Jet project (http://hpoj.sourceforge.net) or Epson's drivers (http://www.avasys.jp/english/linux_e). These projects may be independent or sponsored by the device's manufacturer.

14.2.2.2. Printer interfaces

Printers can be connected to computers in several different ways. Four interface methods are common:


Parallel port

A very popular interface method. Most x86 computers have a single parallel port that's intended for handling a printer (although some other devices have been designed to use this port, too). The parallel port has the advantage of speed, particularly compared with the RS-232 serial port. Under Linux, the parallel port is usually /dev/lp0, although it can be /dev/lp1 or higher, particularly if you've added parallel port cards to your computer to support multiple printers.


RS-232 serial port

Some very old printers use the RS-232 serial port standard. These ports are substantially slower than the parallel port, which is why this interface method hasn't been a favored one in decades. If you have such a printer, it will probably be accessible as /dev/ttyS0 or /dev/ttyS1, although higher numbers are possible. Other devices, such as mice and modems, often use RS-232 serial ports, so you may need to study your cabling to determine which one is your printer. You may also need to use the setserial program to configure your RS-232 serial port.


USB port

In recent years the Universal Serial Bus (USB) port has eclipsed the parallel port as the favored port for printers. The USB 1.x standard nearly matches the speed of the parallel port, and USB 2.0 exceeds it, so USB provides plenty of speed for printing. Under recent kernels, USB printers are accessed from the /proc/bus/usb directory tree, and CUPS should be able to automatically detect USB printers; however, the printer must be turned on when the CUPS daemon is started for this to happen. Because CUPS normally starts automatically when the system boots, this means you should ensure that your printer is plugged in and powered on when you boot your system.


Ethernet

Some printers support Ethernet connections, either directly or indirectly. Workgroup printers often have Ethernet ports and show up as if they were computers on the network. Dedicated print server appliances are also available. These devices enable you to connect a USB or parallel printer, effectively turning them into Ethernet printers. These printers support one or more network printing protocols. The best case from a Linux and CUPS perspective is for the printer to understand the Internet Printing Protocol (IPP ) that CUPS uses. Failing that, the LPD or Server Message Block/Common Internet File System (SMB/CIFS) protocols will do.

You should be aware of which interface method your printer uses. Some testing and configuration features won't work with some interfaces; for instance, you can't easily bypass the printing system to send a file directly to a USB or Ethernet printer. You must also have appropriate ports on your computer to support your printer, and the necessary cabling. If you lack this hardware, you should buy it. You can purchase add-in cards with any of the necessary port types; or if you have USB ports but no open slots in your computer, you can purchase an adapter so that you can connect a parallel, RS-232 serial, or even an Ethernet printer via a USB port. Be sure Linux drivers exist for the adapter, though!

If your printer supports multiple interface types, USB is generally the best to use, followed by a parallel interface and then RS-232 serial. USB provides more information to the computer about the printer, uses less bulky cables, and (in its 2.0 incarnation) can be faster than the parallel port. A network-enabled printer can be a big advantage if you want it to be accessible to several computers, but if it uses an odd protocol it could be more trouble than it's worth, particularly if you use it on only one system. Of course, you should also consider your available ports and cables; it might be more trouble than it's worth to install a USB card in an older system that you're using as a print server, for instance.

14.2.2.3. Verifying basic printer connectivity

Before you set up printer services, be sure the printing devices are online. If you also use another operating system, such as Microsoft Windows, you can exercise the hardware to ensure that it is connected properly and working before loading Linux. Successfully printing a document from another operating system immediately eliminates one major source of woe and head scratching. Similarly, if you are going to use printer services on a network, your system should be on the network and all protocols functioning before proceeding.

If you have a parallel or RS-232 serial printer, you can test basic printer functionality by sending a document directly to the printer device file. For instance, you might test a parallel printer by typing this command:

     # cat /etc/fstab > | /dev/lp0

This command copies the /etc/fstab file to /dev/lp0, the most common identifier for a parallel printer. If your printer can print a text file, the result should be a printout of your /etc/fstab file. On some printers, status lights will blink but nothing will emerge. Frequently, pressing a button (marked Form Feed, Continue, or something similar) on the printer will cause the file to print. This happens because the printer didn't receive a full page of data, and so was waiting until it received more data to continue. This shouldn't happen in normal operation, thoughjust when testing the printer. Another problem is "stair-stepping," which is a printout that doesn't reset the line starts, like this:

     /dev/hda1 / ext3 defaults 1 1                                  /dev/hda5 /home ext3 defaults 1 2

You might be able to figure out what went wrong here. Text files in Unix use just a newline (also known as a linefeed, ASCII code 10) to terminate each line. MS-DOS uses both a newline and a carriage return. Your printer was therefore set up to use MS-DOS-style line endings with both newline and carriage-return characters at the end of each line. In practice, CUPS normally filters newlines so that printers configured for DOS can understand them. If you still see this problem once you've fully configured printing, though, you can reconfigure your printer to properly return to the start of the line on receipt of a newline character. Often this is simply a matter of setting a dip switch. Check your printer manual. (Be careful about changing your printer characteristics if you use multiple operating systems.)

If you're using a USB printer, you can look for it with the lsusb command:

     $ lsusb     Bus 005 Device 004: ID 04b8:0807 Seiko Epson Corp.

In practice, you're likely to see more output than this; however, this output shows a USB printeran Epson RX500, to be precise. It's on USB bus 5, device 4. You can learn more about it by viewing the contents of /proc/bus/usb/devices, but most of the information in that file is likely to look like gibberish to the uninitiated. One feature to look for in this file, though, is Driver=usblp. If a line containing this string is present, it means that Linux has recognized the printer as a printer, which means that CUPS should be able to communicate with it. (Whether you can get output from the printer depends on the status of Ghostscript drivers, though.)

Finally, Ethernet printers can be treated just like other network devices. Specifically, you can use ping to verify that they're connected to the network. More substantial tests of their connectivity depend on the protocols the printer understands. Although low-level diagnostics of these protocols are possible, the simplest approach is usually to try configuring them, as described later in this chapter, in "Defining Printers in CUPS."

14.2.3. Configuring CUPS Security

Before proceeding with configuring CUPS to print, you should review your CUPS security and web-based configuration tool options. Unlike LPD systems, CUPS is best managed through its web-based configuration tool; however, this tool is sometimes disabled or set up in an inconvenient way. (Some distributions provide their own GUI tools for CUPS configuration. When using these distributions, you can either use their GUI tools or use the standard CUPS tools.) Depending on your network configuration, you might want to enable or disable the CUPS browsing feature, which enables CUPS servers to communicate their lists of available printers to one another. Browsing greatly simplifies network printer configuration and maintenance, but some distributions disable it by default. On the other hand, in a high-security environment or if your system is connected directly to the Internet, you might want to disable browsing, but some distributions enable it by default. In any event, you should review these settings and be sure they're set appropriately for your environment and needs.

14.2.3.1. Enabling web-based configuration

The main CUPS configuration file is /etc/cups/cupsd.conf. This file is modeled after the Apache configuration file, so if you're familiar with Apache, you should feel at home with this file. If you're not familiar with the Apache configuration file, the basics are as follows. The file begins with a series of global directives, which take the form of a directive name followed by the directive's value. For instance, to override the default server name (advertised to other systems), you would enter a directive like this one:

     ServerName gutenberg.example.com

This line sets the server name to gutenberg.example.com. CUPS accepts a large number of configuration directives; you should consult its manpage for complete details. Some sets of configuration directives are enclosed in sections delimited by lines that are enclosed in angle brackets:

     <Location /admin>     AuthType   Basic     AuthClass   System     Order   Deny,Allow      Deny From All     Allow From 127.0.0.1     Allow from 192.168.1.0/24     </Location>

This set of lines sets directives that apply only to certain functions of the serverin this case, those handled by the /admin (administrative) subsystem. You can use this feature to selectively modify the CUPS security functions (or other functions). The /admin area is particularly important for controlling access to the CUPS web-based administration tool. The options shown in the preceding example control features you may want to adjust:


AuthType

The AuthType directive tells CUPS what type of authentication to require for access to the location. In the case of /admin, this is usually set to Basic, which corresponds to password exchanges in cleartext. If you intend to administer the server from remote systems, you may want to change this to Digest, which adds encryption for the password exchange. (This feature requires that you set a password digest using the lppasswd program.) Some subsystems don't normally enable authentication; they use None for the AuthType. This configuration is a common default setting, and enables users to print without providing a password.


AuthClass

This directive tells CUPS what groups of users to accept. Possible values are Anonymous, User, System, and Group. The Anonymous option specifies that no authentication should be performed. User means that any valid username and password will grant access. System means that the user who authenticates must be a member of the CUPS system group. (This option varies from system to system, but it's normally sys, system, or root. You can set it with the SystemGroup option.) The Group option enables you to specify a Linux group name with the AuthGroupName directive, which must appear on another line.


Order

This directive tells CUPS whether to grant or deny access by default. If it's set to Deny,Allow, CUPS denies access unless it's explicitly granted. Setting the value to Allow,Deny grants access unless it's specifically denied.


Deny and Allow

These directives specify machines or networks from which access should be denied or allowed, respectively. You can specify machines by IP address, by network address, by hostname, by domain name (preceding the name with a dot), by the keywords All or None, or by the variables @IF (followed by a specific interface name in parentheses) or @LOCAL (for all local networks).

To enable web-based configuration, you should be sure that your CUPS configuration has an /admin location defined and that it grants access to the 127.0.0.1 address, as shown in the preceding example. That example also gives administrative access to users on the 192.168.1.0/24 network. Generally speaking, you should activate such access only for print servers that you want to administer remotely; opening this option up increases the security risks associated with running CUPS.

If you want to completely disable the CUPS web-based administrative tools (say, because you intend to use your distribution's own CUPS administrative programs instead), you should remove all the Allow directives and ensure that the configuration includes a Deny from All directive.

14.2.3.2. Enabling or disabling browsing

While you're digging in the /etc/cups/cupsd.conf file, you may want to examine the server's browsing options. In the context of CUPS, browsing refers to automatic network printer discovery. This feature, supported by IPP, enables IPP servers to exchange lists of printers with one another. Each server periodically sends out broadcasts to which other IPP servers respond. The result is that you need configure each printer only once, on the computer to which it's connected. That server then propagates the configuration for the printer to other CUPS/IPP servers. Applications on those remote systems will see the new printer appear once they're restarted. This feature can be a great time-saver, particularly on networks on which printers are frequently added or removed.

A couple of caveats are in order concerning browsing, though. First, like many network features, browsing comes with some security baggage. Systems configured to browse could be tricked into displaying bogus printer information, and it's conceivable that a bug in the CUPS browsing code could lead to more serious system compromises. For this reason, some distributions ship with browsing disabled. This fact is the second caveat: if you do want to use browsing, you may need to enable it. If you fail to do so, your system won't automatically detect other printers on your network. Likewise, if you want to tell your system to enable others to print to its printers you must be sure certain options are enabled. You should check several options on your client and server systems:


BrowseAllow and BrowseDeny

These directives tell a CUPS client the addresses from which it should accept or reject browse packets, respectively. They take options with the same form as the Allow and Deny directives. On a LAN, setting BrowseAllow @LOCAL generally works well to enable a system to automatically detect remote printers. This option tells the system to accept browse packets from all the local interfaces. You can set specific IP addresses or hostnames instead of this option to tighten this security, or specify entire network addresses to loosen or change the security. You can also explicitly exclude computers or networks with BrowseDeny. You can include multiple BrowseAllow and BrowseDeny directives.


Browsing

This directive takes On and Off options. You should be sure that any CUPS server that is to share its printers has this directive set to On, which is the default setting for stock CUPS configurations. (Some distributions change the default to Off, though.)


BrowseAddress

You can tell a CUPS server to which addresses it should send browse packets with this directive, which takes IP addresses, network addresses, and hostnames in the same forms as the Allow and Deny directives. The default is to not send any browse packets, so chances are you'll need to set this line. Using BrowseAddress @LOCAL works well on small networks, but you may need to use multiple lines or configure your system in another way, depending on your network.

These browsing directives are typically set in the global section of the cupsd.conf file. They're sometimes set separately or redundantly in the /printers section, though, so check there if you have problems.

Actually printing to a server requires general access to the /printers section, independent of the browsing access. Thus, CUPS servers typically have one or more Allow directives in their /printers sections. Without these directives (either in this section or set globally), a CUPS server will reject incoming print jobs.


14.2.3.3. Restarting CUPS

If you make changes to your CUPS configuration, you should restart the CUPS daemon. On most distributions, this is done via the SysV startup script file:

     # /etc/init.d/cupsd restart

This command (or one like it; you may need to change the path to cupsd) shuts down the CUPS daemon and restarts it. The result should be that the system implements any changes you make to the server's configuration.

14.2.4. Defining Printers in CUPS

Now that you've ensured the CUPS administrative tools are available, you can begin using them. To do so, you'll need a web browser. Any modern browser will work: Mozilla Firefox, Konqueror, Opera, or even the text-mode Lynx, to name just four possibilities. With the help of your web browser, you can add your printer definitions and test your printer configuration.

We describe administering CUPS via its own web-based interface because this approach works with all Linux distributions. Many distributions provide their own tools for CUPS administration, though. For instance, Fedora and Red Hat have the Printer Configuration tool (aka system-config-printer), and SUSE uses its YaST and YaST2 utilities. If you like, you can use such tools. They provide the same basic options as the CUPS printer configuration utility, but the details of their operation differ.


14.2.4.1. Accessing the printer definition tool

CUPS runs its web-based configuration tool on port 631, so you should be able to access the system by entering http://localhost:631 in your web browser's address field. If you've configured CUPS to accept administrative input from other systems, you should be able to access the printer configuration tool from another computer by entering the server's hostname, as in http://gutenberg.example.com:631.

You cannot use your computer's regular hostname to access the CUPS configuration tools, even from your computer itself, if you restrict administrative access to the localhost interface (127.0.0.1). When you so restrict access, you must use the localhost name or 127.0.0.1 IP address.


If CUPS is properly configured and running, the result of accessing a computer's port 631 with a web browser should be a display with a series of links called Do Administration Tasks, Manage Printer Classes, On-Line Help, and so on. If you get an error message from your browser, chances are that something is wrong with your CUPS configuration; review the earlier section "Configuring CUPS Security," and check that the cupsd server is running. If you do see the main CUPS page, you can begin using it to add or reconfigure your printers.

14.2.4.2. Creating a printer definition

To add a printer to a system, you should select the Manage Printers link on the main CUPS configuration page. The result should resemble Figure 14-3, which shows a CUPS configuration with some remote printers already autodetected.

To create a new printer definition, follow these steps:

  1. Ensure that your printer is connected and powered on. In the case of USB printers, if it's not already connected and turned on, you may need to restart CUPS, as described earlier in "Restarting CUPS," after connecting and turning on the printer.

    Figure 14-3. The CUPS web-based administrative tool lists all printers, including those detected on other systems

  2. Click Add Printer. This link is near the bottom of the page and is not visible in Figure 14-3. Unless you've already done something that requires authentication, the result will probably be a window asking for your username and password. Enter root and the root password. You should now see a new page entitled Add New Printer, in which you enter basic printer identifying information: a name, a location, and a description.

  3. Enter the printer's name, location, and description. The printer name is used to identify the printer in applications, and is usually fairly short, such as lexmark or hp4500. One-word names (or multiple words separated by an underscore) work best; multiple words and hyphens tend to confuse CUPS, so don't use them. The location and description fields are purely descriptive, so enter information that will help you distinguish the printer from any others on your network. These fields can and often do contain multiple words. When you're done, click the Continue button.

  4. CUPS now displays a Device page, in which you identify the hardware used to connect to the printer. Select the hardware device, which typically appears as follows:

    1. Parallel ports are identified as Parallel Port #1, Parallel Port #2, and so on.

    2. RS-232 serial ports are identified as Serial Port #1, Serial Port #2, and so on.

    3. USB printers are identified as USB Printer #1, USB Printer #2, and so on. In addition, the make and model of the printer should appear in parentheses. If it doesn't, you should check that your printer is connected and powered on and then restart CUPS and begin the process again.

    4. Network printers are identified by protocol, such as LPD/LPR Host or Printer, Windows Printer via SAMBA, or Internet Printing Protocol. You must know what protocol to use, and depending on the protocol you select, you may need to pick extra options, as described in the sidebar "Printing to Network Printers."

    5. Various additional and more obscure options also exist.

    Once you've picked your printer device, click Continue.

  5. You should now see a Model/Driver page, as shown in Figure 14-4. You should pick the make of your printer from the list and then click Continue. Note that, depending on the printer definition packages you've installed, some makes may appear twice, possibly under different spellings or names, such as HP and Hewlett-Packard. If this is the case for your printer, pick one and if you can't find your specific model, move back and try the other entry. If you don't see your make and it's a common one, such as Epson, Canon, or Lexmark, you should try installing a printer definition package, as described earlier in "Printer definitions." If you don't see your printer make because it's a very obscure one, consult your manual to learn what models your printer emulates and select one of them. Some common printer languages, including PostScript, PCL, and ESC/P2, appear under the Generic brand, so you might try that if your printer is an obscure model that uses such a common printer language.

  6. After the first Model/Driver page, CUPS presents a second Model/Driver page in which you select your printer's model, such as the Lexmark Optra Color 45 or the Lexmark Z51. Locate your printer, select it, and click Continue. If you don't see your model, click your browser's Back button and look for another name for your printer manufacturer or select a compatible model and try it. If you still can't find your model, perhaps you need to install more or newer printer definitions; consult the Linux Printing web page for pointers on your model.

  7. After clicking Continue on the second Model/Driver page, CUPS should respond with a message to the effect that your printer has been added. If you click Printers at the top of the page, you should see the printer list (Figure 14-3) again, but it should now include the printer you've just defined. You can now exit and fine-tune the printer definition.

If you decide to change any of the features of your printer configuration, you can do so by clicking Modify Printer in the printer's area on the main printer configuration page (Figure 14-3). The result is a run through the original configuration options, except that the defaults have changed to whatever you've entered before. (You will be unable to change the printer's name, but you can change other options.)

Figure 14-4. CUPS configured with printer definitions


This procedure (or the GUI tools provided by your distribution) is the simplest way to configure a print queue in CUPS. If you happen to know all the values, though, you can use the lpadmin command-line utility instead. When used to define a queue, this utility takes the following syntax:

     lpadmin [-E] [-h server] -p printer option...

The -E option enables the print queue (a desirable option, typically), while -h enables you to modify the configuration of a server other than the local one, and -p sets the name of the queue.

The final, trailing options are the tricky part. Typically, the most important of these options are -i interface, which sets the interface device, and -m model, which points to a PostScript Printer Definition (PPD ) file that defines the printer's model and capabilities. You must know the filename of the PPD file for your printer, which may not be obvious unless you've obtained a PPD file specifically for the printer (say, from the printer's manufacturer). As the name implies, a PPD file describes the capabilities of a PostScript printer, so printer manufacturers normally only make these files available for PostScript models. CUPS printer definitions rely on PPD files for all printers, though, and in fact these are the main part of the Foomatic, GIMP Print, and other Linux printer definition packages.

Printing to Network Printers

Network printers require more in the way of identification (described in step 4 of "Creating a printer definition") than local printers do. In all cases, you enter the information in a Device URI screen, which provides a single text-entry field in which you enter a string to identify the remote printer. Precisely what sort of information is required depends on the network protocol in use:

  • For LPD printers, you must provide the identifying prefix lpd://, the hostname, and the printer queue name. For instance, lpd://gutenberg/lexmark allows printing to the lexmark printer on gutenberg.

  • For printers served by Windows systems or Samba using SMB/CIFS, you must provide a hostname and printer queue name, as with LPD printers, but you may also need to provide a username and password. The full URI might resemble

         smb://printacct:ppass@GUTENBERG/LEXMARK

    to print to the LEXMARK printer on GUTENBERG using the printacct account and ppass password. Depending on the server's configuration, you may be able to omit the account and possibly the password.

  • The best way to manage IPP printers is generally to take advantage of browsing. If that's not possible, though, you can use an ipp:// prefix, a hostname, and a printer name, much as with LPD printers. Some network-enabled devices that support IPP require variants on this, so consult their documentation.


One type of print queue definition requires special mention: a raw queue. You can create a raw queue by selecting a printer make of Raw and model of Raw Queue. Unlike most CUPS printer queues, a raw queue uses no filteringthat is, CUPS won't try to determine the file's type and pass it through programs such as Ghostscript to produce output that's acceptable for your printer. For most Linux purposes, raw queues aren't very useful; however, there are a few cases where you might want to use one. One such instance is if you want to use Linux as a print server for non-Linux systems, such as Windows computers. You might then install Windows drivers on the Windows clients to have them print to the Linux raw queue. Using a raw queue in this instance guarantees that CUPS won't corrupt the Windows print jobs. (Another option for this scenario is to use PostScript drivers on Windows. Each approach has its plusses and minuses.) A second situation where raw queues can be handy is when you use an application that provides its own printer drivers. The GIMP is one such program, and you might get better results using the GIMP's printer drivers than using the standard Ghostscript drivers for your printer.

If in doubt, you should probably create a regular printer queue, which will try to parse the file type and convert it (via Ghostscript or other filtering programs) to your printer's native format. If this doesn't work or if you know you'll need it, though, a raw queue can be the way to go.

14.2.4.3. Testing your printer definition

Once you've configured your printer queue, you can test it. From the main printer description page (Figure 14-3), click Print Test Page for your queue. CUPS should respond with a message to the effect that a test page has been printed. After a brief delay, the result should be a printer test page being printed. (Precisely how long a delay you'll experience depends on the printer, its configuration, how it's connected to your computer, your computer's CPU speed, and your computer's CPU load.)

The standard CUPS test page includes a color wheel; a circle of fine radial lines (used to assess resolution); information on page size, borders, and nominal resolution; and PostScript interpreter data. Check that the resolution (expressed in dots per inch, or dpi, in the Imageable Area box) is reasonable. If it's not, consult "Fine-Tuning Printer Definitions" for help. Likewise, if a color printer produces merely black-and-white printouts, you will have to adjust your configuration. (This is assuming you know the printer is working correctly; it's entirely possible that the printer's color ink is depleted or clogged!)

If your printer doesn't generate any output at all, consult the section "Printer Troubleshooting," later in this chapter.

14.2.5. Fine-Tuning Printer Definitions

Most modern printers provide options that affect print quality and style. These features include variable resolution, ink- or toner-saving modes, printing modes optimized to particular types of paper, and so on. CUPS provides a way to set defaults for these features for a given queue. From the main print queue list page in the web-based CUPS configuration (Figure 14-3), click Configure Printer in the area for the printer you want to modify. The result is a list of options you can set, as shown in Figure 14-5.

The list of options available for any given printer varies greatly from one printer to another. Some common options you might want to investigate include the following:


Output Mode

This option sets the color options for the printer: whether it prints in color or black and white, and if in color, how it encodes color information. For most color printers, RGB Color is the best choice.


Print Quality

This option describes print resolution in imprecise verbal terms (Economy, Standard, High, and so on).


Resolution

You can set the print resolution in precise numeric terms using this option. Many printers support different horizontal and vertical resolutions. As a general rule of thumb, the higher the resolution, the slower the printing, particularly for inkjet printers.

Figure 14-5. CUPS enables you to fine-tune the configuration for each of your print queues


Media Size

You can tell CUPS what size paper you use with this option. Be sure to check it, because it has a habit of setting itself to the wrong size when you first install a printer.


Media Source

Many printers support multiple paper feeds, and this option lets you tell CUPS which one to use by default.


Media Type

This option lets you tell CUPS about the type of paper you're using. This feature can be particularly important for inkjet printers, because different papers absorb ink in different ways. When CUPS knows what type of paper you're using, it can have Ghostscript adjust its output to suit the paper.


Output Order

Depending on the printer's design, multipage documents may print in such a way that the complete stack is backwards. You can set this option to correct for this problem by having the document print backwards, if you like.


Duplexing and paper handling

Some drivers enable you to turn on duplexing (printing on both sides of the paper) and other advanced paper-handling options.


Color and brightness options

Many options relate to the brightness, saturation, and color balance of the output of color printers. These options vary from one printer to another. You may need to experiment with these options to find what works best for you.


Dithering options

Ghostscript dithers its outputthat is, when it's told to print a particular color, it's likely to print a pattern of several different ink colors. The reason is simple: color printers have just a few colors at their disposal, so to match a given color, two or more must be combined in a pattern. Certain dithering algorithms work better for particular applications than others, and personal preference can also play a role. Thus, CUPS lets you tell Ghostscript what dithering algorithm to use. As with color and brightness options, you may need to experiment to determine what works best for you.


Specialty print options

Some printers support borderless (edge-to-edge) printing, printing on CD-R and DVD-R media, and other special options. You can set these options if your Ghostscript driver supports them.


Print direction and interleaving options

Most modern inkjet printers support bidirectional printingthat is, they print in one direction and then in the other to save time. This is handy, but alignment is sometimes improved by printing in one direction alone. Similarly, interleaving options that relate to which ink nozzles fire can improve or degrade print quality while affecting print speed.


Ink options

Some drivers enable you to specify which ink tanks to use, or to tell Ghostscript that you've installed an optional ink set.


Banners

You can have CUPS print a banner page before or after each print job. This page can identify the job and optionally include a brief note, such as Confidential.


PostScript level filtering

For some PostScript printers, CUPS can convert the PostScript level to a specified version, such as converting everything to PostScript Level 1. This can be handy if your printer chokes on more recent versions of PostScript.

Because printer capabilities vary so much, we can't describe all the options here. You may need to examine the options and experiment with them. Change an option and see how it affects output. Some options will affect text more than graphics or graphics more than text. Different types of graphics, such as digital photos versus charts and graphs, may also be affected differently by certain options. As a general rule, if you don't understand an option you should probably leave it alone.

In the past, Linux provided applications with limited or no access to printer options such as those described here. In fact, applications built for the old LPD system may not be able to set these options directly; these programs can only use the printer's defaults. To set such options in such applications, you can create multiple print queues for each printer. For instance, suppose you want to be able to print at 360 dpi for quick printouts or at 1440 dpi for slower but higher-quality printouts. You would create two print queues (say, canon_360 and canon_1440). Both queues would connect to a single printer device, but you'd set different default options for the two queues. You'd then choose your desired print resolution by printing to one queue or the other.

Alternatively, if you're running in X and if the application enables you to enter the printing command, you can use kprinter as the printing command. The result is the standard KDE printing dialog box. When you set it to use CUPS (via the listbox near the bottom of the dialog box) and select a print queue, you can click the Properties button in the upper-right corner of the dialog box. The result is the Configuration dialog box shown in Figure 14-6. This dialog box has multiple tabs that correspond to various CUPS configuration options, so you can adjust the resolution (as shown in Figure 14-6) or other printing options.

Another fine-tuning detail is setting the default print queue. In theory, you should be able to do this from the CUPS interface by clicking the Set as Default option; however, in practice this often produces an error message about an unknown operation. To work around this bug, use the lpadmin command with its -d option, which takes the name of the default queue:

     # lpadmin -d hp4500

This command sets the default queue to hp4500. All subsequent print jobs submitted via lp or lpr that don't specify a queue will go to the hp4500 queue. This queue will also be the one to appear in print dialog boxes when they first open. In the case of both text-mode and GUI programs, though, you can still print to non-default queues by specifying the one you want to use.

14.2.6. Managing Printer Queues

An important part of printer administration is managing active print queues. Once a system has print queues defined, users start using them, and the result can sometimes be problems. You may need to delete jobs that are too big, temporarily shut down a queue while you reconfigure it, or otherwise manipulate the queue. To handle this task, CUPS provides two basic classes of tools: text-mode and web-based.

Figure 14-6. kprinter lets you adjust printer features from many CUPS-unaware applications


14.2.6.1. Using command-line tools

Text-mode CUPS commands enable you to control print queues from a text-mode login, an xterm window, or any other text-mode interface. Most of these commands require root privilege to function correctly, but a few can be used by ordinary users:


lpc

This command is named after the main text-mode queue manager in LPD, but the CUPS version is very limited; its only useful option is status. Type lpc status to see a list of available queues and the status of each (queueing enabled, printing enabled, number of queued jobs, and the availability of a CUPS daemon to manage the queue). You can add a queue name to obtain status on that queue alone.


lpstat

This command lists status information on print jobs, and like lpc, it can be used by ordinary users. Type this command by itself to see a list of jobs that are queued for printing on all the system's printers. You can also use various options to modify its output in various ways. For instance, -p queue restricts output to the specified queue, -u users restricts output to jobs submitted by the specified user or users, and -d displays the current default destination.


lpq

Like lpc, this command is borrowed from the LPD printing system. It displays information on the status of the current queue, similar in some ways to lpstat. It's often used with the -P queue option to display information on the specified queue rather than the default one. (Alternatively, -a can be used to display information on all queues.)


lppasswd

This program changes the CUPS digest passwordthat is, the password used by the system if you set AuthType to Digest in the cupsd.conf configuration file.


enable and disable

These commands start or stop a queue, respectively. Both commands take a queue name as an option, and disable also takes a few options, the most important of which may be -c. This option causes disable to cancel all the jobs currently in the queue. The disable command also accepts an -r reason option, which enters the text string reason as an explanation for the printer 's unavailability.

If you receive the error message not a shell builtin when you use the enable command, you must provide the complete path to the command, usually /usr/bin/enable.



accept and reject

These commands cause the specified print queue to begin accepting or rejecting new jobs for printing. This differs from enable and disable in that accept and reject affect only the queue's ability to accept new jobs for printing, whereas enable and disable affect the queue's ability to print jobs in the queue. Like disable, reject supports a -r reason option so that you can register a reason for the queue's unavailability.


lprm

You can remove a job from the queue using this command. It takes an optional queue definition (-P queue) and a job identifier (which you can obtain with lpstat) as arguments.


lpmove

This command moves a print job from one queue to another. It accepts two arguments: a job identifier and a queue name, as in lpmove oldqueue-456 newqueue. This command moves job oldqueue-456 to the newqueue queue.

As an example of these commands in action, suppose you have a problem with the hp4000 queueperhaps the printer is malfunctioning and needs to be serviced. Thus, you want to disable it and move some of its jobs to another queue (say, the laserwriter queue), and perhaps delete other jobs. You might type commands like these to do all this:

     # disable hp4000     # lpc status hp4000     hp4000:             printer is on device '/dev/null' speed -1             queuing is enabled             printing is disabled             no entries             daemon present     # lpstat     hp4000-433              sholmes          15360   Sun Apr 10 22:20:44 2005     hp4000-434              moriarty          2977   Sun Apr 10 22:21:32     # lpmove hp4000-433 laserwriter     # lprm hp4000-434     # lpstat     laserwriter-433         sholmes          15360   Sun Apr 10 22:20:44 2005

In this example, the hp4000 queue is first disabled, and lpc status hp4000 confirms its disabled statusnote the printing is disabled message. The lpstat command reveals that two jobs are now stuck in the disabled queue. The first of these, belonging to sholmes, is moved to the laserwriter queue with the lpmove command, whereas the second job, belonging to moriarty, is deleted with lprm. A subsequent check with lpstat shows the moved job under its new name. (This job might not show up if it had been completely accepted by the printer before the command was typed.)

14.2.6.2. Using the CUPS web-based interface

The CUPS web-based interface provides an alternative means of controlling print queues whose features largely parallel those of the text-based commands. From the main printer list (Figure 14-3), you can stop a queue (equivalent to disable) or tell it to reject new jobs (equivalent to reject) by clicking the Stop Printer or Reject Jobs links, respectively. Once clicked, these links change to Start Printer and Accept Jobs, respectively, and have the effect of the enable and accept commands.

You can view the contents of print queues by clicking the Jobs link at the top of the page. The result is a process list similar to the one created by lpstat. This list includes a Control column with a Hold Job and a Cancel Job link for each job. Click these links to temporarily stop a job from printing or to delete the job entirely, respectively.

14.2.7. Maintaining LPD Compatibility

CUPS is designed as a drop-in replacement for LPD , and in fact it uses many of the same commands for printing as LPD. (These are described in "Printing," earlier in the chapter.) A couple of key LPD compatibility issues are providing an environment that programs designed for LPD will find helpful and accepting print jobs from networked LPD clients.

14.2.7.1. Maintaining a legacy /etc/printcap file

Many programs that expect to print using LPD examine the /etc/printcap file to determine what queues are available. Under LPD, this file defines all the available print queues, so it's a critical LPD file. Thus, CUPS tries to maintain a minimal /etc/printcap file for the benefit of user programs. (CUPS-enabled programs communicate with CUPS in other ways to obtain print queue lists.)

A full LPD /etc/printcap file contains many types of fields, and any given printer definition is likely to use about half a dozen field types. The simplified needs of CUPS, though, mean that a stripped-down file is sufficient. A typical file looks like this:

     hp4000|Hewlett-Packard HP LaserJet 4000 Series:rm=nessus:rp=hp4000:     epson|Epson RX500 1440x720 dpi:rm=nessus:rp=epson:     epson_360|Epson RX500, 360dpi economy:rm=nessus:rp=epson_360:

These three lines describe three queues: hp4000, epson, and epson_360. Under LPD, print queues may have multiple names, which are separated from one another by vertical bars (|). Typically, a short name begins the entry, and longer names follow. CUPS uses this feature to provide a short name based on the print queue name and a longer name based on the printer description. Subsequent fields in each line are separated by colons (:). In this example, CUPS has generated entries using the rm= and rp= options, which in LPD define the remote server name and remote print queue name for network printers. In this sample, these fields identify the computer on which the file resides and the queue name. CUPS doesn't require this information, nor do most LPD-using programs, but it can help keep a few programs happy to see this minimal information.

Normally, you needn't be concerned with maintaining an /etc/printcap file, because CUPS does so automatically. If something interferes with this process, though, you might want to create a dummy /etc/printcap file yourself. At a minimum, the file should hold each queue's correct name and a colon. Adding rm= and rp= fields, as in the preceding example, might help some programs.

14.2.7.2. Accepting print jobs from LPD systems

As noted earlier, CUPS uses IPP for communicating with other CUPS systems. LPD systems use the older LPD protocol. Thus, if your network contains a mix of CUPS and LPD systems, or a mix of CUPS systems with systems that use some other printing system that nonetheless understands the LPD protocol, you may want to enable LPD support in CUPS. This support will enable a CUPS system to accept print jobs submitted via the LPD protocol. It is not necessary on an all-CUPS network, and is disabled by default on all major Linux distributions.

Enabling LPD support is necessary only to accept print jobs from LPD clients. If you want your CUPS daemon to print to a remote system that runs LPD, you can do so without activating this support. In this case, you need to specify the LPD server as a network print server, as described earlier in "Creating a printer definition."

The CUPS LPD support is provided by a small daemon called, appropriately enough, cups-lpd. This server is designed to be run via a super server, such as inetd or xinetd. On distributions that use xinetd, such as Fedora, Red Hat, and SUSE, look for a xinetd configuration file called cups-lpd in the /etc/xinetd.d directory. Look for a line in this file that reads disable = yes and edit it so that it reads disable = no. You can then restart xinetd or tell it to reload its configuration, and the cups-lpd server should be started. This server will accept print jobs using the LPD protocol just like BSD LPD or LPRng would, but it will redirect the job into the local CUPS queue of the same name.

If your system uses inetd, you must add an entry for cups-lpd to the /etc/inetd.conf file:

     printer stream tcp nowait lp /usr/lib/cups/daemon/cups-lpd cups-lpd

Some systems will require changes to this configuration. For instance, you might want to call cups-lpd via TCP Wrappers (tcpd) rather than calling cups-lpd directly. As with xinetd, you must restart inetd or tell it to reload its configuration to start cups-lpd.

14.2.8. Printer Troubleshooting

With any luck, if you follow the instructions in this chapter, your printer will work with little or no fuss. Unfortunately, CUPS configuration doesn't always work as planned, and printer troubleshooting can be tricky and frustrating. Although we can't provide a sure-fire way to get your printer working, we can provide some suggestions that can help you track down the source of problems and find solutions to them.

  • If possible, verify that the printer works in another OS on the same computer. Even a FreeDOS (http://www.freedos.org) boot floppy can be handy for such verification, at least for parallel and RS-232 serial printers . If the printer works in another OS, that rules out a lot of pure hardware problems. If not, that suggests (but does not prove) that the problem is hardware-related.

  • Try checking all hardware connections, from the power cables to the cables to the computer. Loose or defective cables can cause endless hours of trouble. If your printer has a power switch, check that the printer is turned on. (We know that sounds incredibly basic, but failure to turn on a printer really is a leading cause of problems!) While you're at it, check that you've got paper in the printer's paper traysall of them, if it has multiple trays.

  • Examine the printer's front or top panel for any error signals. Some printers have LCDs that can display short messages such as out of paper or paper jam. Others rely on blinking LEDs. Consult your printer's manual for help interpreting these displays.

  • If you have a parallel or RS-232 serial printer, try sending a print job to the printer using its raw device file, as described earlier in "Verifying printer compatibility." If this doesn't work but the printer checks out physically, it could mean you're missing a kernel driver for your device. Loading it with modprobe will perhaps do the trick. Another possible cause of such problems is that you're using the wrong device file, so you might want to try others. If the printer's LEDs blink when you try to print, chances are the file is getting through but is in a format that the printer can't understand, so basic hardware functions are probably (but not certainly) working.

  • If you have a USB printer, check that the kernel has identified the printer by using the lsusb command and by examining the contents of /proc/bus/usb/devices, as described earlier in "Verifying printer compatibility." If the printer's not showing up, you may be missing kernel drivers or your printer might be an exotic model that's not yet supported by Linux.

  • If the printer has a network interface, try using ping to verify basic connectivity with the printer. If it doesn't respond, consult the printer's manual to learn how to activate its network interface. You might also need to review your DHCP server's configuration and logfiles to see why the printer's not obtaining an IP address, if it's supposed to do so via DHCP.

  • If the printer sports multiple interfaces (such as parallel and USB ports), try using the interface you didn't originally use. If the printer begins working (after appropriate reconfiguration in Linux), it could be that the Linux drivers for the interface you originally tried didn't work, or there could be a hardware defect in the printer, your computer, or a cable. You can either try to track down this problem or continue using the interface that's working.

  • If you can get basic printing via a device file working or if you have a USB or network printer that responds in basic ways, you should move on to CUPS configuration.

  • From the main CUPS interface (Figure 14-3), check the printer's description. (Alternatively, type lpc status at a command prompt.) If the printer is described as stopped or rejecting jobs, you should click the appropriate button or use enable or accept to get the queue working again.

  • If the printer's description includes the phrase waiting for job to complete, it means that something's preventing CUPS from clearing a job from the queue. This could be a physical connection problem or a software foul-up. Sometimes restarting CUPS will clear this problem.

  • If the printer prints, but produces reams of gibberish, it probably means that you've selected the wrong printer when configuring the queue. (Sometimes you'll get gibberish if a job is interrupted and you turn the printer on without clearing the existing jobs from the queue, but this doesn't mean your driver is fouled up.) If the gibberish looks like a PostScript program, you might have selected a PostScript variant of your non-PostScript printer, so selecting the non-PostScript variant might work better. If the gibberish seems utterly random, it's probably a matter of selecting a completely incompatible non-PostScript printer.

  • Slow printouts can be a serious problem. You can often improve print speed, particularly for inkjet printers, by reducing the print resolution. This will degrade the print quality, though, and you'll have to decide where a good trade-off point lies. If a USB 2.0 printer is slow, check that you're using a USB 2.0 port and that you've loaded the Linux USB 2.0 (EHCI) drivers. If not, load the appropriate drivers and, if necessary, buy a supplementary USB 2.0 card.

  • If printouts don't meet your expectations for quality, review the printer options described in "Fine-Tuning Printer Definitions." You may be able to increase resolution, change dithering options, alter brightness settings, or otherwise change the way Ghostscript and the printer process your printouts to improve the quality. Some of these changes will slow down the printouts, though.

On the whole, printer troubleshooting can be as much of an art as a science. A lot of things can go wrong, and it's hard to predict what's most likely to go wrong. The preceding summary should at least help you narrow the list of potential causes and get you on the right track to fixing the problem, though.

14.2.9. Behind the Scenes: CUPS Files and Directories

Most of the preceding description of CUPS has steered clear of describing specific files and directories. This is because, with the exception of the /etc/cups/cupsd.conf file, manually editing CUPS configuration files or changing its directories is seldom helpful. CUPS often responds unpredictably to manual changes in its configuration files; you should really use its web-based interface and text-mode commands to configure and control CUPS.

That said, you may need to know about these files and directories. The CUPS configuration files reside in /etc/cups. The cupsd.conf file, as already noted, controls the server on a broad level, and you may need to edit this file. Other important files in this directory include printers.conf (which defines local printers) and lpoptions (which identifies the default printer). The ppd subdirectory holds PPD files for local printers (they're copied from elsewhere, as described shortly).

CUPS stores a great deal of support data in the /usr/share/cups directory tree. Of particular interest is the /usr/share/cups/model subdirectory, which holds PPD files (most in subdirectories named after the printers' manufacturers). The Foomatic and GIMP Print packages may install PPD files there. If they don't, and if you can't get these printer definitions recognized, try creating symbolic links in this subdirectory to the actual location of the printer definition package's PPD files. This should enable CUPS to locate the PPD files and install the printers.

In actual operation, CUPS uses the /var/spool/cups subdirectory to hold print job descriptions and the actual print job files. This directory is owned by root and the lp group and has 0710 (rwx--x---) permissions. CUPS also uses the /var/spool/cups/tmp directory, which is owned by root and the lp group and has 1710 (rwx--x--T) permissions. (These owners and permissions are typical, but may differ between distributions.) Unlike LPD, CUPS doesn't use separate subdirectories for each printer; print jobs for all printers are dumped into the same directory tree.



Running Linux
Running Linux
ISBN: 0596007604
EAN: 2147483647
Year: 2004
Pages: 220

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net