Subject: The Printing How-To
From: [email-masked] (Grant Taylor)
Date: Tue, 8 Jun 1993 14:45:51 GMT
Newsgroups: comp.os.linux.announce

How to print under Linux - release June 07-93

INTRO  <<<<<<--------

This is my printing/previewing how to for Linux.  Please send
comments, bug reports, etc, to:

[email-masked]

Some details are missing, others are unclear; please fill me in at the
above address, and I will update this thing...

I now have a mail server set up on my machine.  It stores documents
and other things related to printing and previewing with Linux,
including the latest and greatest version of this document.  Send mail
with the subject `help' to:

<not quite done yet... anyone wish to help with testing?>@god.hounix.org

for further information.

Summary of changes since release may 30-93:

lpr
hardware and kernel drivers
contributors
non-x-previewing
enscript

****************************************************************
** -main categories are followed in the text by;              **
**  CATEGORY    <<<<<<<<<<---------- ,                        **
**              ^^^^^^^^^^^^^^^^^^^^                          **
** -sub categories all begin with;                            **
**  '-- CATEGORY',                                            **
**   ^^                                                       **
** -user input field variables are designated by;             **
**  '?' character. You fill in the information.               **
****************************************************************

INDEX   <<<<<<<<<<----------

intro
  me
  changes

index

printing
  ascii
  postscript
  lpr
  remote printing
  *roff/man pages
  mpage
  a2ps
  enscript
  gslp
  psutils
  tex/dvi
  dvilj
  texinfo
  hardware and kernel drivers

previewing
  ghostview
  gspreview
  xdvi
  xtex
  gxditview
  
non-x-previewing
  
ascii translation
  from tex
  from dvi
  from ps
  from troff
  from ascii  (just kidding:)

contributors

PRINTING   <<<<<<<<----------

-- ASCII 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 security
hole there if you've more than one user)  Some printers (ie, HP
DeskJet) want dos-style end of lines: newline+carriage return.  For
these, you can simply filter them through a little sed script which
adds a cr after each nl:

cat file |sed -e "s/$/^M/" >/dev/????

You can also arrange to send the appropriate commands to the printer
(or change some little switches at the back/underneath)
so that it will not require the carriage-returns to print things
sanely.

-- POSTSCRIPT

Printing almost anything other than plain text under unix 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 supposedly some fax
software.  

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.  It didn't used to have the fonts, but I believe it
does now.

The `official' installation is to obtain the sources and build it
yourself:

prep.ai.mit.edu(or any gnu mirror):/pub/gnu/ghostscript-xxxx.tar.z
and                                         ghostscript-fonts-xxxx.tar.z

This is probably best, as you can get the latest version (currently
2.6.1) without waiting for the SLS to get it in there.  Relying on
softlanding is not a good thing; you should learn how to build things
under Unix yourself.  If you haven't the time, others do, and post
binary installations independantly from the SLS folk to major linux
ftp sites.  (This is not an SLS bash; the SLS is the best way to
bootstrap yourself into the Linux world, but it is not very good for
upgrading purposes).  One of these options may be needed if you don't
have X libraries; the SLS binaries include the X11 device and
therefore want the X libraries.

A minimal binary installation of ghostscript and several other
packages needed for printing the linux documentation (which is in the
works and comes in LaTeX) 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.)

To print ps, first determine your driver name:

gs -help

and remember it.  Then type 

gs -dNOPAUSE -sDEVICE=?????? -q -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 just 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 general and 24 pin Epson
compatibles in particular need to choose an appropriate resolution.
Also worth trying is epsonc, with the Epson LQ-2550 command set, which
is apparently the same as for any other epson but for the color.  Thus
if you don't try to print color, you may be fine, and will be using a
driver for more recent epsons.  (I found this made my Panasonic go
faster; mileage may vary).  Note that versions 2.6 and greater of
ghostscript have more drivers.

-- LPR

(This is an attempt at describing a few simple lpd setups.  From more
information, consult the documentation and the lpd FAQ by Brian
McCauley <[email-masked]>)

