This chapter provides some background information about the operation of printers. Numerous examples show how the different parts of the printing system interact. This chapter should help in finding suitable solutions for possible problems and in avoiding unsuitable solution attempts.
On a Linux system, printers are managed via print queues. Before any data is printed, it is sent to the print queue for temporary storage. From there, the print spooler sends the data to the printer.
However, this data is predominantly not available in a form that can be processed by the printer. A graphical image, for example, first needs to be converted into a format the printer can understand. This conversion into a printer language is achieved with a print filter, a program run by the print spooler to translate data as needed so the printer can process it.
SuSE Linux supports two different printing systems:
Under normal conditions, it is not possible to install these two printing systems concurrently, as there are conflicts between them. However, you can switch between the two print systems with YaST (see User Guide, Section YaST -- Configuration, Printers).
PostScript printers do not require a special printer driver (see 6). Other printer types need a Ghostscript driver to produce the data. For non-PostScript devices, choosing the right Ghostscript driver and the right options for it has a big influence on output quality. The Ghostscript drivers available for specific models are listed in the sources mentioned in 6.
If you cannot find a Ghostscript driver for your printer, ask the manufacturer which printer language your model understands. Some manufacturers supply special Ghostscript drivers for their printers. Even if the manufacturer is not able to provide any Linux-specific information on your printer model, he can still provide the following information to facilitate the selection of a suitable printer driver:
A similar model name does not always mean the hardware is really compatible. Printers that appear very similar on the outside sometimes do not use the same printer language at all.
Since the printer drivers for Linux are usually not developed by the hardware manufacturer, it is crucial that the printer can be addressed with one the common printer languages (PostScript, PCL, and ESC/P). Normal printers understand at least one of the common printer languages. However, GDI printers only work with the operating system versions for which the manufacturer has enclosed drivers, as they can only be addressed with special control sequences. As these printers cannot be addressed with any known standard, their use with Linux is either impossible or difficult.
GDI is a programming interface developed by Microsoft for graphical devices. There is not much of a problem with the interface itself, but the fact that GDI printers can only be controlled through the proprietary language they use is an issue. A better name for them would be ``proprietary-language-only printers.''
On the other hand, there are printers that can be operated both in GDI mode and in a standard language mode, but they need to be switched accordingly. If you use Linux together with another operating system, it may be possible that the driver set the printer to GDI mode when you last used it. As a result, the printer will not work under Linux. There are two solutions for this: switch the printer back to standard mode under the other operating system before using it under Linux or use only the standard mode, even under the other operating system. In the latter case, it may turn out that printing functionality is limited, such as to a lower resolution.
There are also some very special printers that implement a rudimentary set of a standard printer language, such as the commands needed for printing raster images. Sometimes these printers can be used in a normal way, as the Ghostscript drivers normally only use commands for printing raster images. In this case it may be impossible to print ASCII text directly. This should not be too much of a problem, however, as ASCII text is mostly printed through Ghostscript and not directly. However, printers that first have to be toggled with special control sequences are problematic. This cannot be done with a normal Ghostscript driver, but requires a specially adapted driver.
For some GDI printers, you may be able to obtain Linux drivers directly from the manufacturer. There is no guarantee that such vendor-made drivers will work with other or future Linux versions.
In any case, the above is only true for GDI models. By contrast, printers that understand one of the standard languages do not depend on a particular operating system nor do they require a particular Linux version. However, they often produce the highest quality of output when used with a vendor-made driver.
To sum all this up, SuSE Linux does support the GDI printers listed below. They can be configured using the printer configuration module of YaST . Be aware that their use will always be rather problematic. Some models might refuse to work at all or their functionality might be limited, for example, to low-resolution black-and-white printing. SuSE does not test GDI printers, so cannot guarantee this list is correct.
To our knowledge, the following GDI printers are not supported by SuSE Linux (this list is not complete by any means):
In most cases, you will want to set up more than one print queue for the following reasons:
If your model is a plain black-and-white printer, such as most laser printers, it will be sufficient to configure just one standard queue. Color inkjets, on the other hand, require at least two different queues (configurations):
Start the YaST printer configuration by selecting it from the YaST Control Center or by entering yast2 printer in a command line as SuSE @nohyphen root. Enter yast2 printer .nodetection to suppress printer autodetection. For more details about autodetection, see 6.
Not all printers are capable of being configured for both print systems. Some options are only supported by either CUPS or LPRng and lpdfilter. YaST provides information about this whenever necessary.
You can easily switch back and forth between CUPS and LPRng/lpdfilter using a submenu of the YaST printer configuration which can be accessed with the ` Advanced' button.
The YaST printer configuration module offers the following printing system selections:
The package cups-client and the package lprng should not be installed concurrently. The package cups-libs must always be installed, as several packages (such as Ghostscript, KDE, Samba, Wine, and the YaST printer configuration) need the CUPS libraries.
The printing system as a whole requires a number of additional packages, although the ` Default system' should include them. The most important ones are:
The YaST printer configuration modules display all configurations that could be created without errors.
As the configurations are not generated until the YaST printerconfiguration module is terminated, you should restart the YaST printer configuration to make sure everything is OK.
The YaST printer configuration also strictly distinguishes between queues created through YaST itself (YaST queues) and queues created through other means (non-YaST queues). Non-YaST queues will never be touched by YaST . Conflicts only arise if queues have identical names. When editing a queue, you can determine whether it should be managed by YaST . If you turn a YaST queue into a non-YaST queue, you can edit the configuration manually (without YaST ) and prevent these changes from being overwritten by YaST . Likewise, you can turn a non-YaST queue into a YaST queue to overwrite an existing configuration deliberately with YaST .
Depending on how much of your hardware can be autodetected and on whether your printer model is included in the printer database, YaST will either autoconfigure your printer or offer a reasonable selection of settings that then need to be adjusted manually. If this is not the case, the user must enter the needed information in the dialogs. YaST can configure your printer automatically if the following conditions are fulfilled:
Each configuration should be tested with the print test function of YaST to see whether it works as expected. In many cases, configuration data not explicitly supported by the printer manufacturer must be used. For this reason, operability cannot be guaranteed for all settings.
Furthermore, the YaST test page provides important information about the respective configuration.
If one of the conditions for automatic configuration is not fulfilled or if you want your own customized setup, the configuration must be performed manually. The following is an overview of the options to set during manual configuration:
It is safest to connect a printer to the first parallel port. In this case, the BIOS settings for this port should look like this:
If the printer does not respond at the first parallel port with these settings, you may need to change the IO address to have the explicit form of 0x378 under the BIOS menu item that lets you configure the advanced settings for parallel ports. If your machine has two parallel ports with IO addresses 378 and 278 (hexadecimal), change them to read 0x378 and 0x278, respectively. For further details on the topic, see 6.
For non-PostScript models, all printer-specific data is produced by the Ghostscript driver. Therefore, the driver configuration (both choosing the right driver and the correct options for it) is the single most important factor determining the output quality. Your settings affect the printer output on a queue-by-queue basis.
If your printer was autodetected, which means the model is included in the printer database, you will be presented with a choice of possible Ghostscript drivers and with several output options such as:
Each default configuration includes a suitable Ghostscript driver and, if available, a number of driver-specific settings related to the output quality.
Any driver-specific settings can be customized in a separate dialog. Click the respective values to view and access any indented submenu entries.
Not all combinations of driver options work with every printer model. This is especially true for higher resolutions. Always check whether your settings work as expected by printing the YaST test page. If the output is garbled (for example, with several pages almost empty), you should be able to stop the printer by first removing all sheets then stopping the test print from within YaST . However, in some cases the printer will refuse to resume work if you do so. It may be better to stop the test print first and wait for the printer to eject all pages itself.
If your model was not found in the printer database, you can select one of the generic Ghostscript drivers for the standard printing languages. These are listed under a generic ``manufacturer''.
For the CUPS printing system, the following special settings are available:
For the LPRng and lpdfilter printing system, change the following hardware-independent settings:
Applications use the existing queues for printing from the command line. In applications, printer options are not configured directly, but rather through the existing queues.
On the command line, you can print with the following command:
Replace <filename> with the name of the file you want to print. The option -P can be used to specify the queue. For example, -Pcolor uses the queue color.
For the most part, printers are connected to a Linux system through a parallel port. Printers on parallel ports are handled by the parport subsystem of the Linux kernel. The basics of parallel port configuration with YaST are described in 6. The paragraphs below provide more in-depth information on the topic.
The parport subsystem manages parallel ports only through the corresponding architecture-specific kernel modules after these are loaded. Among other things, this allows for several devices, such as a parallel port ZIP drive and a printer, to be linked to one parallel port at the same time. Device files for parallel printers are counted beginning with /dev/lp0. With a SuSE Linux standard kernel, printing over the parallel port requires that the modules parport, parport_pc, and lp are loaded. This is achieved by kmod (the kernel module loader). Normally, these modules are loaded automatically as soon as some process requests access to the device file.
If the kernel module parport_pc is loaded without any parameters, it tries to autodetect and autoconfigure all available parallel ports. This may not work in some very rare cases and cause a system lock-up. If that happens, configure it manually by explicitly providing the correct parameters for the parport_pc module. This is also the reason why printer autodetection can be disabled for YaST as described in 6.
The first parallel port (/dev/lp0) is configured with an entry in /etc/modules.conf, as shown in File 5.
alias parport_lowlevel parport_pc
options parport_pc io=0x378 irq=none
Under io, enter the IO address of the parallel port. Under irq, keep the default none for polling mode. Otherwise, provide the IRQ number for the parallel port. Polling mode is less problematic than interrupt mode as it helps to avoid interrupt conflicts.
However, there are combinations of motherboards and printers that only function well if this is set to interrupt mode. Apart from that, interrupt mode ensures a continuous data flow to the printer even when the system is under very high load.
To make the above configuration work, you may still need to change the parallel port settings made available through your machine's BIOS or firmware:
If interrupt 7 is still free, enable in /etc/modules.conf as shown in File 6.
alias parport_lowlevel parport_pc
options parport_pc io=0x378 irq=7
Before activating the interrupt mode, check the file /proc/interrupts to see which interrupts are already in use. Only the interrupts that are currently in use are displayed. This may change depending on which hardware components are active. The interrupt used for the parallel port must not be occupied by any other device. If you are not sure, use the polling mode.
After configuration, the parallel port is enabled when you reboot the machine. If you do not want to reboot, run the following commands as SuSE @nohyphen root to update the module dependency list and to unload all kernel modules related to parallel ports.
depmod -a 2>/dev/null rmmod lp rmmod parport_pc rmmod parport
After this, reload the modules with:
modprobe parport modprobe parport_pc modprobe lp
If the printer is capable of direct ASCII text printing, the following command as SuSE @nohyphen root should print a single page with the word Hello on it:
echo -en "\rHello\r\f" >/dev/lp0
In the above command, the word Hello is enclosed in two \r ASCII characters to produce carriage returns. The closing ASCII character \f is included to produce a form feed. To test a second or third parallel port in the same way, use /dev/lp1 or /dev/lp2, respectively.
First, make sure the interrupt is enabled for USB in your machine's BIOS. In an Award BIOS, for example, go to the menu ` PNP AND PCI SETUP' and set the entry ` USB IRQ' to Enabled. The wording of these menus and entries may vary depending on the BIOS type and version.
Test whether the USB printer is responding by entering the command (as SuSE @nohyphen root):
echo -en "\rHello\r\f" >/dev/usb/lp0
If there is only one USB printer connected to the machine and this printer is able to print ASCII text directly, this should print a single page with the word Hello.
Some USB printers may need a special control sequence before accepting data over a USB line. Further information can be found in the Support Database http://sdb.suse.de/en/sdb/html. Enter the keywords ``Epson'' and ``usb''.
In most cases, you should be able to get information about the printer manufacturer and the product name by entering:
If this does not display any information, it will usually be for one of these reasons:
Sometimes it may happen that the USB printer does not respond anymore, for instance, after unplugging it in the middle of a print job. In such a case, the following commands should be sufficient to restart the USB system:
If you are not successful with these commands, terminate all processes that use /dev/usb/lp0. Use lsmod to check which USB modules are loaded (usb-uhci, usb-ohci, or uhci) and how they depend on each other. For instance, the following entry in the output of lsmod shows that the module usbcore is being used by modules printer and usb-uhci:
usbcore ... [printer usb-uhci]
Accordingly, modules printer and usb-uhci need to be unloaded before unloading usbcore. As SuSE @nohyphen root, enter the following commands (replace usb-uhci with uhci or usb-ohci depending on your USB system):
If you have more than one USB printer connected to the system, there is a special issue to consider: All connected devices are autodetected by the USB subsystem with the first USB printer being addressed as device /dev/usb/lp0 and the second one as /dev/usb/lp1. Depending on the model, USB printers can be detected even when they are powerless. Some have the built-in capability to be queried by the system even when powered off. Therefore, to avoid that the system confuses different printers, switch on all printers before booting and try to leave them connected to power all the time.
With IrDA, the system uses an infrared interface to emulate a parallel port. To do so, the Linux drivers provide a simulated parallel port under the device name of /dev/irlpt0. A printer connected through infrared is handled in the same way as any other parallel printer except it is made available to the system under the name of /dev/irlpt0 instead of /dev/lp0.
Test the connection to an IrDA printer by entering the command (as SuSE @nohyphen root):
echo -en "\rHello\r\f" >/dev/irlpt0
If the printer is able to print ASCII text directly, this should print a single page with the word Hello on it.
Regardless of the outcome of the above test, the printer should appear in the output of irdadump. If the irdadump command is not available, install the package irda. If irdadump does not display the printer, it is not possible to address the printer. If nothing is displayed, most likely the IrDA system service has not been started, as it is not started automatically when the system is booted. Enter the following commands to start and stop the IrDA systems service:
The use of the LPRng spooler with a printer connected to the serial port is described in the LPRng-Howto under file:/usr/share/doc/packages/lprng/LPRng-HOWTO.html (local copy) (especially under file:/usr/share/doc/packages/lprng/LPRng-HOWTO.html#SECSERIAL) and in printcap. Information is also availabe in the Support Database under the keyword ``serial''.
Normally, the printing system is configured with YaST as described in 6. SuSE Linux also includes the program lprsetup, which is a bare-bones command-line tool for the configuration of the LPRng and lpdfilter printing system.
When setting up a printer with YaST , it collects all necessary data then runs lprsetup internally with all the necessary options to write the actual LPRng and lpdfilter configuration.
lprsetup is intended as an expert tool. As such, it will not provide any help to find the correct values for printer options. To see a brief list of the available command line options for lprsetup, enter lprsetup -help or refer to lprsetup and lpdfilter for further details.
For information regarding Ghostscript drivers and driver-specific options, read 6 and 6.
The print spooler used by the LPRng and lpdfilter printing system is LPRng ( package lprng).
The print spooler lpd, or line printer daemon, is usually started automatically on boot. More specifically, the script /etc/init.d/lpd is run as part of the boot procedure. After this, the print spooler runs as a in the background. Start and stop it manually with these commands:
These are the configuration files of LPRng:
According to the script /etc/init.d/lpd, the command rclpd start also runs the command checkpc -f as a subprocess, which in turn creates spool directories with the appropriate permissions in /var/spool/lpd according to the queues defined in /etc/printcap.
When started, the print spooler first reads the entries in /etc/printcap to see which print queues have been defined. The spooler's task is then to manage any jobs queued for printing. In particular, the spooler:
To learn more about the details of this mechanism, read the LPRng Howto (file:/usr/share/doc/packages/lprng/LPRng-HOWTO.html (local copy)) or consult printcap and lpd.
Applications use the lpr command for printing. In the application, select the name of an existing queue (such as color) or enter a suitable print command (such as lpr -Pcolor) in the print dialog of the application.
On the command line, you can print with the command lpr -Plp <filename>. Replace <filename> with the name of the file you want to print. The option -P can be used to specify the queue. For example, -Pcolor uses the queue color.
This section only provides a short overview of the available tools. For details, consult the LPRng Howto, in particular, section file:/usr/share/doc/packages/lprng/LPRng-HOWTO.html#LPRNGCLIENTS.
Details on how to use the lpr command can be found in the LPRng Howto (file:/usr/share/doc/packages/lprng/LPRng-HOWTO.html#LPR (local copy)). The following only covers some basic operations.
To print a file, you normally must enter lpr -P<queuename> <filename>. If you leave out the -P<queuename> parameter, the printing system defaults to the value of the environment variable PRINTER. The same is true for the commands lpq and lprm. See lpr, lpq, and lprm for more information. The environment variable PRINTER is set automatically on login. Display its current value with echo $PRINTER. Change it to expand to another queue by entering export PRINTER=<queuename>.
By entering lpq -P<queuename>, check the status of print jobs handled by the specified queue. If you specify all as the queue name, lpq displays information for all jobs in all queues.
With lpq -s -P<queuename>, tell lpq to display only a minimum of information. lpq -l -P<queuename> tells lpq to be more verbose.
With lpq -L -P<queuename>, lpq displays a detailed status report, which will come in handy when trying to track down errors.
For further information, see lpq, and section file:/usr/share/doc/packages/lprng/LPRng-HOWTO.html#LPQ (local copy) of the LPRng Howto.
The command lprm -P<queuename> <jobnumber>removes the print job with the specified number from the specified queue, if you own the job. A print job is owned by the user who started it. Display the owner and the job number of print jobs with lpq.
The command lprm -Pall all removes all print jobs from all queues for which you have the required permissions. SuSE @nohyphen root may remove any jobs in any queues regardless of permissions.
More information can be obtained in lprm and in the LPRng Howto (file:/usr/share/doc/packages/lprng/LPRng-HOWTO.html#LPRM (local copy)).
The command lpc option <queuename> displays the status of the specified queue and allows changing it. The most important options are:
SuSE @nohyphen root permissions are required to control printer queues with the above commands. Options can be supplied to lpc directly on the command line (as in lpc status all). You can also run the program without any options, which starts it in dialog mode -- it opens the lpc> command prompt. Then enter the options at the prompt. To leave the program, enter either quit or exit.
If you were to enter lpc status all, the output could look like this:
Printer Printing Spooling Jobs Server Subserver lp@earth enabled enabled 2 123 456 color@earth disabled disabled 0 none none laser@earth disabled enabled 8 none none
This gives the following information: Queue lp is completely enabled and holds two print jobs, one of which is being printed at the moment. Queue color, on the other hand, is completely stopped. Finally, the laser queue does not print at the moment, but jobs (there are currently eight of them) are still accepted for the queue and are accumulating in the spooler.
Further information can be obtained from lpc and the LPRng Howto (file:/usr/share/doc/packages/lprng/LPRng-HOWTO.html#LPC (local copy)).
For each of the commands explained below, replace <printserver> with the name or IP address of your print server. <queuename> must be a queue on the print server.
With the LPRng spooler, even remote queues can be addressed directly, using the lpr command with the syntax lpr -P<queuename>@<printserver> <file>. This is only possible if the print server is configured to accept remote print jobs on its queues. This is enabled by default with LPRng.
Check the status of a queue on a remote host by entering:
and
To list the names of and display status information on all queues of a print server, use either lpq -s -Pall@<printserver> or lpc status all@<printserver>, provided that LPRng is used on the print server.
If printing over a remote queue does not work, querying the status of the queues helps determine the cause of the problem. If LPRng is installed on the print server, enter lpq -L -P<queuename>@<printserver> to get a detailed status report for remote diagnosis.
With the following command delete all print jobs in remote queues that have been issued under your user name:
SuSE @nohyphen root has no special privileges on remote queues. The parameter all only works if LPRng is used on the print server host as well.
Print jobs are kept in the queue even if you shut down a machine during a printout so are still there after rebooting. To remove a faulty print job, use the commands described above. Rebooting will not remove them.
For example, it sometimes happens that the host-to-printer connection suffers some kind of fault, after which the printer is unable to interpret data correctly. This can cause it to spit out large amounts of paper with meaningless characters on it.
The print filter used in conjunction with LPRng is lpdfilter, which is installed as a package with the same name. The following is a detailed description of the steps involved in processing a print job. If you need to know about the inner workings of the print filter, read the scripts powering it (in particular, /usr/lib/lpdfilter/bin/if) and probably also follow the steps described in 6.
Ghostscript-relevant parameters are stored either in the cm line of /etc/printcap or in the file /etc/lpdfilter/<queuename>/upp (where <queuename> is the name of the actual queue to use).
If so desired, the Ghostscript output can be reformatted again, if a suitable script is placed in /etc/lpdfilter/<queuename>/post (where <queuename> is the name of the actual queue to use).
Normally, the printing system is configured with YaST (as described in 6), which includes the setup of lpdfilter.
Some of the more special settings, however, can only be changed by editing the configuration files of the print filter by hand. For each queue, a dedicated configuration file is written to /etc/lpdfilter/<queuename>/conf (where <queuename> is the name of the actual queue to be used).
If a suitable script is placed in /etc/lpdfilter/<queuename>/type2ps, it will be used for the PostScript conversion of the file. The script must be able to accept data on stdin and to output data in PostScript format on stdout.
For the purposes of this example, suppose there is a queue called testqueue, which should be configured so ASCII text is printed with line numbers along the left margin. Apart from that, all files should be printed with two pages scaled to fit on one sheet. The scripts /etc/lpdfilter/testqueue/ascii2ps and /etc/lpdfilter/testqueue/pre, as shown below, would achieve that:
#!/bin/bash
cat -n - | a2ps -1 --stdin=' ' -o -
#!/bin/bash
pstops -q '2:0L@0.6(20cm,2cm)+1L@0.6(20cm,15cm)'
These scripts need to be made executable for all users, which can be achieved with the chmod command:
Reformatting files with pstops only works with PostScript files created to allow such transformations, as is usually the case.
PostScript preloads are small files containing PostScript commands that preceed the print data stream to initialize the printer or the Ghostscript program in the desired way. PostScript preloads are mostly used to enable duplex printing on PostScript printers or to activate a special paper tray. They can also be used for margin and gamma adjustments.
To use preloads, the PostScript printer or Ghostscript must be able to interpret the special commands. Ghostscript, for instance, does not interpret commands related to duplex printing or paper trays.
For this example, the queue testqueue is again used:
%!PS
statusdict /setduplexmode known
{statusdict begin true setduplexmode end} if {} pop
%!PS
statusdict /setduplexmode known
{statusdict begin false setduplexmode end} if {} pop
The following PostScript code can be used to revolve the back by 180 degrees for duplex printing:
![\includegraphics[width=0.900\linewidth]{print_overview}](img19.png)
%!PS
statusdict /setduplexmode known
{statusdict begin true setduplexmode end} if {} pop
statusdict /settumble known
{statusdict begin true settumble end} if {} pop
%!PS
statusdict /setpapertray known
{statusdict begin 0 setpapertray end} if {} pop
%!PS
statusdict /setpapertray known
{statusdict begin 2 setpapertray end} if {} pop
%!PS
<<
/.HWMargins [left bottom right top]
/PageSize [width height]
/Margins [left-offset top-offset]
>>
setpagedevice
The margin settings left, bottom, right, and top and the paper size measures width and height are specified in points (with one point equaling 1/72 inches or about 0.35 mm). The margin offsets left-offset and top-offset are specified in pixels, so depend on the resolution of the output device.
To change only the position of the printed area, it is sufficient to create a file like /etc/lpdfilter/testqueue/offset.ps.
%!PS
<< /Margins [left-offset top-offset] >> setpagedevice
%!PS
{cyan exp} {magenta exp} {yellow exp} {black exp}
setcolortransfer
%!PS
{red exp} {green exp} {blue exp} currenttransfer
setcolortransfer
You need to know which color model is used by your printer (either CMYK or RGB) to make this work. The values to use for cyan, magenta, yellow, and black or for red, green, and blue should be determined through testing. Normally, these should be in the range between 0.001 and 9.999.
To get a rough idea of the effect of the above filtering actions on the output, display them on screen. To see how a sample file looks without gamma correction, enter:
To see how it looks with gamma correction according to the above sample filters:
End the test by pressing + C.
%!PS
serverdict begin 0 exitserver
To activate one of the above PostScript preloads, create a file similar to /etc/lpdfilter/testqueue/pre:
#!/bin/bash
cat /etc/lpdfilter/testqueue/preload.ps -
In this file, replace preload.ps with the name of your custom preload file. In addition, make this script executable and readable for all users, which can be achieved with chmod in the following way:
Use the mechanism described above to insert PostScript commands not only before the print data, but also after it. For instance, with a script like /etc/lpdfilter/testqueue/pre, reset the printer to its original state after each print job is finished:
#!/bin/sbash
cat /etc/lpdfilter/test/preload.ps - /etc/lpdfilter/test/reset.ps
This section provides an example for the customized configuration of a gdi print queue. As explained in 6, it is often nearly impossible to make such printers run under Linux. However, special driver programs are available for some GDI models. In most cases, they are designed to run as Ghostscript add-ons with the driver reformatting the Ghostscript output into the printer's own language. Often these drivers make limited use of the printer's functionality, however, allowing only black-and-white printing, for example. If such a driver is available, Ghostscript can be used with it in the following way (also see 6):
For the steps described below, it is assumed that a GDI printer driver suitable for SuSE Linux is already installed or can be downloaded from the Internet. It is also assumed that the driver works in the way described above. In some cases, you may need some familiarity with the way source code is handled under Unix or how to handle these installations (from .zip or .tar.gz archives or maybe from .rpm packages).
After unpacking such an archive, you will often find the latest installation instructions included in some of the files, typically in README or INSTALL, or even in a doc subdirectory. If you have downloaded a .tar.gz archive, you usually need to compile and install the driver yourself.
For the purposes of the example explained below, the following setup is assumed:
The Ghostscript driver and the resolution may be different for your printer. Read the documentation included with the driver to find out about these.
First, create the gdi queue. To do so, log in as SuSE @nohyphen root and run lprsetup, as follows:
Now, create the script /etc/lpdfilter/gdi/post:
Read the documentation of the driver program to find out what options exist for it. Specify them under <gdi_driver_parameters> as needed. Make the script executable for all users and restart the print spooler:
From now on, users should be able to print with this command:
Enable different debug levels for lpdfilter by uncommenting (removing the `#' sign in front of) the corresponding line of the main filter script /usr/lib/lpdfilter/bin/if.
# DEBUG="off"
# DEBUG="low"
# DEBUG="medium"
# DEBUG="high"
With DEBUG="low" enabled, the program logs its stderr output to the file /tmp/lpdfilter.if-$$.XXXXXX (where $$ is the process ID and XXXXXX a unique random string).
With DEBUG="medium" enabled, the program logs, in addition to its own error output, the stderr output of the scripts in /usr/lib/lpdfilter/filter if these scripts are run by /usr/lib/lpdfilter/bin/if. The debugging output is written to /tmp/lpdfilter.name-$$.XXXXXX (where name is the name of the script run and $$.XXXXXX a string composed in the way described above).
With DEBUG="high" enabled, all error output is logged as above. Additionally, all output normally destined to the printer is redirected to a log file named /tmp/lpdfilter.out-$$.XXXXXX (where $$.XXXXXX is a string composed in the way described above).
To avoid losing control over the logging activity, you may want to remove the log files with rm -v /tmp/lpdfilter* before each new test run.
Client or client program refers to a program that sends print jobs to a print daemon. A print daemon is a local service that accepts print jobs either to forward them or to process them locally. Server refers to a daemon able to deliver print data to one or more printers. Each server functions as a daemon at the same time. In most cases, however, there is no special distinction to make between a server and a daemon, neither from the developer or from the user standpoint.
Print jobs are sent to servers by CUPS-based programs, such as lpr, kprinter, or xpp, and with the help of the Internet Printing Protocol, IPP. IPP is defined in RFC-2910 and RFC-2911 (see http://www.rfc-editor.org/rfc.html). IPP is somewhat similar to HTTP with identical headers but different content data. It also uses its own dedicated communication port 631, which has been registered with IANA (the Internet Authority for Number Allocation).
Print data is transferred to a CUPS daemon, which is also acting as a local server in most cases. Other daemons can be addressed using the environment variable CUPS_SERVER.
With the help of the broadcast function of the CUPS daemon, locally managed printers can be made available elsewhere in the network (using UDP port 631). They then appear as print queues on all other daemons configured to accept and use these broadcast packets. This makes it possible to ``see'' printers on other hosts after booting without configuring them locally, something that may be quite useful in corporate networks. On the other hand, this feature may pose a security risk if the host is connected to the Internet. When enabling printer broadcasting, make sure the daemon broadcasts into the local network only, access is limited to clients on the LAN, and the public IP address (the one used for the Internet connection) is not within the local IP range. Otherwise, remote users relying on the same ISP would be able to ``see'' and use the broadcast printers as well. In addition to that, such broadcasts mean more network traffic so may increase connection costs. Prevent a local printer from broadcasting IPP packets into the Internet by configuring the SuSE Firewall (package SuSEfirewall2) accordingly. No extra configuration is needed to receive broadcast IPP packets. A broadcast address must only be specified for outgoing print jobs. This may be configured with YaST , for example.
IPP is used for the communication between a local and a remote CUPS daemon or server. More recent network printers also have built-in support for this protocol (there are a number of models from different makers). Find more information about this on the web pages of manufacturers or in your printer's manual. IPP is also supported by Windows 2000 and newer Microsoft systems, although originally the implementation was somewhat flawed. These problems may have disappeared or it may be necessary to install a Service Pack to repair them.
There are many ways to set up a printer with CUPS and to configure the daemon: with command-line tools, with YaST , with the KDE Control Center, or even through a web browser interface. The following sections are limited to the command-line tools and YaST .
Caution
When using the web browser interface for CUPS configuration,
be aware that there is a risk of compromising the SuSE @nohyphen root
password. The password will be transmitted as plain text if the URL
specified includes the real host name. Therefore, you should always
use http://localhost:631/ as the host address.
For the above reason, the CUPS daemon can only be accessed for administration if addressed as localhost (which is identical to the IP address 127.0.0.1) by default. Entering a different address returns an error message, even if it is valid.
To configure a locally connected printer, first set up a CUPS daemon on the local host. To do so, install package cups together with the PPD files provided by SuSE as included in package cups-drivers and package cups-drivers-stp. After that, start the server as SuSE @nohyphen root with the command /etc/rc.d/cups restart. If you configure it with YaST , the above steps are already covered by selecting CUPS as the printing system and installing a printer.
PPD (PostScript Printer Description) files contain options for printer models in the form of a standard set of PostScript commands. They are required for printer installation under CUPS. SuSE Linux comes with precompiled PPD files for many printers from a number of manufacturers. Manufacturers may also offer PPD files for their PostScript printers on web sites and installation CDs (often in an area called something like ``Windows NT Installation'').
The local daemon can also b started so printers of all broadcasting servers are available locally, although there is no local printer. This facilitates the use of these printers from within KDE applications and OpenOffice.org, for example.
Broadcasting can be enabled either with YaST . Alternatively, enable it by setting the Browsing directive to On (the default) and the BrowseAddress directive to a sensible value, like 192.168.255.255, in the file /etc/cups/cupsd.conf. After that, tell the CUPS daemon explicitly to grant access to incoming packets, either under <Location /printers> or, preferably, under <Location />, where you would have to include a line like Allow From some-host.mydomain (see file:/usr/share/doc/packages/cups/sam.html (local copy)). When finished editing the file, tell the daemon to reread its configuration by entering the command /etc/rc.d/cups reload as SuSE @nohyphen root.
Network printers are printers that have a built-in print server interface (such as the JetDirect interface in some HP printers) or printers connected to a print server box or a router box enabled as a print server. Windows machines offering printer shares are not print servers in the strict sense (although CUPS can handle them easily in a way similar to print servers).
In most cases, a network printer supports the LPD protocol, which uses port 515 for communication. Check lpd availability with the command:
If such a server is available, CUPS can be configured to access it under a device URI, an address in the form lpd://server/queue. Read about the concept of device URIs in file:/usr/share/doc/packages/cups/sam.html (local copy).
However, you should probably not use the LPD protocol for a network printer, but rather the printer's built-in port 9100 if available (HP, Kyocera, and many others) or port 35 (QMS). In this case, the device URI must have the form as follows:
socket://Server:Port/
To use printers made available through Windows, install package samba-client first and configure this package -- enable the correct work group and make other settings. A device URI for Windows printers may be specified in several ways, but the most frequent one has the syntax smb://user:password@host/printer. For other configurations, see file:/usr/share/doc/packages/cups/sam.html (local copy)and smbspool.
If you have a small network consisting of several (Linux) machines and have set up a print server for it, avoid configuring the printer for each and every client host by enabling the broadcast function of the daemon (see above). Thus, when you modify the configuration (for instance, to use the new standard paper size Letter), it is sufficient to do this once on the server side (also see 6). Although the configuration is saved locally on the server side, it is propagated to all clients in the network with the help of the CUPS tools and the IPP protocol.
Basically the CUPS daemon should be able to handle any file type, although PostScript is always the safest bet. CUPS processes non-PostScript files by identifying the file type according to /etc/cups/mime.types first then converting the file into PostScript by calling the appropriate conversion tool for it as defined in /etc/cups/mime.convs. With CUPS, files are converted into PostScript on the server side rather than on the client side. This feature was introduced to ensure that special conversion operations necessary for a particular printer model are only performed on the corresponding server machine.
After conversion into PostScript, CUPS calculates the number of pages for each print job. This is done with the help of pstops (an internal version of the program located at /usr/lib/cups/filter/pstops). The accounting data for print jobs are written to /var/log/cups/page_log. Each line in this file contains the following information:
CUPS can also use other, special filters, if the corresponding printing options have been enabled. These are the most important ones:
Read file:/usr/share/doc/packages/cups/sum.html (local copy) for information about how to enable the various options.
The next step is the launch of the filter needed for generating printer-specific data. These filters are located in /usr/lib/cups/filter/. The suitable filter is determined in the PPD file in the *cupsFilter entry. If this entry does not exist, the print system assumes that the printer is a PostScript model. All device-specific printing options, such as the resolution and paper size, are processed in this filter.
Writing a custom printer-specific filter script is not a trivial task; see the SDB article Using Your Own Filters to Print with CUPS (keywords: ``cups'' + ``filter'').
As the final step, CUPS calls one of its back-ends. A back-end is a special filter that transfers print data to a device or to a network printer (see file:/usr/share/doc/packages/cups/overview.html (local copy)). The back-end maintains the communication with the device or network printer (as specified through a device URI during configuration). If the back-end is usb, for example, CUPS runs /usr/lib/cups/backend/usb, which in turn opens (and locks) the corresponding USB device file, initializes it, and passes the data coming from the print filter. When the job is finished, the back-end closes the device and unlocks it.
The following back-ends are currently available: parallel, serial, usb, ipp, lpd, http, socket (included in package cups). Also available are canon and epson, included in cups-drivers-stp, and smb, included in samba-client.
To print files without any filtering, use the lpr command with -l or use the lp command with the -oraw option. Usually, the printout will not work, as no printer-specific conversion is performed or other important filters are omitted. The options are similar for other CUPS tools.
When printing from OpenOffice.org applications, CUPS is supported such that a running CUPS daemon is autodetected and queried for available printers and options (this is different from StarOffice 5.2, where it was still necessary to perform a setup for each printer). An extra CUPS setup from within OpenOffice.org should not be necessary.
Printers connected to a Windows machine can be addressed through a device URI, such as smb://server/printer. To print from a Windows machine to a CUPS server, set the entries printing = CUPS and printcap name = CUPS in the Samba configuration file /etc/samba/smb.conf (this is preset in SuSE Linux ). Following modifications in /etc/samba/smb.conf, the Samba server must be restarted. See file:/usr/share/doc/packages/cups/sam.html (local copy) for details.
A raw printer can be set up by leaving out the PPD file during configuration, which effectively removes all filtering and accounting features from CUPS. For this purpose, the data must be sent in the printer-specific data format.
The configuration options, such as a different default resolution, can be modified and saved for each user. The configuration is saved in the file /.lpoptions. If such a reconfigured printer is removed on the server side, it will still be visible in various tools, such as kprinter and xpp. You can still select it even if it no longer exists, which causes problems. Experienced users can easily remove the superfluous lines from /.lpoptions with an editor. Refer to the Support Database article Print Settings with CUPS.
CUPS can also receive print jobs from LPR systems. The needed configuration in /etc/xinetd.d/cups-lpd can be handled manually or with YaST .
By default, the configuration file /etc/cups/cupsd.conf contains the following section:
# LogLevel: controls the number of messages logged to the ErrorLog file # and can be one of the following: # # debug2 Log everything. # debug Log almost everything. # info Log all requests and state changes. # warn Log errors and warnings. # error Log only errors. # none Log nothing. # LogLevel info
To detect errors in CUPS, set LogLevel debug and use rccups reload to have cupsd use the modified configuration file. Subsequently, /var/log/cups/error_log will contain detailed messages that assist in detecting the cause of problems.
With the following command print a label before starting to run the test:
echo "LABEL $(date)" | tee -a /var/log/cups/error_log
This label will be entered in /var/log/cups/error_log. This makes it easier to find the messages after the test.
Applications use the existing queues for printing from the command line. In applications, printer options are not configured directly, but rather through the existing queues.
Because package cups-client includes some command-line tools to print with CUPS, such as lpr command, applications can use the lpr command for printing (e.g. , lpr -Plp or lpr -Pcolor). However, to be able to enter print commands, the print dialog in KDE has to be set to ` Print through an external program'. See 6.
In addition, graphical printer dialog programs such as xpp or the KDE program kprinter allow you to select a queue and modify standard CUPS options and printer-specific options in the PPD file by means of graphical selection menus. In order to use kprinter as the default print dialog for various applications, enter the print command kprinter or kprinter -stdin in the print dialog of the applications. Subsequently, whenever you enter the application-specific print command, the kprinter dialog will be displayed after the print dialog of the application, allowing you to specify the queue and other options. When using this approach, make sure there is no conflict between the settings in the print dialog of the application and those in kprinter. If possible, print settings should only be specified in kprinter.
The command-line tools of the CUPS printing system and their manual pages are included in package cups-client. Further documentation is provided by the package cups and installed in /usr/share/doc/packages/cups, in particular the CUPS Software Users Manual, found at /usr/share/doc/packages/cups/sum.html and the CUPS Software Administrators Manual at /usr/share/doc/packages/cups/sam.html. If a CUPS daemon runs locally on your host, you should also be able to access the documentation at http://localhost:631/documentation.html.
As a general rule, it is useful to remember that CUPS command-line tools sometimes require options be supplied in a certain order. Consult the corresponding manual pages if you are unsure about specific options.
To print a file, enter the ``System V style'' print command lp -d <queuename> <file> or a ``Berkeley style'' command like lpr -P<queuename> <file>.
Additional information can be obtained with lpr and lp, as well as in the section ``Using the Printing System'' of the CUPS Software Users Manual (file:/usr/share/doc/packages/cups/sum.html#USING_SYSTEM (local copy)).
The -o parameter allows specification of a number of important options, some of which directly influence the type of printout. More information is available in lpr and lp as well as in the section ``Standard Printer Options'' of the CUPS Software Users Manual (file:/usr/share/doc/packages/cups/sum.html#STANDARD_OPTIONS (local copy)).
To check the status of a queue, enter the ``System V style'' command lpstat -o <queuename> -p <queuename> or the ``Berkeley style'' command lpq -P<queuename>.
If you do not specify a queue name, the commands will display information on all queues. With lpstat -o, the output will show all active print jobs in the form of a <queuename>-<jobnumber> listing.
With lpstat -l -o <queuename> -p <queuename>, the output is more verbose. lpstat -t or lpstat -l -t displays the maximum amount of available information.
For additional information, consult lpq, lpstat, and the section ``Using the Printing System'' of the CUPS Software Users Manual (file:/usr/share/doc/packages/cups/sum.html#USING_SYSTEM (local copy)).
Enter the ``System V style'' command cancel <queuename>-<queuename> or the ``Berkeley style'' command lprm -P<queuename> <queuename> to remove the job with the specified number from the specified queue. For additional information, consult lprm, cancel, and the section ``Using the Printing System'' of the CUPS Software Users Manual (file:/usr/share/doc/packages/cups/sum.html#USING_SYSTEM (local copy)).
To see how to specify hardware-independent options that affect the type of printout, read the section ``Standard Printer Options'' in the CUPS Software Users Manual (file:/usr/share/doc/packages/cups/sum.html#STANDARD_OPTIONS (local copy)). The section ``Saving Printer Options and Defaults'', which is found at file:/usr/share/doc/packages/cups/sum.html#SAVING_OPTIONS (local copy), explains how to save option settings.
Printer-specific options affecting the type of printout are stored in the PPD file for the queue in question. They can be listed with the command lpoptions -p <queuename> -l. The output has the following form:
option/text: value value value ...
The currently active setting is marked with an asterisk (`*') to the left, for example:
PageSize/Page Size: A3 *A4 A5 Legal Letter Resolution/Resolution: 150 *300 600
According to the above output, the PageSize is set to A4 and the Resolution to 300 dpi.
The command lpoptions -p <queuename> -o option=value changes the value for the given option.
With the above sample settings in mind, use the following command to set the paper size for the specified queue to Letter:
If the above lpoptions command is entered by a normal user, the new settings are stored for that user only in the file /.lpoptions.
By contrast, if the lpoptions command is entered by SuSE @nohyphen root, the settings specified are stored in /etc/cups/lpoptions and become the default for all local users of the queue. The PPD file is not touched by this, however.
If (and only if) you change the contents of a PPD file for a given queue, the new settings apply to all users in the local network who print through this queue. The system administrator can change the defaults of a PPD file with a command like:
For more information, refer to the Support knowledgebase article Print Settings with CUPS.
For each of the commands explained below, replace <printserver> with the name or IP address of your print server. <queuename> must be a queue on the print server.
This section merely covers the basic commands. Additional options and information sources are referred to in 6.
You can use the ``System V style'' command
lp -d
<queuename> -h <printserver> <file> to
generate a print job for the specified queue on the specified print
server This is only possible if the print server was configured to
accept remote print jobs on its queues. This is not enabled by default
in CUPS, but can easily be configured in the CUPS server settings in a
submenu of the YaST printer configuration module.
Check the status of a queue on the print server with the ``System V
style'' command
lpstat -h <printserver> -o
<queuename> -p <queuename>.
The ``System V style'' command cancel -h <printserver> <queuename>-<jobnumber> removes the print job with the specified job number from the specified queue on the print server.
In the case of a broken print job, the troubleshooting procedure is basically the same as the one described in 6, with the difference that CUPS requires different commands for the second step:
Ghostscript is a program that accepts PostScript and PDF files as input then converts them into several other formats. Ghostscript includes a number of drivers to achieve this. These are sometimes also referred to as ``devices.''
Ghostscript converts files in two steps:
Ghostscript can also process PostScript files to display them on screen or convert them into PDF documents. To display PostScript files on screen, you should probably use the program gv (rather than relying on bare Ghostscript commands), which gives a more convenient graphical interface.
Ghostscript is a very big program package and has a number of command-line options. Apart from the information available with the gs, the most important part of the documentation is the list of Ghostscript drivers, which is found in:
file:/usr/share/doc/packages/ghostscript/catalog.devices (local copy) and the files:
file:/usr/share/doc/packages/ghostscript/doc/index.html (local copy)
file:/usr/share/doc/packages/ghostscript/doc/Use.htm (local copy)
file:/usr/share/doc/packages/ghostscript/doc/Devices.htm (local copy)
file:/usr/share/doc/packages/ghostscript/doc/hpdj/gs-hpdj.txt (local copy)
file:/usr/share/doc/packages/ghostscript/doc/hpijs/hpijs_readme.html
file:/usr/share/doc/packages/ghostscript/doc/stp/README (local copy)
When executed from the command line, Ghostscript processes any options then presents its own GS> prompt. Exit from this dialog mode by entering quit.
If you enter gs -h, Ghostscript displays its most important options and lists the available drivers. This listing, however, only includes generic driver names, even for drivers that support many different models, such as uniprint or stp. The parameter files for uniprint and the models supported by stp are explicitly named in file:/usr/share/doc/packages/ghostscript/catalog.devices (local copy).
Find a number of PostScript examples in the directory file:/usr/share/doc/packages/ghostscript/examples (local copy). The color circle in file:/usr/share/doc/packages/ghostscript/examples/colorcir.ps is well suited for test printouts.
Under X, the graphical environment, use gs to view a PostScript file on screen. To do so, enter the following command as a single line, omitting the backslash (`\'):
In the above command, the -r option specifies the resolution, which must be appropriate for the output device (printer or screen). Test the effect of this option by specifying a different value, for example, -r30. To close the PostScript window, press + C in the terminal window from which gs was started.
The conversion of a PostScript file into the printer-specific format of a PCL5e or PCL6 printer can be achieved with a command like
Again, the command must be entered as a single line and without any backslash (`\'). With this command, it is assumed that the file /tmp/out.prn does not exist yet.
The conversion of a PostScript file into the printer-specific format for a PCL3 printer can be achieved with a command such as the following:
Depending on the model, you can replace <deskjet> with cdjmomo, cdj500, or cdj550 or use the alternative driver hpdj:
The individual commands can also be entered without `\' in a single line.
These are some sample commands to convert a PostScript file into the printer-specific format of an ESC/P2, ESC/P, or ESC/P raster printer.
The above commands also show that the uniprint Ghostscript driver, which is called through a parameter file (stcany.upp in our example), requires a different command syntax than ``regular'' Ghostscript drivers. Because all driver options are stored in the uniprint parameter file, they do not have to be specified on the Ghostscript command line itself.
With each of the above commands, the output is written in the corresponding printer language and stored in the file /tmp/out.prn. This file can be sent directly to the printer by SuSE @nohyphen root without the use of a print spooler or any filtering. For a printer connected to the first parallel port, this can be achieved with the command cat /tmp/out.prn >/dev/lp0.
Ghostscript can generate PostScript and PDF files, convert both formats to each other, and even merge PostScript and PDF files in mixed order.
Conversion from PostScript to PDF:
Conversion of the generated PDF file /tmp/colorcir.pdf to PostScript:
Following the reconversion from PDF to PostScript, the file /tmp/colorcir.ps does not match the original file /usr/share/doc/packages/ghostscript/examples/colorcir.ps. However, there should be no visible difference in the printout.
Merging PostScript and PDF files into a PostScript file:
Merging PostScript and PDF files into a PDF file:
Depending on the files you use, it may not be possible to merge some PostScript and PDF files.
Before an ASCII file can be printed through Ghostscript, it needs to be converted into PostScript, because this is the input format that Ghostscript expects. This conversion can be achieved with a2ps ( package a2ps package). As package a2ps is not installed by default, you will normally have to install it yourself.
The a2ps program is a powerful, versatile tool that lets you convert simple text files into high-quality PostScript output. It has a large number of command-line options. Learn about these in a2ps or read the full documentation of a2ps as an info page.
As a first example, a2ps can be used to convert a text file into PostScript, with two pages scaled down so they fit on one sheet. This can be achieved with the command:
The output of a2ps can then be displayed under X with
to get a preview of the printout. If the printout is more than one sheet, hit in the terminal window from which gs was started to scroll down to the next page. To exit gs, enter + C.
Take the output of a2ps and convert it into your printer's language by entering:
In the above command, specify your own driver parameters under <driverparameters> as described in the previous section.
As SuSE @nohyphen root, you can send the output of Ghostscript directly to the printer without relying on a spooler or any further filtering with the command
It is assumed here that the printer is connected to the first parallel port (/dev/lp0).
To use one of the reformatting programs described below, generate a PostScript input file by printing to a file, such as /tmp/in.ps, from within an application. Check with file /tmp/in.ps to see whether the generated file is really in PostScript format.
The package psutils includes a number of programs to reformat PostScript documents. The program pstops, in particular, allows you to perform extensive transformations.
Details can be obtained in pstops. The package psutils is not included in the standard setup of SuSE Linux , so you may need to install it.
The following commands only work if the application program has created a PostScript file appropriate for such reformatting operations. This should mostly be the case, but there are some applications that cannot generate PostScript files in the required way.
The command psnup -2 /tmp/in.ps /tmp/out.ps takes /tmp/in.ps as its input and transforms it into the output file /tmp/out.ps in such a way that two pages are printed side by side on one sheet. However, with the contents of two pages being included on one, the complexity of the resulting document is much higher and some PostScript printers may fail to print it, especially if they are equipped with only a small amount of standard memory.
The program pstops allows you to change the size and positioning of PostScript documents:
This command scales the document by a factor of 0.8, which effectively scales down an A4 page from about 21x30 cm to about 17x24 cm. This, in turn, leaves an additional margin of about 4 cm on the right and 6 cm on the top. Therefore, the document is also shifted by 2 cm towards the right and 3 cm towards the top to get roughly the same margins everywhere.
This pstops command shrinks the page by quite an amount and also provides for relatively wide margins, so it should generate a page that is almost always printable -- even with those applications that are far too optimistic about the limits set by your printer. You can use a command like the above for those cases where the application's printer output in /etc/in.ps is too large for the printable area.
As another example:
These commands place two heavily scaled-down pages on one sheet, leaving quite a lot of space between them. To improve this, include instructions to position each of the pages individually:
The above command must be entered as a single line without the `\'.
The following is a step-by-step explanation of the page specifications as expressed by pstops '2:0L@0.6(20cm,2cm)+1L@0.6(20cm,15cm)':
In the case of PostScript files, the origin of the coordinates is located in the bottom left corner of a page in normal orientation, as indicated by the `+' (see Figure 6.2):
psselect enables the selection of individual pages. With psselect -p2-5 /tmp/in.ps /tmp/out.ps, pages 2, 3, 4, and 5 are selected from /tmp/in.ps and written to /tmp/out.ps. The command psselect -p-3 /tmp/in.ps /tmp/out.ps selects all pages up to page 3. The command psselect -r -p4- /tmp/in.ps /tmp/out.ps selects the pages from page 4 to the last page and prints them in reverse order.
On a graphical display, the PostScript file /tmp/out.ps can be viewed with gs -r60 /tmp/out.ps. Scroll through the pages by pressing in the terminal window from which you started Ghostscript. Terminate with + C.
As a graphical front-end for Ghostscript, use gv. To view the above-mentioned output file, for example, enter gv /tmp/out.ps. The program is especially useful whenever there is a need to zoom in or out on a document or to view it in landscape orientation (although this has no effect on the file contents). It can also be used to select individual pages, which can then be printed directly from within gv.
In plain text files, each character is represented as a certain numeric code. Characters and their matching codes are defined in code tables. Depending on the code tables used by an application and by the print filter, the same code may be represented as one character on the screen and as another one when printed.
Standard character sets only comprise the range from code 0 to code 255. Of these, codes 0 through 127 represent the pure ASCII set, which is identical for every encoding. It comprises all ``normal'' letters as well as digits and some special characters, but none of the country-specific special characters. Codes 128 through 255 of the ASCII set are reserved for country-specific special characters, such as umlauts.
However, the number of special characters in different languages is much larger than 128. Therefore, codes 128 to 255 are not the same for each country. Rather, the same code may represent different country-specific characters, depending on the language used.
The codes for Western European languages are defined by ISO-8859-1 (also called Latin 1). The ISO-8859-2 encoding (Latin 2) defines the character sets for Central and Eastern European languages. Code 241 (octal), for example, is defined as the (Spanish) inverted exclamation mark in ISO-8859-1, but the same code 241 is defined as an uppercase A with an ogonek in ISO-8859-2. The ISO-8859-15 encoding is basically the same as ISO-8859-1, but, among other things, it includes the Euro currency sign, defined as code 244 (octal).
The commands below must be entered as a single line without any of the backslashes (`\') at the end of displayed lines.
Create a sample text file with:
echo -en "\rCode 241(octal): \ \241\r\nCode 244(octal): \244\r\f" >example
Under X, enter these commands to open three terminals:
xterm -fn -*-*-*-*-*-*-14-*-*-*-*-*-iso8859-1 -title iso8859-1 & xterm -fn -*-*-*-*-*-*-14-*-*-*-*-*-iso8859-15 -title iso8859-15 & xterm -fn -*-*-*-*-*-*-14-*-*-*-*-*-iso8859-2 -title iso8859-2 &
Use the terminals to display the sample file in each of them with cat example.
The ``iso8859-1'' terminal should display code 241 as the inverted (Spanish) exclamation mark and code 244 as the general currency symbol.
The ``iso8859-15'' terminal should display code 241 as the inverted (Spanish) exclamation mark and code 244 as the Euro symbol.
The ``iso8859-2'' terminal should display code 241 as an uppercase A with an ogonek and code 244 as the general currency symbol.
Due to the fact that character encodings are defined as fixed sets, it is not possible to combine all the different country-specific characters with each other in an arbitrary way. For example, the A with an ogonek cannot be used together with the Euro symbol in the same text file.
To obtain more information (including a correct representation of each character), consult the corresponding man page in each terminal -- iso_8859-1 in the ``iso8859-1'' terminal, iso_8859-15 in the ``iso8859-15'' terminal, and iso_8859-2 in the ``iso8859-2'' terminal.
When printed, ASCII text files, such as the example file, are treated in a similar way according to the encoding set for the print queue used. However, word processor documents should not be affected by this, because their print output is in PostScript format (not ASCII).
Consequently, when printing the above example file, characters are represented according to the encoding set for ASCII files in your printing system. You can also convert the text file into PostScript beforehand to change the character encoding as needed. The following a2ps commands achieves this for the example file:
When printing the files example-ISO-8859-1.ps, example-ISO-8859-15.ps, and example-ISO-8859-2.ps, the files are printed with the encoding determined with a2ps.
Find extensive documentation about the LPRng printing system in the LPRng-Howto in /usr/share/doc/packages/lprng/LPRng-HOWTO.html (local copy) and on the CUPS printing system in the CUPS Software Administrators Manual in /usr/share/doc/packages/cups/sam.html (local copy).
There is an important distinction to be made between a network printer or a print server box on the one hand and a true print server on the other. As a somewhat special case, there are large printer devices that have a complete print server included with them to make them network-capable. These are treated like print servers because clients will talk to the printer only through the server and not directly.
Usually, client machines in a network do not have any locally connected printers. Rather, the client sends print jobs to a print server. If you have a print server and an additional local printer is connected to the client, you need a client configuration as well as a configuration for the local printer. The print system on the client machine should be selected in accordance with the print system on the print server.
If there is no CUPS network server in the network, but only an LPD server, use the LPRng and lpdfilter print system on the client. In this case, the client machine does not require any further configuration, as even remote queues can be addressed directly when using the LPRng spooler. See 6.
However, this is only possible if the LPD server was configured to
allow the client to print to its queues. To print from
applications, enter
lpr
-P<queuename>@<printserver>
in the
application. This corresponds to the procedure described in
6. However, no file name
is specified.
Some applications are preconfigured to use CUPS and must be switched to LPRng. Especially KDE and the KDE printing program kprinter must be set to ` Print through an external program'. If this is not done, it will not be possible to enter the print command.
If the print server is a CUPS network server, start the YaST printer configuration module, click ` Change' then ` Advanced' and select one of the following options:
The client machine does not require any further configuration, as a CUPS network server broadcasts its queues to all network hosts at regular intervals. Therefore, the queues of the network server will automatically be available on the client machine after a short time.
However, this is only possible if the broadcasting function is enabled on the CUPS network server, the broadcast address used is suitable for the client machine, and the client machine is permitted to print to the queues of the CUPS network server.
In this mode, the client machine does not run cupsd and the file /etc/printcap does not exist. However, applications that cannot be configured to use CUPS will only offer the queues listed in the local /etc/printcap. In this case, it is advisable to run CUPS in server mode, as the local cupsd will automatically generate an /etc/printcap containing the queue names of the CUPS network server.
The following lists the different methods that can be used to implement printing on a TCP/IP network. The decision of which one to use does not so much depend on the hardware, but more on the possibilities offered by each protocol. Accordingly, the YaST printer configuration asks you to select a protocol and not a hardware device when setting up network printing.
Nevertheless, the first step in the printer configuration with YaST is the selection of the hardware category for printing (e.g., via CUPS network server, via LPD network server, or direct printing on a network printer or print server box). Accordingly, available protocols are offered for selection. The protocol that should work in most cases is preselected. If only one protocol is possible, there is no selection. Examples:
Data can only be transmitted from the sender to the recipient if both parties support the respective protocol. the software running on the sender and recipient must support the respective protocol.
Ultimately, it does not matter which kind of hardware and software is used, as long as both the sender and the recipient support the respective protocol. Depending on the protocol, print jobs or raw data are transmitted.
Apart from the print data, a print job contains additional information such as the user on whose host the print job was generated as well as any special print options (such as the paper size to use for printing, duplex mode, and so on).
The sender sends a print job to a queue on the recipient via the LPD protocol. According to the LPD protocol, the recipient is expected to receive print jobs on port 515. Therefore, a service receiving the print jobs on port 515 (normally this service is called lpd) and a queue in which received print jobs can be placed are needed on the receiving host.
The sender sends a print job to the queue on the recipient via the IPP protocol. According to the IPP protocol, the recipient is expected to receive print jobs on port 515. Therefore, a service receiving the print jobs on port 631 (in CUPS, this service is called cupsd) and a queue in which received print jobs can be placed are needed on the receiving host.
With this method, no print job is sent to a remote queue, as there is no protocol (LPD or IPP) which can handle print jobs and queues. Rather, the raw data are sent directly to a remote TCP port via TCP socket. Usually, this approach is used for sending printer-specific data to print server boxes and network printers. In many cases, the TCP port 9100 is used for this purpose.
If filtering isn't wanted, append -o raw as an option.
9100 stream tcp nowait lp /bin/dd dd of=/dev/lp0
The previous section described how print jobs or raw data are transmitted from the workstation to the printer. The filtering process (the conversion of the original data to printer-specific data) is yet another subject. The conversion to printer-specific data for network printing occurs in the same way as for a printer locally connected to a stand-alone system. The print filter for network printing and stand-alone system is identical, though the data flow from the workstation to the printer is more complicated and goes through several stages such as the following:
At this point in the chain, the source file must be converted into the format that the printer is able to print (PostScript, PCL, ESC/P).
The conversion is handled by a print filter which should run on a machine with sufficient computing power and storage space - on the workstation or on a print server, but not in a print server box or network printer. Usually, print server boxes and network printers do not have any built-in print filter.
Thus, they can only receive printer-specific data and forward them to the printer or printing unit.
A queue can configured with or without a filter. In the YaST printer configuration, the first step is the selection of the ``Hardware'' category for printing ((e.g., via CUPS network server, via LPD network server, or direct printing on a network printer or print server box). Therefore, the default setting (with or without filtering) should normally work. If necessary, the default setting can be changed in the YaST printer configuration.
The default settings are as follows:
If the queue is configured with filtering, the original data are buffered in the queue and subsequently filtered on the host on which the queue is located. Then the converted data are sent to the recipient (see Figure 6.3).
The following paragraphs describe the filtering options for the above examples.
The easiest and most suitable configuration is shown in Figure 6.4.
This high-level configuration is shown in Figure 6.5.
Figure 6.6 shows this configuration.
The only possible configuration is to have a queue with filtering for each printer on every workstation. The disadvantage of this approach is that all queues have to be configured on all workstations (with filtering) and all changes would require the adaption of the configurations on all workstations.
Figure 6.7 shows this configuration.
Figure 6.8 is what the configuration looks like for a stand-alone system.
If you consider the above cases in reverse order, you will see the development from the configuration on a stand-alone system with a locally connected printer to a high-level configuration for several workstations with a print server for several print server boxes or network printers.
If lpd cannot be reached in this way, it is either not running at all or there is some basic network problem.
This way you can get a (possibly very long) status report about the queue on the host, if lpd is running and the host is reachable. As SuSE @nohyphen root, enter the following command:
If the lpd does not respond, the lpd is either inactive or there are basic network problems. If the lpd responds, the response should indicate why queue on host cannot be used for printing. Examples:
By default, CUPS network servers broadcasts its queues via port 631 at thirty-second intervals. After waiting for forty seconds, the output should appear as follows if a broadcasting CUPS network server exists:
The following command tests whether cupsd can be reached via TCP on port 631 of <host>:
If cupsd cannot be reached in this way, it is either not running at all or there is some basic network problem.
With this command you can get a (possibly very long) status report about all queues on <host>, provided cupsd is running and the host is reachable.
This command sends a print job consisting of a single carriage return character to test if the <queue> on <host> accepts any print jobs. This test command should not print out anything or only cause the printer to eject an empty page.
echo -en "\r" \
| smbclient '/<HOST>/<SHARE>' '<PASSWORD>' \
-c 'print -' -N -U '<USER>' \
&& echo ok || echo failed
For <HOST>, enter the host name of the Samba server. For <SHARE>, enter the name of the remote queue (i.e., the name of the Samba share). For <PASSWORD>, enter the password string. Replace <USER> with the user name. This test command should not print out anything or only cause the printer to eject an empty page.
The following command displays any shares on the <host> that are currently available. Details on this can be obtained from smbclient.
smbclient -N -L <host>
This turns the print server box into a mere data converter between the two different data streams (TCP/IP network and local printer line), which effectively makes the printer behave like a local printer although it is connected to the print server box. Without the spooler acting as an intermediary, this method also gives much more direct control over the printer device in general. To use this method, you need to know the corresponding TCP port on the print server box. If the printer is switched on and properly connected, you should be able to determine the TCP port a minute or so after booting the print server box with the program nmap.
Running nmap on the print server box may return an output similar to this:
Port State Service
23/tcp open telnet
80/tcp open http
515/tcp open printer
631/tcp open cups
9100/tcp open jetdirect
This output means:
By default, the CUPS daemon only supports the IPP protocol. However, the program /usr/lib/cups/daemon/cups-lpd from the cups package enables the CUPS server to accept print jobs sent to port 515 via the LPD protocol. For this purpose, the respective service has to be activated for xinetd. This can be done with YaST or manually by activating the respective line in the file /etc/xinetd.d/cups-lpd.
There may be situations where you want to run both LPRng and lpdfilter and CUPS on one system, maybe because you want to enhance the functionality of LPD with some CUPS features or because you need the LPRng and lpdfilter system as an add-on for certain special cases.
Running the two systems together on the same system will lead to a number of problems, however. Below, we list the most important of these and briefly explain the limitations resulting from them. The topic is too complex to describe them in any greater detail here. There are several ways to solve these issues, depending on the individual case.
![\includegraphics[width=0.7\linewidth]{drucken_ps_alln}](img20.png)
![\includegraphics[width=0.900\linewidth]{print_filter_general}](img21.png)
![\includegraphics[width=0.900\linewidth]{print_config_1}](img22.png)
![\includegraphics[width=0.900\linewidth]{print_config_2}](img23.png)
![\includegraphics[width=0.900\linewidth]{print_config_3}](img24.png)
![\includegraphics[width=0.900\linewidth]{print_config_4}](img25.png)
![\includegraphics[width=0.900\linewidth]{print_config_5}](img26.png)