LDP/LDP/howto/docbook/Printing-HOWTO/Printing-HOWTO.xml

<?xml version="1.0"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" "http://docbook.org/xml/4.1.2/docbookx.dtd" [
<!ENTITY howto "http://tldp.org/HOWTO/">
<!ENTITY phtindex SYSTEM "index.xml">
<!ENTITY printerlist SYSTEM "printers.xml">
<!ENTITY fdl SYSTEM "fdl.xml">
]>
<article id="index">
<articleinfo>
<title>The Printing HOWTO</title>
<author>
<firstname>Grant</firstname>
<surname>Taylor</surname>
<affiliation>
<address>
<email>gtaylor+pht@picante.com</email>
</address>
</affiliation>
</author>
<author>
<firstname>Dirk</firstname>
<surname>Allaert</surname>
<affiliation>
<address>
<email>dirk.allaert@reachout.be</email>
</address>
</affiliation>
</author>
<pubdate>v1.8, 2003-06-22</pubdate>
<abstract>
<para>This is the Printing HOWTO, a collection of information on how to
generate, preview, print and fax anything under GNU/Linux.
Almost everything applies equally well to free software users
using other Unix-like operating systems.</para>
</abstract>
</articleinfo>

<sect1 id="howto-intro">
<title>Introduction</title>

<para>The Printing HOWTO should contain everything you need to know to
help you set up printing services on your GNU/Linux box(en).  As
life would have it, it's a bit more complicated than in the
point-and-click world of Microsoft and Apple, but it's also a bit
more flexible and certainly easier to administer for large LANs.</para>
<para>This document is structured so that most people will only need to
read the first half or so.  Most of the more obscure and
situation-dependent information in here is in the last half, and
can be easily located in the Table of Contents, whereas some 
information through section 10 or 11 is probably needed by most
people.</para>
<para>If you find this document or the <ulink url="http://www.linuxprinting.org/">linuxprinting.org</ulink> website useful, consider buying something (ink, for example)
through the referral links on the site; such purchases support
this effort.</para>
<para>The <ulink url="http://www.linuxprinting.org/">linuxprinting.org
website</ulink> is a good place to find the latest version; it is
also, of course, distributed from <ulink url="http://www.tldp.org">tldp.org</ulink> and your friendly local LDP
mirror.</para>

<sect2 id="terminology">
<title>Terminology</title>