Most 'real' unix systems use lpd, 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.  PLEASE read the lpr, lpd, printcap, lpc, lpq, and lprm man
pages.  You will need to edit /etc/printcap to configure Linux to use
your printer.  Setting up lpd to accept postscript and print it
is not very difficult; simply make the following shell script:

#!/bin/sh
/path.../gs -q -dSAFER -dNOPAUSE -sDevice=?????? -OutputFile=- -

and place its full pathname as the `if' parameter in the printcap for
your printer.  Do not forget to chmod it +x.  (-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).  You may wish to have this be a different printer than
the default.  If so, just create a new entry in printcap with the same
port, but different names and `if' parameters.  A name like `ps' would
be nice.  You will also need to set up a spooling directory, and make
sure you have the binaries lpd, lpr, lprm, lpq.  The biggest problem
seems to be figuring out the permissions for the spool directories and
programs.  Single user systems can just make everything write and
read-able, but multi-user systems will want to be careful about it.  A
binary package which can be coaxed into working perfectly is in the
SLS.  Once you have done this, simply saying

lpr file.ps    or   cat file.ps | lpr   or  ....

will print out postscript on your (probably not postscript) printer,
assuming that lpd is running.  (Lpd is a daemon, which runs, or rather
sleeps, in the background until something to do comes along.  It then
processes the PostScript you want to print, and keeps it in its spool
area until it has finished printing it. Start it
in your /etc/rc.local with the line /etc/lpd).  This use of lpr is
what most programs expect to do under unix when they want to generate
printed output.

This is a relatively simple and unsophisticated installation of lpr.
You power users and unix wizard wannabe's may wish to do something
more elegant.  This may be accomplished by substituting a more complex
script or program for the filter `if'.  A shell script or C program to
determine the type of input and print it appropriately can be easily
written, and there are several versions floating around out there.

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> width length indent user host accountingfile
# 
# to print text out well at any size.  This one does not.  These options
# are particularly 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
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			# otherwise it's plain text
        echo $first_line
        cat
        printf "\014"
fi

Note that for the extremely paranoid, shell scripts run as someone
other that the user are a security hole, but it was illustrative.

Even more snazzy things can be done.  The following is the gzip'd,
uuencoded, C source to a full-featured program which automagically
recognizes text, dvi, postscript, and direct printer driving (aka
binary) and does the appropriate thing.  You will have to modify it to
reflect your printer rather than an HP LJ III.  In particular, the
driver used for gs, and the use of dvips instead of dvilj2p would need
changing.  This approach also has less overhead and as there is not
another incarnation of bash interpreting it.  This was sent to me by
Hal Brooks; he wins the award for best print spooler setup from those
who responded to the survey. :) Note that this program is also
somewhat in need of a real test, nor does it make any use of the
arguments passed to `if', but it works for him.

