CD Actual 13/CDA13.ISO/DOC/HOWTO/OTHER_FO/SGML/PRINTIN0.GZ/Printing-HOWTO.sgml

SGML Document | 1996-08-02 | 37.0 KB | 970 lines

<!doctype linuxdoc system>

<!--
       pht.sgml,v 3.9 1996/07/25 18:55:33 gtaylor Rel
 -->

<article>
<title>The Linux Printing HOWTO

<author>Grant Taylor, <tt/<[e-mail]>/
<date>v3.9, 25 July 1996

<abstract>
This is the Linux Printing HOWTO, a collection of information on how
to generate, preview, print and fax anything under Linux (and other
Unices in general).
</abstract>

<toc>

<sect>Intro
<p>
Since this is a complete rewrite, much information from previous
editions has been lost.  This is by design, as the previous HOWTOs
were so large as to be 60 typeset pages, and had the narrative flow of
a dead turtle.  If you do not find the answer here, you are encouraged
to a) scan the previous version at <url
url="http://www.picante.com/~gtaylor/pht/" name="The PHT Home Page">
and b) drop me a note saying what ought to be here but isn't.
<p>
The <url name="Printing HOWTO Home Page"
url="http://www.picante.com/~gtaylor/pht/"> is a good place to find
the latest version; it is also, of course, distributed from SunSite
(<tt/sunsite.unc.edu/) and your friendly local LDP mirror.