<para>I try to use consistent terminology throughout this document, so
that users of all free Unix-like systems, and even users of
non-Unix-like free software, can benefit.  Unfortunately, there are
many handy ambiguous names and many awkward unambiguous names, so
just to be clear, here's a quick glossary of what each name means:
<variablelist>
<varlistentry><term>Unix</term>
<listitem><para>Unix is an operating system constructed at Bell Labs by
various researchers.  A variety of operating systems, mostly
commercial, are based on this code and are also included in
the name Unix.</para></listitem></varlistentry>
<varlistentry><term>Un*x</term>
<listitem><para>Un*x is an awkward word used to refer to every Unix-like
operating system.  A Unixlike operating system provides
something similar to a POSIX programming interface as its
native API.  GNU/Linux, FreeBSD, Solaris, AIX, and even
special-purpose systems like Lynx and QNX are all Un*x.</para></listitem></varlistentry>
<varlistentry><term>Linux</term>
<listitem><para>Linux is a Unixlike kernel and a small assortment of
peripheral software written by Linus Torvalds and
hundreds of other programmers.  It forms the foundation of
the most widely used Un*x operating system.</para></listitem></varlistentry>
<varlistentry><term>GNU</term>
<listitem><para>The GNU (GNU's Not Unix) project is a longtime development
effort to produce an entirely free Unixlike operating system.
The GNU Project is in many ways the father of most modern free
software efforts.</para></listitem></varlistentry>
<varlistentry><term>GNU/Linux</term>
<listitem><para>A GNU/Linux operating system is a complete system
comprised of the Linux kernel, its peripheral programs, and
the GNU runtime environment of libraries, utilities, end-user
software, etc.  Red Hat, Debian, Caldera, SuSE, TurboLinux,
and similar companies are all commercial vendors of complete
GNU/Linux systems.</para></listitem></varlistentry></variablelist>
</para>
</sect2>

<sect2 id="howto-hist">
<title>History</title>

<para>This have been severel generations of the Printing HOWTO.  The history
of the PHT may be chronicled thusly:
<orderedlist>
<listitem><para>Grant Taylor wrote the printing HOWTO in 1992 in response to all the
printing questions in comp.os.linux, and posted it.  This
predated the HOWTO project by a few months and was the first
FAQlet called a `howto'.  This edition was in plain ASCII.</para></listitem>
<listitem><para>After joining the HOWTO project, the Printing-HOWTO was merged
with an Lpd FAQ by Brian McCauley <literal remap="tt">&lt;B.A.McCauley@bham.ac.uk&gt;</literal>; Grant Taylor
continued to co-author the PHT for two years or so.  At some
point he incorporated the work of Karl Auer <literal remap="tt">&lt;Karl.Auer@anu.edu.au&gt;</literal>.  This
generation of the PHT was in TeXinfo, and available in PS,
HTML, ASCII, and Info.</para></listitem>
<listitem><para>After letting the PHT rot and decay for over a year, and an
unsuccessful attempt at getting someone else to maintain it,
this rewrite happened.  This generation of the PHT is written
in SGML using the LinuxDoc DTD and the SGML-Tools-1 package.
Beginning with version 3.27, it incorporated a summary of a
companion printer support database; before 3.27 there was never
a printer compatibility list in this HOWTO (!).</para></listitem>
<listitem><para>In mid-January, 2000, Grand found out about the PDQ print
"spooler".  PDQ provides a printing mechanism so much better
than lpd ever did that he spent several hours playing with it,
rewrote parts of this HOWTO, and bumped the version number of
the document to 4.</para></listitem>
<listitem><para>In mid-2000, Grant moved his printing website to <literal remap="tt">www.linuxprinting.org</literal>, and began offering
more powerful configuration tools there.  He also converted the
HOWTO to DocBook, and initiated coverage of CUPS, LPRng, and
GPR/libppd.</para></listitem>
<listitem><para>In early 2001, Grant began using the GNU Free Documentation
License, which seems quite suitable.  He also began an effort to
clarify what is and isn't Linux-specific; there are several
free Unixlike kernels out there, and they all use the same
printing software.</para></listitem>
<listitem><para>In early 2003, after listening to a presentation from Till Kampeter at FOSDEM, I (Dirk) decided to update this HOWTO. Since Grant last edited the HOWTO, CUPS has gotten more mature and a lot more popular.</para></listitem>
</orderedlist>
</para>

</sect2>

<sect2 id="howto-copy">
<title>Copyright</title>

<para>Copyright (c)  1992-2001 Grant Taylor.</para>
<para>Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License,
Version 1.1 or any later version published by the Free Software
Foundation; with no Invariant Sections, with no Front-Cover
Texts, and with no Back-Cover Texts.  A copy of the license is 
included in <xref linkend="gfdl"/>.</para>
</sect2>

</sect1>

<sect1 id="quickstart">
<title>Quick Start</title>

<para>The quickest way to get started is simply to use the setup tools
provided by your vendor.  Assuming that this includes support for
your driver, and assuming that your vendor shipped the driver for
your printer, then it should be easy to get a basic setup going
this way.  For information on vendor-provided setup tools, see <xref linkend="vendors"/>.</para>
<para>If your vendor's tool doesn't work out, you should
figure out if your printer is supposed to work at all.  Consult the
printer compatibility listings in <xref linkend="printer-compat-list"/> as well as the online version
described there.</para>
<para>If your printer is known to work with a driver, check that you have
that driver, and install if it not.  Typically you will be able to
find a contributed Ghostscript package including newer Ghostscript
code and assorted third-party drivers.  If not, you can compile it
yourself; the process is not trivial, but it is well documented.
See <xref linkend="ghostscript"/> for more information on
Ghostscript.</para>

<para>After installing the proper driver, attempt again to configure your
printer with your vendor's tools.  If that fails, select a
suitable third party tool from those described in <xref linkend="setup"/>. If that also fails, you'll need to construct
your own setup; again see <xref linkend="setup"/>.</para>

<para>If you're still stuck, you've got a little troubleshooting to do.
It's probably best to read most of this document first to get a
feel for how things are supposed to work; then you'll be in a
better position to debug.</para>

<sect2 id="getting-help">
<title>Where to Get Help</title>
<indexterm>
<primary>finding</primary>
<secondary>help</secondary>
</indexterm>
<indexterm>
<primary>help</primary>
</indexterm>

<para>The Usenet newsgroups comp.os.linux.hardware, comp.os.linux.setup,
and comp.periphs.printers all have a share of general printing
questions.  These are well-trafficked newsgroups where an answer
is sure to be found; check in the Google Groups archives, too.  There are also
the linuxprinting.foo newsgroups; these are available both as web-based forums and via NNTP; see the website.</para>
<para>Please also poke around the web looking for your answers.  <ulink url="http://www.linuxprinting.org/">LinuxPrinting.org</ulink> is
an excellent place to start; other websites and projects are
linked to from there.</para>
<para>If you need more help, please try newsgroups, mailing lists, your
distribution's support line, and so forth. If do want to contact me, please do
so via the discussion forums on <ulink url="http://www.linuxprinting.org/">LinuxPrinting.org</ulink>;
this will give others a chance to respond, and will archive your
problem and any solution publicly for the next hapless user.</para>

</sect2>

</sect1>

<sect1 id="how">
<title>How to print</title>

<para>You actually use a different command to print depending on which
spooling software you use.</para>


<sect2 id="with-lpd-and-lpr">
<title>With BSD LPD and the lpr command</title>

<indexterm>
<primary>lpr</primary>
<secondary>usage</secondary>
</indexterm>

<para>If you've already got lpd setup to print to your printer, or your
system administrator already did so, or your vendor did so for
you, then all you need to do is learn how to use the lpr command.
The <ulink url="http://www.tldp.org/HOWTO/Printing-Usage-HOWTO.html">Printing Usage HOWTO</ulink> covers this, and a few other queue
manipulation commands you should probably know.  Or just read the
lpr(1) man page.</para>
<para>In a nutshell, you specify the queue name with <literal remap="tt">-P</literal>, and specify a filename to print a file,
or nothing to print from stdin.  Driver options are traditionally
not controllable from lpr, but various systems accept certain
options with <literal remap="tt">-o</literal>, <literal remap="tt">-Z</literal>, or <literal remap="tt">-J</literal>.</para>
<example><title>lpr</title>
<programlisting>lpr /etc/hosts
lpr -J &quot;my hosts file&quot; /etc/hosts
lpr -P mylaserjet /etc/services</programlisting>
</example>

</sect2>

<sect2>
<title>With System V LPD and the lp command</title>

<indexterm>
<primary>lp</primary>
<secondary>usage</secondary>
</indexterm>

<para>There are two sets of commands that you may encounter if you have to deal with several brands of Unix. The BSD based LPD print system (*BSD, Linux) uses lpr (print),lpq (display queue),lprm (remove jobs). System V based systems on the other hand use lp (print), lpstat (display queue), cancel (remove jobs). Solaris, SCO and others are System V Unix systems.</para>
<para>On SYSV systems, you can of course consult the man page of the lp command. To specify a queue you use the -d option and a filename to print a file, or nothing to print from stdin.</para>
<example><title>lp</title>
<programlisting>lp /etc/hosts
lp -d mylaserjet /etc/services</programlisting>
</example>
</sect2>

<sect2>
<title>With CUPS</title>

<indexterm>
<primary>CUPS</primary>
<secondary>usage</secondary>
</indexterm>

<para>CUPS provides both the System V and Berkeley command-line interfaces. This means that you can use either lpr or lp to print. This is really nice if you have a bunch of scripts that already use eg. lp or you have prior experience with either a System V or a BSD flavor.</para>
</sect2>

<sect2 id="how-with-gui-tools">
<title>GUI Printing Tools</title>

<para>Most spooling systems alone offer only a rather basic command-line
interface.  Rather than use <command>lpr</command> directly, you
may wish to obtain and use a front-end interface.  These generally
let you fiddle with various printing options (the printer, paper
types, collation, n-up, etc) in an easy-to-use graphical way.
Some may have other features, as well.</para>
<simplesect id="kdeprint-sect">
<title>KDEPrint</title>
<indexterm>
<primary>KDEPrint</primary>
</indexterm>
<para>KDEPrint allows users access to printing subsystems (CUPS, LPD, RLPR, LPRng etc.) through a KDE graphical user interface. With KDEPrint, you can easily print, administer jobs and printers and the printing daemon. KDEPrint is a replacement for the old QtCUPS and KUPS. It is easy to use for both developers and users. KDEPrint is already a part of KDE since 2.2.0 and has several nice features.</para>
<para>kprinter is the print dialog of KDEPrint which allows you to select the destination printer and change printer options. Among the destination printers, there are a few virtual printers allowing you to print to email, fax or pdf.
<figure><title>kprinter</title>
<mediaobject><imageobject><imagedata fileref="images/snapshot-kdeprint-kprinter.png"/></imageobject></mediaobject></figure></para>
<para>You can use KDEPrint's <command>kprinter</command> in any application that lets you configure your print command. Examples of these are Mozilla and OpenOffice.
<figure><title>Using kprinter with Mozilla</title>
<mediaobject><imageobject><imagedata fileref="images/snapshot-kdeprint-mozilla.png"/></imageobject></mediaobject></figure>
</para>
<para>KDEPrint also features a Print Preview. that you can select from the Print Dialog. This is accomplished by passing the print file through the filters which make it suitable for displaying on screen using KGhostView or an external application like gv.</para>
<para>The KDEPrint Job Viewer <command>KJobViewer</command> allows you to view, move and cancel print jobs.
<figure><title>KJobViewer</title>
<mediaobject><imageobject><imagedata fileref="images/snapshot-kdeprint-kjobviewer.png"/></imageobject></mediaobject></figure></para>
<para>You can find more information about KDEPrint at <ulink url="http://printing.kde.org/">http://printing.kde.org/</ulink>.</para>
</simplesect>
<simplesect id="xpp-sect">
<title>XPP</title>
<indexterm>
<primary>XPP</primary>
</indexterm>
<indexterm>
<primary>CUPS</primary>
<secondary>XPP</secondary>
</indexterm>
<para>Another good choice for CUPS is the program <command><ulink url="http://cups.sourceforge.net/xpp/">XPP</ulink></command>
     (see <xref linkend="snapshot-xpp-main"/>).  XPP is built from the
FLTK library and is therefore desktop agnostic.</para>
<para>To print with XPP, simply run the xpp program, and specify a file
     (or nothing, if you're using xpp in place of lpr to print from
stdin).  Then select a printer from the list of configured
printers, and select any options you'd like to apply from the
various tabbed panels.  See <xref linkend="snapshot-xpp-options"/>
for an example options panel highlighting the standard CUPS
options.</para>
<para>
<indexterm>
<primary>Foomatic</primary>
<secondary>XPP</secondary>
</indexterm>
When used with Foomatic driver interface system, XPP will
also let you control numeric parameters not normally supported by
CUPS.  This typically includes such things as extended color
tuning, cartridge alignment, and so forth.  See <xref linkend="snapshot-xpp-foomaticoptions"/> for an example of this.</para>
<para>You can save your selected printer and all the options with the
     `Save Settings' button.</para>
<figure id="snapshot-xpp-main">
<title>XPP Main Window</title>
<mediaobject>
<imageobject><imagedata fileref="images/snapshot-xpp-main.png"/></imageobject>
</mediaobject>
</figure>
<figure id="snapshot-xpp-options">
<title>CUPS/XPP Options Window</title>
<mediaobject>
<imageobject><imagedata fileref="images/snapshot-xpp-options.png"/></imageobject>
</mediaobject>
</figure>
<figure id="snapshot-xpp-foomaticoptions">
<title>CUPS/XPP Foomatic Options Window</title>
<mediaobject>
<imageobject><imagedata fileref="images/snapshot-xpp-foomaticoptions.png"/></imageobject>
</mediaobject>
</figure>
</simplesect>
<simplesect id="gpr-intro">
<title>GPR</title>
<para><ulink url="http://www.compumetric.com/linux.html">GPR</ulink>,
by Thomas Hubbell, uses code from CUPS to filter Postscript jobs
and offer easy user control over job options.  Some options (like
n-way printing, page selection, etc) are implemented directly by
GPR, while most others are implemented by the printer or by the
spooler's filter system.</para>
<para>GPR works with LPD or LPRng; or can be compiled specifically for
use with GNUlpr.  When compiled normally, it
uses VA's libppd directly to produce printer-specific
PostScript which it will then submit to the lpr command.  When
compiled for GNUlpr, it will submit your unmodified Postscript job
to the lpr command, along with the set of job options
you specify.  This is arguably the better route, since it allows
the Postscript to be redirected to a different printer by the
spooler when appropriate; unfortunately it requires GNUlpr, which is not in wide circulation (although it is of
course trivial to install).</para>
<para>To use GPR, first select a printer (by LPD queue name) and check
that GPR has loaded the proper PPD file.  If it hasn't, you'll
need to specify the PPD filename, and specify your printer's
options in the Printer Configuration dialog (you get this dialog
by pressing the Printer Configuration button; it contains
assorted printer setup options defined by the PPD).</para>
<para>Once you've configured your printer in GPR, you can print jobs by
specifying the filename and selecting the proper options from the
     `Common' and `Advanced' tabbed panels.  The `Common' options are
implemented directly by GPR for all printers, while the
     `Advanced' options are defined by the PPD file for your printer.
You can see these option panels in <xref linkend="snapshot-gpr-common"/> and <xref linkend="snapshot-gpr-printer"/>.</para>
<figure id="snapshot-gpr-main">
<title>GPR Main Options</title>
<mediaobject>
<imageobject>
<imagedata fileref="images/snapshot-gpr-main.png" scale="60"/>
</imageobject>
</mediaobject>
</figure>
<figure id="snapshot-gpr-common">
<title>GPR Common Options</title>
<mediaobject>
<imageobject>
<imagedata fileref="images/snapshot-gpr-common.png" scale="60"/>
</imageobject>
</mediaobject>
</figure>
<figure id="snapshot-gpr-printer">
<title>GPR Printer Options</title>
<mediaobject>
<imageobject>
<imagedata fileref="images/snapshot-gpr-printer.png" scale="60"/>
</imageobject>
</mediaobject>
</figure>
</simplesect>

</sect2>
</sect1>

<sect1 id="kernel">
<title>Kernel printer devices</title>

<indexterm>
<primary>ports</primary>
</indexterm>
<indexterm>
<primary>drivers</primary>
<secondary>port</secondary>
<seealso>ports</seealso>
</indexterm>

<para>There are two completely different device drivers for the parallel
port; which one you are using depends on your kernel version (which
you can find out with the command <literal remap="tt">uname
   -a</literal>).  The driver changed in Linux 2.1.33; essentially all
current systems will be running kernel 2.2 or later, so you'll
probably want to skip ahead to the parport driver section.</para>
<para>A few details are the same for both styles of driver.  Most
notably, many people have found that Linux will not detect their
parallel port unless they disable "Plug and Play" in their PC BIOS.
   (This is no surprise; the track record for PnP of non-PCI devices
with Windows and elsewhere has been something of a disaster).</para>

<sect2 id="old-lp-device">
<title>The lp device (kernels &lt;=2.1.32)</title>

<indexterm>
<primary>ports</primary>
<secondary>parallel</secondary>
</indexterm>


<para>The Linux kernel (&lt;=2.1.32), assuming you have compiled in or
loaded the lp device (the output of <literal remap="tt">cat /proc/devices</literal> should include the device lp if it is
loaded), provides one or more of <emphasis>/dev/lp0</emphasis>,<emphasis>/dev/lp1</emphasis>, and <emphasis>/dev/lp2</emphasis>.
These are NOT assigned dynamically, rather, each corresponds to a
specific hardware I/O address.  This means that your first printer
may be <emphasis>lp0</emphasis> or <emphasis>lp1</emphasis>
depending on your hardware.  Just try both.</para>
<para>A few users have reported that their bidirectional lp ports aren't
detected if they use an older unidirectional printer cable.  Check
that you've got a decent cable.</para>
<para>One cannot run the plip and lp drivers at the same time on any
given port (under 2.0, anyway).  You can, however, have one or the
other driver loaded at any given time either manually, or by
kerneld with version 2.x (and later 1.3.x) kernels.  By carefully
setting the interrupts and such, you can supposedly run plip on
one port and lp on the other.  One person did so by editing the
drivers; I eagerly await a success report of someone doing so with
only a clever command line.</para>
<para>There is a little utility called <literal remap="tt"><ulink url="http://www.linuxprinting.org/man/tunelp.8.html">tunelp</ulink></literal> floating about with which you, as root, can tune the
Linux 2.0 lp device's interrupt usage, polling rate, and other
options.</para>
<para>When the lp driver is built into the kernel, the kernel will
accept an <literal remap="tt">lp=</literal> option to set
interrupts and io addresses:<screen>
When the lp driver is built in to the kernel, you may use the
LILO/LOADLIN command line to set the port addresses and interrupts
that the driver will use.

Syntax:      lp=port0[,irq0[,port1[,irq1[,port2[,irq2]]]]]

For example:   lp=0x378,0   or   lp=0x278,5,0x378,7 **

Note that if this feature is used, you must specify *all* the ports
you want considered, there are no defaults.  You can disable a
built-in driver with lp=0.</screen></para>
<para>When loaded as a module, it is possible to specify io addresses
and interrupt lines on the insmod command line (or in<emphasis>/etc/conf.modules</emphasis> so as to affect kerneld)
using the usual module argument syntax.  The parameters are<literal remap="tt">io=port0,port1,port2</literal> and <literal remap="tt">irq=irq0,irq1,irq2</literal>.  Read the man page for<emphasis><ulink url="http://www.linuxprinting.org/man/insmod.1.html">insmod</ulink></emphasis> for more information on this.</para>

<para>**For those of you who can never find the standard port
numbers when you need them, they are as in the second example
above.  The other port (<emphasis>lp0</emphasis>) is at 0x3bc.
I've no idea what interrupt it usually uses.</para>

<para>The source code for the Linux 2.0 parallel port driver is in
    /usr/src/linux/drivers/char/lp.c.</para>
</sect2>

<sect2 id="new-parport-device">
<title>The parport device (kernels &gt;= 2.1.33)</title>
<indexterm>
<primary>ports</primary>
<secondary>parallel</secondary>
</indexterm>

<para>Beginning with kernel 2.1.33 (and available as a patch for kernel
2.0.30), the lp device is merely a client of the new parport
device.  The addition of the parport device corrects a number of
the problems that plague the old lp device driver - it can share
the port with other drivers, it dynamically assigns available
parallel ports to device numbers rather than enforcing a fixed
correspondence between I/O addresses and port numbers, and so
forth.</para>

<para>The advent of the parport device has enabled a whole flock of new
parallel-port drivers for things like Zip drives, Backpack CD-ROMs
and disks, and so forth.  Some of these are also available in
versions for 2.0 kernels; look around on the web.</para>

<para>The main difference that you will notice, so far as printing goes,
is that parport-based kernels dynamically assign lp devices to
parallel ports.  So what was lp1 under Linux 2.0 may well be lp0
under Linux 2.2.  Be sure to check this if you upgrade from an
lp-driver kernel to a parport-driver kernel.</para>

<para>The most popular problems with this device seems to stem from
misconfiguration:<variablelist><varlistentry><term>The Distribution</term><listitem><para>Some GNU/Linux distributions don't ship with a properly setup /etc/modules.conf (or /etc/conf.modules), so the driver isn't loaded properly when you need it to be.  With a recent
modutils, the proper magical lines from modules.conf seem to be:<screen>
alias /dev/printers lp             # only for devfs?
alias /dev/lp*      lp             # only for devfs?
alias parport_lowlevel parport_pc  # missing in Red Hat 6.0-6.1</screen></para></listitem></varlistentry><varlistentry><term>The BIOS</term><listitem><para>Many PC BIOSes will make the parallel port into a Plug-and-Play device.  This just adds needless complexity to a
perfectly simple device that is nearly always present; turn
off the PnP setting for your parallel port ("LPT1" in many
BIOSes) if your parallel port isn't detected by the Linux
driver.  The correct setting is often called "legacy", "ISA",
or "0x378", but probably not "disabled".</para></listitem></varlistentry></variablelist></para>

<para>You can also read the  <ulink url="http://people.redhat.com/twaugh/parport/html/parportguide.html">parport documentation</ulink> in your kernel sources, or
look at the <ulink url="http://people.redhat.com/twaugh/parport/">parport web
site</ulink>.</para>
</sect2>

<sect2 id="serial-devices">
<title>Serial devices</title>
<indexterm>
<primary>ports</primary>
<secondary>serial</secondary>
</indexterm>

<para>Serial devices are usually called something like<emphasis>/dev/ttyS1</emphasis> under Linux.  The utility <literal remap="tt"><ulink url="http://www.linuxprinting.org/man/stty.1.html">stty</ulink></literal> will allow you to interactively view or
set the settings for a serial port; <literal remap="tt"><ulink url="http://www.linuxprinting.org/man/setserial.8.html">setserial</ulink></literal> will allow you to control a few
extended attributes and configure IRQs and I/O addresses for
non-standard ports.  Further discussion of serial ports under
Linux may be found in the <ulink url="http://metalab.unc.edu/mdw/HOWTO/Serial-HOWTO.html">Serial-HOWTO</ulink>.</para>

<para>When using a slow serial printer with flow control, you may find
that some of your print jobs get truncated.  This may be due to
the serial port, whose default behavior is to purge any
untransmitted characters from its buffer 30 seconds after the port
device is closed.  The buffer can hold up to 4096 characters, and
if your printer uses flow control and is slow enough that it can't
accept all the data from the buffer within 30 seconds after
printing software has closed the serial port, the tail end of the
buffer's contents will be lost.  If the command <literal remap="tt">cat file &gt; /dev/ttyS2</literal> produces complete
printouts for short files but truncated ones for longer files, you
may have this condition.</para>

<para>The 30 second interval can be adjusted through the
    "closing&lowbar;wait" command-line option of setserial (version
2.12 and later).  A machine's serial ports are usually initialized
by a call to setserial in the rc.serial boot file.  The call for
the printing serial port can be modified to set the
closing&lowbar;wait at the same time as it sets that port's other
parameters.</para>
</sect2>

<sect2 id="usb-devices">
<title>USB Devices</title>
<indexterm>
<primary>ports</primary>
<secondary>USB</secondary>
</indexterm>
<simplesect><title>USB 1.1</title>
<para>Linux supports USB pretty well. USB should work with any late-model 2.2 kernel, and any 2.4 kernel or newer. Of course you need kernel support for USB, either linked in or through a module (recommended). 
<itemizedlist>
<title>If you have a modular kernel, the following modules need to be loaded:</title>
<listitem><para>usb-core.o</para></listitem>
<listitem><para>usb-uhci.o or uhci.o or usb-ohci.o</para></listitem>
<listitem><para>printer.o</para></listitem>
</itemizedlist>
Which one of usb-uhci.o or uhci.o or usb-ohci.o you need depends on the kind of motherboard or adaptor you have. Intel and Via motherboards and Via based adaptors are UHCI (you can use either usb-uhci.o or uhci.o). You can find out which type of HCI (Host Controller Interface) you have with <command>lspci -v|grep HCI</command></para>
</simplesect>
<simplesect><title>USB 2.0</title>
<para>To get high speed transfers out of a USB 2.0 capable device you must attach it to an USB 2.0 controller and use the EHCI driver (ehci-hcd.o). A recent 2.4 kernel or higher is recommended if you want to use USB 2.0.</para></simplesect>
<simplesect><title>Hints</title>
<para>One thing to remember is that USB devices are dynamically allocated. A USB printer gets assigned a device file (/dev/usb/lp*) when it is turned on or connected. This could mean that print jobs are sent to the wrong printer because you turned them on in a certain order. CUPS uses special Uri's containing manufacturer, model and printer serial number to keep sending the jobs to the correct physical printer.</para>
<para>Although most USB printers work fine on Linux, there are exceptions. For example the new MF devices from Epson (Stylus CX3200/CX5200) return garbage when one polls the IEEE-1284 ID string via IOCTL, for example 
with the code of the CUPS "usb" backend. Whereas one can poll the ID string via an Epson-proprietary method.</para>
<para>Till Kamppeter has written some tools to retrieve the device ID string from USB printers. <ulink url="http://www.linuxprinting.org/download/printing/getusbprinterid.pl">getusbprinterid.pl</ulink> and <ulink url="http://www.linuxprinting.org/download/printing/usb_id/test.c">usb_id_test.c</ulink> are the same thing but respectively in Perl and C. As mentioned above, the new MF devices from Epson are an exception, but the &quot;Epson proprietary method&quot; is implemented in the ttink tool of the <ulink url="http://xwtools.automatix.de/">MTink</ulink> package.</para>

<para>More documentation about USB is available at the <ulink url="http://www.linux-usb.org/">Linux USB Website</ulink>.</para>
</simplesect>
</sect2>
</sect1>

<sect1 id="printers">
<title>Supported Printers</title>

<para>The Linux kernel will let you speak with any printer that you can
plug into a serial, parallel, or usb port, plus any printer on the
network.  Unfortunately, this alone is insufficient; you must also
be able to generate data that the printer will understand.  Primary
among the incompatible printers are those referred to as "Windows"
or "GDI" printers.  They are called this because all or part of the
printer control language and the design details of the printing
mechanism are not documented.  Typically the vendor will provide a
Windows driver and happily sell only to Windows users; this is why
they are called Winprinters.  In some cases the vendor also
provides drivers for NT, OS/2, or other operating systems.</para>

<indexterm>
<primary>winprinters</primary>
</indexterm>

<para>Many of these printers <emphasis>do not work</emphasis> with free
software.  A few of them do, and some of them only work a little
bit (usually because someone has reverse engineered the details
needed to write a driver).  See the printer support list below for
details on specific printers.</para>

<para>A few printers are in-between.  Some of NEC's models, for example,
implement a simple form of the standard printer language PCL that
allows PCL-speaking software to print at up to 300dpi, but only NEC
knows how to get the full 600dpi out of these printers.</para>

<para>Note that if you already have one of these Winprinters, there are
roundabout ways to print to one, but they're rather awkward.  See<xref linkend="winprinters"/> in this document for more discussion
of Windows-only printers.</para>

<sect2 id="supported-printers-postscript">
<title>Postscript</title>
<indexterm>
<primary>Postscript</primary>
</indexterm>
<indexterm>
<primary>Postscript</primary>
<secondary>printers</secondary>
</indexterm>

<para>As for what printers <emphasis>do</emphasis> work with free
software, the best choice is to buy a printer with native
PostScript support <emphasis>in firmware</emphasis>.  Nearly all
Un*x software that produces printable output produces it in
PostScript, so obviously it'd be nice to get a printer that
supports PostScript directly.  Unfortunately, PostScript support
is scarce outside the laser printer domain, and is sometimes a
costly add-on.</para>

<para>Un*x software, and the publishing industry in general, have
standardized upon Postscript as the printer control language of
choice.  This happened for several reasons:<variablelist><varlistentry><term>Timing</term><listitem><para>Postscript arrived as part of the Apple Laserwriter, a
perfect companion to the Macintosh, the system largely
responsible for the desktop publishing revolution of the 80s.</para></listitem></varlistentry><varlistentry id="pdf-description"><term>It's device-independent<indexterm><primary>PDF</primary></indexterm></term><listitem><para>Postscript programs can be run to generate output on a
pixel screen, a vector screen, a fax machine, or almost any
sort of printer mechanism, without the original program
needing to be changed.  Postscript output will look the same
on any Postscript device, at least within the limits of the
device's capabilities.  Before the creation of PDF, people
exchanged complex documents online as Postscript files.  The
only reason this standard didn't "stick" was because Windows
machines didn't usually include a Postscript previewer, so
Adobe specified hyperlinks and compression for Postscript,
called the result PDF, distributed previewers for it, and
invented a market for their "distiller" tools (the
functionality of which is also provided by ghostscript's
ps2pdf and pdf2ps programs).</para></listitem></varlistentry><varlistentry><term>It's a real programming language</term><listitem><para>Postscript is a complete programming language; you can
write software to do most anything in it.  This is mostly
useful for defining subroutines at the start of your program
to reproduce complex things over and over throughout your
document, like a logo or a big "DRAFT" in the background.  But
there's no reason you couldn't compute &pgr; in a Postscript
program.</para></listitem></varlistentry><varlistentry><term>It's open</term><listitem><para>Postscript is fully specified in a publically available
series of books (which you can find at any good bookstore) and also online at <ulink url="http://partners.adobe.com/asn/developer/technotes/postscript.html">http://partners.adobe.com/asn/developer/technotes/postscript.html</ulink>.
Although Adobe invented it and provides the dominant
commercial implementation, other vendors like Aladdin produce
independently coded implementations as well.</para></listitem></varlistentry></variablelist></para>
</sect2>

<sect2 id="non-ps-printers">
<title>Non-Postscript</title>

<para>Failing the (larger) budget necessary to buy a Postscript printer,
you can use any printer supported by <emphasis>Ghostscript</emphasis>, the free
Postscript interpreter used in lieu of actual printer Postscript
support. Note that most GNU/Linux distributions can only ship a
somewhat outdated version of Ghostscript due to the license.
Fortunately, there is usually a prepackaged up to date Ghostscript
made available in each distribution's contrib area.</para>

<para>Adobe now has a new printer language called "PrintGear".  I think
it's a greatly simplified binary format language with some
Postscript heritage but no Postscript compatibility.  And I
haven't heard of Ghostscript supporting it.  But some PrintGear
printers seem to support another language like PCL, and these
printers will work with GNU/Linux (if the PCL is implemented in the
printer and not in a Windows driver).</para>

<para>Similarly, Adobe offers a host-based Postscript implementation
called <productname>PressReady</productname>.  This works much
like Ghostscript does to provide Postscript support for a
non-Postscript printer, but has the disadvantage that it runs only
on Windows.</para>
</sect2>

<sect2 id="what-printers-work">
<title>What printers work?</title>
<indexterm>
<primary>printers</primary>
<secondary>buying</secondary>
</indexterm>
<indexterm>
<primary>finding</primary>
<secondary>drivers</secondary>
</indexterm>

<para>You can look in several places to see if a particular printer will
work.  The cooperatively maintained Printing HOWTO printer <ulink url="http://www.linuxprinting.org/database.html">database</ulink> aims to be a comprehensive listing of the state of GNU/Linux printer
support.  A summary of it is below; be sure to check online for
more details and information on what driver(s) to use.</para>

<para>The best bet for new printer shoppers is to consult the list of <ulink url="http://www.linuxprinting.org/suggested.html">suggested printers</ulink>.  These center around color inkjets
and mono laser devices.  You can even help support this document
and the website by buying from one of <ulink url="http://www.linuxprinting.org/affiliate.html">affiliated vendors</ulink>.</para>

<para>Ghostscript's <ulink url="http://www.cs.wisc.edu/~ghost/doc/printer.htm">printer
compatibility page</ulink> has a list of some working printers,
as well as links to other pages.</para>

<para>
<ulink url="http://groups.google.com/">Google groups</ulink> contains hundreds of "it works" and "it doesn't work"
testimonials.  Try all three, and when you're done, check that
your printer is present and correct in the <ulink url="http://www.linuxprinting.org/database.html">database</ulink>, so that it will be listed properly in this document in the
future.</para>


<sect3 id="printer-compat-list">
<title>Printer compatibility list</title>
<indexterm>
<primary>drivers</primary>
<secondary>printer</secondary>
</indexterm>

<para>This section is a summary of the <ulink url="http://www.linuxprinting.org/database.html">online
database</ulink>.  The online version includes device
specifications, notes, driver information, user-maintained
documentation, manufacturer web pages, and interface scripts for
using drivers with several print spooling systems (including LPR,
LPRng, PDQ, and CUPS).  The online version of this list is also
interactive; people can and do add printers all the time, so be
sure to check it as well.  Finally, if your printer isn't listed,
add it!</para>

<para>Note that this listing is not gospel; people sometimes add
incorrect information, which are eventually weeded out.  Entries which
have not been sanity-checked are marked with an asterisk (*).  Verify
from Google Groups that a printer works for someone before buying it
based on this list.</para>

<para>Printers here are categorized into four types:<variablelist><varlistentry><term>Perfectly</term><listitem><para>Perfect printers work perfectly - you can print to the full
ability of the printer, including color, full resolution, etc.
In a few cases printers with undocumented "resolution
enhancement" modes that don't work are listed as perfect;
generally the difference in print quality is small enough that
it isn't worth worrying about.</para></listitem></varlistentry><varlistentry><term>Mostly</term><listitem><para>You can print fine, but there may be minor limitations of one
sort or another in either printing or other features.</para></listitem></varlistentry><varlistentry><term>Partially</term><listitem><para>You can print, but maybe not in color, or only at a poor
resolution.  See the online listing for information on the
limitation.</para></listitem></varlistentry><varlistentry><term>Paperweight</term><listitem><para>You can't print a darned thing; typically this will be due to
lack of a driver and/or documentation on how to write one.
Paperweights occasionally get "promoted", either when someone
discovers that an existing driver works, or when someone
creates a new driver, but you shouldn't count on this
happening.</para></listitem></varlistentry></variablelist>

In all cases, since this information is provided by dozens of
people, none of it is guaranteed to be correct; entries with an
asterisk (*) are particularly suspect.  The facts, however, should
be easy to corroborate from the driver web pages and manufacturer
web sites.</para>

<para>And without further ado, here is the printer compatibility list:
&printerlist;
     * This entry has not been sanity-checked.</para>
</sect3>
</sect2>

<sect2 id="shopping">
<title>How to buy a printer</title>
<indexterm>
<primary>printers</primary>
<secondary>buying</secondary>
</indexterm>

<para>It's a bit difficult to select a printer these days; there are many
models to choose from.  Here are some shopping tips:<variablelist><varlistentry><term>Cost</term><listitem><para>You get what you pay for.  Most printers under $200-300
can print reasonably well, but printing costs a lot per page.
For some printers, it only takes one or two cartridges to add
up to the cost of a new printer!  This is specially true for cheap inkjets. Similarly, the cheapest
printers won't last very long.  The least expensive printers,
for example, have a MTBF of about three <emphasis>months</emphasis>; obviously these are poorly suited
for heavy use.</para></listitem></varlistentry><varlistentry><term>Inkjets</term><listitem><para>Inkjet printheads will clog irreparably over time, so the
ability to replace the head somehow is a feature.  Inkjet
printheads are expensive, with integrated head/ink cartridges
costing ten times (!) what ink-only cartridges go for, so the
ability to replace the head only when needed is a feature.
Epson Styluses tend to have fixed heads, and HP DeskJets tend
to have heads integrated into the cartridges.  Canons have
three-part cartridges with independently replaceable ink
tanks; I like this design.  OTOH, the HP cartridges aren't
enormously more expensive, and HP makes a better overall line;
Canon is often the third choice from the print quality
standpoint. Epson Styluses and HP inkjets are the best supported by
free software at the moment.</para></listitem></varlistentry>
<varlistentry><term>Lasers</term><listitem><para>Laser printers consume a drum and toner, plus a little
toner wiping bar.  The cheapest designs include toner and drum
together in a big cartridge; these designs cost the most to
run.  The best designs for large volume take plain toner
powder or at least separate toner cartridges and drums.</para></listitem></varlistentry><varlistentry id="photo-printers-shopping"><term>Photography<indexterm><primary>photograph</primary><secondary>printers</secondary></indexterm>
<indexterm>
<primary>printers</primary>
<secondary>photograph</secondary>
</indexterm>
</term>
<listitem><para>The best color photograph output is from continuous tone
printers which use a silver halide plus lasers approach to
produce&mdash;surprise!&mdash;actual photographs.  Since these
printers cost tens of thousands to buy, <ulink url="http://www.ofoto.com">Ofoto.com</ulink> offers
inexpensive print-by-print jobs.  The results are stunning;
even the best inkjets don't compare.</para>
<para>
The best affordable photo prints come from the dye-sublimation
devices like some members of the Alps series (thermal transfer
of dry ink or dye sublimation), or the few consumer-grade Sony
photo printers.  Unfortunately the Alps devices have poor free
software support (the one report I have from a Alps user of
the Ghostscript driver speaks of banding and grainy pictures),
and even then it's unclear if the dye-sub option is supported.
I have no idea if the Sonys work at all.</para>
<para>
The more common photo-specialized inkjets usually feature 6
color CMYKcm printing or even a 7 color CMYKcmy process.  All
photo-specialized printers are expensive to run; either you
always run out of blue and have to replace the whole
cartridge, or the individual color refills for your high-end
photo printer cost an arm and a leg.  Special papers cost a
bundle, too; you can expect top-quality photo inkjet output to
run over a US dollar per page.  See also the section on
printing photographs later in this document, and the sections
on color tuning (such as it is) in Ghostscript.</para>
<para>Lately color lasers have been getting a lot cheaper, these devices may be interesting for color reports. Color lasers are a lot cheaper per page than inkjets. However they may still not be suited for photographs. One day color lasers may become common and replace those boring monochrome laser printers.</para></listitem></varlistentry><varlistentry><term>Speed</term><listitem><para>Speed is proportional to processing power, bandwidth, and
generally printer cost.  The fastest printers will be networked
Postscript printers with powerful internal processors.
Consumer-grade printers will depend partly on Ghostscript's
rendering speed, which you can affect by having a reasonably
well-powered machine; full pages of color, in particular, can
consume large amounts of host memory.  As long as you actually<emphasis>have</emphasis> that memory, things should work out
fine.</para></listitem></varlistentry>
<varlistentry><term>Forms</term><listitem><para>If you want to print on multicopy forms, then you need an
impact printer; many companies still make dot matrix printers,
most of which emulate traditional Epson models and thus work
fine.</para></listitem></varlistentry>
<varlistentry><term>Labels</term><listitem><para>There are two supported lines of label printer; look for
the Dymo-Costar and the Seiko SLP models.  Other models may or
may not work.  Avery also makes various sizes of stick-on
labels in 8.5x11 format that you can run through a regular
printer.</para></listitem></varlistentry>
<varlistentry><term>Plotting</term><listitem><para>Big drafting formats are usually supported these days by
monster inkjets; HP is a popular choice.  Mid-sized (11x17)
inkjets are also commonly used for smaller prints.  Much
plotting of this sort is done with the languages RTL, HP-GL,
and HP-GL/2, all of which are simple HP proprietary vector
languages usually generated directly by application software.</para></listitem></varlistentry>
</variablelist>
</para>
</sect2>

</sect1>

<sect1 id="spoolers">
<title>Spooling software</title>

<para>Until recently, the choice for free software users was simple -
everyone ran the same old lpd lifted mostly verbatim out of BSD's
Net-2 code.  Even today, some vendors ship this software.  But this
is beginning to change. SVR4-like systems including Sun's Solaris
come with a completely different print spooling package, centered
around lpsched.</para>

<para>Today, there are a number of good systems to chose from. They are
all described below; read the descriptions and make your own
choice. CUPS is a good option and recommended for most users; it has excellent Postscript
printer support, offers IPP support, a web interface, and a
number of other features.
For business environments with mainly networked Postscript printers, a front-end
program like GPR with LPRng is another option; it handles
PPD options directly and has a nice interface.</para>

<!--FIXME: indexterm-->
<sect2 id="cups-which-spooler">
<title>CUPS</title>
<indexterm>
<primary>CUPS</primary>
</indexterm>
<indexterm>
<primary>CUPS</primary>
<secondary>XPP</secondary>
<see>XPP</see>
</indexterm>
<indexterm>
<primary>spoolers</primary>
<secondary>CUPS</secondary>
</indexterm>
<indexterm>
<primary>XPP</primary>
</indexterm>

<para>
<indexterm>
<primary>IPP</primary>
</indexterm>
<indexterm>
<primary>Internet Printing Protocol</primary>
<see>IPP</see>
</indexterm>
<ulink url="http://www.cups.org/">CUPS</ulink> has become the standard printing system in most distributions today. What makes CUPS different from the rest ? CUPS is an implementation of the Internet Printing Protocol (IPP), a new standard intended to solve some of the deficiencies of the old LPD protocol. CUPS also supports LPD, SMB and AppSocket (JetDirect) with reduced functionality. The implementation of CUPS has been driven by Michael Sweet of
Easy Software Products; CUPS is distributed under the GPL. Being a new protocol, the IPP has a number of advantages on the ancient LPD protocol:
<itemizedlist>
<listitem><para>the scheduler is a HTTP 1.1 web server and also delivers a web interface</para></listitem>
<listitem><para>printer options, you can even ask the IPP device what options and document formats it supports.</para></listitem>
<listitem><para>access control which restricts print jobs, job controls, and system administration commands coming from and to specified computers and printers. Like Apache, you can control access to CUPS using Allow and Deny directives.</para></listitem>
<listitem><para>proxy support (since IPP uses HTTP)</para></listitem>
<listitem><para>encryption support</para></listitem>
<listitem><para></para></listitem>
</itemizedlist>
Today, all major operating system vendors actively support IPP, as well as the major printer vendors. IPP is a standard printing protocol in Windows 2000 (IIS needs to be installed) which may be a better option for free software users than the proprietary SMB protocol. However, on Windows 2000 automatic printer driver downloading only works with SMB and not with IPP, this may be a reason for administrators with a lot of Windows clients to choose for SMB printer sharing using Samba and CUPS.</para>

<para id="cups-home-environ">
<indexterm>
<primary>environment</primary>
<secondary>home</secondary>
</indexterm>
There are a number of very good features in
it, including sensible option handling; web, GUI, and command-line
interfaces; and a mime-based filtering system with strong support
for Postscript.</para>

<para id="cups-drivers-finding">There are several sets of PPDs which you can use with CUPS:<variablelist><varlistentry><term>Built-in</term><listitem><indexterm><primary>built-in</primary><secondary>CUPS</secondary></indexterm>
<para>The default CUPS installation contains generic PPDs for 9-pin and 24-pin Epson matrix printers, Epson Stylus Color, Stylus Photo printers, HP LaserJet, DeskJet printers and Dymo Label printers. These will enable you to print to a lot of printer models, but will not give you access to specific capacities of the models</para>
</listitem></varlistentry>
<varlistentry><term><ulink url="http://www.linuxprinting.org/foomatic.html">Foomatic</ulink></term><listitem><indexterm><primary>Foomatic</primary><secondary>CUPS</secondary></indexterm><indexterm><primary>foomatic-rip</primary></indexterm>
<para>Foomatic can generate a suitable
PPD for use with any printer driver that has full details
entered in the linuxprinting.org database.  The PPD gets used
together with a backend script named <command>foomatic-rip</command>. foomatic-rip uses free
software drivers.  At the moment there is support for a rather
large number of printers in this system. Foomatic forms a basis for non-Postscript printer
support in most GNU/Linux distributions. CUPS and Foomatic are becoming quite popular and this is currently the recommended printing system for most situations.</para></listitem></varlistentry>
<varlistentry><term>Postscript PPDs</term><listitem><para>CUPS can use vendor-supplied PPD files for Postscript
printers directly.  Often these come with the Windows drivers
for a printer, or can be found on the printer vendor's
website. If you have a choice between a driver for Windows 9x and Windows NT/W2K, than select the driver for Windows NT. <ulink url="http://www.adobe.com/products/printerdrivers/winppd.html">Adobe</ulink> also distributes PPD files for many Postscript
printers.</para></listitem></varlistentry>
<varlistentry><term>ESP Print Pro</term><listitem><para><ulink url="http://www.easysw.com/">Easy Software
Products, Inc.</ulink> sells CUPS bundled with a collection of
proprietary drivers.  Although they are not free software,
they do drive many common printers.  The bundle is somewhat
expensive measured against the price of a single supported
printer, but it certainly has a place. The package
includes graphical front-end tools.</para></listitem></varlistentry>
<varlistentry><term>Gimp-Print</term><listitem><para>The <ulink url="http://gimp-print.sourceforge.net/">Gimp-Print</ulink> drivers are high quality drivers for Canon, Epson, Lexmark, and PCL printers for use with Ghostscript, CUPS, Foomatic, and the Gimp.</para></listitem></varlistentry>
<varlistentry><term><ulink url="http://www-124.ibm.com/developerworks/oss/linux/projects/omni/">OMNI</ulink></term><listitem><indexterm><primary>OMNI</primary><secondary>CUPS</secondary></indexterm>
<para>Omni is a package made by IBM, now containing support for more than 450 printers. The OMNI printer driver model is distributed by IBM under LGPL License.</para></listitem></varlistentry>
<varlistentry><term><ulink url="http://hpinkjet.sourceforge.net/">HPIJS</ulink></term><listitem><indexterm><primary>HPIJS</primary><secondary>CUPS</secondary></indexterm>
<para>HPIJS supports around 150 of HP's own printers at excellent print quality now (currently only via the Foomatic path). As of Version 1.0.1 , the "hp Product Only" clause has been removed from the license and the drivers are distributed with a BSD license.</para></listitem></varlistentry>
</variablelist></para>
<para>The third-party program <command><ulink url="http://cups.sourceforge.net/xpp/">XPP</ulink></command> (see <xref linkend="snapshot-xpp-main"/>) offers a
very nice graphical interface to the user functionality of CUPS,
including an marvelous interface to print-time options (shown in <xref linkend="snapshot-xpp-options"/>).  For information on using
XPP, see <xref linkend="xpp-sect"/>.</para>
</sect2>

<sect2 id="lpd-which-spooler">
<title>LPD</title>
<indexterm>
<primary>LPD</primary>
<secondary>GNUlpr</secondary>
</indexterm>
<indexterm>
<primary>GNUlpr</primary>
<secondary>LPD</secondary>
</indexterm>

<para>LPD, the original BSD Unix Line Printer Daemon, has been the
standard on Unix for years.  It is available for every style of
Unix, and offers a rather minimal feature set derived from the
needs of timesharing-era computing.  Despite this somewhat
peculiar history, it is still useful today as a basic print
spooler.  To be really useful with modern printer, a good deal of
extra work is needed in the form of companion filter scripts and
front-end programs.  But these exist, and it does all work.</para>

<para>LPD is also the name given to the network printing protocol by <ulink url="http://www.ietf.org/rfc/rfc1179.txt">RFC
1179</ulink>.  This network protocol is spoken not only by
the LPD daemon itself, but by essentially every networked print
server, networked printer, and every other print spooler out
there; LPD is the least common denominator of standards-based
network printing.</para>

<para><ulink url="http://www.lprng.org">LPRng</ulink>(see <xref linkend="lprng-which-spooler"/>) is a far better
implementation of the basic LPD design than the regular one; if
you must use LPD, consider using LPRng instead.  There is far less
voodoo involved in making it do what you want, and what voodoo
there is well documented. LPRng is essentially an enhanced LPD implementation with better security and extra features.</para>

<para>There are a large number of LPD sources floating around in the
world.  Arguably, some strain of BSD Unix is probably the official
owner, but everyone implements changes willy-nilly, and they all
cross-pollinate in unknown ways, such that it is difficult to say
with certainty exactly which LPD you might have.  Of the readily
available LPDs, <ulink url="http://sourceforge.net/projects/lpr/">GNUlpr</ulink> offers one with a few minor modifications
that make the user interface much more flexible.  The GNUlpr supports command-line option specification with a<option>-o</option> flag; options are then passed through to
filters.  This is similar to the features offered by a number of
traditional Unix vendors, and similar to (although incompatible
with) LPRng's <option>-z</option> option mechanism.</para>

<para>If you go with LPD, the best way to use it is via a front-end.
There are several to chose from; KDEPrint, GPR (see <xref linkend="how-with-gui-tools"/>) and XPP are perhaps the best. Others exist; tell me about them.</para>
</sect2>

<sect2 id="lprng-which-spooler">
<title>LPRng</title>
<indexterm>
<primary>LPRng</primary>
</indexterm>
<indexterm>
<primary>spoolers</primary>
<secondary>LPRng</secondary>
</indexterm>

<para>Some GNU/Linux vendors provide LPRng, a far less
ancient LPD print spooling implementation. LPRng is far easier to
administer for large installations (read: more than one printer,
any serial printers, or any peculiar non-lpd network printers) and
has a less frightfully haphazard codebase than does stock lpd.  It
can even honestly claim to be secure - there are no SUID binaries,
and it supports authentication via PGP or Kerberos.</para>

<para>LPRng also includes some example setups for common network
printers - HP LaserJets, mainly - that include some accounting
abilities. LPRng uses more or less the same basic filter model
as does BSD lpd, so the <ulink url="http://www.linuxprinting.org/lpd-doc.html">LPD
support</ulink> offered by the linuxprinting.org website applies to LPRng as well.
This can help you effectively use free software drivers for many
printers.</para>

<para>LPRng is distributed under either the GPL or an Artistic license.</para>
</sect2>

<sect2 id="ppr-which-spooler">
<title>PPR</title>
<indexterm>
<primary>PPR</primary>
</indexterm>
<indexterm>
<primary>spoolers</primary>
<secondary>PPR</secondary>
</indexterm>

<para><ulink url="http://ppr.trincoll.edu/">PPR</ulink> is a
Postscript-centric spooler which includes a rudimentary Postscript
parsing ability from which it derives several nice features.  It
includes good accounting capabilities, good support for Appletalk,
SMB, and LPD clients, and much better error handling than lpd.
PPR, like every other spooler here, can call Ghostscript to handle
non-Postscript printers.</para>

<para>PPR was written by, and is in use at, Trinity
College.  The license is BSD-style; free for all use but credit is
due.</para>
</sect2>

<sect2 id="others-which-spooler">
<title>Others</title>

<sect3><title>PDQ</title>
<para> PDQ stands for "Print, Don't Queue", and the way it works reflects this design. PDQ is a non-daemon-centric print system which has a built-in, and sensible, driver configuration syntax. This includes the ability to declare printing options, and a GUI or command line tool for users to specify these options with; users get a nice dialog box in which to specify resolution, duplexing, paper type, etc.</para>
<para> Running all of the filters as the user has a number of advantages: the security problems possible from Postscript are mostly gone, multi-file LaTeX jobs can be printed effectively as dvi files, and so forth.</para>
<para> PDQ is not without flaws: most notably it processes the entire job before sending it to the printer. This means that, for large jobs, PDQ may simply be impractical—you can end up with hundreds of megs being copied back and forth on your disk. Even worse, for slow drivers like the better quality inkjet drivers, the job will not start printing until Ghostscript and the driver have finished processing. This may be many minutes after submission.</para>
<para>There's a real place for PDQ; it has a simple design that doesn't
subtract user control.  And the normal control path crosses no
security boundaries, so it can't have the classes of security bug
people are always finding in other systems.  And to top it off, it's
small.</para>
<para>However there is no active development done on PDQ. A new maintainer would be most welcome.</para>
</sect3>
<sect3><title>GNUlpr</title>
<para>GNUlpr began its life in some work that HP sponsored VA Linux to do. Unfortunately, GNUlpr is now pretty much dead.</para>
</sect3>
<sect3><title>CPS</title>
<para>The <ulink url="http://www.tww.cx/cps.php">Coherent Printing System</ulink>  is a set of Perl scripts called "lpr", "lpd", "lprm", and "lpq". These replace the programs of the same name which come with many Linux systems.</para>
</sect3>
<sect3><title>CEPS</title>
<para>The Cisco Enterprise Print System was developed by Damian Ivereigh when he was a sysadmin at Cisco. He did more than he was hired to do, he developed a new printing system to improve the administrative hassle. Cisco authorized the release of the software for free under the GNU General Public License. Installing CEPS will however only pay off at large organisations.</para>
</sect3>

</sect2>

</sect1>

<sect1 id="background">
<title>How it all works</title>
<indexterm>
<primary>spoolers</primary>
</indexterm>

<para>In order to get printing working well, you need to understand how your 
spooling software works.  All systems work in essentially the same
way, although the exact order might vary a bit, and some systems
skip a step or two:<figure id="spool-illustration"><title>Spooling Illustration</title><mediaobject><imageobject><imagedata fileref="images/spool-illustration.png"/></imageobject></mediaobject></figure><orderedlist><listitem><simpara>The user submits a job along with his selection of options.  The
job data is usually, but not always, Postscript.</simpara></listitem><listitem><simpara>The spooling system copies the job and the options over the
network in the general direction of the printer.</simpara></listitem><listitem><simpara>The spooling system waits for the printer to be available.</simpara></listitem><listitem><indexterm><primary>filtering</primary></indexterm></listitem><listitem id="background-filtering"><simpara>The spooling system applies the user's selected options to the
job, and translates the job data into the printer's native
language, which is usually not Postscript.  This step is called <emphasis>filtering</emphasis>; most of the work in setting
things up lies in getting the proper filtering to happen.</simpara></listitem><listitem><simpara>The job is done.  The spooling system will usually do assorted
cleanup things at this point.  If there was an error along the
way, the spooler will usually notify the user somehow (for
example, by email).</simpara></listitem></orderedlist></para>

<sect2 id="cups-overview">
<title>CUPS</title>
<para>To print a job with CUPS, you can use both the BSD (see <xref linkend="printer-compat-list"/>) and System V commands making it really easy for people with prior experience with either system.</para>
<figure><title>Simplified CUPS illustration</title>
<mediaobject><imageobject><imagedata fileref="images/cups-overview.png"/></imageobject></mediaobject></figure>
<para>Initially CUPS lacked an LPD backend. This was of course quickly added. Currently there are backends available for at least IPP, LPD, SMB, JetDirect, USB, Netatalk, parallel and serial printers. You may find others on the net or write your own.</para>
<para>There are only a handfull of built-in drivers, allowing you to print with most printers but probably not at the maximum resolution. A PPD file for a Postscript driver can be added to CUPS but if you want to print at best quality with your fancy new HP Deskjet you are out of luck. It is here that Foomatic comes to the rescue. You can use Foomatic in combination with CUPS. Foomatic uses a CUPS filter called foomatic-rip to do its magic. foomatic-rip uses PPD files to describe printer capabilities, even for non-Postscript printers. CUPS + Foomatic is currently the recommended printing system. Some Linux distributions already use it and the number that do will only grow.</para><para>The CUPS scheduler does not only accept jobs, it is also a administrative webinterface. Currently you can add/delete printers, cancel jobs, start/stop printers. Moving jobs will be available in a later release.</para>

</sect2>

<sect2 id="lpd-overview">
<title>LPD</title>

<indexterm>
<primary>LPD</primary>
</indexterm>

<para>Lpd stands for Line Printer Daemon, and refers in different
contexts to both the daemon and the whole collection of programs
which run print spooling.  These are:<variablelist><varlistentry><term><command><ulink url="http://www.linuxprinting.org/man/lpd.8.html">lpd</ulink></command></term><listitem><para>The spooling daemon.  One of these runs to control everything
on a machine, AND one is run per printer while the printer is
printing.</para></listitem></varlistentry><varlistentry id="lpr-in-lpd-overview"><term><command><ulink url="http://www.linuxprinting.org/man/lpr.1.html">lpr</ulink></command><indexterm><primary>lpr</primary></indexterm><indexterm><primary>LPD</primary><secondary>lpr</secondary></indexterm></term><listitem><para>The user spooling command.  Lpr contacts lpd
and injects a new print job into the spool.</para></listitem></varlistentry><varlistentry id="lpq-in-lpd"><term><command><ulink url="http://www.linuxprinting.org/man/lpq.1.html">lpq</ulink></command><indexterm><primary>lpq</primary></indexterm><indexterm><primary>LPD</primary><secondary>lpq</secondary></indexterm></term><listitem><para>Lists the jobs in a print queue.</para></listitem></varlistentry><varlistentry id="lpc-in-lpd"><term><command><ulink url="http://www.linuxprinting.org/man/lpc.8.html">lpc</ulink></command><indexterm><primary>lpc</primary></indexterm><indexterm><primary>LPD</primary><secondary>lpc</secondary></indexterm></term><listitem><para>The Lpd system control command.  With lpc you can stop, start,
reorder, etc, the print queues.</para></listitem></varlistentry><varlistentry id="lprm-in-lpd"><term><command><ulink url="http://www.linuxprinting.org/man/lprm.1.html">lprm</ulink></command><indexterm><primary>lprm</primary></indexterm><indexterm><primary>LPD</primary><secondary>lprm</secondary></indexterm></term><listitem><para><command>lprm</command> removes a job from the print spool.</para></listitem></varlistentry></variablelist></para>

<para>So how does it fit together?  The following things happen:<orderedlist><listitem><simpara>At boot time, <command>lpd</command> is run.  It waits for
connections and manages printer queues.</simpara></listitem><listitem><simpara>A user submits a job with the <command>lpr</command> command
or, alternatively, with an lpr front-end like GPR, PDQ, etc.<command>Lpr</command> contacts <command>lpd</command> over the
network and submits both the user's data file (containing the
print data) and a control file (containing user options).</simpara></listitem>
<listitem><simpara>When the printer becomes available, the main <command>lpd</command> spawns a child <command>lpd</command> to
handle the print job.</simpara></listitem>
<listitem><simpara>The child <command>lpd</command> executes the appropriate
filter(s) (as specified in the <option>if</option> attribute in<filename>/etc/printcap</filename>) for this job and sends the
resulting data on to the printer.</simpara></listitem>
</orderedlist></para>

<para>The lp system was originally designed when most printers were line
printers - that is, people mostly printed plain ASCII.  By placing
all sorts of magic in the <option>if</option> filter, modern
printing needs can be met with <command>lpd</command> (well, more
or less; many other systems do a better job).</para>

<para>There are many programs useful for writing LPD filters.  Among
them are:<variablelist><varlistentry><term><command>gs</command></term>
<listitem><para>Ghostscript is a host-based Postscript interpreter (aka a
Raster Image Processor or RIP).  It accepts Postscript and
produces output in various printer languages or a number of
graphics formats.  Ghostscript is covered in <xref linkend="ghostscript"/>.</para></listitem></varlistentry><varlistentry><term><command>ppdfilt</command></term>
<listitem><para><command><ulink url="http://sourceforge.net/project/?group_id=1658">ppdfilt</ulink></command> is a standalone version of a CUPS
component.  It filters Postscript, executing a few basic
transformations on it (n-up printing, multiple copies, etc)
and adding in user option statements according to a Postscript
Printer Definition (PPD) file usually included with Postscript
printers.</para><para><command>ppdfilt</command> is best used together with an
option-accepting LPD system (like the GNUlpr, or LPRng)
and a filter script which parses user-provided options into
the equivalent <command>ppdfilt</command> command.  VA Linux
and HP provide a modified rhs-printfilters package which does
exactly this; it produces nice results if you have a
Postscript printer.  See <xref linkend="lpd-for-postscript-printers"/> for information on
this system.</para></listitem></varlistentry><varlistentry><term><command>ps2ps</command></term><listitem><para><command>ps2ps</command> is a utility script included
with Ghostscript.  It filters Postscript into more streamlined
Postscript, possibly at a lower Language Level.  This is
useful if you have an older Postscript printer; most modern
software produces modern Postscript.</para></listitem></varlistentry><varlistentry><term><command>mpage</command></term><listitem><para><command>mpage</command> is a utility which accepts
text or Postscript, and generates n-up output&mdash;that is,
output with several page images on each piece of paper.  There
are actually several programs which do this, including<command>enscript</command>, <command>nenscript</command>, and<command>a2ps</command>.</para></listitem></varlistentry><varlistentry><term><command>a2ps</command></term><listitem><para><command>a2ps</command>, aka any-to-ps, is a program which
accepts a variety of file types and converts them to
Postscript for printing.</para></listitem></varlistentry></variablelist></para>
</sect2>
</sect1>

<sect1 id="setup">
<title>How to set things up</title>

<para>For common configurations, you can probably ignore this section
entirely - instead, you should jump straight to <xref linkend="vendors"/> below, or better yet, your vendor's
documentation.  Most GNU/Linux distributions supply one or more
   "idiot-proof" tools to do everything described here for common
printers.</para>

<para>If your vendor's tool doesn't work out for you, or you'd like the
ability to interactively control printing options when you print,
then you should use some other system. APS Filter
is another good system; it configures LPD queues and filters very
easily on most any sort of Unix system.</para>

<para>You can also use the printing system interfaces from the <ulink url="http://www.linuxprinting.org/">linuxprinting.org website</ulink>
to connect many free drivers into several spooling systems. Once
this project is complete, these interfaces will offer the best
functionality: all styles of free software drivers are supported,
user-settable options are available, and most common spooling
systems are supported. Currently the foomatic print system is used in most modern distributions anyway. However, your distro may include a slightly outdated version of foomatic.</para>

<sect2 id="cups-config-tutorial">
<title>Configuring CUPS</title>
<para>If you are using a client with CUPS and a CUPS server has already been configured, installing the printers on your client can not get much easier than this: do nothing. Through broadcasting, the client should find the CUPS server and automatically configure the printers that are installed on that print server. This is one of the features of CUPS that will be really appreciated on large networks.</para>
<para>Manually configuring printers with CUPS, also is a peace of cake. If you are new to CUPS and/or Unix printing, the way to go is probably the web interface. If you have to configure lots of printers, using the command-line will probably be faster.</para>
<para>The URL to access the CUPS web interface is http://hostname:631/admin by default. The port can be changed in cupsd.conf if necessary.</para>
<para>To add a printer from the command-line the general syntax is
<command>lpadmin -p printer -E -v device -m ppd</command>
Lpadmin with the -p option adds or modifies a printer. The printers are saved in the file
The -x option deletes the named printer. Read the lpadmin man page for available options.
</para>
<example><title>command-line examples</title>
<screen>
/usr/sbin/lpadmin -p testpr1 -E -v socket://192.168.1.9 -m deskjet.ppd
/usr/sbin/lpadmin -p testpr2 -E -v parallel:/dev/lp0 -m laserjet.ppd
/usr/sbin/lpadmin -x testpr1
</screen>
</example>
<para>More information about configuring printers and options can be found in the <ulink url="http://www.cups.org/documentation.html">CUPS documentation</ulink>. The Software Administrators Manual will teach you all you need to know about configuring printers with CUPS.</para>
</sect2>

<sect2 id="lpd-config-tutorial">
<title>Configuring LPD</title>
<indexterm>
<primary>LPD</primary>
<secondary>configuration</secondary>
</indexterm>
<indexterm>
<primary>configuration</primary>
<secondary>LPD</secondary>
</indexterm>


<para>Until recently most GNU/Linux distributions shipped with LPD. This section describes a very
basic setup for LPD; further sections detail the creation of
complex filters and network configuration.</para>

<sect3 id="basic-lpd-configuration">
<title>Basic LPD configuration</title>

<para>The minimal setup for lpd results in a system that can queue
files and print them.  It will not pay any attention to whether or
not your printer will understand them, and will probably not let
you produce attractive output.  But we have to start somewhere.</para>

<para>To add a print queue to lpd, you must add an entry in<filename>/etc/printcap</filename>, and make the new spool
directory under <filename>/var/spool/lpd</filename>.</para>

<para>An entry in <filename>/etc/printcap</filename> looks like:<programlisting><![CDATA[
# LOCAL djet500
lp|dj|deskjet:\
        :sd=/var/spool/lpd/dj:\
        :mx#0:\
        :lp=/dev/lp0:\
        :sh:
]]></programlisting>
This defines a spool called <emphasis>lp</emphasis>,<emphasis>dj</emphasis>, or <emphasis>deskjet</emphasis>, spooled
in the directory <filename>/var/spool/lpd/dj</filename>, with no
per-job maximum size limit, which prints to the device<filename>/dev/lp0</filename>, and which does not have a banner
page (with the name of the person who printed, etc) added to the
front of the print job.</para>

<para>Go now and read the man page for <filename><replaceable><ulink url="http://www.linuxprinting.org/man/printcap.5.html">printcap</ulink></replaceable></filename>.</para>

<para>The above looks very simple, but there a catch - unless I send in
files a DeskJet 500 can understand, this DeskJet will print
strange things.  For example, sending an ordinary Unix text file
to a deskjet results in literally interpreted newlines, and gets
me:<screen>
This is line one.
	This is line two.
		This is line three.</screen>
ad nauseam.  Printing a PostScript file to this spool would get a
beautiful listing of the PostScript commands, printed out with
this "staircase effect", but no useful output.</para>

<para id="lpd-filtering-example">
<indexterm>
<primary>
<option>if</option>
</primary>
</indexterm>
<indexterm>
<primary>LPD</primary>
<secondary>
<option>if</option>
</secondary>
</indexterm>Clearly more is needed, and this is the purpose of filtering.
The more observant of you who read the printcap man page might
have noticed the spool attributes <option>if</option> and<option>of</option>.  Well, <option>if</option>, or the
input filter, is just what we need here.</para>

<para>If we write a small shell script called <command>filter</command>
that adds carriage returns before newlines, the staircasing can
be eliminated.  So we have to add in an <option>if</option>
line to our printcap entry above:<programlisting><![CDATA[
lp|dj|deskjet:\
        :sd=/var/spool/lpd/dj:\
        :mx#0:\
        :lp=/dev/lp0:\
        :if=/var/spool/lpd/dj/filter:\
        :sh:
]]></programlisting>
A simple filter script might be:<programlisting><![CDATA[
#!perl
# The above line should really have the whole path to perl
# This script must be executable: chmod 755 filter
while(<STDIN>){chomp $_; print "$_\r\n";};
# You might also want to end with a form feed: print "\f";
]]></programlisting>
If we were to do the above, we'd have a spool to which we could
print regular Unix text files and get meaningful results.  (Yes,
there are four million better ways to write this filter, but few
so illustrative.  You are encouraged to do this more
efficiently.)</para>

<para>The only remaining problem is that printing plain text is really
not too hot - surely it would be better to be able to print
PostScript and other formatted or graphic types of output.  Well,
yes, it would, and it's easy to do.  The method is simply an
extension of the above linefeed-fixing filter.</para>

<para>Such a filter is called a <emphasis>magic</emphasis> filter. Don't bother
writing one yourself unless you print strange things - there are
a good many written for you already, and most have easy-to-use
interactive configuration tools.  You should simply select a
suitable pre-written filter:<variablelist id="lpd-filters-available-now"><title><indexterm><primary>LPD</primary><secondary>filters</secondary></indexterm><indexterm><primary>filtering</primary><secondary>LPD</secondary></indexterm></title><varlistentry id="lpdomatic-filter-available"><term>foomatic-rip<indexterm><primary>filters</primary><secondary>lpdomatic</secondary></indexterm><indexterm><primary>LPD</primary><secondary>lpdomatic</secondary></indexterm><indexterm><primary>lpdomatic</primary></indexterm><indexterm><primary>lpdomatic</primary><seealso>Foomatic</seealso></indexterm><indexterm><primary>Foomatic</primary><secondary>LPD</secondary></indexterm></term>
<listitem><para><ulink url="http://www.linuxprinting.org/lpd-doc.html">foomatic-rip</ulink> is a filter designed to use data from the 
LinuxPrinting.org printer database.  It supports essentially
all free software printer drivers, including regular
Ghostscript drivers, Uniprint drivers, and the assorted
filter programs floating around out there. foomatic-rip works with
CUPS, LPRng, LPD, GNUlpr, PPR, PDQ, no spooler. </para></listitem></varlistentry><varlistentry id="apsfilter-available-now"><term>APS Filter<indexterm><primary>filters</primary><secondary>APS Filter</secondary></indexterm><indexterm><primary>LPD</primary><secondary>APS Filter</secondary></indexterm><indexterm><primary>APS Filter</primary></indexterm></term><listitem><para><ulink url="http://www.apsfilter.org/">apsfilter</ulink> is a filter designed for use on a wide
variety of Unices.  It supports essentially all
Ghostscript drivers.  It, too, works with
various strains of LPD, including stock BSD and
LPRng.</para></listitem></varlistentry>
<varlistentry id="rhs-printfilters-available"><term>RHS-Printfilters<indexterm><primary>filters</primary><secondary>rhs-printfilters</secondary></indexterm><indexterm><primary>rhs-printfilters</primary></indexterm><indexterm><primary>LPD</primary><secondary>rhs-printfilters</secondary></indexterm></term><listitem><para>RHS-Printfilters is a filter system constructed by Red Hat.
It shipped beginning, I think, in version 4 of Red Hat Linux,
as the backend to the easy-to-use <command>printtool</command> GUI printer configuration tool.
</para>
<para>The rhs filter system is built on an ASCII database listing
distributed with it.  This listing supports many Ghostscript
and Uniprint drivers, but not filter-style drivers.  The
filters constructed also do not support much in the way of
user-controllable options at print time.</para><para>
The <command>printtool</command> places a configuration file
named <filename>postscript.cfg</filename> in the spool
directory.  Inside this Bourne shell-style file, each setting
is a variable.  In unusual cases, you can make useful changes
directly to the config file which the printtool won't allow;
typically this would be the specification of an unusual
Ghostscript driver, or a PPD filename for the VA
rhs-printfilters version.</para><para>
VA Linux has made some enhancements to the rhs-printfilters
system under contract from HP.  With the proper versions, it
is possible to select options for Postscript printers
under control of Adobe PPD files.  I cover this system in<xref linkend="lpd-for-postscript-printers"/>.</para></listitem></varlistentry></variablelist></para>

<para>There's one catch to such filters: older version of lpd don't run
the <emphasis>if</emphasis> filter for remote printers, while
most newer ones do (although often with no arguments).  The
version of LPD shipped with modern GNU/Linux and FreeBSD
distributions does; most commercial Unices that still ship LPD
have a version that does not.  See the section on network
printing later in this document for more information on this.  If
you only have locally-connected printers, then this won't affect
you.</para>
</sect3>

<sect3 id="lpd-for-postscript-printers">
<title>LPD for PostScript Printers</title>
<indexterm>
<primary>PostScript</primary>
<secondary>printers</secondary>
</indexterm>
<indexterm>
<primary>PostScript</primary>
<secondary>LPD</secondary>
</indexterm>
<indexterm>
<primary>LPD</primary>
<secondary>PostScript</secondary>
</indexterm>
<indexterm>
<primary>LPD</primary>
<secondary>VA Linux's version</secondary>
</indexterm>
<indexterm>
<primary>VA Linux</primary>
<secondary>LPD</secondary>
</indexterm>


<para>While most versions of LPD don't gracefully handle PostScript
     (never mind user options), VA Linux modified LPD and Red
Hat's filtering software to support PostScript printers fairly
well. Because the intention was to donate the code to the gnu project, they called it <ulink url="http://lpr.sourceforge.net/">GNUlpr</ulink></para>
<simplesect>
<title>How it works</title>

<para>VA's system uses Postscript Printer Definition, or PPD,
files.  PPD files are provided by printer manufacturers and
declare the available options on a printer, along with the
Postscript code needed to activate them.  With the VA system,
the normal LPD scheme works a little differently:<orderedlist><listitem><para>The user can specify options with the <option>-o</option>
flag.  For example, you might specify <option>-o
MediaType:Transparency</option> if you were about to print on
overhead film.  Alternatively, the front-end <ulink url="http://www.compumetric.com/linux.html">GPR</ulink> can
be used to specify options in a dialog box; you can see
screenshots of GPR in <xref linkend="gpr-intro"/>.</para></listitem><listitem><para>LPR passes the options to LPD as an extended attribute in the
LPD control file.</para></listitem><listitem><para>A modified version of the rhs-printfilters package is given
the extended options data in an environment variable, and
uses ppdfilt to add these options to the print data.</para></listitem></orderedlist></para>
</simplesect>

<simplesect>
<title>Obtaining and Installing</title>

<para>You can obtain RPM packages, or source tarballs, from the
project's <ulink url="http://sourceforge.net/projects/lpr">website
on SourceForge</ulink>.  For installation details, consult the
project's <ulink url="http://printing.sourceforge.net/gpr-libppd-uhowto.html">installation
micro-HOWTO</ulink>.   In essence, you need to uninstall the Red
Hat version of printtool, lpd, and rhs-printfilters entirely,
and then install the VA versions, plus ppdfilt, gpr, and a few
other utilities.</para>

<para>You will also need PPD files for your Postscript printers.
PPD files are usually fairly easy to find.  VA Linux and HP
distribute PPD files for many Laserjet models.  Other vendors
provide PPDs for their own printers, and Adobe distributes <ulink url="http://www.adobe.com/products/printerdrivers/winppd.html">PPD files</ulink> for many printers.</para>

<para>At the moment, much of this is a bit difficult to install.  But
future installation tools will build upon the printer
configuration library <command>libprinterconf</command>, which
enables both the autodetection and rhs-printfilter configuration
of both networked and local printers.</para>
<note>
<para>It is possible to use GPR alone, without the modified LPD
or even rhs-printfilters.  GPR can be compiled with
all the logic needed to massage Postscript jobs directly.
This may be an easier-to-install option suitable for
people who never really need to print using lpr
directly.</para>
</note>
</simplesect>

<simplesect>
<title>Controlling Postscript Options</title>
<para>Once you've setup VA's Postscript-capable LPD system (GNUlpr), you can
control your printer's options in two ways:<variablelist><varlistentry><term>With the GUI</term><listitem><para>To use GPR, you first make sure that you've specified the
proper PPD file.  Then the printer's options will be
available on the `Advanced' panel.  Basic <command>ppdfilt</command> options will be available on the
	  `Common' panel.</para></listitem></varlistentry><varlistentry><term>With the command line</term><listitem><para>This <command>lpr</command> supports the <option>-o</option>
option.  You may specify any option/value pair from your
printer's PPD file with <option>-o</option>.  For example,
consider this PPD file option clause:<programlisting><![CDATA[
*OpenUI *PrintQuality/Print Quality: PickOne
*DefaultPrintQuality: None
*OrderDependency: 150 AnySetup *PrintQuality
*PrintQuality None/Printer Setting: ""
*PrintQuality Quick/QuickPrint:  "<< /DeviceRenderingInfo ...
*PrintQuality Normal/Normal: "<< /DeviceRenderingInfo << /...
*PrintQuality Pres/Presentation: "<< /DeviceRenderingInfo ...
*PrintQuality Image/1200 Image Quality: "<< /DeviceRenderi...
*CloseUI: *PrintQuality
]]></programlisting>
For the option <option>PrintQuality</option>, the possible
values are <option>Quick</option>, <option>Normal</option>,<option>Pres</option>, or <option>Image</option>.  You might
give a command like:<screen><prompt>%</prompt> <command>lpr</command> <option>-o PrintQuality:Image</option> <option>file.ps</option></screen></para><para>
There are a number of options common to all printers which
will work in addition to the ones from your PPD.  These
include:<variablelist><varlistentry><term><option>page-ranges</option></term><listitem><para>You can specify a range of pages to print.  For example,<option>page-ranges:2-3</option>.</para></listitem></varlistentry><varlistentry><term><option>page-set</option></term><listitem><para>You can print only odd or even pages.  For example,<option>page-set:odd</option>.</para></listitem></varlistentry><varlistentry><term><option>number-up</option></term><listitem><para>You can print multiple pages on each piece of paper.
For example, <option>number-up:2</option>.</para></listitem></varlistentry></variablelist>

Other options are detailed in the <command>ppdfilt</command>
man page.</para></listitem></varlistentry></variablelist></para>
</simplesect>
</sect3>

<sect3 id="lpd-permissions">
<title>File Permissions</title>
<indexterm>
<primary>LPD</primary>
<secondary>permissions</secondary>
</indexterm>

<para>By popular demand, I include below a listing of the permissions
on interesting files on my system.  There are a number of better
ways to do this, ideally using only SGID binaries and not making
everything SUID root, but this is how my system came out of the
box, and it works for me.  (Quite frankly, if your vendor can't
even ship a working lpd you're in for a rough ride).<screen>
-r-sr-sr-x   1 root     lp    /usr/bin/lpr*
-r-sr-sr-x   1 root     lp    /usr/bin/lprm*
-rwxr--r--   1 root     root  /usr/sbin/lpd*
-r-xr-sr-x   1 root     lp    /usr/sbin/lpc*
drwxrwxr-x   4 root     lp    /var/spool/lpd/
drwxr-xr-x   2 root     lp    /var/spool/lpd/lp/</screen></para>

<para>Lpd must currently be run as root so that it can bind to the
low-numbered lp service port.  It should probably become UID
lp.lp or something after binding, but I don't think it does.
This is simply one more reason to avoid the stock BSD LPD.</para>
</sect3>
</sect2>

<sect2 id="large-installations">
<title>Large Installations</title>
<indexterm>
<primary>networks</primary>
<secondary>large</secondary>
</indexterm>
<indexterm>
<primary>environment</primary>
<secondary>enterprise</secondary>
</indexterm>

<para>Large installations, by which I mean networks including more than
two printers or hosts, have special needs.  Below are some tips.</para>
<para>CUPS has some nice features that make a good choice for a large network. Printer classes, access control and automatic client configuration to name a few.</para>
<para>If you use LPD, for really large environments, merely distributing printcap/filter
information becomes a difficult problem; the <ulink url="http://ceps.sourceforge.net/">Cisco Enterprise Print
System</ulink> addresses this and is probably either a good starting
point or a nearly complete solution, depending on your needs.
Medium to large environments can be well supported by native LPRng
features.
<itemizedlist>
<listitem><para>Each printer should have a single point of control, where an
administrator can pause, reorder, or redirect the queue.  To
implement this, have everyone printing to a local server,
which will then queue jobs and direct them to the proper
printer.  For large campuses or distributed networks, have one
server per building or other suitable network subset.</para></listitem>
<listitem><para>Use CUPS or LPRng, at least on servers; the BSD LPD is too buggy for
       "real" use. But don't take my word for it&mdash;you should test a number of
spoolers and see which suits you best.</para></listitem>
<listitem><para>Client systems should not have unique printing configurations. CUPS provides automatic client configuration of printers on the same subnet. You can even configure CUPS (BrowsePoll) to poll servers on other subnets for available printers. These features limit the amount of configuration that needs to take place at the client.
To implement a uniform printing configuration with LPRng, use LPRng's extended printcap syntax so
that you have one printcap to use everywhere.  CEPS provides
for this by building atop a lightweight distributed database
instead of traditional printcap files.</para></listitem>
<listitem><para>Print queues should not be named for make or model; name print
queues for something sensible like location (floor2&lowbar;nw)
or capability (color&lowbar;transparency).  Three years from
now, when a printer breaks, you will be able to replace it
with a different make or model without causing confusion.</para></listitem>
<listitem><para>Operate a web page which shows detailed information on each
printer, including location, capabilities, etc.  Consider
having it show the queue and include a button to remove jobs
from the queue.  Complex networked environments are
unmanageable for users without proper documentation.</para></listitem>
<listitem><para>On Windows and Apple systems, use either the platform-specific
drivers <emphasis>everywhere</emphasis> (Samba supports the
Windows automagical driver-download mechanism) or, better, use
generic Postscript drivers <emphasis>everywhere</emphasis>.  Do
not mix and match; primitive word processors often produce
different output when the installed printer driver changes;
users cannot deal with output that varies depending on the
particular client/printer pair.</para></listitem>
<listitem><para>If at all possible, buy a large-volume printer for
large-volume printing.  If on a budget, use LPRng's multiple
printers/one queue facility or CUPS printer classes and assign a babysitter; printers
are complex mechanical devices that will often jam and run out
of paper in such configurations.</para></listitem>
<listitem id="network-print-servers-in-large"><indexterm><primary>networks</primary><secondary>print servers</secondary></indexterm><para>Do not feel that printers must be plugged into workstations;
Ethernet "print servers" now cost under $100.  The ability to
locate printers anywhere you can network is a big improvement
over forced location near a host; locate printers in sensible,
central locations.</para></listitem>
<listitem><indexterm><primary>npadmin</primary><secondary>uses</secondary></indexterm>
<para>Use any SNMP trap or other monitoring/alert facility available
to you - someone should be tasked with running around and
fixing printers with no ink or paper.  Npadmin (see <xref linkend="npadmin"/>) can be used to do some management
operations with SNMP printers.</para></listitem>
</itemizedlist>
</para>
</sect2>

<sect2 id="accounting">
<title>Accounting</title>
<indexterm>
<primary>accounting</primary>
</indexterm>
<indexterm>
<primary>LPD</primary>
<secondary>accounting</secondary>
</indexterm>

<para>Regular LPD provides very little to help you with accounting.  You
can specify the name of an accounting file in the <option>af</option> printcap attribute, but this is merely passed
as an argument to your <option>if</option> filter.  It's up to you
to make your <option>if</option> filter write entries to the
accounting file, and up to you to process the accounting file
later (the traditional format is mainly useful for line printers,
and is nontrivial to parse in Perl, so there's no reason to
preserve it).  Also, if you're using <command>foomatic-rip</command> program as your filter, you'll need
to make changes, since it depends on being given a configuration
file as the ``accounting'' file name.</para>
<para>CUPS provides page accounting by passing jobs through the pstops filter. This filter expects Postscript input. If you use print &quot;raw&quot; jobs, this is always counted as 1 page. This means that accounting will not work, if you print from Windows client with the native printer driver.</para>


<para id="gs-accounting">
<indexterm>
<primary>Ghostscript</primary>
<secondary>accounting</secondary>
</indexterm>Ghostscript provides a PageCount operator that you can use to
count the number of pages in each job; basically you just tack a
few lines of postscript onto the end of the job to write an
accounting file entry; for the best example of this see the file<filename>unix-lpr.sh</filename> in the Ghostscript source
distribution.</para>

<para>Note that the <command>unix-lpr</command> implementation of
accounting writes to a file from the Ghostscript interpreter, and
is thus incompatible with the recommended -dSAFER option.  A
better solution might be to query the printer with a PJL command
after each job, or to write a postscript snippet that prints the
pagecount on stdout, where it can be captured without having to
write to a file.</para>

<para id="lprng-accounting">
<indexterm>
<primary>LPRng</primary>
<secondary>accounting</secondary>
</indexterm>The LPRng print spooler includes an HP-specific sample
implementation of accounting; I assume that it queries the
printer with PJL.  This technique should work for most PJL,
Postscript, or SNMP printers with which you have two-way
communications.</para>

<indexterm>
<primary>npadmin</primary>
<secondary>uses</secondary>
</indexterm>
<para>If you have a networked printer that supports SNMP, you can use
the npadmin program to query a pagecount after each job.  This
should work properly for all print jobs.  See <xref linkend="npadmin"/> for more information on npadmin.</para>
</sect2>
</sect1>

<sect1 id="vendors">
<title>Vendor Solutions</title>

<para>This section is, by definition, incomplete.  Feel free to send in
details of your favorite distribution.</para>

<para>There are a number of third-party packages out there designed to
make printer configuration under Unix easy.  These are covered in <xref linkend="setup"/>; see the subsection there for your
particular spooling software for pointers.</para>

<sect2 id="rhs-filters-come-with-redhat">
<title>Red Hat</title>
<indexterm>
<primary>Red Hat</primary>
</indexterm>
<indexterm>
<primary>filters</primary>
<secondary>rhs-printfilters</secondary>
</indexterm>

<para>Red Hat has a GUI printer administration tool called printtool
which can add remote printers and printers on local devices.  It
lets you choose a ghostscript-supported printer type and Unix
device file to print to, then installs a print queue in<filename>/etc/printcap</filename> and uses a filter program from
the rhs-printfilters package to support postscript and other
common input types.  This solution works fairly well, and is
trivial to setup for common cases.</para>

<para>Red Hat 6.x shipped a BSD LPD flavor; Red Hat 7.x and 8.0 appear to
default to using LPRng.</para>

<para>Where Red Hat 6.x and 7.x fail is when you have a printer which isn't
supported by their standard Ghostscript (which is GNU rather than
Aladdin Ghostscript, and which supports fewer printers).  Check in
the printer compatibility list above (or <ulink url="http://www.linuxprinting.org/printer_list.cgi">online</ulink>) if you find that you can't print properly with the stock Red
Hat software.  If your printer isn't supported by Red Hat's tools,
you may need to install a contributed venison of Aladdin
Ghostscript, and will probably also be better off if you use the
lpdomatic or apsfilter packages, which know all about the printers
supported by late-model Ghostscripts, and others besides.</para>
<para>Red Hat 8.0 still installs LPRng by default although you can select CUPS. But even if you explicitly select only CUPS, LPRng is still installed. In Red Hat 8.1 CUPS will finally be the default spooler.</para>
<para>Red Hat 9.0 finally uses CUPS as default spooler.</para>

</sect2>

<sect2 id="debian-what-comes-with">
<title>Debian</title>
<indexterm>
<primary>Debian</primary>
</indexterm>

<para>Debian offers a choice between plain LPD, LPRng, or CUPS; LPRng or
CUPS are probably the better choices.  PDQ is provided in the
unstable tree (currently called sid).  Debian also offers a choice
of printer configuration tools; apsfilter version 5 or later is
probably your best bet, since that venison adds support for LPRng
and Ghostscript's uniprint driver scheme.  Red Hat's printtool is
also supported, for those who like GUI administration tools.</para>
</sect2>

<sect2 id="suse-what-comes-with">
<title>SuSE</title>
<indexterm>
<primary>SuSE</primary>
</indexterm>
<indexterm>
<primary>APS Filter</primary>
<secondary>SuSE</secondary>
</indexterm>
<indexterm>
<primary>filters</primary>
<secondary>APS Filter</secondary>
</indexterm>

<para>The printing system on SuSE Linux is based on apsfilter, with some
enhancements; SuSE's apsfilter will recognize all common file
formats (including HTML, if html2ps is installed).  There are two
ways to setup printers on SuSE systems:<itemizedlist><listitem><para>YaST will let you configure "PostScript", "DeskJet" and "Other
printers", supported by Ghostscript drivers; it's also possible
to setup HP's GDI printers (DeskJet 710/720, 820, 1000, via the
       "ppa" package).  YaST will provide<filename>/etc/printcap</filename> entries for every printer
       ("raw", "ascii", "auto" and "color", if the printer to
configure is a color printer).  YaST will create spool
directories and it will arrange apsfilterrc files, where you're
able to fine tune some settings (Ghostscript preloads, paper
size, paper orientation, resolution, printer escape sequences,
etc.).  With YaST it's also possible to setup network printers
       (TCP/IP, Samba, or Novell Netware Printer).</para></listitem><listitem><para>In addition SuSE includes the regular SETUP program from the
original apsfilter package (with some enhancements); run<command>lprsetup</command> to invoke this configuration
script.  Once you get accustomed to its GUI, you'll be able to
configure local and network printers.</para></listitem></itemizedlist></para>

<para>The SuSE installation manual explains both of these setup
procedures.</para>

<para>Wolf Rogner reported some difficulties with SuSE.  Apparently the
following bugs may bite:<itemizedlist><listitem><para>Apsfilter's regular SETUP script is a bit broken, as are the
KDE setup tools.  Use YaST.  [ Ed: does this still apply?  It's
been some time Wolf's report. ]</para></listitem><listitem><para>For networked printers that need to be fed from Ghostscript,
you'll need to first uncomment the line
REMOTE&lowbar;PRINTER="remote" in <filename>/etc/apsfilterrc</filename>.  Then run YaST to
configure the printer and, under Network configurations, set up
a remote printer queue.</para></listitem><listitem><para>YaST's setup doesn't allow color laser printers, so configure a
mono printer and then change mono to color everywhere in the
printcap entry.  You may have to rename the spool directory,
too.</para></listitem></itemizedlist></para>
</sect2>

<sect2 id="caldera-what-comes-with">
<title>Caldera</title>
<indexterm>
<primary>Caldera</primary>
</indexterm>
<indexterm>
<primary>LPRng</primary>
<secondary>Caldera</secondary>
</indexterm>

<para>Caldera ships LPRng.  I have no idea what sort of setup tools they
offer.</para>

<para>I've just signed up a Caldera employee as a maintainer of the
LinuxPrinting.org database; evidently they plan to ship a CUPS and
Foomatic-based print system in future releases.</para>
</sect2>


<sect2 id="corel-what-comes-with">
<title>Corel</title>
<indexterm>
<primary>Corel</primary>
</indexterm>
<indexterm>
<primary>Debian</primary>
<secondary>Corel</secondary>
</indexterm>

<para>Corel is Debian-based, so all the Debian facts above should still
apply.  In addition, they've written their own setup
tool, based on the sysAPS library which in turn uses my database.
They've certainly done so as part of WordPerfect.</para>

<para>Corel operates a printing support newsgroup named <ulink url="news://cnews.corel.com/corelsupport.linux.printing">corelsupport.linux.printing</ulink>.  The bulk of the traffic
appears to be WordPerfect and Corel Linux related.</para>
</sect2>

<sect2 id="mandrake-what-comes-with">
<title>Mandrake</title>
<indexterm>
<primary>Mandrake</primary>
</indexterm>
<indexterm>
<primary>Foomatic</primary>
<secondary>Mandrake</secondary>
</indexterm>


<para>As of version 7.2b1, Mandrake ships with CUPS standard.  The
program QtCUPS is used to provide a clean GUI administration
interface.  Till went to some trouble to include as many drivers
as possible, and they ship CUPS PPD files build with my own <ulink url="http://www.linuxprinting.org/foomatic.html">foomatic</ulink>
interface code. Mandrake was the first distro to ship CUPS.</para>

<para>I think Earlier Mandrake versions shipped with the Red Hat
printtool.</para>
</sect2>

<sect2 id="slackware-what-comes-with">
<title>Slackware</title>
<indexterm>
<primary>Slackware</primary>
</indexterm>

<para>Slackware ships with APS Filter.  The apsfilter SETUP script is
installed as the command `apsfilterconfig'.  You should be able to
get a reasonable setup by simply running that.</para>

<para>As of Slackware 9.0, CUPS is included in the extras dir of slackware but the default is still LPRng + APSFilter.</para>
</sect2>

<sect2 id="other-dists">
<title>Other Distributions</title>

<para>Please send me info on what other distributions do!</para>
</sect2>
</sect1>

<sect1 id="ghostscript">
<title>Ghostscript.</title>
<indexterm>
<primary>Ghostscript</primary>
</indexterm>
<indexterm>
<primary>Postscript</primary>
<seealso>Ghostscript</seealso>
</indexterm>

<para>
<ulink url="http://www.cs.wisc.edu/~ghost/">Ghostscript</ulink> is
an incredibly significant program for free software-driven
printing.  Most printing software under Unix generates PostScript,
which is typically a &dollar;100 option on a printer.  Ghostscript,
however, is free, and will generate the language of your printer
from PostScript.</para>

<para>Ghostscript is available in several forms.  The commercial version of
Ghostscript, called Aladdin Ghostscript, may be used freely for
personal use but may not be distributed by commercial entities.  It
is generally a year or so ahead of the free Ghostscript; at the
moment, for example, it supports many color inkjets that the older
Ghostscripts do not and has rather better PDF support.</para>

<para>The main free version of Ghostscript is GNU Ghostscript, and is
simply an aged version of Aladdin ghostscript.  This somewhat
awkward arrangement has allowed Aladdin to be a totally self-funded
free software project; the leading edge versions are done by L
Peter and a few employees, and are licensed to hardware and
software vendors for use in commercial products.  Unfortunately,
while this scheme has provided for L Peter's continued work on
Ghostscript for years, it has also inhibited the participation of
the wider free software community.  Driver authors, in particular,
find the arrangement poor.  L Peter's retirement plans mandate a
larger community involvement in the project, so he is considering
license changes, and has established a SourceForge project.</para>

<para>The third version of Ghostscript is ESP Ghostscript, maintained by
Easy Software Products (authors of CUPS) under contract from Epson.
ESP Ghostscript is a combination of the gimp-print driver project's
drivers and GNU Ghostscript, plus assorted usability patches.  This
version is not yet in full swing, but it will be available soon,
and will hopefully simplify life for owners of Gimp-print-driven
printers.</para>

<para>Whatever you do with <command><ulink url="http://www.linuxprinting.org/man/gs.1.html">gs</ulink></command>, be very sure to run it with the option for disabling
file access (<option>-dSAFER</option>).  PostScript is a fully
functional language, and a bad PostScript program could give you
quite a headache.</para>

<para>Speaking of PDF, Adobe's Portable Document Format (at least through
1.3) is actually little more than organized PostScript in a
compressed file.  Ghostscript can handle PDF input just as it does
PostScript.  So you can be the first on your block with a
PDF-capable printer.</para>