(This is only 40 lines or so, don't panic :)

You may find that you don't like or ever expect to need the header
page which lpr by default prints out.  According to the man page, the
`sh' printcap parameter will let you turn this off.  (I hope you have
the man pages :) Try this first.  For my binaries, this didn't work,
so I made the following shell script, which I called lpr:

#!/bin/sh
real.lpr -h $*

Setting up lpr correctly is definitely worth the trouble...  
Of course, if all you ever print is the occasional man page or
instruction book, then you can get by without it.

Ghostscript 2.6 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 are probably worth a look.

-- REMOTE PRINTING

(This is an excerpt from a message on the NORMAL channel by Rusty Carruth)

> I have a problem: I want to print on a remote machine. What did I have to do 
> for this ?
> Local host is a pc running linux, remote host is a rs6000 running aix3.2 .
> 
> Any Ideas ?

If the remote machine is using the lpr print service, then you "simply"
have to:

On the linux machine:

set your /etc/printcap to point to the remote machine, like this:

ps1w01|lp|Brother ps1w01:\
	:lp=:rm=qip:rp=ps1w01:\
	:lf=/usr/adm/lpd-errs:\
	:sd=/usr/spool/lpd/ps1w01:

Where	"ps1w01"    is the printer name locally (on the linux box),
	"|lp"       means this is the default printer.
	"|Brother ps1w01" is a comment
	"lp="       says no local printer
	"rm=qip"    means that the remote machine is named "qip"
	"rp=ps1w01" means that the remote printer name is "ps1w01"
	"lf=/blah"  tells where the log file is (locally)
	"sd=/blah"  tells where the spool directory is (locally)

Create the spool directory and fire up lpd, assuming its not already
running (gotta start it as root)   (its a good idea to put the lpd 
starup into your initialization sequence, also, so you don't have 
to fire up lpd after booting).

On the remote machine, assuming it already knows about its printer
and is running lpd:

put the name of the linux box into /etc/hosts.lpd (or whatever silliniess
AIX uses as its equivalent).

Finally, go to the linux box and type "lpq -Pprinter" where "printer"
is the name of the printer you defined.  If it says "no entries"
or shows the queue then you are set up.  IF not, sorry about that...

Once lpd is running on both machines, it takes less time to install
a new printer on the remote machine than it did for you to read this
entire message!
	
(End excerpt)

-- {N,T,G}ROFF, MAN PAGES:

Man pages can often 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
would be easy to arrange with sed or awk or C, but I do not know if
anyone has done so.  You might also try PostScript-ifying the text
with an enscript clone and printing it that way.  (Several enscript
clones are described here, you probably have several of them.)

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.

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/man-pl*

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
mans 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  \
                                        [|{dvips,lpr}]

-- MPAGE

The package mpage is an excellent ASCII postscript-ifyer and n-up
reformatter for postscript.  Available as:

wuarchive.wustl.edu:/pub/mirrors/unix-c/printing/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.

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

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

A clone version of enscript is called nenscript, available somewhere
on gatekeeper.dec.com.

-- GSLP

Gslp is one of the uilities which comes with ghostscript 2.6.1 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.

-- 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 which may be found as:

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.

-- TEX/DVI

[La]TeX is the text formatting package used by most in the academic
world and many in other places where people realize word perfect to be
annoying.  TeX works much like any other compiler -- source code is
run through the program tex to become a .dvi file (analogous to a .o
object file in C) which can be further manipulated to produce printed
output.  This manipulation a dvi (device independant) file usually
takes a little bit of doing.  This `bit of doing' 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 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 must be able to seek around in its input file, so
it will not accept a pipe as input (ie, cat file.dvi |dvips...).
Dvips responds to either command line arguments or a file 
/usr/TeX/lib/tex/ps/config.ps (in the SLS, at least) in which you can
arrange to have dvips automatically send it's output to lpr.  Thus 

dvips file.dvi

will do everything that needs to be done.  (this is much better than
the 'manual' dvips -f1 file.dvi |gs -q -sDEVICE=xxx -sOutputFile=- -
|/dev/????)

Note that some .dvi's may include 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.  Lilo docs are an example of this.

Dvips has several interesting options; 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)

-- 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 dvilj, and if not on tsx or sunsite, is
certainly available near

wuarchive.wustl.edu:/pub/mirrors/unix-c/printing/...

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

There are other specific dvi drivers for different printers, as well.
I know of ones for the HP Deskjet and Epson.

-- 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 be
coerced into producing nice printed docs 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.  The SLS ought to have the macro package.  Just do:

tex thefile.texi[nfo] 

twice (for index generation purposes), and you end up with a plain
.dvi, 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.

-- HARDWARE AND DRIVERS

(This information is based on perusal of the source to Linux 0.99p9
and a letter from Michael K. Johnson.)

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
permanently with a parameter in .../linux/include/linux/lp.h.  It is
identified there.  The program lptune may be used to change this
without kernel twiddling (lptune is recommended) The actual driver is
in .../linux/kernel/chr_drv/lp.c.  

To choose the interrupt driver rather than the polled, use the program
lpcntl to set it.  Lpcntl is available on tsx-11, or from my
mail-server.  Just put the appropriate line in /etc/rc.

