DVIOUT is a program that reads in DVI files generated by TeX and
other programs and generates output on a particular device.
Currently, the Tektronix 4014 and PostScript are supported (also,
an untested IMAGEN driver is supplied).

The file 'dviout.hlp' contains specific information on the use
of DVIOUT. This is a VMS help file which can be inserted into the
system help file for general access. This is the only documentation
furnished for DVIOUT.

The file 'dviout.cld' is the command definition file for DVIOUT.
The "image" description will have to be site tailored to point to the
proper executable file specification. Other default parameters, such
as the pixel source and mark font, can be altered by changing this
file. You can use the VMS $ SET COMMAND command to allow DCL to
recognize the DVIOUT command; or, the system manager can make it part
of DCLTABLES.

There are three logical names hard-coded into the software. These
are:

    TEX_FONTS        points to where the TeX TFM files are.
    TEX_IM_PIXEL     points to where the imagen-style PXL, PK and/or
                     GF files are (write-black, 300dpi).
    DVI_TEK4014      defines the terminal port connected to the
                     Tektronix terminal.

These logical names can be PATCHed to different values, if necessary.
(Refer to the link map for the locations to patch.) If you have a C
compiler, then you can directly modify the source code to obtain the
same effect.

If one or more system #include modules are unavailable on your system,
the file DVISYSDEF contains all those referenced by the software. You
will need to compile using a command similar to:

    $ CC file+DVISYSDEF/LIBRARY

in order to compile. Of course, this only applies if you plan to make
modifications to the software. The author has defined the modules
fscndef.h and lbrdef.h and put them in the C system text library. You
may have to jockey things about a bit to make sure all the right
#include modules are properly referenced.

DVIOUT uses packed (PK) pixel files. If your installation uses old
PXL files instead (or GF files), you will have to modify the command
definition file PIXEL_SOURCE default value to either "PXL" or "GF".
Additionally, if you have the Kellerman & Smith TeX distribution, pixel
files are located in separate directories, partitioned by magnification
size. I felt this was incorrect and instead insist on all pixel files
for a particular print engine to be in a single directory. If this is a
real problem for you, you should be able to construct a search list logical
name for TEX_IM_PIXEL that references all of the individual sub-directories.

DVIOUT includes a feature to paste Tektronix 4010/14 graphics files
and MacPaint bitmap files into the output. This is done with the
\special "paste" command, which is described in the help file for DVIOUT.
The file 'special.tex' contains an example how to provide an easy-to-use
interface to this facility of DVIOUT. There are also a number of graphics
extensions which are documented in the help file.

Several features of DVIOUT are still being developed. The program is
close to full functionality, but a few things are still missing.
These include:

    a) DVIOUT does not, as yet, handle output devices with aspect
       ratios other than one-to-one.

    b) Additional paste capabilities for mixing text and graphics.
       (Specifically, GKS metafile and PostScript interpretation are
       considered quite desirable.)

    c) The /PICTURE qualifier to the \special paste command is not
       yet implemented (affects Tektronix paste function only).

    d) Support for some graphics extensions are not present in the
       Tektronix driver. Only the basic TeX functionality is currently
       supported.

    e) There is an untested driver for the Imagen laser printer family
       (imPRESS language, circa 1984) that is accessed using the
       /DEVICE=IMAGEN qualifier. The author does not have access to an
       IMAGEN printer, and the driver is supplied in case anyone wants
       to see if it works. The polygon clipping function of the graphics
       extensions is not yet complete (will generate errors at the
       device if any polygon vertex extends outside the page boundaries).

    f) The sizes for metric form types specified with the /FORM
       qualifier are only approximate. If anybody knows the exact
       (metric) dimensions for form types A3, A4, etc., let me know.

    g) DVIOUT uses virtual memory quite liberally. If you have a small
       working set, DVIOUT may have poor performance. The amount of memory
       used is dependent upon the complexity of the DVI file being
       processed, especially, the number of fonts used.