<sect2 id="invoking-gs">
<title>Invoking Ghostscript</title>

<para>Typically, Ghostscript will be run by whatever filter you settle
upon (I recommend Foomatic if your vendor didn't supply anything
that suits you), but for debugging purposes it is often handy to
run it directly.</para>

<para>
<command>gs -help</command>will give a brief listing of options
and available drivers (note that this list is the list of drivers
compiled in, not the master list of all available drivers).</para>

<para>You might run gs for testing purposes like: `<command>gs
	  &lt;options&gt; -q -dSAFER -sOutputFile=/dev/lp1
test.ps</command>'.</para>
</sect2>

<sect2 id="gs-tuning-stuff">
<title>Ghostscript output tuning</title>
<indexterm>
<primary>Ghostscript</primary>
<secondary>tuning</secondary>
</indexterm>

<para>There are a number of things one can do if Ghostscript's output is
not satisfactory (actually, you can do anything you darn well
please, since you have the source).</para>

<para>Some of these options, and others are described in the Ghostscript
User Guide (the file <filename><replaceable><ulink url="http://www.cs.wisc.edu/~ghost/aladdin/doc/Use.htm">Use.htm</ulink></replaceable></filename> in the Ghostscript distribution;
possibly installed under <filename>/usr/doc</filename> or<filename>/usr/share/doc</filename> on your system) are all
excellent candidates for driver options in your filter system.</para>

<sect3 id="gs-output-loc-size">
<title>Output location and size</title>

<para>The location, size, and aspect ratio of the image on a page is
controlled by the printer-specific driver in ghostscript.  If you
find that your pages are coming out scrunched too short, or too
long, or too big by a factor of two, you might want to look in
your driver's source module and adjust whatever parameters jump
out at you.  Unfortunately, each driver is different, so I can't
really tell you what to adjust, but most of them are reasonably
well commented.</para>
</sect3>

<sect3 id="gsgamma">
<title>Gamma, dotsizes, etc.</title>
<indexterm>
<primary>photograph</primary>
<secondary>gamma</secondary>
</indexterm>


<para>Most non-laser printers suffer from the fact that their dots are
rather large. This results in pictures coming out too dark. If
you experience this problem with an otherwise untunable driver,
you could use your own transfer function.  Simply create the
following file in the ghostscript lib-dir and add its name to the
gs call just before the actual file. You may need to tweak the
actual values to fit your printer. Lower values result in a
brighter print.  Especially if your driver uses a Floyd-Steinberg
algorithm to rasterize colors, lower values ( 0.2 - 0.15 ) are
probably a good choice.</para>

<para>
<programlisting><![CDATA[
%!
%transfer functions for cyan magenta yellow black
{0.3 exp} {0.3 exp} {0.3 exp} {0.3 exp} setcolortransfer
]]>

</programlisting>
</para>

<para>It is also possible to mend printers that have some kind of
color fault by tweaking these values. If you do that kind of
thing, I recommend using the file<filename>colorcir.ps</filename>, that comes with ghostscript (in
the <filename>examples/</filename> subdirectory), as a test page.</para>

<para>For many of the newer color inkjet drivers, there are
command-line options, or different upp driver files, which
implement gamma and other changes to adapt the printer to
different paper types.  You should look into this before playing
with Postscript to fix things.</para>
</sect3>

<sect3 id="gscolor">

<title>Color Printing in Ghostscript</title>
<indexterm>
<primary>photograph</primary>
<secondary>color</secondary>
</indexterm>

<para>Ghostscript's default color dithering is optimized for
low-resolution devices.  It will dither rather coarsely in an
attempt to produce 60ppi output (not dpi, ppi - the "apparent"
color pixels per inch you get after dithering).  This produces
rather poor output on modern color printers; inkjets with photo
paper, in particular, are capable of much finer ppi settings.</para>

<para>To adjust this, use the Ghostscript option<option>-dDITHERPPI=x</option>, where <option>x</option> is the
value to use.  This may or may not have an effect with all
drivers; many newer drivers (the Epson Stylus<command>stp</command> driver, for example) implement their own
dithering and pay no attention to this setting.  Some drivers can
use either the regular Ghostscript or driver-specific dithering
     (the Canon Bubblejet <command>bjc600</command> driver, for
example).</para>

<para>Ghostscript's dithering is in fact rather rudimentary.  Many
things needed for good output on modern printers are simply not
available in the Ghostscript core.  Various projects to fix this
situation&mdash;and the free software world does have the
software to do so ready and waiting&mdash;are hampered by
Ghostscript's licensing situation and the resulting "cathedral"
development style.  Beginning at the <ulink url="http://www.linuxprinting.org/summit.html">Open Source
Printing Summit 2000</ulink>, however, all the necessary people are
talking, so you can expect this situation to improve shortly.</para>
</sect3>
</sect2>
</sect1>

<sect1 id="network">
<title>Networks</title>
<indexterm>
<primary>networks</primary>
</indexterm>


<para>One of the features of most spoolers is that they support printing
over the network to printers physically connected to a different
machine, or to the network directly.  With the careful combination
of filter scripts and assorted utilities, you can print
transparently to printers on all sorts of networks.</para>

<sect2 id="network-to-unix">
<title>Printing to a Unix/lpd host</title>
<indexterm>
<primary>networks</primary>
<secondary>Unix</secondary>
</indexterm>
<indexterm>
<primary>networks</primary>
<secondary>LPD</secondary>
</indexterm>
<indexterm>
<primary>LPD</primary>
<secondary>Unix networks</secondary>
</indexterm>


<para>To allow remote machines to print to your printer using the LPD
protocol, you must list the machines in<emphasis>/etc/hosts.equiv</emphasis> or<emphasis>/etc/hosts.lpd</emphasis>.  (Note that<emphasis>hosts.equiv</emphasis> has a host of other effects; be
sure you know what you are doing if you list any machine there).
You can allow only certain users on the other machines to print to
your printer by using the <emphasis>rs</emphasis> attribute; read
the <literal remap="tt"><ulink url="http://www.linuxprinting.org/man/lpd.8.html">lpd</ulink></literal> man page for information on this.</para>

<sect3 id="network-to-unix-with-lpd">
<title>With <literal remap="tt">lpd</literal></title>

<para>To print to another machine, you make an<emphasis>/etc/printcap</emphasis> entry like this:<screen>
# REMOTE djet500
lp|dj|deskjet:\
        :sd=/var/spool/lpd/dj:\
        :rm=machine.out.there.com:\
        :rp=printername:\
        :sh:</screen>
Note that there is still a spool directory on the local machine
managed by <literal remap="tt">lpd</literal>.  If the remote
machine is busy or offline, print jobs from the local machine
wait in the spool area until they can be sent.</para>
</sect3>

<sect3 id="network-to-unix-with-rlpr">
<title>With <literal remap="tt">rlpr</literal></title>
<indexterm>
<primary>rlpr</primary>
</indexterm>
<indexterm>
<primary>networks</primary>
<secondary>rlpr</secondary>
</indexterm>


<para>You can also use <emphasis>rlpr</emphasis> to send a print job
directly to a queue on a remote machine without going through the
hassle of configuring lpd to handle it.  This is mostly useful in
situations where you print to a variety of printers only
occasionally.  From the announcement for<emphasis>rlpr</emphasis>:</para>

<para>Rlpr uses TCP/IP to send print jobs to lpd servers anywhere on a
network.</para>

<para>Unlike lpr, it *does not* require that the remote printers be
explicitly known to the machine you wish to print from,
     (e.g. through <emphasis>/etc/printcap</emphasis>) and thus is
considerably more flexible and requires less administration.</para>

<para>rlpr can be used anywhere a traditional lpr might be used, and is
backwards compatible with traditional BSD lpr.</para>

<para>The main power gained by rlpr is the power to print remotely
     *from anywhere to anywhere* without regard for how the system you
wish to print from was configured.  Rlpr can work as a filter
just like traditional lpr so that clients executing on a remote
machine like netscape, xemacs, etc, etc can print to your local
machine with little effort.</para>

<para>Rlpr is available from <literal remap="tt"><ulink url="ftp://metalab.unc.edu/pub/Linux/system/printing/">Metalab</ulink></literal>.</para>
</sect3>
</sect2>

<sect2 id="network-to-windows">
<title>Printing to a Windows or Samba printer</title>
<indexterm>
<primary>networks</primary>
<secondary>Windows</secondary>
</indexterm>
<indexterm>
<primary>Windows</primary>
<secondary>printing to</secondary>
</indexterm>


<para>There is a Printing to Windows mini-HOWTO out there which has more
info than there is here.</para>


<sect3 id="network-to-windows-with-lpd">
<title>From LPD</title>
<indexterm>
<primary>LPD</primary>
<secondary>Windows networks</secondary>
</indexterm>


<para>It is possible to direct a print queue through the <literal remap="tt"><ulink url="http://www.linuxprinting.org/man/smbclient.1.html">smbclient</ulink></literal> program (part of the Samba suite)
to a TCP/IP based SMB print service.  Samba includes a script to
do this called <literal remap="tt">smbprint</literal>.  In short,
you put a configuration file for the specific printer in question
in the spool directory, and install the <literal remap="tt">smbprint</literal> script as the<emphasis>if</emphasis>.</para>

<para>The <emphasis>/etc/printcap</emphasis> entry goes like this:<screen>
lp|remote-smbprinter:\
    :sh:\
    :lp=/dev/null:\
    :sd=/var/spool/lpd/lp:\
    :if=/usr/local/sbin/smbprint:</screen></para>

<para>You should read the documentation inside the <literal remap="tt">smbprint</literal> script for more information on how
to set this up.</para>

<para>You can also use <literal remap="tt">smbclient</literal> to
submit a file directly to an SMB printing service without
involving <literal remap="tt">lpd</literal>.  See the man page.</para>
</sect3>
</sect2>

<sect2 id="network-to-netware">
<title>Printing to a NetWare Printer</title>
<indexterm>
<primary>networks</primary>
<secondary>Netware</secondary>
</indexterm>
<indexterm>
<primary>Netware</primary>
<secondary>printing to</secondary>
</indexterm>
<para>The ncpfs suite includes a utility called <literal remap="tt">nprint</literal> which provides the same functionality
as <literal remap="tt">smbprint</literal> but for NetWare.  You
can get ncpfs from <ulink url="ftp://metalab.unc.edu/pub/Linux/system/filesystems/ncpfs/">Metalab</ulink>.  From the LSM entry for version 0.16:</para>

<para>
<quote>With ncpfs you can mount volumes of your NetWare server under
Linux. You can also print to NetWare print queues and spool
NetWare print queues to the Un*x print spooler. You need
kernel 1.2.x or 1.3.54 and above. ncpfs does NOT work with any
1.3.x kernel below 1.3.54.</quote>
</para>

<sect3 id="network-to-netware-with-lpd">
<title>From LPD</title>
<indexterm>
<primary>LPD</primary>
<secondary>Netware networks</secondary>
</indexterm>


<para>To make <literal remap="tt">nprint</literal> work via lpd, you
write a little shell script to print stdin on the NetWare
printer, and install that as the <emphasis>if</emphasis> for an
lpd print queue.  You'll get something like:<screen>
sub2|remote-NWprinter:\
        :sh:\
        :lp=/dev/null:\
        :sd=/var/spool/lpd/sub2:\
        :if=/var/spool/lpd/nprint-script:</screen>

The <literal remap="tt">nprint-script</literal> might look
approximately like:<screen>
#! /bin/sh
# You should try the guest account with no password first!
/usr/local/bin/nprint -S net -U name -P passwd -q printq-name -</screen></para>
</sect3>
</sect2>

<sect2 id="network-to-apple">
<title>Printing to an EtherTalk (Apple) printer</title>
<indexterm>
<primary>networks</primary>
<secondary>Apple</secondary>
</indexterm>
<indexterm>
<primary>Apple</primary>
<secondary>printing to</secondary>
</indexterm>


<para>The netatalk package includes something like <literal remap="tt">nprint</literal> and <literal remap="tt">smbclient</literal>.  Others have documented the
procedure for printing to and from an Apple network far better
than I ever will; see the <ulink url="http://thehamptons.com/anders/netatalk/">Linux
Netatalk-HOWTO</ulink>.</para>
</sect2>

<sect2 id="networked-printers">
<title>Printing to a networked printer</title>
<indexterm>
<primary>networks</primary>
<secondary>network printers</secondary>
</indexterm>
<indexterm>
<primary>networks</primary>
<secondary>print servers</secondary>
</indexterm>


<indexterm>
<primary>LPD</primary>
<secondary>network printers</secondary>
</indexterm>

<para>Many printers come with an ethernet interface which you can print
to directly, typically using the LPD protocol.  You should
follow the instructions that came with your printer or its network
adaptor, but in general, such printers are "running" lpd, and
provide one or more queues which you can print to.  An HP, for
example, might work with a printcap like:<screen>
lj-5|remote-hplj:\
        :sh:\
        :sd=/var/spool/lpd/lj-5:\
        :rm=printer.name.com:\
        :rp=raw:</screen></para>

<para>HP Laserjet printers with JetDirect interfaces generally support
two built in lpd queues - "raw" which accepts PCL (and possibly
Postscript) and "text" which accepts straight ascii (and copes
automatically with the staircase effect).  If you've got a
JetDirect Plus3 three-port box, the queues are named "raw1",
    "text2", and so forth.</para>

<para>Note that the ISS company has identified an assortment of denial
of service attacks which hang HP Jetdirect interfaces.  Most of
these have been addressed beginning in Fall 98.  These sorts of
problems are common in embedded code; few appliance-style devices
should be exposed to general Internet traffic.</para>

<indexterm>
<primary>environment</primary>
<secondary>enterprise</secondary>
</indexterm>
<para>In a large scale environment, especially a large environment where
some printers do not support PostScript, it may be useful to
establish a dedicated print server to which all machines print and
on which all ghostscript jobs are run.  This will allow the queue
to be paused or reordered using the topq and lprm commands.</para>

<para>This also allows your GNU/Linux box to act as a spool server for the
printer so that your network users can complete their print jobs
quickly and get on with things without waiting for the printer to
print any other job that someone else has sent.  This is suggested
too if you have unfixable older HP Jetdirects; it reduces the
likelihood of the printers wedging.</para>

<para>To do this, set up a queue on your linux box that points at the
ethernet equipped HP LJ (as above). Now set up all the clients on
your LAN to point at the LPD queue (eg lj-5 in the example above).</para>

<para>Some HP network printers apparently don't heed the banner page
setting sent by clients; you can turn off their internally
generated banner page by telnetting to the printer, hitting return
twice, typing "banner: 0" followed by "quit".  There are other
settings you can change this way, as well; type "?" to see a list.</para>

<para>The full range of settings can be controlled with HP's <ulink url="http://www.hp.com/go/webjetadmin">webJetAdmin</ulink>
software.  This package runs as a daemon, and accepts http
requests on a designated port.  It serves up forms and Java
applets which can control HP printers on the network.  In theory,
it can also control Unix print queues, but it does so using the
rexec service, which is completely unsecure.  I don't advise using
that feature.</para>

<sect3 id="networked-printers-appsocket">
<title>To AppSocket Devices</title>
<indexterm>
<primary>AppSocket protocol</primary>
</indexterm>
<indexterm>
<primary>networks</primary>
<secondary>AppSocket protocol</secondary>
</indexterm>
<indexterm>
<primary>HP</primary>
<secondary>JetDirect</secondary>
</indexterm>


<indexterm>
<primary>LPRng</primary>
<secondary>AppSocket protocol</secondary>
</indexterm>
<para>Some printers (and printer networking "black boxes") support only
a cheesy little non-protocol involving plain TCP connections;
this is sometimes called the "AppSocket" protocol.  Notable in
this category are early-model JetDirect (including some
JetDirectEx) cards.  Basically, to print to the printer, you must
open a TCP connection to the printer on a specified port
     (typically 9100, or 9100, 9101 and 9102 for three-port boxes) and
stuff your print job into it.  LPRng has built-in support for
stuffing print jobs into random TCP ports, but with BSD lpd it's
not so easy.  The best thing is probably to obtain and use the
little utility called netcat.</para>



<para>Failing that, it can be implemented, among other ways, in Perl
using the program below.  For better performance, use the
program netcat ("nc"), which does much the same thing in a
general purpose way.  Most distributions should have netcat
available in prepackaged form.</para>
</sect3>
</sect2>

<sect2 id="if-for-remote-printers">
<title>Running an <option>if</option> for remote printers with old
LPDs</title>
<indexterm>
<primary>
<option>if</option>
</primary>
<seealso>LPD</seealso>
</indexterm>
<indexterm>
<primary>LPD</primary>
<secondary>
<option>if</option>
</secondary>
</indexterm>


<para>One oddity of older versions of lpd is that the <option>if</option>
is not run for remote printers.  (Versions after 0.43 or so have
the change originated on FreeBSD such that the <option>if</option>
is always run).  If you find that you need to run an<option>if</option> for a remote printer, and it isn't working
with your lpr, you can do so by setting up a double queue and
requeueing the job.  As an example, consider this<filename>printcap</filename>:</para>

<para>
<programlisting><![CDATA[
lj-5:\
        :lp=/dev/null:sh:\
        :sd=/var/spool/lpd/lj-5:\
        :if=/usr/lib/lpd/filter-lj-5:
lj-5-remote:sh:rm=printer.name.com:\
        :rp=raw:sd=/var/spool/lpd/lj-5-raw:
]]>

</programlisting>in light of this <command>filter-lj-5</command> script:<programlisting><![CDATA[
#!/bin/sh
gs <options> -q -dSAFER -sOutputFile=- - | \
lpr -Plj-5-remote -U$5
]]></programlisting></para>

<para>The <option>-U</option> option to lpr only works if lpr is run
as daemon, and it sets the submitter's name for the job in the
resubmitted queue correctly.  You should probably use a more
robust method of getting the username, since in some cases it is
not argument 5.  See the man page for <filename><replaceable><ulink url="http://www.linuxprinting.org/man/printcap.5.html">printcap</ulink></replaceable></filename>.</para>
</sect2>

<sect2 id="network-from-windows">
<title>From Windows.</title>
<indexterm>
<primary>Windows</primary>
<secondary>printing from</secondary>
</indexterm>
<indexterm>
<primary>Windows</primary>
<secondary>samba</secondary>
<see>samba</see>
</indexterm>
<indexterm>
<primary>networks</primary>
<secondary>Windows</secondary>
</indexterm>

<indexterm>
<primary>samba</primary>
</indexterm>

<para>Printing from a Windows (or presumably, OS/2) client to a Un*x
server is directly supported over SMB through the use of the
SAMBA package, which also supports file sharing of your Un*x
filesystem to Windows clients.</para>

<para>Samba includes fairly complete documentation, and there is a good
Samba FAQ which covers it, too.  You can either configure a magic
filter on the Un*x box and print PostScript to it, or run around
installing printer-specific drivers on all the Windows machines
and having a queue for them with no filters at all.  Relying on
the Windows drivers may in some cases produce better output, but
is a bit more of an administrative hassle if there are many
Windows boxes.  So try Postscript first.  Modern versions of
Samba should support the automagical driver download mechanism
offered by Windows NT servers to deal with this problem.</para>
</sect2>

<sect2 id="networks-from-apple">
<title>From an Apple.</title>
<indexterm>
<primary>networks</primary>
<secondary>Apple</secondary>
</indexterm>
<indexterm>
<primary>Apple</primary>
<secondary>printing from</secondary>
</indexterm>
<indexterm>
<primary>netatalk</primary>
</indexterm>
<indexterm>
<primary>Apple</primary>
<secondary>netatalk</secondary>
<see>netatalk</see>
</indexterm>


<para>Netatalk supports printing from Apple clients over EtherTalk.  See
the <ulink url="http://thehamptons.com/anders/netatalk/">Netatalk
HOWTO Page</ulink> for more information.</para>

<para>Really, though, any modern Mac can print over TCP/IP using the LPD
protocol just fine.  UVa provides a very nice <ulink url="http://www.itc.virginia.edu/desktop/mac/ip_printing/ip_printing.html">support page</ulink> detailing how to set this up.</para>
</sect2>

<sect2 id="networks-from-netware">
<title>From Netware.</title>
<indexterm>
<primary>networks</primary>
<secondary>Netware</secondary>
</indexterm>
<indexterm>
<primary>Netware</primary>
<secondary>printing from</secondary>
</indexterm>
<indexterm>
<primary>ncpfs</primary>
</indexterm>
<indexterm>
<primary>Netware</primary>
<secondary>ncpfs</secondary>
<see>ncpfs</see>
</indexterm>


<para>The ncpfs package includes a daemon named pserver which can be
used to provide service to a NetWare print queue.  From what I
understand, this system requires a Bindery-based NetWare, eg 2.x,
3.x, or 4.x with bindery access enabled.</para>

<para>For more information on ncpfs and it's pserver program, see <ulink url="ftp://ftp.gwdg.de/pub/linux/misc/ncpfs/">the ncpfs FTP
site</ulink>.</para>
</sect2>


<sect2>
<title>Networked Printer Administration</title>
<indexterm>
<primary>networks</primary>
<secondary>administration</secondary>
</indexterm>
<indexterm>
<primary>npadmin</primary>
</indexterm>


<para>Most networked printers support some method of remote
administration.  Often there are easy-to-use web pages for
configuration.  More usefully, there is often support for SNMP
management.  Typically you can find out interesting information on
printer status like ink and paper levels, print volumes, and so
forth, and you can usually change certain settings.  SNMP printer
control, and a number of other printing-related things, are being
standardized by the IEEE's <ulink url="http://www.pwg.org/">Printer Working Group</ulink></para>

<sect3 id="npadmin">
<title>
<command>npadmin</command>
</title>

<para>
<ulink url="http://npadmin.sourceforge.net/">Npadmin</ulink>is a
command-line program which offers an interface to the common SNMP
functionality of networked printers.  It implements the standard <ulink url="http://www.ietf.org/rfc/rfc1759.txt">Printer
MIB</ulink>, as well as a few vendor-proprietary schemes used
mainly for older devices.  Both printer-discovery style actions
and various printer status queries are supported.</para>

<para>npadmin has an excellent <ulink url="http://npadmin.sourceforge.net/man/">man page</ulink>, and
precompiled packages are distributed for a number of RPM and dpkg
based distributions.</para>
</sect3>

<sect3>
<title>Other SNMP tools</title>
<para>Besides npadmin, there are a number of SNMP tools that will be
useful.  <command>snmptraplogd</command> can log SNMP trap
events.  This is useful for observing printer jams, out of paper
events, etc; it would be straightforward to retransmit certain
events to a pager, or to send an email.</para>

<para>While npadmin provides simplified support for many network
printers' SNMP interfaces, some printers may have vendor
extensions which npadmin doesn't know about.  In this case, you
can use the CMU SNMP tools, which support arbitrary SNMP GET and
SET operations, as well as walks and the like.  With these, and a
bit of work, you can make use of any SNMP feature offered by your
printer's MIB.  You may need to obtain a MIB from your vendor to
figure out what all the variables are; sometimes vendors think
that people actually use the proprietary tools they ship.</para>

<para>VA Linux's <command><ulink url="http://sourceforge.net/project/?group_id=3648">libprinterconf</ulink></command> includes code to perform
network printer discovery.  Printers are identified against a
compiled-in library of printer signatures; at the moment the
library is not large, but does cover many common networked
printer models.</para>
</sect3>
</sect2>
</sect1>

<sect1 id="winprinters">
<title>Windows-only printers</title>
<indexterm>
<primary>winprinters</primary>
<secondary>workarounds</secondary>
</indexterm>


<para>As I discussed earlier, some printers are inherently unsupported
because they don't speak a normal printer language, instead using
the computer's CPU to render a bitmap which is then piped to the
printer at a fixed speed.  In a few cases, these printers also
speak something normal like PCL, but often they do not.  In some
   (really low-end) cases, the printer doesn't even use a normal
parallel connection but relies on the vendor's driver to emulate
what should be hardware behavior (most importantly flow control).</para>

<para>In any case, there are a few possible workarounds if you find
yourself stuck with such a lemon.</para>

<sect2 id="gs-win-redirector">
<title>The Ghostscript Windows redirector</title>

<para>There is now a Ghostscript printer driver available (called <command>mswinpr2</command>) that will print using Windows GDI
calls.  There is also a port redirection tool called <command>redmon</command> which will run a print job through
Ghostscript before finally printing it.  (Rather like an <option>if</option> filter in Unix's LPD).  Taken all together,
this allows a Windows machine to print PostScript to a
Windows-only printer through the vendor's driver.</para>

<para>If you have a host-based printer that can't be used directly, you
can export it as a "Postscript" printer by using redmon,
Ghostscript, and mswinpr2 on a Windows PC and print through the
vendor's drivers.</para>
</sect2>

<sect2 id="hp-winprinters">
<title>HP Winprinters</title>

<para>Some HP printers use "Printing Performance Architecture"
    (marketing speak for "we were too cheap to implement PCL").  This
is supported in a roundabout way via the pbm2ppa translator
written by Tim Norman.  Basically, you use ghostscript to render
PostScript into a bitmapped image in pbm format and then use
pbm2ppa to translate this into a printer-specific ppa format
bitmap ready to be dumped to the printer.  This program may also
come in ghostscript driver format by now.</para>

<para>The ppa software can be had from <ulink url="http://www.rpi.edu/~normat/technical/ppa/">the ppa home
page</ulink>; pbm2ppa supports some models of the HP 720, 820,
and 1000; read the documentation that comes with the package for
more details on ppa printer support.</para>
</sect2>

<sect2 id="lex-winprinters">
<title>Lexmark Winprinters</title>

<para>Most of the cheap Lexmark inkjets use a proprietary language and
are therefore Winprinters.  However, Henryk Paluch has written a
program which can print on a Lexmark 7000.  Hopefully he'll be
able to figure out color and expand support to other Lexmark
inkjets.  See <ulink url="http://bimbo.fjfi.cvut.cz/~paluch/l7kdriver/">here</ulink>
for more info.</para>

<para>Similarly, there are now drivers for the 5700, 1000, 1100, 2070,
3200, and others.  See the supported printers listing above, and
my web site, for more information on obtaining these drivers.</para>
</sect2>
</sect1>

<sect1 id="faxing">
<title>How to print to a fax machine.</title>

<para>You can print to a fax machine with, or without, a modem.</para>

<sect2 id="using-a-faxmodem">
<title>Using a faxmodem</title>

<para>There are a number of fax programs out there that will let you fax
and receive documents.  One of the most powerful is Sam Leffler's <productname><ulink url="http://www.hylafax.org/">HylaFAX</ulink></productname>.  It supports all sorts of things
from multiple modems to broadcasting.</para>

<para>SuSE ships a Java HylaFax client which allegedly works on any Java
platform (including Windows and GNU/Linux).  There are also non-Java
fax clients for most platforms; GNU/Linux can almost certainly handle
your network faxing needs.</para>

<para id="efax">
<indexterm>
<primary>environment</primary>
<secondary>home</secondary>
</indexterm>Also available, and a better choice for smaller installations, is <command><ulink url="http://casas.ee.ubc.ca/efax/">efax</ulink></command>, a simple program which sends and receives faxes.  The
getty program <command>mgetty</command> can receive faxes using <command>efax</command> (and do voicemail or interactive logins).</para>
</sect2>

<sect2 id="fax-via-email">
<title>Using the Remote Printing Service</title>

<para>There is an experimental service offered that lets you send an
email message containing something you'd like printed such that it
will appear on a fax machine elsewhere.  Nice formats like
postscript are supported, so even though global coverage is
spotty, this can still be a very useful service.  For more
information on printing via the remote printing service, see the <ulink url="http://www.tpc.int/">Remote Printing WWW Site</ulink>.</para>
</sect2>

<sect2 id="fax-via-web">
<title>Commercial Faxing Services</title>
<para>A number of companies operate web-based faxing services.  <ulink url="http://www.efax.com/">EFax</ulink>, in particular, offers
free inbound faxes (to your own dedicated fax number, no less) via
email, and fax transmission for a fee.  Other companies offer
similar services.</para>
</sect2>
</sect1>

<sect1 id="authoring">
<title>How to generate something worth printing.</title>

<para>Here we get into a real rat's-nest of software.  Basically, Linux
can run many types of binaries with varying degrees of success:
Linux/x86, Linux/Alpha, Linux/Sparc, Linux/foo, iBCS, Win16/Win32s
   (with dosemu and, someday, with Wine), Mac/68k (with Executor), and
Java.  I'll just discuss native GNU/Linux and common Un*x software.</para>

<sect2 id="markup-languages">
<title>Markup languages</title>

<para>Most markup languages are more suitable for large or repetitive
projects, where you want the computer to control the layout of the
text to make things uniform.<variablelist><varlistentry><term><command>nroff</command></term><listitem><para>This was one of the first markup languages on the
original version of Unix.  Man pages
are the most common examples of things formatted in *roff
macros; many people swear by them, but nroff has, to me at
least, a more arcane syntax than needed (see <xref linkend="roff-example"/>), and probably makes a poor choice for
new works.  It is worth knowing, though, that you can typeset
a man page directly into postscript with groff.  Most man
commands will do this for you with <command>man -t foo
        &verbar; lpr</command>.</para><figure id="roff-example"><title>Example of <command>roff</command> Input</title><programlisting><![CDATA[
.B man
is the system's manual pager. Each
.I page
argument given to 
.B man
is normally the name of a program, utility or function. 
The 
.I manual page 
associated with each of these arguments is then found and
displayed. A 
.IR section ,
if provided, will direct
.B man
to look 
only in that
.I section
of the manual.
]]></programlisting></figure></listitem></varlistentry><varlistentry><term>TeX</term><listitem><para>TeX, and the macro package LaTeX, are one of the most
widely used markup languages on Un*x systems, although TeX did
not originate on Unix and is available to run on a wide
variety of systems.  Technical works are frequently written in
LaTeX because it greatly simplifies the layout issues and is<emphasis>still</emphasis> one of the few text processing
systems to support mathematics both completely and well.
TeX's output format is <filename>dvi</filename>, and is
converted to PostScript or Hewlett Packard's PCL with <command>dvips</command> or <command>dvilj</command>.  If you
wish to install TeX or LaTeX, install the whole teTeX group of
packages; it contains everything.  Recent TeX installations
include pdfTeX and pdfLaTeX, which produce Adobe PDF files
directly.  Commands are available do create hyperlinks and
navigation features in the PDF file.</para><figure id="latex-example"><title>Example of LaTeX Input</title><programlisting><![CDATA[
\subsubsection{NAT}

Each real server is assigned a different IP address, and the NA
implements address translation for all inbound and outbound
packets.

  \begin{description}
  \item[Advantage] Implementation simplicity, especially if we
already implement other NAT capabilities.

  \item[Disadvantage] Return traffic from the server goes through
address translation, which may incur a speed penalty.  This
probably isn't too bad if we design for it from the
beginning.

  \item[Disadvantage] NAT breaks the end-to-end semantics of normal
internet traffic.  Protocols like ftp, H.323, etc would
require special support involving snooping and in-stream
rewriting, or complete protocol proxying; neither is likely
to be practical.
  \end{description}
]]></programlisting></figure></listitem></varlistentry><varlistentry><term>SGML</term><listitem><para>There is at least one free SGML parser available for Un*x
systems; it forms the basis of Linuxdoc-SGML's homegrown
document system.  It can support other DTD's, as well, most
notably DocBook.  This document is written in DocBook-DTD
SGML; see <xref linkend="sgml-example"/> for an example.</para><figure id="sgml-example"><title>Example of DocBook SGML</title><programlisting><![CDATA[
<varlistentry>
<term>SGML</term>
<listitem>
<para>
There is at least one free SGML parser available for Un*x 
systems; it forms the basis of Linuxdoc-SGML's homegrown 
document system.  It can support other DTD's, as well, most
notably DocBook.  This document is written in DocBook-DTD 
SGML.
</para>
</listitem>
</varlistentry>
]]></programlisting></figure></listitem></varlistentry></variablelist></para>
</sect2>

<sect2 id="wysiwyg-processors">
<title>WYSIWYG Word Processors</title>

<para>There is no shortage of WYSIWYG word processing software.  Several
complete office suites are available, including one that's free
for personal use (StarOffice).<variablelist><varlistentry><term>StarOffice</term><listitem><para>This full-blown office suite has all the features
you'd expect, including both import and export of Microsoft
Office file formats (including Word documents).  There's a
mini-HOWTO out there which describes how to obtain and install
it.  It generates PostScript, so should work with most any
printer that works otherwise on GNU/Linux.</para></listitem></varlistentry>
<varlistentry><term>WordPerfect</term><listitem><para>Corel distributes a basic version of WordPerfect 8 free for
GNU/Linux, and sells various packages of Word Perfect Office 2000
        (which includes WordPerfect, Corel Draw and Quattro Pro
Versions 9).  The <ulink url="http://www.rodsbooks.com/wpfonts/"> Linux WordPerfect
Fonts and Printers</ulink> page has information about
configuring WordPerfect for use with either Ghostscript or its
built-in printer drivers (which are apparently identical the
DOS WordPerfect drivers, if your printer's driver isn't
included in the distribution).</para></listitem></varlistentry><varlistentry><term>Applix</term><listitem><para>Applix is a cross-platform (eg, various Unices, Windows, and
others) office suite sold by the Applix company.  Red Hat and
SuSE sold it themselves when it was the only game in town;
now sales have reverted to Applix.  This is the only native
Unix-style application suite; it probably fits in better with
the Unix way of doing things.</para></listitem></varlistentry><varlistentry><term>AbiWord</term><listitem><para><ulink url="http://www.abisource.com/">AbiWord</ulink> is one
of several GPL WYSIWYG word processor projects; this one has
produced a very nice word processor based on an XML format.
It is capable of Word file import.  AbiWord is still a work in
progress, although it is useful for small things now.</para><figure><title>AbiWord</title><mediaobject><imageobject><imagedata fileref="images/snapshot-abiword.png" scale="60"/></imageobject></mediaobject></figure></listitem></varlistentry><varlistentry><term>LyX</term><listitem><para>LyX is a front-end to LaTeX which looks very promising.  See
the <ulink url="http://www.lyx.org/">LyX Homepage</ulink>
for more information.  There is a KDE-styled version of LyX,
called Klyx; the author of LyX and the instigator of KDE are
the same person.</para><figure><title>LyX</title><mediaobject><imageobject><imagedata fileref="images/snapshot-lyx.png" scale="60"/></imageobject></mediaobject></figure></listitem></varlistentry><varlistentry><term>Maxwell</term><listitem><para>Maxwell is a simple MS RTF-format based word processor which
started as a commercial product but is now distributed under
the GPL.</para></listitem></varlistentry></variablelist></para>

<para>Other vendors should feel free to drop me a line with your offerings.</para>
</sect2>
</sect1>

<sect1 id="photos">
<title>Printing Photographs</title>

<indexterm>
<primary>photograph</primary>
<secondary>tips</secondary>
</indexterm>

<para>There are many details to getting decent photo output from common
printers.  If you haven't bought a photo printer yet, see the
photo-related tips in <xref linkend="shopping"/>.</para>

<sect2 id="gs-photos-tips-and-tricks">
<title>Ghostscript and Photos</title>
<indexterm>
<primary>Ghostscript</primary>
<secondary>photographs</secondary>
</indexterm>
<indexterm>
<primary>photograph</primary>
<secondary>Ghostscript</secondary>
</indexterm>



<para>Ghostscript has some difficulties rendering color photographs
through most drivers.  The problems are several:<itemizedlist><listitem><para>Many drivers have poorly tuned color support.  Often the
colors don't match the Windows driver output or the screen.
OTOH, all drivers, and Ghostscript as a whole, have readily
adjustable color support; the "Gamma" settings (see<xref linkend="gsgamma"/>) are one thing
to play with, and there are others documented in Ghostscript's<filename>Use.htm</filename> documentation file.</para></listitem><listitem><para>I'm only aware of one Ghostscript driver with support for 6
and 7 color printing; it's in beta at the moment and supports
most Epson Stylus Photo models.  It is rumored to produce
better color than the Windows driver (!).  The Ghostscript
driver core itself provides no support for non CMYK or RGB
colors; arguably, some work to put that there is needed.</para></listitem><listitem><para>Ghostscript often ends up dithering coarsely, or generating
printouts with artifacts like banding.  The dithering can
usually be corrected; see <xref linkend="gscolor"/>, and read
the documentation for your driver.</para></listitem></itemizedlist>
You should be able to correct some of these problems by tuning
Ghostscript; see <xref linkend="ghostscript"/> for more
information on how to do this.  Fiddling with Ghostscript options
is much easier if you declare them as options in your spooling system.</para>

<para>That said, the obvious solution for now is to use non-Ghostscript
software for printing photos, and indeed, such things do exist.
The main contender is the print plugin in the Gimp, which supports
pixel-for-pixel printing on Epson Styluses and Postscript printers
    (with basic PPD support).  That Epson Stylus portion of that
driver is available for Ghostcript, as well, as the<command>stp</command> driver.  Also possible to use for this
purpose are the assorted external pnm-to-foo programs used to
print on printers like the cheap Lexmarks; these print attempt to
print pixmaps pixel-for-pixel.</para>

<para>The best solution, of course, is to buy a Postscript printer;
such printers can usually be completely controlled from available
free software, and will print to the full capability of the
printer.</para>
</sect2>

<sect2 id="paper-for-inkjets">
<title>Paper</title>
<indexterm>
<primary>paper</primary>
<secondary>quality</secondary>
</indexterm>


<para>Color inkjets are extremely dependent on the paper for good
output.  The expensive glossy coated inkjet papers will allow you
to produce near-photographic output, while plain uncoated paper
will often produce muddy colors and fuzzy details.  Non-glossy
coated inkjet papers will produce results in between, and are
probably best for final prints of text, as well.  Stiffer glossy
coated "photo" papers will produce similar output to
lighter-weight glossy papers, but will feel like a regular photo.</para>
</sect2>

<sect2 id="photo-printer-settings">
<title>Printer Settings</title>

<para>For photo output on most color inkjets, you should use the most
highly interlaced (and slowest) print mode; otherwise solid
regions may have banding or weak colors.  Generally with
Ghostscript this is what will happen when you pick the highest
resolution.  With Postscript printers, you may need to add a
snippet to the prologue based on the settings available in the PPD
file.  The Gimp's PPD support doesn't include (printer-specific)
print quality settings, but I added one in an ugly way for my own
use; contact me if you'd like that.  If you use PDQ or CUPS, you
can easily control all the printer settings you need.  VA Linux's<command>libppd</command> and the GPR front-end can also add these
options for Postscript printers.</para>
</sect2>

<sect2 id="inkjet-archiving">
<title>Print Durability</title>
<indexterm>
<primary>archiving</primary>
<secondary>print durability</secondary>
</indexterm>

<para>Color inkjet printouts usually fade after a few years, especially
if exposed to lots of light and air; this is a function of the
ink.  Printers with ink-only consumables like the Epsons and
Canons can buy archival inks, which are less prone to this
problem.  Newer printers often use pigment-based inks, which
don't fade as much as the older dye-based ink did.  No inkjet
output is really particularly good for long-term archival use.
Write the bits to a CD-R and store that instead.</para>
</sect2>

<sect2 id="commercial-photo-printing-software">
<title>Shareware and Commercial Software</title>
<indexterm>
<primary>photograph</primary>
<secondary>commercial software</secondary>
</indexterm>

<para>There's a program called <ulink url="http://home.t-online.de/home/jj.sarton/startE.htm">xwtools</ulink> which supports photo printing with all the
bells and whistles on an assortment of Epson, HP, and Canon
printers.  Unfortunately, it was written under NDA, so comes
without source.  Unless you use it for the Epson Stylus Color 300
on GNU/Linux x86, it costs E15 for personal use; commercial pricing
is unknown.</para>

<para>The ESP Print Pro package from Easy Software supports some
printers which might otherwise be unsupported.  These drivers are
not reported to be very well-tuned for photos, but they do work.</para>
</sect2>
</sect1>

<sect1 id="previewing">
<title>On-screen previewing of printable things.</title>
<indexterm>
<primary>previewing</primary>
</indexterm>

<para>Nearly anything you can print can be viewed on the screen, too.</para>

<sect2 id="previewing-with-ghostscript">
<title>PostScript</title>
<indexterm>
<primary>Ghostscript</primary>
<secondary>previewing</secondary>
</indexterm>
<indexterm>
<primary>previewing</primary>
<secondary>Postscript</secondary>
</indexterm>
<indexterm>
<primary>Postscript</primary>
<secondary>previewing</secondary>
</indexterm>

<para>Ghostscript has an X11 driver best used under the management of
the PostScript previewer <ulink url="http://wwwthep.physik.uni-mainz.de/~plass/gv/">gv</ulink>.
The latest versions of these programs should be able to view PDF
files, as well.  Note that gv has replaced the older previewer
    "Ghostview"; the new user interface is much prettier and featureful
that ghostview's plain old Athena GUI.</para>

<figure>
<title>Gv</title>
<mediaobject>
<imageobject>
<imagedata fileref="images/snapshot-gv.png" scale="60"/>
</imageobject>
</mediaobject>
</figure>
</sect2>

<sect2 id="previewing-tex-dvi">
<title>TeX dvi</title>

<para>TeX DeVice Independent files may be previewed under X11 with<ulink url="http://www.linuxprinting.org/man/xdvi.1.html">xdvi</ulink>.  Modern versions of xdvi call ghostscript to
render PostScript specials.</para>

<para>A VT100 driver exists as well.  It's called <literal remap="tt">dgvt</literal>.  <literal remap="tt">Tmview</literal>
works with GNU/Linux and svgalib, if that's all you can do.</para>
</sect2>

<sect2 id="pdf-previewing">
<title>Adobe PDF</title>
<indexterm>
<primary>Ghostscript</primary>
<secondary>previewing</secondary>
</indexterm>
<indexterm>
<primary>previewing</primary>
<secondary>PDF</secondary>
</indexterm>
<indexterm>
<primary>PDF</primary>
<secondary>previewing</secondary>
</indexterm>

<para>Adobe's Acrobat Reader is available for GNU/Linux; just download it
from the <ulink url="http://www.adobe.com/">Adobe web site</ulink>.</para>

<para>You can also use xpdf, which is free software, and I believe<command>gv</command> supports viewing PDF files with gs under X11.</para>
</sect2>
</sect1>

<sect1 id="serial">
<title>Serial printers under lpd</title>
<indexterm>
<primary>ports</primary>
<secondary>serial</secondary>
</indexterm>

<para>Serial printers are rather tricky under lpd.</para>

<sect2 id="serial-printcap">
<title>Setting up in printcap</title>

<para>Lpd provides five attributes which you can set in<emphasis>/etc/printcap</emphasis> to control all the settings of
the serial port a printer is on.  Read the <emphasis><ulink url="http://www.linuxprinting.org/man/printcap.5.html">printcap</ulink></emphasis> man page and note the meanings of<emphasis>br&num;</emphasis>, <emphasis>fc&num;</emphasis>,<emphasis>xc&num;</emphasis>, <emphasis>fs&num;</emphasis> and<emphasis>xs&num;</emphasis>.  The last four of these attributes
are bitmaps indicating the settings for use the port.  The<emphasis>br&num;</emphasis> attribute is simply the baud rate, eg
    `<literal remap="tt">br&num;9600</literal>'.</para>