You can also change it in the kernel: change the second element of the
appropriate entry in lp_table[] to be the irq number to use:

struct lp_struct {
        int base;
        unsigned int irq;      <---- this, if 0, indicates polling driver
        int flags;
        unsigned int chars;
        unsigned int time;
        unsigned int wait;
        struct wait_queue *lp_wait_q;
        char *lp_buffer;
};

/* the BIOS manuals say there can be up to 4 lpt devices
 * but I have not seen a board where the 4th address is listed
 * if you have different hardware change the table below 
 * please let me know if you have different equipment
 * if you have more than 3 printers, remember to increase LP_NO
 */
struct lp_struct lp_table[] = {
        { 0x3bc, 0, 0, LP_INIT_CHAR, LP_INIT_TIME, LP_INIT_WAIT, NULL, NULL, },
        { 0x378, 0, 0, LP_INIT_CHAR, LP_INIT_TIME, LP_INIT_WAIT, NULL, NULL, },
        { 0x278, 0, 0, LP_INIT_CHAR, LP_INIT_TIME, LP_INIT_WAIT, NULL, NULL, },
};               ^
                 ^
                 ^This value is the one to change.  These entries are in
                 ^order - lp0,lp1,lp2.

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.

PREVIEWING   <<<<<---------

-- GHOSTVIEW

There are five previewing mechanisms commonly available of which I am
aware.  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.  A binary installation
of this is probably in the SLS.  The real installation is from source

prep.ai.mit.edu:/pub/gnu/ghostview-xxx.tar.z

and is a clean build.  Ghostview requires gs to work.  The new
version, 2.6.1, will use X display fonts in an effort to improve
legibility at low resolution (a previous failing of this pair relative
to commercial display-postscript based systems such as Sun's
pageview).

-- 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)

export.lcs.mit.edu:/contrib/GSPreview*

-- 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 export.lcs.mit.edu:/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.

-- XTEX

Xtex is similar in purpose to xdvi.  I have never seen it, but I have
it and will give it a look-see.  It is available as:

export.lcs.mit.edu:/contrib/xtex-2.18.5.tar.Z

-- GXDITVIEW

Produces a preview version of troff source using X fonts (this means
it's legible and typeset-looking.)  

groff -TX100 -mandoc man_page.1

will typeset and 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

-- NON-X-PREVIEWING

Gs comes with pc video hardware drivers, but under unix these are not
a good thing.  However, there are gs binaries around which will use
the Linux VGA library (vgalib).  I do not know where to find them or
the patch, but they must be on tsx-11 somewhere.  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 evidently important for this.  At one point the SLS
binaries had this driver, hopefully they still do.  (gs -h will list
the available drivers in your binary.)

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.

ASCII TRANSLATION   <<<<<<------------

-- FROM TEX

Lametex will generate ascii from tex source.  a beta (?) version is
now available:

sunsite.unc.edu:/pub/Linux/apps/tex/lametex.tar.z

L2a is a program available via FTP which is currently NOT in beta.
However, as lametex is being tailored to the needs of the Linux
community in general and the LDP in particular, I feel it is the
better choice for Linux users.  (But feel free to differ).

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

-- 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'

-- FROM TROFF

groff -Tascii.....    

will do you :)

CONTRIBUTORS <<<<<<<<<<<<<<<<--------------

The following people have offered suggestions, answered surveys,
provided examples, or otherwise contributed to this document:

Steven S. Dick
Ian McCloghrie
Scott Doty
Keith Walker
Werner Almesberger
Hal N. Brooks
Kai Makisara
Kris Gleason
Savio Lam
Matthew Ewin Maguire
James Henrickson
Telly Mavroidis
Lloyd Miller
Richard Brown
Erik Stenvall
Ian Turton
Ian Jackson
Harri Pasanen
Nils Rennebarth
Rusty Carruth
Martin Neimeier
Brian McCauley
Michael K. Johnson
Erik Stenval

END <<<<<<<<<<<<<<---------------