<sect1>History
<p>
This is the third generation, which is to say the third complete
rewrite, of the Printing HOWTO.  The history of the PHT may be
chronicled thusly:
<enum>
<item>I wrote the printing-howto in response to too many printing
      questions in comp.os.linux, and posted it.  This predated the
      HOWTO project by a few months and was thus the first FAQlet
      called a `howto'.  This edition was in plain ascii.

<item>After joining the HOWTO project, the Printing-HOWTO was merged
      with an Lpd FAQ by Brian McCauley <tt/<[e-mail]>/; we
      continued to co-author
      the PHT for two years or so.  At some point we incorporated the
      work of Karl Auer <tt/<[e-mail]>/.  This
      generation of the PHT was in
      TeXinfo, and available in PS, HTML, Ascii, and Info.

<item>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 in
      Linuxdoc-SGML.
</enum>
<sect1>Copyright
<p>
This document is Copyright (c) 1996 by Grant Taylor.  Please copy and
distribute it widely, but do not modify the text or omit my name.
<sect>How to print
<p>
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 <url
name="Printing Usage HOWTO"
url="http://sunsite.unc.edu/mdw/HOWTO/Printing-Usage-HOWTO.html"> covers
this, and a few other queue manipulation commands you should probably
know.

<sect>Kernel printer devices
<sect1>The lp device
<p>
The Linux kernel, assuming you have compiled in or loaded the lp
device (the output of <tt>cat /proc/devices</tt> should include the
device lp), provides one or more of <em>/dev/lp0</em>,
<em>/dev/lp1</em>, and <em>/dev/lp2</em>.  These are NOT assigned
dynamically, rather, each corresponds to a specific hardware I/O
address.  This means that your first printer may be <em/lp0/ or
<em/lp1/ depending on your hardware.  Try both ;)
<p>
One cannot run the plip and lp drivers at the same time on any given
port.  You can, however, have one or the other driver loaded at any
given time either manually, or by kerneld with v2 (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.
<p>
There is a little utility called <tt><htmlurl
url="http://www.picante.com/~gtaylor/pht/man/tunelp.html"
name="tunelp"></tt> floating about with which you, as root, can tune
the Linux lp device's interrupt usage, polling rate, and other
options.
<p>
When built in to some 1.3.x and v2 kernels, the kernel will accept an
<tt>lp=</tt> option to set interrupts and io addresses:
<tscreen><verb>
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.
</verb></tscreen>
<p>
When loaded as a module in version 2 and late-model 1.3.x kernels, it
is possible to specify io addresses and interrupt lines on the insmod
command line (or in <em>/etc/conf.modules</em> so as to affect
kerneld) using the usual syntax.  The parameters are
<tt/io=port0,port1,port2/ and <tt/irq=irq0,irq1,irq2/.  Read ye the
man page for <em/insmod/ for more information on this.

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

<sect1>Serial devices
<p>
Serial devices are usually called something like <em>/dev/ttyS1</em>
under Linux.  The utility <tt><htmlurl
url="http://www.picante.com/~gtaylor/pht/man/stty.html"
name="stty"></tt> will allow you to interactively view or set the
settings for a serial port; <tt><htmlurl name="setserial"
url="http://www.picante.com/~gtaylor/pht/man/setserial.html"></tt>
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 <url
url="http://sunsite.unc.edu/mdw/HOWTO/Serial-HOWTO.html"
name="Serial-HOWTO">.

<sect>How it works, basic
<p>

In order to get printing working well, you need to understand how the
lpd system works.
<p>
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:
<p>
<descrip>
<tag><tt><htmlurl name="lpd" url="http://www.picante.com/~gtaylor/pht/man/lpd.html"></tt></tag>The spooling daemon.  One of these runs to control
                       everything on a machine, AND one is run per
                       printer while the printer is printing.
<tag><tt><htmlurl name="lpr" url="http://www.picante.com/~gtaylor/pht/man/lpr.html"></tt></tag>The user spooling command.  Lpr contacts lpd
                       and injects a new print job into the spool.
<tag><tt><htmlurl name="lpq" url="http://www.picante.com/~gtaylor/pht/man/lpq.html"></tt></tag>Lists the jobs in a print queue.
<tag><tt><htmlurl name="lpc" url="http://www.picante.com/~gtaylor/pht/man/lpc.html"></tt></tag>The Lpd system control command.  With lpc you
                       can stop, start, reorder, etc, the print queues.
<tag><tt><htmlurl name="lprm" url="http://www.picante.com/~gtaylor/pht/man/lprm.html"></tt></tag><tt/lprm/ will remove a job from the print spool.
</descrip>
<p>
So how does it fit together?  Well, when the system boots, lpd is
run.  It scans the file <em>/etc/printcap</em> to learn which printers
it will be managing spools for.  Each time someone runs lpr, lpr
contacts lpd through the named socket <em>/dev/printer</em>, and feeds
lpd both the file to print and some information about who is printing
and how to print it.  Lpd then prints the file on the appropriate
printer in turn.
<p>
The lp system was originally designed when most printers were line
printers - that is, people mostly printed plain ascii.  As it turns
out, only a little extra scripting is needed to make lpd work quite
well for today's print jobs, which are often in PostScript, or text,
or dvi, or...

<sect>How to set things up, basic
<sect1>Traditional lpd configuration
<p>
The minimal setup for lpd rsults in a system that can queue files and
print them.  It will not pay any attention to wether or not your
printer will understand them, and will probably not let you produce
attractive output.  Nevertheless, it is the first step to
understanding, so read on!
<p>
Basically, to add a print queue to lpd, you must add an entry in
<em>/etc/printcap</em>, and make the new spool directory under
<em>/var/spool/lpd</em>.
<p>
An entry in <em>/etc/printcap</em> looks like:
<tscreen><verb>
# LOCAL djet500
lp|dj|deskjet:\
    :sd=/var/spool/lpd/dj:\
    :mx#0:\
    :lp=/dev/lp0:\
    :sh:
</verb></tscreen>
This defines a spool called <em/lp/, <em/dj/, or <em/deskjet/, spooled
in the directory <em>/var/spool/lpd/dj</em>, with no per-job maximum size
limit, which prints to the device <em>/dev/lp0</em>, 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.
<p>
Go now and read the man page for <em><htmlurl name="printcap" url="http://www.picante.com/~gtaylor/pht/man/printcap.html"></em>.
<p>
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:
<tscreen><verb>
This is line one.
                 This is line two.
                                  This is line three.
</verb></tscreen>
ad nauseum.  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.
<p>
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 <em/if/ and <em/of/.  Well, <em/if/, or
the input filter, is just what we need here.
<p>
If we write a small shell script called <em/filter/ that adds carriage
returns before newlines, the staircasing can be eliminated.  So we
have to add in an <em/if/ line to our printcap entry above:
<tscreen><verb>
lp|dj|deskjet:\
    :sd=/var/spool/lpd/dj:\
    :mx#0:\
    :lp=/dev/lp0:\
    :if=/var/spool/lpd/dj/filter:\
    :sh:
</verb></tscreen>
A simple filter script might be:
<tscreen><verb>
#!perl
while(<STDIN>){chop $_; print "$_\r\n";};
</verb></tscreen>
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.)
<p>
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 extention of the above
linefeed-fixing filter.  If you write a filter than can accept
arbitrary file types as input and produce DeskJet-kosher output for
each case, then you've got a clever print spooler indeed!
<p>
Such a filter is called a <em/magic/ filter.  Don't bother writing one
yourself unless you print strange things - there are a good many
written for you already on the net.

<sect1>File Permissions
<p>
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).
<tscreen><verb>
-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/
</verb></tscreen>
<p>
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.  Bummer.

<sect>How to obtain an appropriate magic filter

<sect1>APS Filter
<p>
One of the nicest magic filter packages is aps filter, by Andreas
Klemm.  The Linux Software Map entry goes something like this:
<tscreen><verb>
Begin3
Title:        apsfilter
Version:    4.9.1
Entered-date:    Montag, 10. Juli 1995, 21:22:35 Uhr MET DST
Description:    magicfilter for lpd with auto filetype detection
Keywords:    lpd magicfilter aps apsfilter
Author:     [e-mail] (Andreas Klemm)
Maintained-by:    [e-mail] (Thomas Bueschgens)
        [e-mail] (Andreas Klemm)
Primary-site:    sunsite.unc.edu
        /pub/Linux/system/Printing/
        211KB aps-491.tgz
Original-site:    ftp-i2.informatik.rwth-aachen.de
        /pub/Linux/pak/APSfilter/aps-491.tgz
Platforms:    C-Compiler, gs Postscript emulator, pbmutils
Copying-policy:    GPL
End
</verb></tscreen>
APS filter installs as an <em/if/ filter for a print queue, and will
translate from many common file types into your printer's command
set.  It understands, for example, text, PostScript, dvi, gif, and
others.

<sect1>Magic-filter
<p>
The magic-filter package, written by B.A.McCawley, works much the same
way as does APSfilter, but since it is written in bash, it might be
more easy to customize.  The LSM entry:
<tscreen><verb>
Version: 0.4
Description: Bash scripts to simplify the task of configuring lpd to
   auto-detect file types using /etc/magic. (As advertised in the
   printing-HOWTO).
   This package uses existing filters so it only prints file types for
   which one already has filters (or compressed versions
   thereof). Alterative magic filter approches are described in the
   printing-HOWTO.
Keywords: lpd, /etc/magic, printing, filter
Author: [e-mail] (Brian McCauley)
Maintained-by: [e-mail]
Primary-site: tsx-11.mit.edu pub/linux/sources/usr.bin
              magic-filter-0.4.tar.gz  5709
Copying-policy: GNU GPL
</verb></tscreen>

<sect1>The other Magicfilter
<p>
For maximum confusion, there appear to be two packages named just
magic filter out there.  (Or are they the same?)
<tscreen><verb>
Title:          magicfilter
Version:        1.1b
Entered-date:   04APR95
Description:    A customizable, extensible automatic printer filter.
                Lets you automatically detect and print just about any
                data type you can find a conversion utility for.  This
                filter is written in C and is controlled completely
                from an external printer configuration file.
                This version adds automagic creation of configuration
                files based on the installed software on your system,
                courtesy of GNU Autoconf.
                This version is a bug fix from 1.1/1.1a; filters for
                non-ASCII capable PostScript printers have been added.
Author:         H. Peter Anvin <[e-mail]>
Primary-site:   sunsite.unc.edu
                53000 /pub/Linux/system/Printing/magicfilter-1.1b.tar.gz
Copying-policy: GPL
</verb></tscreen>

<sect>Serial printers under lpd
<sect1>Setting up in printcap
<p>
Lpd provides five attributes which you can set in
<em>/etc/printcap</em> to control all the settings of the serial port
a printer is on.  Read the <em><htmlurl name="printcap"
url="http://www.picante.com/~gtaylor/pht/man/printcap.html"></em> man
page and note the meanings of <em/br#/, <em/fc#/,
<em/xc#/, <em/fs#/ and <em/xs#/.  The last four of these
attributes are bitmaps indicating the settings for use the port.  The
<em/br#/ atrribute is simply the baud rate, ie `<tt/br#9600/'.