<para>It is very easy to translate from <ulink url="http://www.linuxprinting.org/man/stty.1.html">stty</ulink> settings to printcap flag settings. If you need to,
see the man page for stty now.</para>

<para>Use stty to set up the printer port so that you can cat a file to
it and have it print correctly. Here's what `<emphasis>stty
    -a</emphasis>' looks like for my printer port:<screen>
dina:/usr/users/andy/work/lpd/lpd# stty -a &lt; /dev/ttyS2
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = &lt;undef&gt;;
eol2 = &lt;undef&gt;; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr 
-igncr -icrnl ixon -ixoff -iuclc -ixany -imaxbel
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 
bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase
-tostop -echoprt -echoctl -echoke</screen>

The only changes between this and the way the port is initialized
at bootup are <literal remap="tt">-clocal</literal>, <literal remap="tt">-crtscts</literal>, and <literal remap="tt">ixon</literal>. Your port may well be different
depending on how your printer does flow control.</para>

<para>You actually use stty in a somewhat odd way.  Since stty operates
on the terminal connected to it's standard input, you use it to
manipulate a given serial port by using the `<literal remap="tt">&lt;</literal>' character as above.</para>

<para>Once you have your stty settings right, so that `<emphasis>cat
file &gt; /dev/ttyS2</emphasis>' (in my case) sends the file to
the printer, look at the file
    /usr/src/linux/include/asm-i386/termbits.h. This contains a lot of
    &num;defines and a few structs (You may wish to cat this file to
the printer (you do have that working, right?) and use it as
scratch paper).  Go to the section that starts out</para>

