home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Usenet 1994 October
/
usenetsourcesnewsgroupsinfomagicoctober1994disk1.iso
/
answers
/
linux
/
howto
/
printing
< prev
next >
Wrap
Internet Message Format
|
1993-12-15
|
94KB
Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!gatech!concert!samba.oit.unc.edu!sunSITE!mdw
From: gtaylor@cs.tufts.edu (Grant Taylor)
Newsgroups: comp.os.linux.announce,comp.os.linux.admin,comp.answers,news.answers
Subject: Linux Printing HOWTO
Followup-To: poster
Date: 15 Dec 1993 22:10:06 GMT
Organization: The University of North Carolina at Chapel Hill
Lines: 1973
Approved: linux-announce@tc.cornell.edu (Matt Welsh)
Message-ID: <2eo1vu$659@samba.oit.unc.edu>
NNTP-Posting-Host: calypso.oit.unc.edu
Summary: HOWTO on printing under Linux
Keywords: Linux, printing, lpr
Originator: mdw@sunSITE
Xref: senator-bedfellow.mit.edu comp.os.linux.announce:1574 comp.os.linux.admin:2507 comp.answers:3047 news.answers:15871
Archive-name: linux/howto/printing
Last-Modified: 1 Dec 93
The Linux Printing HOWTO
by Grant Taylor and Brian McCauley
Contents:
1 Intro
2 Printing and Faxing Software
3 LPR
4 Previewing
5 Ascii Translation
0.1 Intro
This is the Printing HOWTO for Linux. This is a member of the
second generation of Linux FAQS. The original Linux FAQ
gradually became a monolithic beast, and has now been
re-written in a new syle, refering to HOWTOs for details. This
HOWTO details how to properly set up most types of printers,
how to configure the software to make them print well, what
types of fax software are available, and how to preview many
types of printable output. Other HOWTOs detail networking,
kernel hacking, etc. All HOWTOs are found in several places,
the official location being
sunsite.unc.edu:/pub/Linux/docs/HOWTO, and another being
rtfm.mit.edu.
Please send comments, bug reports, etc, to
printing@god.ext.tufts.edu. This address goes to both Brian
and Grant.
If you know anything or can point us towards any useful
programs not in this document that should be, please let us
know!
Grant has a mail server set up on his machine. It stores
documents and other things related to printing and previewing
with Linux, including the latest and greatest version of this
document. Mail to listserv@god.ext.tufts.edu with a body of
``info'' will have you sent a list of available files. A body
of ``get file1 [ file2 file3... ] '' will send you specific
files.
0.1.1 Summary of changes
* Now in La [ me ] TeX!
* New mailserver info.
* Assorted little changes
0.2 Printing Software
These sections describe printing software known to be available
for Linux. Note that most Un*x printing software can be easily
compiled under Linux.
0.2.1 text
Under Linux, or under most any Un*x operating system, the
easiest thing to print with most printers is plain ASCII. Any
way you can arrange to send the text to the printer is
perfectly valid. If you have a serial printer, then try devices
/dev/ttys?, /dev/ttyS?, /dev/cua?, etc, and if you have a
regular parallel hookup, use /dev/lp?. Typing ``cat file
>/dev/????'' should do it. You may need root privileges, or
you may wish to chmod your printer device if this is all you
ever print. (Note the security hole there if you've more than
one user) Some printers (ie, HP DeskJet) want dos-style end of
lines: newline+carriage return. These printers will show the
'staircase effect'; further information on how to deal with it
is in ``How do I prevent the staircase effect,''
0.2.2 pr
Most plain ascii files in the un*x world have a tendency to be
just that - plain, unformatted ascii with no page breaks or
anything else to make a printed copy look nice and not have
lines printed over perferations. The answer to this problem is
to run your text through a formatter such as pr. Pr is a
standard un*x utility designed to format plain text for
printing on a line printer. The usual appearance of the
resulting formatted text has a header and/or footer, page
numbers, the date, possibly margins, double spacing, etc. As is
common with un*x utils, pr has a bazillion options. They are
detailed in the man page.
0.2.3 Postscript
Printing almost anything other than plain text under Un*x
usually involves the ability to print Postscript. If you have a
Postscript printer, you're all set. But for most, this is not
so easy.
The established way to interpret Postscript under Linux is to
use ghostscript, which, like nearly everything else, comes from
the GNU project. Ghostscript is a Postscript interpreter which
accepts Postscript input and generates output appropriate for X
displays, most printers, some specialized display hardware, and
fax software.
The following devices are available as of ghostscript
2.6.1pl4:
linux PC vga using linux vgalib
# x11 X Windows version 11, release >=4 [Unix and VMS only]
# Printers:
# * appledmp Apple Dot Matrix Printer (Imagewriter)
# bj10e Canon BubbleJet BJ10e
# * bj200 Canon BubbleJet BJ200
# * cdeskjet H-P DeskJet 500C with 1 bit/pixel color
# * cdjcolor H-P DeskJet 500C with 24 bit/pixel color and
# high-quality color (Floyd-Steinberg) dithering
# * cdjmono H-P DeskJet 500C printing black only
# * cdj500 H-P DeskJet 500C (same as cdjcolor)
# * cdj550 H-P DeskJet 550C
# * declj250 alternate DEC LJ250 driver
# + deskjet H-P DeskJet and DeskJet Plus
# * dfaxhigh DigiBoard, Inc.'s DigiFAX software format
# * dfaxlow DigiFAX low (normal) resolution
# djet500 H-P DeskJet 500
# * djet500c H-P DeskJet 500C
# epson Epson-compatible dot matrix printers (9- or 24-pin)
# + eps9high Epson-compatible 9-pin, interleaved lines
# (triple resolution)
# * epsonc Epson LQ-2550 and Fujitsu 3400/2400/1200 color printers
# * escp2 Epson ESC/P 2 language printers, including Stylus 800
# + ibmpro IBM 9-pin Proprinter
# * jetp3852 IBM Jetprinter ink-jet color printer (Model #3852)
# + laserjet H-P LaserJet
# * la50 DEC LA50 printer
# * la75 DEC LA75 printer
# * lbp8 Canon LBP-8II laser printer
# * ln03 DEC LN03 printer
# * lj250 DEC LJ250 Companion color printer
# + ljet2p H-P LaserJet IId/IIp/III* with TIFF compression
# + ljet3 H-P LaserJet III* with Delta Row compression
# + ljet4 H-P LaserJet 4 (defaults to 600 dpi)
# + ljetplus H-P LaserJet Plus
# * m8510 C.Itoh M8510 printer
# * necp6 NEC P6/P6+/P60 printers at 360 x 360 DPI resolution
# * nwp533 Sony Microsystems NWP533 laser printer [Sony only]
# * oki182 Okidata MicroLine 182
# paintjet H-P PaintJet color printer
# * pj alternate PaintJet XL driver
# * pjxl H-P PaintJet XL color printer
# * pjxl300 H-P PaintJet XL300 color printer
# * r4081 Ricoh 4081 laser printer
# * sparc SPARCprinter
# * t4693d2 Tektronix 4693d color printer, 2 bits per R/G/B component
# * t4693d4 Tektronix 4693d color printer, 4 bits per R/G/B component
# * t4693d8 Tektronix 4693d color printer, 8 bits per R/G/B component
# * tek4696 Tektronix 4695/4696 inkjet plotter
#%* trufax TruFax facsimile driver [Unix only]
# File formats and others:
# bit A plain "bit bucket" device
# bmpmono Monochrome MS Windows .BMP file format
# bmp16 4-bit (EGA/VGA) .BMP file format
# bmp256 8-bit (256-color) .BMP file format
# bmp16m 24-bit .BMP file format
# gifmono Monochrome GIF file format
# gif8 8-bit color GIF file format
# pcxmono Monochrome PCX file format
# pcxgray 8-bit gray scale PCX file format
# pcx16 Older color PCX file format (EGA/VGA, 16-color)
# pcx256 Newer color PCX file format (256-color)
# pbm Portable Bitmap (plain format)
# pbmraw Portable Bitmap (raw format)
# pgm Portable Graymap (plain format)
# pgmraw Portable Graymap (raw format)
# ppm Portable Pixmap (plain format)
# ppmraw Portable Pixmap (raw format)
# * tiffg3 TIFF/F (G3 fax)
Lines beginning with a ` # ' are drivers included with the
gs261 source distribution.
Drivers marked with % require commercial software to work
Installations of ghostscript are available from several
places:
A full, and presumably correct, installation is available in
the SLS; note that this binary requires libX.so.???, as it
includes the X11 display driver.
The `official' installation is to obtain the sources and
build it yourself:
prep.ai.mit.edu:/pub/gnu/ghostscript-xxxx.tar.gz
and ghostscript-fonts-xxxx.tar.gz
This is probably best, as you can get the latest version
(currently 2.6.1pl4 (the four patches are separate, they are
available from my mail-server as gs261-patches)).
A patch which uses the Linux svgalib, and hence does not
require X for previewing is available from
ws105.zfn.uni-bremen.de:/pub/gs261-linuxdriver.sh.
A minimal binary installation of ghostscript and several
other packages needed for printing the Linux documentation is
available as
sunsite.unc.edu:/pub/linux/apps/tex/texmin/texmin-0.1.tar.z.
Note that this does not contain any postscript fonts. (Nor do
you need them to print dvi (aka [ La ] TeX).)
The main Ghostscript documentation is contained in the file
use.doc, either in the source directory, or
.../lib/ghostscript/doc/use.doc if you haven't the sources.
To print ps, first determine your driver name with:
gs -help
which lists installed drivers. If the device you need is not
listed, you must compile gs yourself from the source
distribution (do not panic. do follow the instructions in
make.doc. you will need 5 or 6 megs of space to build it in.)
Then type
gs -dNOPAUSE -sDEVICE=?????? -sOutputFile=/dev/???? file.ps
and your output should (hopefully) appear at your printer.
Those of you with non-US paper sizes may wish to build gs
yourself with the right default, or you may use the
-sPAPERSIZE=a4 option.
Ghostscript may be used to print at most of the resolutions
your printer supports; -r300, -r150, -r360x180 are examples of
the option used to control this. Dot matrix printers in
particular need to choose an appropriate resolution, since they
do not typically run at the most common 300. Note that versions
2.6 and greater of ghostscript have more drivers.
0.2.4 fonts
(This section contains font information not specific to any
ghostscript driver (nor even specific to ghostscript). Font
information pertaining to the X11 gs drivers (and thus to
ghostview) is included in the ghostview section under
previewing)
All versions of ghostscript come with assorted public-domain
fonts, most of which were generated from bitmaps, and are
therefore of relatively poor quality. However, ghostscript can
use any PostScript Type 1 or 3 fonts you may have handy. For
example, the Adobe Type Manager (for any platform other than
mac (a conversion util for mac ps fonts was on simtel-20 in the
windows3 directory)) comes with fonts you can use. Place the
fonts (typically *.pc?) in .../lib/ghostscript/fonts/ and add
to your fontmap lines such as:
/Courier (com_____.pfb) ;
A full fontmap file for the ususal set of fonts included with
the Adobe Type Manager is available as fontmap.atm from the
printing mailserver.
TimesNewRomanPS and ArialMT fonts are interchangable with
Times Roman and Helvetica, so you can alias them this way if
this is what you have.
Adobe Type 1 fonts may be found on the net in several places:
ftp.cica.indiana.edu:/pub/pc/win3/fonts and
archive.umich.edu:/msdos/mswindows/fonts
I have not looked in these places, but this information is
lifted straight from the comp.fonts FAQ (which you should read
if fonts are a thing for you. I'll be glad to mail you a copy).
Conversion between various font types is tricky. Ghostscript
comes with the tools needed to take a bitmap (hopefully large)
and make a scalable ps font. Groff comes with the tools to
allow use of tfm/mf (TeX) and pfb (Type 1) fonts in *roff
documents. X11R5 includes several font utilities and Type 1
rendering code contributed by IBM. I have used none of the
above, but they all come with manpages, so read them. Other
font conversion utilities are listed in the comp.fonts FAQ.
Also look into the package fontutils on
prep.ai.mit.edu:/pub/gnu
0.2.5 faxing
If you have a fax modem, you can arrage to fax things out (and
in), including PostScript, dvi, ascii, etc... Arranging for
e-mail to fax itself somewhere is also straightforward.
Fax modems correspond to one of two types: Classes 1 and 2.
Class one modems are fairly common and have less of what goes
on in a fax supported in firmware (thus the software has to do
more and do it carefully. supporting such timing-critical
things under a preemptive multitasking environment such as
Linux is tricky at best). The class 1 standard is EIA 578.
Class 2 modems tend to be more expensive and comply with the
standard EIA 592. Mention of your fax modem's level of support
should be in its manuals. Do not confuse class and group. You
would be hard pressed to find a non-group III fax modem these
days (but you probably could).
Fax software which runs under linux must convert input in
whatever format into a Group III compatible image format for
transmission. As usual, Ghostscript does the job. The device
tiffg3 generates standard g3/tiff encoded fax messages. You
must compile them in if they are not there already; this is yet
another reason to get the source. Some fax sofware on
commercial platforms can use the display PostScript renderer to
render the fax image; this is not yet an option under Linux.
The GNU program netfax supports Class 2 fax modems only. It
builds nearly out of the box under linux. I have patches for
version 3.2.1; you can get them from the printing mail server
as ``netfaxpatch''. It runs a server and accepts jobs into a
queue from the local machine and the net. netfax is in use at
MIT. It accepts postscript, dvi, and ascii, and can be
configured to work as an email gate. Documentation in the
package is limited to compile notes and man pages for the
individual programs; actual installation tips are few and far
between. prep.ai.mit.edu:/pub/gnu/fax-3.2.1.tar.gz
FlexFax, available from
sgi.com(192.48.153.1):/sgi/fax/?????.src.tar.Z, is written in
C++, and thus requires g++ to build. FlexFax supports class 1
and 2 modems, uses ghostview (or a display postscript server)
for rendering, and generally is more complete, or at least
general than the somewhat MIT-specific netfax. It also can run
in place of getty and either receive a fax or spawn a login as
appropriate for the type of call. It includes precise
instructions on configuring smail3 (and other mail agents) to
send mail for so-and-so@12345678.fax to the fax at 12345678.
This is the package I recommend if you have real faxing needs,
as it is properly documented and full-featured. Version 2.x of
FlexFax is in real release now and fully supports Linux - just
type ./configure and make.
mgetty+sendfax is a Linux and SCO-specific getty for
faxmodems and a simple sendfax program. This package is on
sunsite. This is a good package for those who need to send a
fax every now and then.
modgetty (which uses tcl, an interpreted language) can
receive faxes. Try harbor.ecu.purdue.edu:/pub/tcl
0.2.6 *roff, man pages
Man pages can sometimes be printed straight from the cat pages
which come with the SLS (in lieu of the normal nroff source
pages) as though they were a normal text file (which they
mostly are). However, many printers do not like the VT escape
codes for highlighting and what not that find themselves
imbedded in these. A filter for this purpose comes with the
net-2 lpd package. It is called lpf.
If you have the nroff source to the page (the finding of
which I highly recommend) you can say
man -t foobar |lpr
and your man program will (hopefully) format the man page using
groff into PostScript, which will then be sent to your lpd and
on to the printer. This form of man page output looks MUCH
better than the plain ASCII version. Unfortunately, this
depends very much on which man program and what supporting
software you have installed. If your man doesn't do this, you
might try the perl version of man, available near
sunsite.unc.edu:/pub/Linux/system/Manual-Pagers/ It is written
entirely in perl, and is thus easily customizable (perl being
an interpreted language reminiscent of C and sh).
You can also find the nroff source file in the man
directories (most versions of man have an option to just spit
out the filename) and do it yourself, into any format supported
by groff:
groff -mandoc -T ascii,dvi,ps,X100,X75,latin8 foobar.1 [ |lpr ]
0.2.7 mpage
The package mpage converts plain text into postscript and/or
prints more than one page onto each peice of paper given
postscript or text. It is available as
wuarchive.wustl.edu:/pub/mirrors/unix-c/postscript/mpage.tar-z
or thereabouts. Note that wuarchive uses the -z suffix to mean
.Z, ie, compress, not GNUzip or freeze. ``man -t foobar |
mpage'' will send a 2-up (depending on the environment variable
MPAGE) version of the man page to lpr and its postscript
interpreter. This saves paper and speeds up printing.
0.2.8 a2ps
A2ps will take ASCII and turn it into a nice postscript
document with headers and footers and page numbers, printed two
pages on one (or otherwise, if you say so). A2ps does a very
nice job at this. It is available at the same place mpage is.
0.2.9 enscript
Enscript is a program which does basically the same thing as
a2ps. I do not know where to get it. It comes with most
commercial Un * xes.
A clone version of enscript is called nenscript, available as
/pub/Linux/system/Printing/nenscript-1.13++.bin.tar.z or
/pub/Linux/system/Printing/nenscript-1.13++.tar.z on sunsite.
0.2.10 gslp
Gslp is one of the uilities which comes with ghostscript 2.6.x
and purports to do the same ascii --> ps conversion as enscript
and a2ps. I have not used it, but the docs say that
gs -q -sDEVICE=????? -dNOPAUSE -- gslp.ps text.file [ options ]
should do the trick. (gslp.ps is the actual program, which is
written in postscript. Here it is run with the argument
`text.file.' Postscript is in many respects a programming
language more than a mere printer command language.) Further
documentation is in the file gslp.ps. There is a script file
which does the above for you.
0.2.11 psutils
Those of you who deal with large amounts of postscript may wish
for more utility programs than come with the SLS. There are
probably millions of little programs which do things to your
Postscript. A representative package of them may be found in
achilles.doc.ic.ac.uk:/tex/inter/psutils/ or
guardian.cs.psu.edu:/pub/src/psutil.tar.Z
These handle page selection, double-sided printing, booklet
creation, etc. Most large ftp sites (eg, wuarchive.wustl.edu,
ftp.uu.uunet) will have many such packages to choose from.
0.2.12 tex/dvi
[ La ] TeX is the text formatting package used by many in the
academic world and elsewhere. TeX works much like any other
compiler -- source code is run through the program ``tex'' to
become a .dvi file (analogous to an .o object file in C) which
can be further manipulated to produce printed output. This
manipulation of a dvi (DeVice Independant) file usually takes a
little bit of doing. It is well worth it; TeX's output is of
professional quality.
For those in the real world who cannot afford a dvi
understanding printer, it is usually best to convert the dvi
into postscript that you can pipe into ghostscript or lpr. The
SLS comes with a functioning installation of both TeX and
dvips. Typing ``dvips -f1 file.dvi | lpr'' will do it. Dvips
responds to either command line arguments or a file
/usr/TeX/lib/tex/ps/config.ps (in the SLS TeX distribution, at
least) in which you can arrange to have dvips automatically
send its output to lpr. Thus ``dvips file.dvi'' will do
everything that needs to be done.
Note that some .dvi's may include PostScript graphics in the
dvips stage rather than the tex stage of the game; if they are
not found, you will get a hole instead of a picture. This
follows naturally from the object file analogy above. Usually,
pre-made documentation in this form has a makefile or script to
do everything for you. The LILO documentation is an example of
this.
Dvips has several interesting options; for exemple, ``dvips
-r1 file.dvi'' will print it out backwards. We deskjet users
love this one.
If all you are given is a file with a .tex ending, try either
``tex file.tex'' or ``latex file.tex''. One of these is bound
to work. Then you have a dvi. (You may have to run it twice for
indexing)
0.2.13 eps
Eps is a program which converts dvi files directly into the
standard Epson printer language; thus it is a dvi driver for
epsons. I beleive it supports MakeTeXPK, the automatic font
rendering system used by many dvi drivers, and is available as
sunsite.unc.edu:/pub/Linux/apps/tex/eps-060.tar.gz or in
ftp.ctd.comsat.com:/pub/. Note that it is still coming out with
new versions fairly often, so there may be a newer version than
060.
0.2.14 dvilj
For LaserJet owners, there is a separate program which I
beleive is in the SLS that will take dvi and convert it
directly into your printer's language (PCL). It is called
dvilj2p or dvilj, and if not on tsx or sunsite, is certainly
available on ftp.uu.net.
(Description by Nils Rennebarth)
Its a nice driver, but a little out of fashion in the sense
that configuration (especially of font-paths) font-paths is not
very flexible and that it doesn't support virtual fonts (at
least the version 0.51 not). The biggest advantage over the
dvips/ghostscript combo is that it uses downloadable fonts
which: a) reduces data transmission to the printer drastically,
which makes the printer usable even on a serial line. b)
reduces printer-memory-requirements drastically. A standard
Laserjet with 512k memory is able to print almost every
TeX-document.
It has support for double side printing and most options you
expect a driver to have. It compiles cleanly and worked
flawlessly on our diverse hardware here.
0.2.15 texinfo
This is the native documentation format of the GNU project.
Emacs can be coerced into producing an info file out of this,
and TeX can produce nice printed documantation from the same
file. It is a bit of a stretch for both systems, but it works.
It is really just TeX source which expects the macro file
texinfo.tex to be installed on your system. Just do ``tex
<filename>'' twice (for index generation purposes), and you end
up with a plain dvi file, to print or preview at your leisure.
In emacs, you can also do M-x texinfo-format-buffer to
convert the texinfo file into an info file viewable with emacs
M-x info or an info viewer of your choice.
There are also separate programs which read and format info
from a texinfo file. These are available in
prep.ai.mit.edu:/pub/gnu/
0.2.16 hardware and drivers
There are two ways the kernel driver may be used to run the
parallel ports. One, the original, is the polling driver. The
other is the interrupt driver. In principle, the interrupt
driver only deals with the port when it gets an interrupt and
should therefore be more efficient. In practice, people have
found that it depends on the machine. It probably doesn't make
too much difference in most situations.
For the polling driver, you may adjust its polling frequency
with the program lptune without kernel twiddling. The actual
driver is in .../linux/kernel/chr_drv/lp.c.
To choose the interrupt driver rather than the polled, use
the program lptune to set it. (Lptune is available on sunsite,
or from the printing mail server.) Just put the appropriate
line in /etc/rc.local
Seven is the usual "LPT1:" IRQ, 5 is "LPT2:" for an AT class
machine. Note that if your printer is on lp0, the interrupt
driver will probably not work. The first parameter should
already contain the correct i/o base address. Many bios boot
screens have this information if you need it.
0.2.17 Printer device names
On an XT bus system LPT1: becomes /dev/lp0 (major=6, minor=0),
on an AT LPT1: becomes /dev/lp1 (major=6, minor=1). To be more
precise:
Name Major Minor I/O address
lp0 6 0 0x3bc
lp1 6 1 0x378
lp2 6 2 0x278
For a serial printer use the ttyS? (or ttys?, if you follow
that scheme) device, not the cua? device. The ttyS? devices
have major 4; the cua? devices have major 5.
0.3 LPR
This section used to the the lpd-HOWTO then it became part of
the linux-HOWTO and now it is part of printing.how-to. Who
knows where it will go next?
0.3.1 What lpr and lpd do
Most un*x systems use lpd (or the System V variant lp), the
line printer daemon, and friends to spool print jobs and run
them through all needed filters. While line printers are
certainly on their way out, spooling print jobs and running
them through filters is definitely a convenient thing. Thus
lpr. (subliminal note: PLEASE find and read the lpr, lpd,
printcap, lpc, lpq, and lprm man pages. They are in the source
dist of the net-2, if you haven't got them.)
Lpd and family are available in several places. The new Linux
net-2 package contains a working lpd. I now use this one with
my stock 0.99pl10 kernel after following the directions in Matt
Welsh's net-2 HOWTO to get my NET-2 going (you only need
loopback). A binary package which can be coaxed into working
with the old net things (pre 0.99pl10 kernel) is in the SLS.
Note a subtle difference between the two versions: the old one
placed lock files and such in /var/spool, while the net-2
version requires the directory /var/spool/lpd to exist for it's
lock file.
You will need to edit /etc/printcap to configure lpd to use
your printer. Setting up lpd to accept postscript and print it
is not very difficult; simply make a shell script fiter (qv).
Setting up lpr correctly is definitely worth the trouble if
you are going to do any printing at all. Of course, if all you
ever print is the occasional man page or instruction book, then
you can probably get by without it (but even then it's nice).
Ghostscript 2.6.x also comes with a complicated script and
utilities to generate printcap entries and manage multiple
types of queues for a printer. I have not tested these, but I
assume they can be made to work. If you are in a large-scale
environment with varied printing needs, these may be worth a
look.
0.3.2 Where do the files go and what should their permissions
be?
There is quite a bit of variation between the various releases
but I'll try where possible to offer solutions that are
universally applicable. Put /etc/lpd in your /etc/rc or
/etc/rc.local (usually in /etc/rc.local after you start syslogd
(if you use syslogd)).
Set the group fields of the file permissons/ownership as
follows:
-rwxr-s--- 1 root lp 37892 Nov 19 23:32 /etc/lpd
-rwx--s--x 1 root lp 21508 Nov 19 23:32 /usr/bin/lpc
-rws--s--x 1 root lp 17412 Nov 19 23:32 /usr/bin/lpq
-rwx--s--x 1 root lp 17412 Nov 19 23:32 /usr/bin/lpr
-rwx--s--x 1 root lp 17412 Nov 19 23:32 /usr/bin/lprm
-rwxr-xr-x 1 root lp 2816 May 10 13:37 /usr/bin/lptest
...and for each of the spool directories listed in the sd fields of
/etc/printcap...
/var/spool/lpd:
total 5
drwxrwxr-x 2 root lp 1024 May 18 23:00 .
drwxr-xr-x 11 root root 1024 Feb 19 20:56 ..
-rw-rw-r-- 1 root lp 4 May 18 23:00 .seq
-rw-rw-r-- 1 root lp 18 May 18 23:00 lock
-rw-rw-r-- 1 root lp 25 May 18 23:00 status
Note these 3 files are created by lpr and lpd so if you've
never run these they will be absent and you should touch them
into being.
In older versions the group was ``daemon'' not ``lp''.
There's also a named socket but lpd creates/deletes it as
needed.
Some of these permissions may be overkill so don't be
surprised if your system works with different permissions. The
fact that lpq needs to be suid(root) is inelegant and may
change in the future. People tell me that lpr must be
suid(root) but I've not seen evidence that this is really the
case as long as the file permissions on the spool queues are
right. Still as far as I know lpr is designed to be secure when
installed setuid(root).
Alternative approach: just make lpc, lpr and lprm
setuid(root) then you can almost forget the file permissions on
the spool queues!
You're free to choose different directories for the
executables on your system (notably lpc is usually in /etc even
though it has commands that are useful to non-root).
The master lpd lock file is fixed at compile time to be
/var/spool/lpd/lpd.lock so you must have a /var/spool/lpd
directory even if you choose not to keep your spool queue
there. In the older binaries the lock file was
/usr/spool/lpd.lock so this was not an issue.
My advise is keep your primary spool queue in /usr/spool/lpd
and make /var a symlink to usr or keep it in /var/spool/lpd and
make /usr/spool a symlink to ../var/spool. This gives the
greatest compatibility with the pathnames that are compiled
into the various distributed binaries.
The main configuration file is /etc/printcap although the old
binaries look for it in /usr/etc/. The old binaries' README
says hosts.equiv and hosts.lpd files are looked for in
/etc/inet but again the more accepted convention is to locate
them in /etc.
Since, IMHO, working out in which particular etc directory
each file should reside is tedious, I would advise having only
one:
mv -i /usr/etc/inet/* /etc/inet/* /usr/etc/* /etc/
rmdir /usr/etc/inet /etc/inet /usr/etc
ln -s ../etc /usr/etc
ln -s . /etc/inet
[ But make sure the files in /usr/etc and /etc/inet are not
already symlinks into /etc or you'll be in deep water. ]
This makes your /etc huge but I think it's safe. All the
latest stuff has only /etc paths compiled into it so eventually
we can get rid of these links.
0.3.3 What are all these diretories for?
People like to put all things that aren't needed during
bootstrap in /usr so that / is as small as possible. They
therefore move unessential big files (usually the binaries)
from /etc/ to /usr/etc/.
Unless you know what you are doing (or following the example
of someone that does) I'd advise keeping it all in /etc with
/usr/etc and /etc/inet being symlinks back to /etc. (In fact
these links are probably soon to be redundant as most recent
binaires now look in /etc/.)
The Linux/PRO approach is to have a real /usr/etc directory
containing all the non-essential stuff and make symlinks to
each file therein from its namesake in /etc. To spread out the
configuration files for the sake of tidiness there is a
directory tree called /conf and many files in /etc symlinks
into this tree.
Also a few people like all their internet stuff in /etc/inet
but as recent binaries excpect to find this stuff in /etc they
must create links for each file from /etc into /etc/inet.
To avoid the problem of your /usr filesystem filling up as a
result of stuff in spool queues some poeple perfer to keep
their spool queues and such like in a separate filesystem
called /var. If you don't have a /var file system then you
should make /var a symlink to usr. If you do have a /var
filesystem to may want to make /usr/spool a symlink to
../var/spool so that any programs expecting to find /usr/spool
will not be dissapointed.
0.3.4 lpd not working
If ``ps ax'' does not reveal a lpd then you daemon has died (or
was never started) - usually a sign that it couldn't create its
lockfile (or you tried to start it before all your filesystems
were mounted).
If lpr works only for root then you've probably got a
permission problem.
If you get ``jobs queued, but cannot start daemon'' or ``lpc:
connect: No such file or directory'' you are having trouble
with the socket connection to lpd. "start" in the context of
this error really means "wake". I don't really understand this
but the problem was common in early days with the old binaries
but developments in the TCP/IP code in the kernel fixed it for
most people. Basically is stems from a network porblem. If
you're not on a network then try congifuring youself as a
single node network and the problem should vanish.
0.3.5 Where do I get a printcap for a xxxxx?
This question is essentially meaningless - see next question.
0.3.6 The semantics of /etc/printcap
Given the similarity in appearence and name between
/etc/termcap and /etc/printcap one could be forgiven for
assuming that they contain analogous infomation. This is not
the case. Whereas termcap contains informations about terminal
*types* - (mostly escape seqences) printcap contains
information about *specific* printers (like the directory that
holds the spool queue and the device name of the printer). The
information about a printer model's escape sequences and so on
are held in the various filters which are programs called by
lpd to drive the printer. /etc/printcap simply gives the
locations of these filters. For details RTFM(printcap). [
Alternatively the net-HOWTO has a summary of some of the more
important fields. ]
One last point you should always specify ``suppress header''
``:sh:'' unless you have *text* (not postscript) printer and
want banners. On a text printer they are usually a waste of
time and paper. On a postscript printer they usually stop your
printer working. (See the banners question for further
expanation).
0.3.7 The syntax of a /etc/printcap
Ideally RTFM(termcap) (yes, I said *termcap*) but since most
people don't have TFM(termcap) here are the essentials.
Lines starting # are comments (as you might have guessed).
For each printer usable from the lpr command on your system
there is one logical line in the file. For the sake of
readability each logical line may be spread over several
physical lines by making the last character on all but the last
physical line a backslash.
Each logical line has the following format:
name1|name2|name3:string_capability=string:\
:numeric_capability#number:boolean_capability:
The leading spaces and colon on the second line are for
readability only.
A printer can have as many names as you like but
conventionally the final name is used as a longhand description
of the printer. (Still people are free to say `lpr -P "Fred's
grotty teletype"' if that's the description you've given.)
The list of capabilities can be as long as needed and the
order is not significant. Each ``capability'' is denoted by a
two character code. (The name ``capability'' comes form the
file format's termcap heritage - parameter or attribute would
be a more sensible terms.) [ Note from Ross Biro: capabilities
with 3 character names don't work properly which is why the
serial port stuff in the old binaries failed. ] Capabilities
having string value and have a = delimiter between the
capability name and the value while those having a numeric
value use a # (actually they can use either a # or an =).
Boolean ``capablilties'' are true if they appear in the list
and false if they do not.
Special characters in a string value can be expressed using `
\\'-escape sequences as in C; in addition, `\E' stands for
ESC. ` ' is also a kind of escape character; ` ' followed by
CHAR stands for the control-equivalent of CHAR. Thus, ` a'
stands for the character control-a, just like `\001'. `\'
and ` ' themselves can be represented as `\\' and `\'
respectively. `\:' for `:' seems to work but the source code
contains a waring that it can confuse the parser and `\072'
is a better idea.
Example:
lp|bam|BAM's Epson FX-80:lp=/dev/lp1:sd=/usr/spool/lp1:sh:mx#0:\
:df=/usr/local/lib/magic-filter/lp.df:\
:if=/usr/local/lib/magic-filter/lp.if:
Name is lp (this is the printer that lpr uses by default).
It's also known as bam or "BAM's Epson FX-80".
The printer is on /dev/lp1 (aka AT-bus LPT1:). I don't want a
burst page. I don't want a file length limit. Files queued by
`lpr -d' are passed through /usr/local/lib/magic-filter/lp.df
and those queued by `lpr' through
/usr/local/lib/magic-filter/lp.lf.
See also the next section.
0.3.8 An /etc/printcap gotcha
Two /etc/printcap files can look identical and yet one works
and the other doesn't.
See if ``lpc stat'' reports a printer called ` :'. The last
character on a continued line must be a\. If there are
whitespace characters after the\then it doesn't register the
next line as a continuation.
0.3.9 The minimum /etc/printcap?
This is a silly question but it is frequently asked. The answer
is ``lp:sh'' (that's 6 bytes including the required linefeed
character on the end). To use this /etc/printcap you must make
/dev/lp a symlink to your printer and create your spool queue
directory as /usr/spool/lpd. (You might think that if you
wanted banner pages you could loose the ``:sh'' but the termcap
syntax requires at least one capability per entry).
0.3.10 How do I prevent the `staircase effect'?
Un*x terminates each line of a file with a linefeed but not a
carriage return so taken literally a Un*x text file printed on
an ASCII device will start each line below the end of the
previous line. Some printers can be set to treat "linefeed" as
"carriage return, linefeed", others can't. If yours can then do
simply do that. If the printer cannot be fixed create a shell
script filter that reads:
#!/bin/sh
if [ $1 = -c ]; then
cat
else
sed -e s/$/^M/
fi
# the ``echo -ne'' assumes that /bin/sh is realy bash
echo -ne "f
where M is a carriage return character not a followed by a M.
To type M in emacs use the sequence C-q C-m and in vi use C-v
C-m. Conventionally this script is called /usr/lib/lpf. The
test of $ 1 allows the isertion of carriage returns to be
switched off by the `-l' switch on lpr.
Alternatively your printer may have an escape sequence that
will set the way it handles linefeed characters. A simple
filter that uses an `echo -ne' command to send this sequence
may be appropriate.
#!/bin/sh
# Filter for HP printers to treat LF as CRLF
# the ``echo -ne'' assumes that /bin/sh is realy bash
echo -ne "033\&k2G
cat
echo -ne "f
0.3.11 Resetting the printer after each printout
Either make your filters do it or define the `tr'
``capability'' in /etc/printcap to be your printer's font reset
command. For details of the format of this string see the
question on the format of printcap. This may not work if a
printout crashes in the middle of an escape sequence - putting
a lot of @ on the front may help but this probably won't be
enough it you were printing raster graphics when the filter
died.
0.3.12 Preventing formfeed after each printout
If you don't have an `if' specified in /etc/printcap then lpd
will automatically put a formfeed at the end of each file. If
you're using a filter then it's up to the filter to decide if
it wants to put a formfeed. To disable formfeed completely if
you don't have an `if' put :ff=: in your /etc/printcap. But
please note this suppresses the formfeed that would usually be
printed if a filter dies. If you want formfeeds after text
printouts but not on printouts printed with `lpr -l' then
create the following `if' filter:
#!/bin/sh
# the ``echo -ne'' assumes that /bin/sh is realy bash
cat
if [ "$1" != -c ]; then
echo -ne "f
fi
If you want a formfeed after `lpr -l' to be optional you can
misuse the `-i' switch to suppress the formfeed with the
following trick (after all `lpr -i -l' would usually not be
implemented).
#!/bin/sh
cat
# use lpr -i -l to print raw without trailing formfeed
if [ "$1" != -c -o "$4" = -i0 ]; then
# the ``echo -ne'' assumes that /bin/sh is realy bash
echo -ne "f
fi
0.3.13 Printing to a serial port
The first section applies to both net-2 and pre-net-2
implementations of lpd; then there is a section applicable only
to the older implementation; the rest applies to net-2 only.
First, there is a kernel patch you need to make. This applies
to pre-net-2 lpd as well (actually, the use of this should
probably just be commented out of the lpd source code). The
change is for at least patchlevel 10, but probably all others
as well.
in /usr/src/linux/kernel/chr_drv/tty_ioctl.c, around line
390, you will see:
case TIOCEXCL:
return -EINVAL; /* not implemented */
Change this to return 0, recompile the kernel, and you'll be
all set.
The following applies only to the "old" lpd, before net-2.
You cannot set any serial port settings (including baud rate)
in your printcap. Leave them all out and use stty to set up the
port (if necessary) in your rc.local, and you should be all set
(to find the correct stty settings, start with the default and
twiddle until you can correctly cat a file out the port).
The rest of this applies only to net-2 lpd although it may be
helpful to read. I put more detail into this because it's what
I use.
0.3.14 Serial settings in printcap
There are two sets of flags which you will need to set, plus
the baud rate (Note: the "fc" flag setting seems to override
the br # capability, so be sure to set that correctly as well
as the br # !).
Each of the flags can have bits set and cleared. Clearing is
done first, so specify the clear flags (fc # and xc # ) before
the set flags (fs and xs).
Setting the br # capability is self-explanatory. Example: br
# 9600
It is very easy to translate from 'stty' settings to printcap
flag settings. If you need to, see the man page for stty now.
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 "stty -a"
looks like for my printer port:
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
The only changes between this and the way the port is
initialized at bootup are -clocal, -crtscts, and ixon. Your
port may well be different depending on how your printer does
flow control.
Once you have your stty settings right, so that cat file >
/dev/ttyS2 (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 -- I did!). Go to the section that starts
out
/* c_cflag bit meaning */
#define CBAUD 0000017
This section lists the meaning of the ``fc # '' and ``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?
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
fc # capability. Of course, remember that you will be setting
bits directly after you clear, so you can just use fc # 0177777
(I do).
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 fs # capability (fs # 02275 works
fine in my example).
Do the same with set & 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 ``xc # 0157777'' and ``xs # 0''.
Once your printcap is set up, try it out. If things don't
work, see the next section.
0.3.15 cat works to the serial port, but not lpd (1)
Generally getting lpd up and running is explained elsewhere,
but if you are having trouble with serial port settings you can
prevent lpd from trying to configure your port by treating you
printer as one that does not present a normal device interface
(qv).
1. Set your printer (in your printcap) to /dev/null1. Create
/dev/null1 using mknod /dev/null1 c 1 3 (because you don't want
/dev/null to be opened exclusively).
remove the baud rate and flags settings from your printcap.
2. Create a script such as this:
#!/bin/sh
echo if: $* >> /var/spool/lpd/results
# /dev/lp is linked to /dev/ttyS2 which has the printer
exec your-old-input-filter $* > /dev/lp
...or if you didn't have an old if installed...
#!/bin/sh
echo if: $* >> /var/spool/lpd/results
cat > /dev/lp
# the ``echo -ne'' assumes that /bin/sh is realy bash
echo -en "f > /dev/lp
Make sure it's world-executable and world-readable. I call my
script /var/spool/lpd/if, to make things easy. Try out your
script (/var/spool/lpd/if < somefile) and see if it prints.
3. Set the if= capability in your printcap to call this script,
e.g. if=/var/spool/lpd/if
4. Use stty to correctly set your port settings. Try to print now.
You should be able to tell if things are being spooled, and
things *should* be printed, if your manual testing of the if
script works. But this is a kludge, so the idea is not to use
the if script.
0.3.16 cat works to the serial port, but not lpd (2)
Assuming the above method using the "if" filter works and that
you belive that you have specified what you think are the
correct flags and baud rate in printcap; check ``stty -a <
/dev/ttyS2'' (or whatever your printer port is). If the
settings are not correct, check your flags against your
printout from termios.h. If the settings are *way* not correct,
you may need to fix lpd itself. The patch follows, and you can
probably see why it's needed :-) It gets applied in the lpd/
subdirectory of the lpd source.
(the patch is coming in just a sec)
When I was setting mine up, I followed a sequence like this:
lprm (whatever -- make sure queue is empty and lpd is running)
stty (correct settings) < /dev/ttyS2
lpr (something small)
stty -a < /dev/ttyS2 (often had to ctrl-c out of this one)
(twiddle with flags)
lprm (whatever -- make sure queue is empty again...)
Here's the patch (I think its reversed so apply it with -R):
-------------------------------Cut Here-------------------------------------
*** printjob.c Thu Jul 8 20:56:59 1993
--- printjob.c~ Sat Feb 27 09:07:01 1993
***************
*** 1271,1277 ****
}
#ifdef LINUX
ttybuf.c_cflag &= ~FC; /* not quite right! */
! ttybuf.c_cflag |= FS; /* not quite right! */
#else
ttybuf.sg_flags &= ~FC;
ttybuf.sg_flags |= FS;
--- 1271,1277 ----
}
#ifdef LINUX
ttybuf.c_cflag &= ~FC; /* not quite right! */
! ttybuf.c_cflag |= ~FS; /* not quite right! */
#else
ttybuf.sg_flags &= ~FC;
ttybuf.sg_flags |= FS;
-------------------------------Cut Here-------------------------------------
0.3.17 Printers that aren't simple character devices
[ Firstly I'll explain the subject. ] The most common example
is a printer that is connected via a network in some strange
way. For example consider a printer conneccted to a host
running some esoteric OS with which you can only communicate
via E-mail. To use this printer without going through lpr you
would say something like:
| uuencode tmp | mail printer-request@eosteric
in place of:
> /dev/lp
To use such a printer through lpr the ``lp'' capability of
the print queue should be directed to a /dev/null type device
(e.g. ``mknod /dev/null1 c 1 3'') but not /dev/null itself as
lpd opens the device exclusively. Each filter must must
explicitly uuencode and mail its output. In more complex cases
if you already have an ``if'' or ``of'' filter for a strangely
connected printer then other filters can pass their output
to/through this filter to avoid duplication of effort. In this
case the ``if'' filter should usually be called with the ``-c''
switch to minimise the further manipulations if performs.
0.3.18 Getting burst/banner pages
For a simple text printer (in particular not postscript) and a
simple text banner simply take :sh: out of the printcap record.
If you want to prevent the banner comming out in whatever font
was last used on the printer then define the `tr'
``capability'' to be your printer's font reset command.
If you want a fancy customised banner (or have a postscript
printer) leave :sh: in the printcap and make each of your
filters print the banner. All the information to put on the
banner is included in the filter's positional parameters.
RTFM(printcap) for details. [ If you're using
<B.A.McCauley@bham.ac.uk>'s magic-filter package then call the
code to print the banners from the config script. ]
0.3.19 Printing text on a PS printer
You need a filter based on a program that converts ascii to
postscript. The most well known of these is ``enscript'' but
it's also the hardest to find. Others include ``a2ps'',
``nenscript'', and ``mpage'' (for details of these see sections
0.2 - 0.2 ).
0.3.20 Trunation of graphics files
This is usually because you've got a limit set on the maximum
size file that can sit in the spool queue. Put `mx # 0' in your
printcap.
0.3.21 Why doesn't `lpr -i' work?
To get lpr -i to work you need a filter istalled as `if' that
implements it. The -i switch is simply passed on by lpd to the
filter. There is such a filter usually called /usr/lib/lpf that
can be obtained from bsd source archives in the directory
bsd-source/lpr/filters. It's also part of Fred's port but he
put it in /usr/bin/. If you whant to use this program but still
want your filter to do some printer specific initialisation
then write script thus:
#!/bin/sh
# My initialisation stuff goes here
exec /usr/lib/lpf $*
0.3.22 Why doesn't `lpr -p' work?
Because it's broken. lpd always thinks that the printer is 0
characters wide regardless of what printcap says. Previous
versions of the lpd-HOWTO contained a patch but it has now been
applied to the latest distribution of the net-2 stuff.
One other thing: lpd calls pr by full pathname so if you keep
pr somewhere different from /usr/bin/pr you will need a
symlink. (Where lpd expects to find pr may vary from version to
version).
0.3.23 lprm says `too many users'
You have an anchient libc.so with a broken scandir().
0.3.24 lpc complains that it hasn't stopped a daemon
One lpd process runs all the time and it spawns children to
handle each printer as needed. Sometimes these children leave
lock files lying about. This is harless.
0.3.25 lpr over a network
To print on the printer listed as foor "foo" in the printcap on
machine "bar.baz.net" from the machine "mine.baz.net" you put
an entry like this in your /etc/printcap (on mine.baz.net):
foo:lp=:rm=bar.baz.net:rp=foo:sd=/usr/lpd/spool/foo:
and, of course, create the spool directory /usr/lpd/spool/foo.
There's no point specifying filters and the like in
mine.baz.net:/etc/printcap as it's the ones in
bar.baz.net:/etc/printcap that will get used.
On the machine bar.baz.foo, you need to put "mine.baz.net" on
a line by itself in either /etc/hosts.equiv or /etc/hosts.lpd;
note that putting it in /etc/hosts.equiv will allow for
unauthenticated logins as well as printing. /etc/hosts.lpd is
printing only.
0.3.26 Writing lpd filters
In normal Un*x terminology, filters are just programs (so they
must have execute permission) that read a stream from their
standard input and write to their standard output.
lpd filters are filters in the sense that thay read STDIN and
write to STDOUT, but are unusual in that they may assume that
their standard input is a file and perform lseek() operations
on it.
All lpd filters have a common command line syntax (or more
often simply ignore command line parameters). For details of
the command line parameters RTFM(printcap).
It's easier to debug filters if you test them in an immediate
shell before you install them. (If your filter makes use of its
command line arguments you'll have to specify them too).
my-new-filter <file >/dev/lp1
If you want to write a shell script filter it must have a #
!/bin/sh header. Here is the generic form of a filter to accept
postscript.
#!/bin/sh
/path.../gs -q -dSAFER -dNOPAUSE -r??? -sDevice=?????? -sOutputFile=- -
and place its full pathname as one of the filter (usually `if'
but not 'of'!) parameter in the printcap for your printer. I
suggest putting such scripts in a subdirectory off /usr/lib
(sat /usr/lib/lpd/). (-dSAFER attempts to protect against ps
interpreter security holes, -q and -dNOPAUSE make it churn
right along quietly, and Device is the appropriate driver for
your printer).
Here is an Epson FX-80 dvi filter using ghostscript:
#!/bin/sh
/usr/TeX/bin/dvips -f | \
/usr/bin/gs -q -dSAFER -sDEVICE=eps9high -r120x216 \
-dNOPAUSE -sOutputFile=- -
More tools useful for makeing filters are described elsewhere
in this document.
0.3.27 A filter tests OK but fails when lpd uses it
You may need a # !/bin/sh header. You may also need to set PATH
within the script since the daemon's PATH may not have
everything you need.
0.3.28 `of' filters
Never use these. (Well strictly speaking there are
circumstances but you're unlikey to meet them).
0.3.29 Getting filters for given printers
From: B.A.McCauley@bham.ac.uk (Brian McCauley)
>From BSD source archives (I think). [ Editors note: I need a
better answer here ] .
If you already have a program to print say DVI on your
printer by some mechanism then making it into a filter is
usually a matter of writting trivial shell script - see this
HOWTO. If the program you are using insists on reading a names
file as input see the next question. Text mode filters are
trivial too (see this HOWTO) unless you want lpr to have a
choice of fonts in which case they are slightly harder than
trivial. You will probably want to insert and `echo -ne'
command at the beginning and end of your filter to set up the
font etc to your liking.
0.3.30 Filters from programs that won't read STDIN
For example dvilj2p insists on a named file as its input (and
what's more expects one with a .dvi suffix) so do this:
#!/bin/sh
ln -s /proc/self/fd/0 /tmp/$$.dvi
dvilj2p /tmp/$$
rm /tmp/$$.dvi
Note: If it wasn't for the fact that dvilj2p adds a .dvi
suffix you wouldn't need the temporary symlink and could just
specify /proc/self/fd/0 directly. People who use this trick
often usually keep permanant symlinks to /proc/self/fd/* in
/dev. If you don't have procfs you'll need to create a
temporary file.
0.3.31 Having many filters
Historically the lpr command was created to support a finite
set of possible file types. You can, in fact, use any of the
filters for any reason. If you're never going to use Benson
Varian raster files you could use the -v switch for GIF files.
You could even use -d for low res and -v for high res. Remember
that if you create a filter for a file format that takes a long
time to process then your printer may sit idle between print
jobs even when there are things in the queue.
If you are on a network remember that the filter setups go on
the print server. One way to avoid running out of filter
options is to define several logical printers in /etc/printcap
that all point to the same physical one and put each filter in
the ``if'' field of a different printcap entry. This has the
advantage that you can set the PRINTER enviroment variable to
choose your filter rather than having to specify it on the
command line each time. One small problem with this is that you
have no control over the order in which files from separate
queues are printed.
Another way to avoid running out of possible types is to use
magic filters.
0.3.32 What are magic filters?
Magic filters deduce their input files' types from `magic
numbers' (distictive byte patterns at particular offsets).
Magic filters are usually perl scripts, shell scripts or C
programs that simply identify the file type then call the
appropriate non-magic filter. Blatent plug :-) I
<B.A.McCauley@bham.ac.uk> have a generic magic filter bash
script that selects the right filter to use based on the output
of the `file' command. With my magic ``dvi'' filter (and 3
associated non-magic filters) I can do things like:
lpr -d file1.dvi file2.div.Z file3.ps file4.texinfo.gz
(BTW confguring lpr to handle texinfo files is getting a bit
silly - see previous question).
This is now at:
tsx-11.mit.edu:pub/linux/sources/usr.bin/magic-filter-0.3.tar.gz
(Although the release number will possibly change in future).
Magic filters should never specified as `of' as the output
filter only gets called once if a number of files are printed
without a gap.
IMHO magic filters as `if' can also cause problems as they
may prevent you, say, listing a PostScript or nroff file.
(Other people disagree as, if you are making your printer
available on a network, it can be a pain having people
accidently listing ps files.) The following is an example of a
magic shell script which should take either postscript or text
and deal with it:
0.3.33 Magic filter examples
The following is an example of a magic shell script which
should take either postscript or text and deal with it:
#!/bin/sh
# This is based on a script I received from Scott Doty and which was
# written by Keith Walker. Keith's script made use of the fact that
# lpd passes options to if:
#
# <if> -w<width> -l<length> -i<indent> -n <user> -h <host> <accountingfile>
#
# to print text out well at any size. This one does not. These options
# are also handy if you want to do your own snazzy header page, much
# like NeWSPrint from Sun does (although running PostScript through
# the display server to get it interpreted is a bit much :)
#
# This is untested, but bits of it came from working programs, so it
# should work.
#
# gs will reset the printer anyway, so the this text setup doesn't matter
# setup should include the escape code for \n conversion, if applicable
#
printf "<printer setup for text printing (escape codes, etc)>"
read first_line
first_two_chars=`expr $first_line : '(..)'`
if [ "$first_two_chars" = "%!" ]; then # it's postscript
/usr/bin/gs -dSAFER -dNOPAUSE -q -sDEVICE=??????? -sOutputFile=- -
else # it's plain text
echo -n $first_line
cat
printf "\014"
fi
Note that for the paranoid, shell scripts run as someone
other that the user are a security hole, but they are
illustrative.
An example written in C, which may be easily adapted to most
installations is available from the printing mail server as lpr
_if.c
0.4 Previewing
These sections describe various ways to preview things under
Linux - that is, how to view them in a way approximating their
final form without printing them out.
0.4.1 ghostview
Ghostview, a companion program for gs, previews postscript on
an X display. It also lets you select individual or ranges of
pages from a postscript document to print using lpr. The new
version, 1.5, has fixed a few glitches which never bothered me
but may make a difference to you. It also calls gs with the
-dSAFER option and has a few more resource and command-line
options relative to 1.4.1. The real installation is from
prep.ai.mit.edu:/pub/gnu/ghostview-XXX.tar.gz and builds out of
the box. Ghostview requires gs to work. The new version of gs,
2.6.x, will use X display fonts in an effort to improve
legibility at the low resolutions of a video monitor (a
previous failing of this pair relative to commercial
display-postscript based systems such as Sun's pageview). This
works very well for me at least, at the expense of exact
character positioning (x fonts have different widths). In fact,
I thought that Ghostview looks better than Sun's pageview the
other day when I looked at the same page in oth programs
side-by-side. Ghostview/gs also has much more intelligent color
handling than pageview. You might wish to let gs render some
Type 1 fonts you install instead of using platform fonts (or
the awful fonts gs comes with. To do this while in ghostview
(or in any situation involving the X11 driver), place
``ghostscript.useExternalFonts: false'' in your .Xdefaults
file, and the platform fonts will not be used.
This is part of a message posted to gnu.ghostscript.bug by
Tim Theisen <ghostview@cs.wisc.edu>:
(note that the usual Linux X-server, XFree, is simply an
enhanced version of MIT's effort at a i386 X-server (X386), and
does contain the X11R5 Type 1 rasterizer which I beleive was
contributed by IBM.)
Ghostscript now uses the X Toolkit to pick up X Resources.
Now ghostscript uses the standard X rules that allow more
specific resources to override less specific ones giving users
the full power of X resources to control the X11 driver. It
also allows system administrators to establish an application
defaults file with resources specific to their ghostscript
installation.
The customization choices mentioned in make.doc have been
moved into X resources and are now configured at run time
rather than compile time. Sorry, this section of make.doc did
not get revised for the 2.6.1 release.
If useBackingPixmap is set, ghostscript will attempt to
allocate a backing pixmap. If one cannot be allocated,
ghostscript will issue a warning and ask for backing store
instead. (Since there were insufficient resources for a backing
pixmap, the X server may not provide backing store either.)
Color Handling was totally revamped for gs 2.6.
Ghostscript first checks for a suitable standard colormap. If
you have static colormap in your X server, it would be best to
store a standard colormap property on the root window
describing the color layout. Ghostscript will then be able to
take full advantage of the device. If you have a standard
colormap installed, ghostscript will start slightly faster
since it does not have to allocate colors for a cube or ramp.
If no standard colormap is available, ghostscript will
allocate an RGB cube or gray ramp. Ghostscript tries for a
5x5x5 cube on a color device, and a 128 gray ramp on grayscale
devices. It will never ask for more than 1/2 of the colors for
a RGB cube or gray ramp. It also takes into account the number
of significant bits per pixel. (i.e. It won't ask for 128 gray
levels if you only have 16 available.)
Ghostscript will attempt to allocate colors that are off the
color cube/ramp as the picture is being rendered. Ghostscript
will keep track of 256 dynamic colors. After all these are
allocated, ghostscript asks the X server directly.
The foreground and background color can be set explicitly.
This is important for the visually impaired and when using the
ghostview widget.
Color Resources:
* palette(Palette): Default value: "Color". Other allowable
settings: "Grayscale", "Monochrome". The palette resource is
used to restrict the palette used for display. One can set
palette to "Grayscale" or "Monochrome" to see how a file would
be rendered in grayscale or monochrome on a color display. I
use it to avoid dithering of gray- scale figures on a color
display with 4-bit DACs.
* maxGrayRamp(MaxGrayRamp): Default value: 128. Maximum number of
gray levels that ghostscript will attempt to allocate. (It
won't try for more than this on an 8-bit pseudo color display
even if you set it higher.) Set this lower if you want a
smaller ramp and would prefer ghostscript to use dynamic
colors.
* maxRGBCube(MaxRGBCube): Default value: 5. Maximum number of
colors levels that ghostscript will attempt to allocate. (It
won't try for more than this on an 8-bit pseudo color display
even if you set it higher.) Set this lower if you want a
smaller ramp and would prefer ghostscript to use dynamic
colors.
I believe these values to be a good compromise between
dynamic allocation and fall back onto a fairly good color cube
for dithering.
You can use the foreground and background colors to
accomplish "reverse video". However, if you have a grayscale
device, it may be better to reverse the gray ramp using the
following PostScript code fragment:
[ 1 exch sub /exec load currenttransfer /exec load ] cvx
settransfer
The X11 driver now supports native X11 fonts. If you have
installed the HP XLFD font extensions into your font or X
server. Ghostscript will also be able to use platform fonts at
rotations of 90 degrees, with mirroring, and anamorphic
scaling.
The X11 driver does most if its work silently. You can get it
to report when it is using an X11 font by setting the
logExternalFonts boolean in your X resources.
The X11 driver is setup to use the standard fonts distributed
with X11R5. We purchased the Adobe Type Manager and the Adobe
Plus Pack. These font packages give all the fonts normally
found in the Apple LaserWriter Plus. The X11 driver is setup to
handle these fonts as well. (They are a superset of the bitmap
fonts distributed with X11.)
You may set the regularFonts, symbolFonts, or dinbatFonts
resources if you have different fonts available. Each font name
must have 7 dashes or it will be ignored. Minimize the use of
wildcards to promote faster matching. (I once encountered an X
server that took many seconds to do a font lookup when
wildcards were carelessly used.)
There is a different list of fonts for each common encoding.
Regular fonts may be accessed in standard or ISO Latin 1
encoding. The bdf files that are distributed with X11 are in
the ISO Latin 1 encoding. This leaves out the ligatures.
Luckily, the ligatures are present in the bdf files, but are
not given an encoding, essentially commenting them out. You can
use the fixfont program from the xproof distribution
(ftp.cs.wisc.edu:/pub/X/xproof.tar.Z, or
ftp.x.org:/contrib/xproof.tar.Z) to reencode the bdf files and
build X11 fonts that contain the ligatures (i.e standard
encoding).
If you have the Type1 fonts mentioned above, and you
installed the Type1 rasterizer into you font or X server, you
can use the appended fonts.scale to name your fonts so that
ghostscript can find them.
Font resources:
* useExternalFonts(UseExternalFonts): Default value: true. This
resource controls whether X11 fonts will be used.
* useScalableFonts(UseScalableFonts): Default value: true. This
resource controls whether scalable fonts will be used. If you
have an outline scaler in your X server, you should have this
on. If you have an X terminal, you may get slightly better
performance with this on. If you have to use the X11 bitmap
scaler, turn this off. Fonts scaled by the bitmap scaler look
worse than the default ghostscript fonts.
* logExternalFonts(LogExternalFonts): Default value: false.
Controls whether to report when X11 fonts are being used.
The following fonts.scale makes all of the fonts of the Adobe
Type Manager and Adobe Plus pack available in standard and ISO
Latin 1 encoding. (We were able to purchase the above two
packages at an educational discount price of $ 150.)
70
agw_____.pfb -Adobe-ITC Avant Garde Gothic-Book-r-normal--0-0-0-0-p-0-iso8859-1
agwo____.pfb -Adobe-ITC Avant Garde Gothic-Book-o-normal--0-0-0-0-p-0-iso8859-1
agd_____.pfb -Adobe-ITC Avant Garde Gothic-Demi-r-normal--0-0-0-0-p-0-iso8859-1
agdo____.pfb -Adobe-ITC Avant Garde Gothic-Demi-o-normal--0-0-0-0-p-0-iso8859-1
bkl_____.pfb -Adobe-ITC Bookman-Light-r-normal--0-0-0-0-p-0-iso8859-1
bkli____.pfb -Adobe-ITC Bookman-Light-i-normal--0-0-0-0-p-0-iso8859-1
bkd_____.pfb -Adobe-ITC Bookman-Demi-r-normal--0-0-0-0-p-0-iso8859-1
bkdi____.pfb -Adobe-ITC Bookman-Demi-i-normal--0-0-0-0-p-0-iso8859-1
com_____.pfb -Adobe-Courier-Medium-r-normal--0-0-0-0-m-0-iso8859-1
coo_____.pfb -Adobe-Courier-Medium-o-normal--0-0-0-0-m-0-iso8859-1
cob_____.pfb -Adobe-Courier-Bold-r-normal--0-0-0-0-m-0-iso8859-1
cobo____.pfb -Adobe-Courier-Bold-o-normal--0-0-0-0-m-0-iso8859-1
hv______.pfb -Adobe-Helvetica-Medium-r-normal--0-0-0-0-p-0-iso8859-1
hvo_____.pfb -Adobe-Helvetica-Medium-o-normal--0-0-0-0-p-0-iso8859-1
hvb_____.pfb -Adobe-Helvetica-Bold-r-normal--0-0-0-0-p-0-iso8859-1
hvbo____.pfb -Adobe-Helvetica-Bold-o-normal--0-0-0-0-p-0-iso8859-1
hvn_____.pfb -Adobe-Helvetica-Medium-r-Narrow--0-0-0-0-p-0-iso8859-1
hvno____.pfb -Adobe-Helvetica-Medium-o-Narrow--0-0-0-0-p-0-iso8859-1
hvnb____.pfb -Adobe-Helvetica-Bold-r-Narrow--0-0-0-0-p-0-iso8859-1
hvnbo___.pfb -Adobe-Helvetica-Bold-o-Narrow--0-0-0-0-p-0-iso8859-1
ncr_____.pfb -Adobe-New Century Schoolbook-Medium-r-normal--0-0-0-0-p-0-iso8859-1
nci_____.pfb -Adobe-New Century Schoolbook-Medium-i-normal--0-0-0-0-p-0-iso8859-1
ncb_____.pfb -Adobe-New Century Schoolbook-Bold-r-normal--0-0-0-0-p-0-iso8859-1
ncbi____.pfb -Adobe-New Century Schoolbook-Bold-i-normal--0-0-0-0-p-0-iso8859-1
por_____.pfb -Adobe-Palatino-Medium-r-normal--0-0-0-0-p-0-iso8859-1
poi_____.pfb -Adobe-Palatino-Medium-i-normal--0-0-0-0-p-0-iso8859-1
pob_____.pfb -Adobe-Palatino-Bold-r-normal--0-0-0-0-p-0-iso8859-1
pobi____.pfb -Adobe-Palatino-Bold-i-normal--0-0-0-0-p-0-iso8859-1
sy______.pfb -Adobe-Symbol-Medium-r-normal--0-0-0-0-p-0-iso8859-1
tir_____.pfb -Adobe-Times-Medium-r-normal--0-0-0-0-p-0-iso8859-1
tii_____.pfb -Adobe-Times-Medium-i-normal--0-0-0-0-p-0-iso8859-1
tib_____.pfb -Adobe-Times-Bold-r-normal--0-0-0-0-p-0-iso8859-1
tibi____.pfb -Adobe-Times-Bold-i-normal--0-0-0-0-p-0-iso8859-1
zcmi____.pfb -Adobe-ITC Zapf Chancery-Medium-i-normal--0-0-0-0-p-0-iso8859-1
zd______.pfb -Adobe-ITC Zapf Dingbats-Medium-r-normal--0-0-0-0-p-0-iso8859-1
agw_____.pfb -Adobe-ITC Avant Garde Gothic-Book-r-normal--0-0-0-0-p-0-adobe-fontspecific
agwo____.pfb -Adobe-ITC Avant Garde Gothic-Book-o-normal--0-0-0-0-p-0-adobe-fontspecific
agd_____.pfb -Adobe-ITC Avant Garde Gothic-Demi-r-normal--0-0-0-0-p-0-adobe-fontspecific
agdo____.pfb -Adobe-ITC Avant Garde Gothic-Demi-o-normal--0-0-0-0-p-0-adobe-fontspecific
bkl_____.pfb -Adobe-ITC Bookman-Light-r-normal--0-0-0-0-p-0-adobe-fontspecific
bkli____.pfb -Adobe-ITC Bookman-Light-i-normal--0-0-0-0-p-0-adobe-fontspecific
bkd_____.pfb -Adobe-ITC Bookman-Demi-r-normal--0-0-0-0-p-0-adobe-fontspecific
bkdi____.pfb -Adobe-ITC Bookman-Demi-i-normal--0-0-0-0-p-0-adobe-fontspecific
com_____.pfb -Adobe-Courier-Medium-r-normal--0-0-0-0-m-0-adobe-fontspecific
coo_____.pfb -Adobe-Courier-Medium-o-normal--0-0-0-0-m-0-adobe-fontspecific
cob_____.pfb -Adobe-Courier-Bold-r-normal--0-0-0-0-m-0-adobe-fontspecific
cobo____.pfb -Adobe-Courier-Bold-o-normal--0-0-0-0-m-0-adobe-fontspecific
hv______.pfb -Adobe-Helvetica-Medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
hvo_____.pfb -Adobe-Helvetica-Medium-o-normal--0-0-0-0-p-0-adobe-fontspecific
hvb_____.pfb -Adobe-Helvetica-Bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
hvbo____.pfb -Adobe-Helvetica-Bold-o-normal--0-0-0-0-p-0-adobe-fontspecific
hvn_____.pfb -Adobe-Helvetica-Medium-r-Narrow--0-0-0-0-p-0-adobe-fontspecific
hvno____.pfb -Adobe-Helvetica-Medium-o-Narrow--0-0-0-0-p-0-adobe-fontspecific
hvnb____.pfb -Adobe-Helvetica-Bold-r-Narrow--0-0-0-0-p-0-adobe-fontspecific
hvnbo___.pfb -Adobe-Helvetica-Bold-o-Narrow--0-0-0-0-p-0-adobe-fontspecific
ncr_____.pfb -Adobe-New Century Schoolbook-Medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
nci_____.pfb -Adobe-New Century Schoolbook-Medium-i-normal--0-0-0-0-p-0-adobe-fontspecific
ncb_____.pfb -Adobe-New Century Schoolbook-Bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
ncbi____.pfb -Adobe-New Century Schoolbook-Bold-i-normal--0-0-0-0-p-0-adobe-fontspecific
por_____.pfb -Adobe-Palatino-Medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
poi_____.pfb -Adobe-Palatino-Medium-i-normal--0-0-0-0-p-0-adobe-fontspecific
pob_____.pfb -Adobe-Palatino-Bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
pobi____.pfb -Adobe-Palatino-Bold-i-normal--0-0-0-0-p-0-adobe-fontspecific
sy______.pfb -Adobe-Symbol-Medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
tir_____.pfb -Adobe-Times-Medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
tii_____.pfb -Adobe-Times-Medium-i-normal--0-0-0-0-p-0-adobe-fontspecific
tib_____.pfb -Adobe-Times-Bold-r-normal--0-0-0-0-p-0-adobe-fontspecific
tibi____.pfb -Adobe-Times-Bold-i-normal--0-0-0-0-p-0-adobe-fontspecific
zcmi____.pfb -Adobe-ITC Zapf Chancery-Medium-i-normal--0-0-0-0-p-0-adobe-fontspecific
zd______.pfb -Adobe-ITC Zapf Dingbats-Medium-r-normal--0-0-0-0-p-0-adobe-fontspecific
0.4.2 gspreview
This is another front-end for ghostscript. I have gotten and
built it, and actually preferred the user interface, but it had
a slight glitch which was probably me doing a careless install
rather than a program bug. It didn't seem as feature-full as
ghostview, though. (Not that there are all THAT many features
in ghostview, but it does its job well).
ftp.x.org:/contrib/GSPreview...
0.4.3 xdvi
A beautifully legible previewing program for dvi with a handy
zoom+pan feature. Will not interpret ps specials, which are
understood only by dvips (back to the compiler, object file,
and now linker analogy :) To view a file, do ``xdvi file.dvi''.
Mine (from ftp.x.org:/contrib/... ) has the selfile feature,
where xdvi puts up a file browser... cute but useless. This
comes with either TeX or X in the SLS -- I don't remember.
Either way, you've probably got one.
0.4.4 xtex
Xtex is similar in purpose to xdvi. I have tried to build it
under Linux and failed. It is available as
ftp.x.org:/contrib/xtex-2.18.5.tar.Z
0.4.5 gxditview
Ditview produces a preview version of troff source using X
fonts ``groff -TX100 -mandoc man_page.1'' will run gxditview
to show you a typeset version of the man page. -TX75 is the
same thing, but tiny. My SLS didn't have a working one at all.
A good one comes with the source to groff, which you might want
to get anyway for the additional drivers (the SLS, until
recently, was missing several, including postscript).
prep.ai.mit.edu:/pub/gnu/groff-xxxx.tar.z
0.4.6 non-x-previewing
Gs comes with pc video hardware drivers, but under un*x these
are not a good thing. However, there are gs binaries around
which will use the Linux VGA library (vgalib). The ghostscript
device for this is called linux, thus ``gs -sDEVICE=linux
file.ps'' will show you an image of the Postscript. The
environment variable GSVGAMODE is important for this. Set it to
the nuber of the video mode you want, taken from the vga.h
which comes with vgalib.
At one point the SLS binaries had this driver, then they
didn't, and now they do again (I saw an announcement to this
effect Aug 14). (``gs -help'' will list the available drivers
in your binary.)
If you need this driver, a patch to put in Linux svgalib is
available as ws105.zfn.uni-bremen.de:/pub/gs261-linuxdriver.sh.
The plain vgalib driver is available on Sunsite.
Texmgr is a program which will preview dvi under MGR. I don't
beleive that it currently works under Linux MGR, but if it
does, MGR uses sufficiently less memory and disk that this
might be an attractive option for some.
dvgt is a program which will preview dvi with Linux svgalib,
or on one of several types of graphics terminals including vt,
tek, or a PC with MS-Kermit. It is available on sunsite.
0.5 Ascii translation
These sections describe various programs which can generate
plain ascii from some file formats.
0.5.1 from TeX
Lametex will generate ascii from tex source. It is available as
sunsite.unc.edu:/pub/Linux/apps/tex/lametex.tar.z
0.5.2 from dvi
Dvi2tty is the name of a program which will process dvi into
text. Aparently, it will also make an effort at reproducing
graphics as well.
0.5.3 from ps
Ghostscript 2.6.1 comes with a script file which will use gs to
extract just the text from a ps file, called ps2ascii. See the
gs information above for where it can be found. Further
documentation is in the ghostscript 2.6.1 distribution files
`gs_2asc.ps' and `use.doc'
0.5.4 from troff
groff -Tascii or -Tlatin1.....
0.5.5 from ascii/latin1
The GNU program recode handles conversion between various forms
of straight text encoding, ie from Latin-1 to ASCII. This would
be available on prep.ai.mit.edu.