<p>
It is very easy to translate from <htmlurl name="stty"
url="http://www.picante.com/~gtaylor/pht/man/stty.html"> settings to
printcap flag settings. If you need to, see the man page for stty now.

<p>
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 `<em/stty -a/' looks like for my
printer port:
<tscreen><verb>
dina:/usr/users/andy/work/lpd/lpd# stty -a < /dev/ttyS2
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; 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
</verb></tscreen>
The only changes between this and the way the port is initialized at
bootup are <tt/-clocal/, <tt/-crtscts/, and <tt/ixon/. Your port may
well be different depending on how your printer does flow control.

<p>
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 `<tt/</' character as
above.

<p>
Once you have your stty settings right, so that `<em>cat file >
/dev/ttyS2</em>' (in my case) sends the file to the printer, look at
the file /usr/src/linux/include/linux/termios.h. This contains a lot
of #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

<tscreen><verb>
/* c_cflag bit meaning */
#define CBAUD   0000017
</verb></tscreen>
This section lists the meaning of the <em/fc#/ and <em/fs#/ 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?

<p>
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 <em/fc#/ capability.  Of
course, remember that you will be setting bits directly after you
clear, so you can just use `<tt/fc#0177777/' (I do).

<p>
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 <em/fs#/ capability (`<tt/fs#02275/' works fine in my
example).