<para>
<screen>/* c_cflag bit meaning */
#define CBAUD   0000017</screen>This section lists the meaning of the <emphasis>fc&num;</emphasis>
and <emphasis>fs&num;</emphasis> bits. You will notice that the
names there (after the baud rates) match up with one of the lines
of stty output. Didn't I say this was going to be easy?</para>

<para>Note which of those settings are preceded with a - in your stty
output. Sum up all those numbers (they are octal). This represents
the bits you want to clear, so the result is your<emphasis>fc&num;</emphasis> capability.  Of course, remember that
you will be setting bits directly after you clear, so you can just
use `<literal remap="tt">fc&num;0177777</literal>' (I do).</para>

<para>Now do the same for those settings (listed in this section) which
do not have a - before them in your stty output. In my example the
important ones are CS8 (0000060), HUPCL (0002000), and CREAD
    (0000200). Also note the flags for your baud rate (mine is
0000015). Add those all up, and in my example you get
0002275. This goes in your <emphasis>fs&num;</emphasis> capability
    (`<literal remap="tt">fs&num;02275</literal>' works fine in my
example).</para>

<para>Do the same with set and clear for the next section of the include
file, "c&lowbar;lflag bits". In my case I didn't have to set
anything, so I just use `<literal remap="tt">xc&num;0157777</literal>' and `<literal remap="tt">xs&num;0</literal>'.</para>
</sect2>