<p>
Do the same with set and clear for the next section of the include
file, "c_lflag bits". In my case I didn't have to set anything, so I
just use `<tt/xc#0157777/' and `<tt/xs#0/'.

<sect1>Older serial printers that drop characters
<p>
Jon Luckey points out that some older serial printers with ten-cent
serial interfaces and small buffers <em/really/ mean stop when they
say so with flow control.  He found that disabling the FIFO in his
Linux box's 16550 serial port with <tt><htmlurl name="setserial"
url="http://www.picante.com/~gtaylor/pht/man/setserial.html"></tt>
corrected the problem of dropped characters (you apparently just
specify the uart type as an 8250 to do this).

<sect>Vendor Solutions
<p>
[ This section is, by definition, incomplete.  Feel free to send in
details of your favourite distribution. ]

<sect1>RedHat 2.x
<p>
RedHat has a GUI printer administration tool 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 <em>/etc/printcap</em> and writes a
short PostScript-and-ascii magic filter based around <tt/gs/ and
<tt><htmlurl name="nenscript"
url="http://www.picante.com/~gtaylor/pht/man/nenscript.html"></tt>.
This solution works fairly well, and is trivial to setup for common
cases.

<sect1>Other Distributions
<p>
Please send me info on what other distributions do.

<sect>How to print to a printer over the network
<p>
One of the features of lpd is that it supports printing over the
network to printers physically connected to a different machine.  With
the careful combination of filter scripts and assorted utilities, you
can make lpr print transparently to printers on all sorts of networks.
<sect1>To a Unix/lpd host
<p>
To allow remote machines to print to your printer, you must list the
machines in <em>/etc/hosts.equiv</em> or <em>/etc/hosts.lpd</em>.
(Note that <em/hosts.equiv/ 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
usign the <em/rs/ attribute; read the <tt><htmlurl name="lpd"
url="http://www.picante.com/~gtaylor/pht/man/lpd.html"></tt> man page
for information on this.

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

<sect1>With <tt>rlpr</tt>
<p>
You can also use <em>rlpr</em> 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
<em>rlpr</em>:

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

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

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

<p>
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.  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.

<p>
Rlpr is available from <tt><url name="SunSite"
url="ftp://sunsite.unc.edu/pub/Linux/system/Printing/"></tt>.

<sect1>To a Win95, WinNT, LanManager, or Samba printer
<p>
It is possible to direct an lpd queue through the <tt><htmlurl
name="smbclient"
url="http://www.picante.com/~gtaylor/pht/man/smbclient.html"></tt>
program (part of the samba suite) to a TCP/IP based SMB print service.
Samba includes a script to do this called <tt/smbprint/.  In short,
you put a configuration file for the specific printer in question in
the spool directory, and install the <tt/smbprint/ script as the
<em/if/.
<p>
The <em>/etc/printcap</em> entry goes like this:
<tscreen><verb>
lp|remote-smbprinter:\
    :lp=/dev/null:sh:\
    :sd=/var/spool/lpd/lp:\
    :if=/usr/local/sbin/smbprint:
</verb></tscreen>
<p>
You should read the documentation inside the <tt/smbprint/ script for
more information on how to set this up.
<p>
You can also use <tt>smbclient</tt> to submit a file directly to an
SMB printing service without involving <tt>lpd</tt>.  See the man page.

<sect1>To a NetWare Printer
<p>
The ncpfs suite includes a utility called <tt/nprint/ which provides
the same functionality as <tt/smbprint/ but for NetWare.  You can get
ncpfs from <url url="ftp://linux01.gwdg.de/pub/ncpfs/">.  From the
LSM entry for version 0.16:

<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 Linux printing system. 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>

<p>
To make <tt/nprint/ work via lpd, you write a little shell script to
print stdin on the NetWare printer, and install that as the <em/if/
for an lpd print queue.  You'll get something like:
<tscreen><verb>
sub2|remote-NWprinter:\
    :lp=/dev/null:sh:\
    :sd=/var/spool/lpd/sub2:\
    :if=/var/spool/lpd/nprint-script:
</verb></tscreen>
The <tt>nprint-script</tt> might look approximately like:
<tscreen><verb>
#! /bin/sh
/usr/local/bin/nprint -S net -U name -P passwd -q printq-q -
</verb></tscreen>

<sect1>To an EtherTalk (Apple) printer
<p>
The netatalk package includes something like <tt/nprint/ and
<tt/smbclient/.  Werner Eugster has documented the procedure for
printing to and from an Apple network far better than I ever will; see
his <url name="web page"
url="http://garnet.berkeley.edu/~weugster/appleprint.html">.
<p>
Obscure caveat of the week: Netatalk does not work with SMC Etherpower
PCI Card with a DEC tulip chip.

<sect1>To an HP or other ethernet printer
<p>
HPs and some other printers come with an ethernet interface which you
can print to directly using lpd.  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:
<tscreen><verb>
lj-5|remote-hplj:\
        :lp=/dev/null:sh:\
        :sd=/var/spool/lpd/lj-5:\
        :rm=printer.name.com:rp=raw:
</verb></tscreen>
<p>
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.

<sect2>To older HPs
<p>
Some printers (and printer networking "black boxes") support only a
cheesy little non-protocol involving plain TCP connections.  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)
and stuff your print job into it.  This can be implemented, among
other ways, in Perl:

<tscreen><verb>
#!/usr/bin/perl
# Thanks to Dan McLaughlin for writing the original version of this
# script (And to Jim W. Jones for sitting next to Dan when writing me
# for help ;)

$fileName = @ARGV[0];

open(IN,"$fileName") || die "Can't open file $fileName";

$dpi300     = "\x1B*t300R";
$dosCr      = "\x1B&ero;k3G";
$ends = "\x0A";

$port =  9100 unless $port;
$them = "bach.sr.hp.com" unless $them;

$AF_INET = 2;
$SOCK_STREAM = 1;
$SIG{'INT'} = 'dokill';
$sockaddr = 'S n a4 x8';

chop($hostname = `hostname`);
($name,$aliases,$proto) = getprotobyname('tcp');
($name,$aliases,$port) = getservbyname($port,'tcp')
    unless $port =~ /^\d+$/;;
($name,$aliases,$type,$len,$thisaddr) =
        gethostbyname($hostname);
($name,$aliases,$type,$len,$thataddr) = gethostbyname($them);
$this = pack($sockaddr, $AF_INET, 0, $thisaddr);
$that = pack($sockaddr, $AF_INET, $port, $thataddr);

if (socket(S, $AF_INET, $SOCK_STREAM, $proto)) {
#    print "socket ok\n";
}
else {
    die $!;
}
# Give the socket an address.
if (bind(S, $this)) {
#    print "bind ok\n";
}
else {
    die $!;
}

# Call up the server.

if (connect(S,$that)) {
#    print "connect ok\n";
}
else {
    die $!;
}

# Set socket to be command buffered.

select(S); $| = 1; select(STDOUT);