<sect2>
<title>Older serial printers that drop characters</title>

<para>Jon Luckey points out that some older serial printers with
ten-cent serial interfaces and small buffers<emphasis>really</emphasis> mean stop when they say so with flow
control.  He found that disabling the FIFO in his Linux box's
16550 serial port with <literal remap="tt"><ulink url="http://www.linuxprinting.org/man/setserial.8.html">setserial</ulink></literal> corrected the problem of dropped
characters (you apparently just specify the UART type as an 8250
to do this).</para>
</sect2>
</sect1>

<sect1 id="development">
<title>What's missing?</title>

<para>Many of the parts for a complete printing system do not exist yet.
Projects are underway to address most of these, although most have
not yet produced running useful code, and efforts to standardize
the necessary protocols and APIs are in their infancy.</para>

<simplesect>
<title>Plumbing</title>

<para>There's a general problem with getting all the parts to talk to
one another; especially in a spooler-independent way.  This
problem manifests itself most noticeably in the pathetic
application support for control over all the "usual" printing
features.  There is simply no way for an application writer to get
information about printers, jobs, etc; no standardized way to
submit jobs; no good way to get job status back; nor even really a
standardized way to generate print data (although most of the new
desktop systems offer desktop-specific facilities for doing this).</para>
</simplesect>

<simplesect>
<title>Fonts</title>
<para>Font handling on free systems is rather awkward.  The display, the
printer, the application, and the data files should ideally all
have access to the same fonts.  Unfortunately this was simply not
the case. With the advent of xft2 and fontconfig - which the newest distributions will start deploying - this should finally be solved. Redhat 8.0 is AFAIK the first distro that uses xft2.</para>
</simplesect>


<simplesect>
<title>Drivers</title>
<para>There is still some work to be done on free software drivers. Although the drivers have improved a lot the last several years, not all printers are supported.</para>

<para>Printer vendors have a major role to play in this area. With the increasing popularity of Linux it is getting really hard for them to simple ignore this userbase.</para>
</simplesect>
</sect1>

<sect1 id="credits">
<title>Credits</title>

<para>Special thanks to Grant Taylor for creating this HOWTO and to Till Kampeter for foomatic and his expert advice.</para>

<para>The <literal remap="tt">smbprint</literal> information is from an
article by Marcel Roelofs <literal remap="tt">&lt;marcel@paragon.nl&gt;</literal>.</para>

<para>The <literal remap="tt">nprint</literal> information for using
Netware printers was provided by Michael Smith <literal remap="tt">&lt;mikes@bioch.ox.ac.uk&gt;</literal>.</para>

<para>The serial printers under lpd section is from Andrew Tefft <literal remap="tt">&lt;teffta@engr.dnet.ge.com&gt;</literal>.</para>

<para>The blurb about gammas and such for gs was sent in by Andreas<literal remap="tt">&lt;quasi@hub-fue.franken.de&gt;</literal>.</para>

<para>The two paragraphs about the 30 second closing&lowbar;wait of the
serial driver was contributed by Chris Johnson <literal remap="tt">&lt;cdj@netcom.com&gt;</literal>.</para>

<para>Robert Hart sent a few excellent paragraphs about setting up a print
server to networked HPs which Grant used verbatim.</para>

<para>And special thanks to the dozens upon dozens of you who've pointed
out typos, bad URLs, and errors in the document over the years.</para>
</sect1>


<!-- GNU Free Doc License -->&fdl;</article>