#    print S "@PJL ECHO Hi $hostname! $ends";
#    print S "@PJL OPMSG DISPLAY=\"Job $whoami\" $ends";
#    print S $dpi300;

# Avoid deadlock by forking.

if($child = fork) {
    print S $dosCr;
    print S $TimesNewR;

    while (<IN>) {
        print S;
    }
    sleep 3;
    do dokill();
} else {
    while(<S>) {
        print;
    }
}

sub dokill {
    kill 9,$child if $child;
}
</verb></tscreen>

<sect1>Running an <em/if/ for remote printers
<p>
One oddity of lpd is that the <em/if/ is not run for remote printers.
If you find that you need to run an <em/if/, you can do so by
setting up a double queue and requeueing the job.  As an example,
consider this <em/printcap/:
<tscreen><verb>
lj-5:remote-hplj:\
        :lp=/dev/null:sh:\
        :sd=/var/spool/lpd/lj-5:\
    :if=/usr/lib/lpd/filter-lj-5:
lj-5-remote:lp=/dev/null:sh:rm=printer.name.com:\
    :rp=raw:sd=/var/spool/lpd/lj-5-raw:
</verb></tscreen>
in light of this <tt/filter-lj-5/ script:
<tscreen><verb>
#!/bin/sh
gs <options> -q -dSAFER -sOutputFile=- - | \
    lpr -Plj-5-remote -U$5
</verb></tscreen>
<p>
The <em/-U/ 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 <em><htmlurl name="printcap"
url="http://www.picante.com/~gtaylor/pht/man/printcap.html"></em>.

<sect>How to print to a fax machine.
<sect1>Using a faxmodem
<p>
There are a number of fax programs out there that will let you fax and
receive documents.  One of the most complex is Sam Leffler's
<em/HylaFax/, available from <tt/ftp.sgi.com/.  It supports all sorts
of things from multiple modems to broadcasting.
<p>
Also available, and a better choice for most Linux boxen, is
<tt><htmlurl name="efax"
url="http://www.picante.com/~gtaylor/pht/man/efax.html"></tt>, a
simple program which sends faxes.  The getty program <tt/mgetty/ can
receive faxes (and even do voicemail on some modems!).

<sect1>Using the Remote Printing Service
<p>
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 <url
url="http://www.town.hall.org/fax/faq.html" name="FAQ">.


<sect>How to generate something worth printing.
<p>
Here we get into a real rat's-nest of software.  Basically, Linux can
run four types of binaries with varying degrees of success: Linux,
iBCS, Win16/Win32s (with dosemu and, someday, with Wine), and Mac/68k
(with Executor).  I'll just discuss native Linux and common Unix
software, except to say that WordPerfect for SCO, and quite probably
other commercial word processing software, runs fine under Linux's iBCS
emulation.
<p>
For Linux itself, choices are mostly limited to those available for
Unix in general:

<sect1>Markup languages
<p>
Most markup languages are more suitable for large or repetative
projects, where you want the computer to control the layout of the
text to make things uniform.  Trying to make a pretty sign in a markup
language would probably hurt...
<p>
<descrip>
<tag><tt>nroff</tt></tag>This was one of the first Unix markup
languages.  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, 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 <tt/man -t foo | lpr/.

<tag/TeX/TeX, and the macro package LaTeX, are one of the most widely
used markup languages on Unix.  Technical works are frequently written
in LaTeX because it greatly simplifies the layout issues and is
<em/still/ one of the few text processing systems to support
mathematics both completely and well.  TeX's output format is
<tt/dvi/, and is converted to PostScript or Hewlett Packard's PCL with
<tt/dvips/ or <tt/dvilj/.

<tag/SGML/There is at least one free sgml parser available for Unix
and Linux; it forms the basis of Linuxdoc-SGML's homegrown document
system.  It can support other DTD's, as well.

<tag/HTML/Someone suggested that for simple projects, it may suffice
to write it in HTML and print it out using Netscape.  I disagree, but
YMMV.
</descrip>

<sect1>WYSIWYG
<p>
There is a general shortage of WYSIWYG text processing software.  Feel
free to write some, and do let me know of anything I've omitted here.
<descrip>
<tag/Lyrix/
Lyrix is a front-end to LaTeX which looks very promising.
<tag/The Andrew User Interface System/
AUIS includes <tt/ez/, a WYSIWYG-style editor with most basic word
processor features, HTML capabilities, and full MIME email and
newsgroup support.
<tag/Commercial offerings/
At least Caldera and Red Hat ship packages containing the
usual office apps like a WYSIWYGish word processor and a spreadsheet.
I would assume they do a dandy job, but I've never used them.  I
think Caldera also ships Sun's WABI, so you could probably run
something like MS Office under that if you had to integrate with other
folks' files.
<p>

Jeff Phillips <tt/<jeff@I_RATUS.org>/ uses Caldera's WordPerfect
for Linux (on Slackware, of all things) and says that it works well.
It apparently includes built-in printer support, as one would expect.
Caldera should have info on <url url="http://www.caldera.com/">.
<p>

RedHat ships a suite called <em/Applixware/; you can find their web
site at <url url="http://www.redhat.com/">.

<p>
Other vendors feel free to drop me a line with your offerings.

</descrip>

<sect>Ghostscript.
<p>
Ghostscript is an incredibly significant program for Linux printing.
Most printing software under Unix generates PostScript, which is
typically a $100-300 option on a printer.  Ghostscript,
however, is free, and will generate the language of your printer from
PostScript.  When tied in with your <tt/lpd/ input filter, it gives
you a virtual PostScript printer and simplifies life immensely.
<p>
Ghostscript is available in two forms.  The commercial version of
Ghostscript, called Aladdin Ghostscript, may be used freely for
personal use but may not be distributed by commercial Linux
distributions.  It is generally a year or so ahead of the free
Ghostscript; at the moment, for example, it supports Adobe Acrobat's
Portable Document Format, while the older Ghostscripts do not.
<p>
The free version of Ghostscript is GNU Ghostscript, and is simply an
aged version of Aladdin ghostscript kindly given to GNU.  (Kudos to
Aladdin for this arrangement; more software vendors should support
free software in this way).
<p>
Ghostscript's main failing is in its fonts, which are derived from
bitmap scans of the characters.  Superior, but commercially licensed
fonts may be obtained from several places, since Ghostscript can read
type 1 Adobe fonts.  Adobe distributes useable fonts with their
Acrobat PDF reader, or you may use the fonts from Adobe's ATM or a
fontpack.
<p>
Whatever you do with <tt><htmlurl name="gs"
url="http://www.picante.com/~gtaylor/pht/man/gs.html"></tt>, be very
sure to run it with the option for disabling file access
(<tt/-dSAFER/).  PostScript is a fully functional language, and a bad
PostScript program could give you quite a headache.

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

<sect2>Output location and size
<p>
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.

<sect2>Gamma, dotsizes, etc.
<p>
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 you should 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.

<tscreen><verb>
---8<---- gamma.ps ----8<---
%!
%transfer functions for cyan magenta yellow black
{0.3 exp} {0.3 exp} {0.3 exp} {0.3 exp} setcolortransfer
---8<------------------8<---
</verb></tscreen>

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


<sect>On-screen previewing of printable things.
<p>
Nearly anything you can print can be viewed on the screen, too.
<sect1>PostScript
<p>
Ghostscript has an X11 driver best used under the management of the
PostScript previewer <htmlurl name="Ghostview"
url="http://www.picante.com/~gtaylor/pht/man/ghostview.html">.  The
latest versions of these programs should be able to view PDF files, as
well.

<sect1>TeX dvi
<p>
TeX DeVice Independant files may be previewed under X11 with <htmlurl
name="xdvi" url="http://www.picante.com/~gtaylor/pht/man/xdvi.html">.
Modern versions of xdvi call ghostscript to render PostScript
specials.
<p>
A VT100 driver exists as well.  It's called <tt/dgvt/.  <tt/Tmview/
works with Linux and svgalib, if that's all you can do.

<sect>Credits
<p>
The <tt/smbprint/ information is from an article by Marcel Roelofs
<tt/<[e-mail]>/.

<p>
The <tt/nprint/ information for using Netware printers was provided by
Michael Smith <tt/<[e-mail]>/.

<p>
The serial printers under lpd section is from Andrew Tefft
<tt/<[e-mail]>/.

<p>
The blurb about gammas and such for gs was sent in by Andreas
<tt/<[e-mail]>/.

</article>