% -*-LaTeX-*-
%/u/sy/beebe/tex/ndvi/doc/dvistatus.ltx, Tue May 30 16:18:20 1989
%Edit by Nelson H.F. Beebe <beebe@plot79.utah.edu>
% Second edition
% <BEEBE.TEX.DVI.DOC>DVISTATUS.LTX.52, 12-Oct-88 22:24:57, Edit by BEEBE
% First edition
%------------------------------------------------------------------------
% EVERYTHING TO THE RIGHT OF A  %  IS A REMARK TO YOU AND IS IGNORED BY
% LaTeX.
%
% WARNING!  DO NOT TYPE ANY OF THE FOLLOWING 10 CHARACTERS AS NORMAL TEXT
% CHARACTERS:
%                &   $   #   %   _    {   }   ^   ~   \
%
% The following seven are printed by typing a backslash in front of them:
%  \$  \&  \#  \%  \_  \{  and  \}.
%------------------------------------------------------------------------

\documentstyle[dvidriver]{article}
 \makeunderscoreletter          % used in file names; don't need subscripts
 \newcommand{\INDEX}[2]{}       % no indexing here
 \newcommand{\HOST}[1]{{\sf #1}}
 \newcommand{\PGM}[1]{{\sf #1}}
 \hbadness = 10000              % don't complain about underfull boxes
 \title{\protect\TeX{} DVI Driver Family Status}

 \author{Nelson H.F. Beebe\\
Center for Scientific Computing\\
Department of Mathematics\\
220 South Physics Building\\
University of Utah\\
Salt Lake City, UT 84112\\
USA\\
 \medskip
Tel: (801) 581-5254\\
 \medskip
EMAIL: Beebe@Science.Utah.Edu (Internet)
}

 \date{Second Edition, 01 July 1989}

\begin{document}
 \maketitle
 \section{Introduction}

This document summarizes the status of the \TeX{} DVI driver
family distribution.   It describes
 \begin{itemize}
   \item
        the current versions of documentation and software;
   \item
        what operating systems, compilers, and output devices are
        supported;
   \item
        how to obtain the distribution from Utah and several
        other sources;
   \item
        the DVI electronic newsletter, and
   \item
        work in progress.
 \end{itemize}

Since the informal announcement of this software at the 1986
\TeX{} Users Group meeting at Tufts University and the formal
announcement in the April 1987 TUGboat, demand has exploded; the
author estimates that over 1000 sites in 28 countries are now
running this software.  Our initial attempts at providing the
software for free, or in return for a donation, proved
economically infeasible (we ran seriously in the red), and
consequently, a fixed distribution charge was instituted in the
spring of 1988.  The burden of exact cost accounting for each
order would be too great to manage; a fixed fee results in some
being subsidized at the expense of others, but not excessively
so.

The distribution tapes contain not only the driver family,
but also an extensive collection of Computer Modern fonts (itself
requiring over 100 hr of DEC-20/60 time to generate), additional
\TeX{}-related support software, and for \VAX{} \VMS{}, the
latest GNU Emacs release, so it remains a bargain.

Since the driver family is in the public domain, those who obtain
distributions may freely re-distribute what they get.  Local user
groups are encouraged to share the software; we are doing this on
a national scale in Poland.

In the interests of the end users, however, it must be recognized
that this is an active software development project, and
periodically returning to the source at Utah, or one of the
official redistribution channels, should be rewarding.

 \section{Documentation}

Documentation for the \TeX{} DVI driver family was last updated
15 April 1987 for Revision 2.07;  it is now slightly out-of-date,
and will be updated for release 3.0.   It consists of
  \begin{itemize}
   \item
        a large manual entitled {\em A \TeX{} DVI Driver
        Family\/} contained in source files \FN{dvidriver.*}
        intended for people who are installing the family on a
        new operating system, or adding support for a new device;
        it need not be read by people who just use the drivers;
   \item
        a \UNIX{} manual page file, \FN{dvi.1l};
   \item
        a \VAX{} \VMS{} help file, \FN{dvi.vms};
   \item
        a GNU and \TOPS{} Emacs info file, \FN{dviman2};
   \item
        a GNU Emacs \TeX{}info file, \FN{dviman2.texinfo}, used
        to produce the previous info file; and
   \item
        a \LaTeX{} document, \FN{dviman.ltx}, that prints in a
        similar style to a \UNIX{} manual page.
  \end{itemize}
\noindent%
The last five contain essentially the same information, but in
different formats.  They are intended to provide end-user
documentation, with details of what drivers are available, how to
run them, and what command-line options are available.

\section{DVI Driver Versions}

The version history of the family is given in
Table~\ref{version}.  Starting with 2.10.12, an edit number will
be appended to the major and minor version numbers; edit number
12 reflects 12 edits applied since 2.10(.00) was released.  Major
versions will appear at long intervals.  Minor versions will
appear every few months, and will generally add new drivers or
new operating system support.  Edits fix small bugs, or make
small cosmetic changes that improve the user interface.

  \begin{table}[thb]
\caption{Version history (reverse chronological order).}\label{version}
    \begin{center}
      \begin{tabular}{|ll|}
    \hline
    3.00 & [??-???-89] \\
    2.10.12 & [01-Sep-88] \\
    2.10 & [01-Nov-87] \\
    2.09 & [23-Sep-87] \\
    2.08 & [15-Aug-87] \\
    2.07 & [15-Apr-87] \\
    2.06 & [1986-1987] \\
    \hline
      \end{tabular}
    \end{center}
  \end{table}

 \begin{quotation}
 \bf \noindent
Note: Version 2.10 incorporated a major rewrite of \PGM{dvialw}
and \PGM{dvijep}, the two most popular drivers, to make much
better use of the limited memory on the laser printers, and to
permit arbitrary numbers and sizes of fonts.  Users running older
versions are urged to update to 2.10 or later.
 \end{quotation}

\section{Host Operating Systems and Compilers}

The operating systems supported are given in Table~\ref{os}.  The
drivers will port to almost any other \UNIX{} system not listed in
the table with relatively little effort.

  \begin{table}[thb]
  \caption{Operating systems supported.}\label{os}
    \begin{center}
      \begin{tabular}{|ll|}
    \hline
    Operating System & Compiler(s) \\
    \hline
    Gould \UNIX{}                       & \PGM{cc} \\
    Sun \UNIX{}                         & \PGM{cc}, \PGM{gcc} \\
    Hewlett-Packard \UNIX{}             & \PGM{cc}\\
    \PCDOS{}                            & Microsoft C 3, 4, 5 \PGM{cl}\\
    \TOPS{}                             & \PGM{kcc-20}, \PGM{pcc-20}\\
    \VAX{} \UNIX{}                      & \PGM{cc}, \PGM{gcc}\\
    \VAX{} \VMS{}                       & \PGM{cc}, \PGM{gcc}\\
    \hline
      \end{tabular}
    \end{center}
  \end{table}

On \PCDOS{}, only the Microsoft C compilers have so far been
found usable.  Microsoft C 5.1 has been tried and found unusable
because it permanently predefines the ANSI C macro \CN{__STDC__}
to be 0 instead of 1.  Borland Turbo C 1.5 is definitely {\em
not\/} usable for the DVI drivers because of completely erroneous
floating-point code generation.  Turbo C 2.0 resolves the
floating-point problems, and in November, 1988, I developed
work-arounds for several new bugs in the compiler and the
library.

For programs that have no floating-point code, I have found Turbo
C 1.5 quite usable; it compiles about 5--7 times faster than the
Microsoft C 5.0 compiler.  Version 2.0 remains as fast, but
examination of the assembly code generated for the string
primitives shows that, when optimization is selected in both
compilers, the Microsoft C compiler produces substantially better
object code.  In the large memory model required for the DVI
drivers, the inner loops for \CF{strchr} and \CF{strrchr}
have 11 instructions each with Turbo C 2.0 when the \CN{-O}
option is chosen, and 5 and 7 respectively with Microsoft C 5.0
with \CN{-Oailt}.

\PGM{gcc} is the GNU Project C compiler, which generates code for
at least these architectures:
 \begin{itemize}
   \item
        Alliant FX/8,
   \item
        Altos 3068,
   \item
        Convex C1 and C2,
   \item
        Intel 386 (Compaq 386, Sequent 386, Sun 386i),
   \item
        MIPS (MIPS and DECstation 3100),
   \item
        Motorola 68xxx (Sun 2 and 3, HP 9000/300 and 320, AT\&T 3B1,
        Integrated Solutions, Sony NEWS, NeXT),
   \item
        Motorola 88000 (in progress),
   \item
        National Semiconductor 32xxx (Sequent, Encore, NS Genix),
   \item
        Sun SPARC (Sun 4 and Solbourne), and
   \item
        \VAX{} (\UNIX{} and \VMS{}).
 \end{itemize}
\noindent%
That is a remarkable record surpassed only by \PGM{pcc}, but that was
never available for diverse systems from one set of master sources.
\PGM{gcc} is also {\em free\/}.  On the Sun 3, it produces code about
10\% more compact, and 10\% faster than the native Sun \PGM{cc}
compiler at Sun OS 3.x; Sun \PGM{cc} produces better floating-point
code than \PGM{gcc} at Sun OS 4.0.  \PGM{gcc} is the standard C
compiler on the NeXT workstation.

Due to code generation errors, neither Sun \PGM{cc} nor \PGM{gcc} %
compile the drivers correctly on the Sun 386i under \UNIX{}; under
386i DOS, the Microsoft and Borland compilers produce working drivers.

Version 3.0 is expected to add support for the operating systems in
Table~\ref{new-os}.  These are not in the 2.10 distribution, but once
3.0 development has stabilized, pre-releases from the development
directories may be made available by special arrangement on tape or
for ANONYMOUS FTP; IBM PC floppy distributions will not be offered.
Contact the author for details and current status.

  \begin{table}[thb]
  \caption{New operating systems supported.}\label{new-os}
    \begin{center}
      \begin{tabular}{|ll|}
   \hline
   Vendor & Operating System \\
   \hline
   Acorn & Archimedes \\
   IBM & VM/CMS \\
   Intel & RMX \\
   Prime & Primos \\
   \hline
      \end{tabular}
    \end{center}
  \end{table}

\section{Output Devices Supported}

Devices supported by the \TeX{} DVI driver family at version 2.10
are given in Table~\ref{devices}.  The \PGM{dvitype} program is
not strictly part of the distribution; it should be a standard
part of every \TeX{} distribution.  Similarly, there are programs
\PGM{dvitty} and \PGM{dvidoc} which attempt to display DVI
files on ASCII printers and terminals; they are included in the
tape and ANONYMOUS FTP distributions, but are not members of the
family.

  \begin{table}[thb]
  \caption{Supported output devices.}\label{devices}
    \begin{center}
      \begin{tabular}{|lp{3in}|}
  \hline
   Program   &   Output Device \\
  \hline
  \PGM{dvialw} & \POSTSCRIPT{} (Apple LaserWriter) \\
  \PGM{dvibit} & Version 3.10 BBN BitGraph terminal \\
  \PGM{dvica2} & Canon LBP-8 A2 laser printer (fast experimental version) \\
  \PGM{dvican} & Canon LBP-8 A2 laser printer \\
  \PGM{dvidla} & DEC LA50 144 $\times$ 72dpi and LA75 144 dpi printers \\
  \PGM{dvieps} & Epson 9-pin family 60/72 and 240/216 dpi matrix printer\\
  \PGM{dviimp} & Imagen imPRESS-language laser printer family \\
  \PGM{dvijep} & Hewlett-Packard LaserJet Plus \\
  \PGM{dvijet} & Hewlett-Packard LaserJet \\
  \PGM{dvil3p} & DEC LN03 Plus laser printer \\
  \PGM{dvimac} & Apple Imagewriter 72 and 144 dpi printer \\
  \PGM{dvimpi} & MPI Sprinter 72 dpi printer \\
  \PGM{dvioki} & OKIDATA Pacemark 2410 72 and 144 dpi printer \\
  \PGM{dviprx} & Printronix 60h $\times$ 72v dpi printer \\
  \PGM{dvitos} & Toshiba P-1351 180 dpi printer \\
  \PGM{dvityp} or \PGM{dvitype} & DVI Translator for human-readable output \\
  \hline
      \end{tabular}
    \end{center}
  \end{table}
New devices for which support should be available in 3.0 are
given in Table~\ref{new-devices}.

  \begin{table}[thb]
  \caption{New device drivers scheduled for future release.
Names are subject to change before final release.}\label{new-devices}
    \begin{center}
      \begin{tabular}{|lp{3in}|}
  \hline
   Program   &   Output Device \\
  \hline
  \PGM{dviadx} & Anadex Silent Scribe 72 and 144 dpi dot matrix printer\\
  \PGM{dviapo} & Apollo screen display previewer\\
  \PGM{dvicon} & IBM RT 6150 and 6155 console previewer\\
  \PGM{dvidsk} & Hewlett-Packard DeskJet 300 dpi ink jet printer\\
  \PGM{dvielq} & Epson LQ 24-pin family 180 dpi dot matrix printer\\
  \PGM{dviep2} & Epson 9-pin family 120/216 dpi dot matrix printer\\
  \PGM{dvifuj} & Fujitsu DL2400 24-pin 180 dpi dot matrix printer\\
  \PGM{dvigp}  & Phillips GP 72 dpi and 144 dpi dot matrix printer\\
  \PGM{dvihl8} & Brother HL-8 with
                 brain-damaged Hewlett-Packard LaserJet emulation\\
  \PGM{dviibm} & IBM 4202 120 dpi dot matrix printer\\
  \PGM{dvilzr} & Data Products laser printers (1230 and 1260) with
                 brain-damaged Hewlett-Packard LaserJet emulation\\
  \PGM{dvio92} & OKIDATA 192 72 and 144 dpi dot matrix printer\\
  \PGM{dvisun} & Sun Windows screen display previewer\\
  \PGM{dviupc} & AT\&T \UNIX{} PC screen display previewer\\
  \PGM{dvivga} & IBM PC VGA display previewer\\
  \hline
      \end{tabular}
    \end{center}
  \end{table}

In addition, the \TOPS{} \POSTSCRIPT{} spooler program,
\FN{lw78.c}, has now been ported to \UNIX{}.

\section{DVI Driver Distribution}

Distributions of the DVI driver family are available from a
number of sources; they are described in this section.

The master files reside on the author's main host machine,
\HOST{science.\-utah.\-edu}, a DEC-20/60 TOPS-20 system.  ANONYMOUS FTP
(any password) to that machine can retrieve the file
\FN{00readme.\-txt} which tells how to find the DVI distribution, and
much else, on local machines.  Distribution formats of individual
files, compressed \UNIX{} \PGM{tar} files, and \IBMPC{} \FN{.arc}
files are available on \HOST{science.\-utah.\-edu}.  It is
important to read the \FN{00readme.\-txt} file carefully and
follow its instructions about what files to retrieve, and how;
otherwise you risk getting corrupted, or incomplete, data.

\VAX{} \VMS{} \PGM{backup} save sets of the DVI family, Computer Modern
fonts, a \POSTSCRIPT{} printer spooler, and several \TeX{}-related
programs are available on \HOST{ctrsci.\-utah.\-edu}, a \VAX{}
8600 running \VMS{} 4.4, where again a \FN{00readme.\-txt} file
gives retrieval details.  The ANONYMOUS FTP password is {\em
GUEST\/}; no other string will be accepted.

Distribution from Utah must be requested in writing,  by postal
mail to
  \begin{verse}
\TeX{} DVI Driver Distribution\\
Center for Scientific Computing\\
Department of Mathematics\\
220 South Physics Building\\
University of Utah\\
Salt Lake City, UT 84112\\
USA
  \end{verse}
or by electronic mail to
\HOST{dvi-request@\-science.\-utah.\-edu} or the author, or by
FAX to the telephone number (801) 581-4801.  A telephone number
and street address should be provided to facilitate resolution of
questions, and delivery by express freight companies (who cannot
deliver to postal boxes).  Telephone orders will be accepted only
in unusual circumstances.

Nine-track tape (1600 bpi, and for \VMS{} only, 6250 bpi), Sun
$1/4in$ cartridge tape, and IBM PC floppy distributions are
available from Utah for a fixed US\$100 charge, which includes
documentation, media, and shipping.  Shipping is by UPS ground
service within the lower 48 states, or airmail to Alaska, Hawaii,
and international destinations.  Do {\em not\/} send tapes or
floppies with your request.  Prepayment in checks drawn on a US
bank, or international postal money orders, is preferred because
it reduces paperwork.  Purchase orders will be accepted when
prepayment is not possible; an invoice will accompany the
shipment.

Faster shipment by UPS, DHL, Federal Express or Airborne Express
is possible by special arrangement, {\em provided our local staff
has the time to handle the order}.  It carries a surcharge equal
to the approximate freight charges; prepaid or collect shipments
should be used.

We try to fill orders within one to two weeks of receipt, but it
sometimes takes longer because of our local responsibilities, or
because an order is missing information, like tape format and
density, that we need before it can be completed.

Distributions are available from the following other channels;
allow up to 2 months after release of new versions for these to
be available.  All of these are volunteers, and have full-time
commitments elsewhere.  They are updated by net distribution
where possible, but it still takes them some effort for them to
incorporate the changes in their local distribution mechanism.

 \begin{quote}
Peter Abbott\\
Aston University\\
Computing Services\\
Aston Triangle\\
Birmingham B47 ET\\
England\\
Email: {\small \HOST{AbbottP\%uk.ac.aston.mail\%uk.ac.rl.gb@nss.cs.ucl.ac.uk}}\\
or\\
Email: {\small \HOST{PAbbott@nss.cs.ucl.ac.uk}}\\
{}[only net retrieval]\\

\medskip
Massimo Calvani\\
Department of Astronomy\\
University of Padova\\
Vicolo dell'Osservatorio\\
35122 Padova\\
Italy\\
Email: {\small \HOST{Calvani\%vaxfpd.infnet\%iboinfn.bitnet@cunyvm.cuny.edu}}\\
{}[only net retrieval]\\

\medskip
Lance Carnes\\
Personal \TeX, Inc.\\
12 Madrona Ave\\
Mill Valley, CA 94941\\
Email: {\small \HOST{"well!pti"@lll-lcc.arpa}}\\
{}[only \IBMPC{} floppies]\\

\medskip
Edgar M. Cooke\\
Software Research Assoc. Inc.\\
1-1-1 Hirakawa-cho\\
Chiyoda-ku\\
Tokyo 102\\
Japan\\
Email: {\small \HOST{kddlab!srava.sra.junet!cooke@uunet.uu.net}}\\
{}[only net retrieval]\\

\medskip
Richard J. Kinch\\
Kinch Computer Co.\\
501 S Meadow St\\
Ithaca, NY 14850\\
Email: {\small \HOST{-unknown-}}\\
{}[only \IBMPC{} floppies]\\

\medskip
Mark Kosten\\
LaTrobe University\\
Bundoora, Victoria\\
Australia\\
Email: {\small \HOST{"munnari!latvax8.lat.oz.au!ccmk"@uunet.uu.net}}\\
{}[net retrieval and tape distribution]\\

\medskip
Joachim Lammarsch\\
Universit\"{a}t Heidelberg\\
Rechenzentrum - Im Neuenheimer Feld 293\\
Heidelberg 6900\\
West Germany\\
Email: {\small \HOST{\$rz92\%dhdurz1.bitnet@cunyvm.cuny.edu}}\\
{}[only net retrieval]\\

\medskip
Jon Radel\\
P. O. Box 2276\\
Reston, VA 22090\\
U.S.A.\\
Email: {\small \HOST{jonradel\%icecream.princeton.edu@princeton.edu}}\\
{}[only \IBMPC{} floppies]\\
 \end{quote}

We would prefer that \IBMPC{} floppy distributions be handled
through Personal \TeX{} or Jon Radel; their prices are also
lower.  Preparation of floppies takes substantial personal time
for the author which would be better spent on other activities.

\section{Electronic Newsletter}

A network mailing list is maintained for the issuance of
newsletters; there were 285 subscribers on 29 May 1989.  Requests
for addition or deletion should be sent to the author at the
address on the first page of this document.  Users on any network
reachable from the Internet can be included; that includes at
least Arpanet, CSnet, MILnet, NSFnet, and SPAN (mainly US),
Bitnet (US, Canada, and Europe), NetNorth (Canada), EARNnet
(Europe), JUNET (Japan), Janet (Britain), Usenet (worldwide), and
national university nets in Australia and New Zealand.  A total
of 19 newsletter issues have so far appeared.  Back issues are
included in all DVI distributions as the files \FN{00mail.*}.

Regrettably, local staffing and funding do not permit postal
mailings of the newsletter; if there is a demand for it, and
subscribers are willing to pay for it, it could be arranged in
the future.

There is a smaller related electronic list for beta testing of a
powerful \LaTeX{} editing mode in GNU Emacs; this will probably
become part of the standard GNU Emacs distribution in 1989.  It
contains many useful functions, and recognizes {\em every\/}
macro in the {\em \LaTeX{} User's Guide and Reference Manual}.
Send requests for addition to the list to the author at the same
address as for the newsletter.  The code is also included in the
\VAX{} \VMS{} distribution tapes in the file
\FN{[.emacs-18-52\-.lisp]latex-mode\-.el}.

\section{Future Directions}

{\bf NB: Anything discussed in this section is subject to possibly
substantial changes.}

Source release of the 3.0 development is still many months off in the
future; changes are still frequent, and a premature release would open
a horrendous bag of worms that would make management of the
development beyond my limited resources.  Every time I have attempted
to predict when a piece of software would be complete, I have been
wrong, so I shall not attempt to set any date for the version 3.0
release.

Here is a summary of new features in the 3.0 development:

 \begin{itemize}
   \item
         For devices which require page bitmaps, the bitmaps are
         constructed in strips with multiple passes through the
         commands for the current page in the DVI file.  The
         amount of memory to be used for a bitmap strip is set to
         a default value, but the value may be changed by a
         command-line option.  This removes the need to limit the
         printable page size that existed in earlier versions on
         small machines, particularly the \IBMPC{}.
   \item
         File search paths are supported for all supported
         operating systems.  A separate search path,
         \CN{DVIINPUTS}, is provided for startup files,
         \POSTSCRIPT{} header files, and files required by
         \verb|\special{}| commands.  It defaults to the same
         value as \CN{TEXINPUTS}, so normally, it need not be
         specified.
   \item
         Font file names are constructed from a format that may
         be set at run-time in the \CN{FONTFMT} environment
         variable, and that variable can specify several name
         formats.   This generalizes, and replaces, the
         \CN{FONTLIST} variable used in earlier versions.
   \item
         A new font file encoding, Group 4 FAX, implemented by
         Michael Ferguson and colleagues at INRS
         Telecommunications in Montr\'{e}al, has been added.  This
         is even more compact than \CN{PK} format, and will be
         referred to as \CN{FX4} format.  A utility for converting
         from \CN{GF} or \CN{PK} formats to \CN{FX4} format is
         provided.
   \item
         \verb|\special{}| strings of arbitrary length are
         supported.  Although the \TeX{} input buffer size
         typically limits input strings to about 500 characters,
         macro-generated strings can be larger.
   \item
         NUL characters in \verb|\special{}| strings are
         supported.  In C, such characters terminate strings by
         default, so extra processing is necessary to avoid such
         truncations.
   \item
         Support for Wizard C on \PCDOS{} has been replaced by
         support for its descendant, Borland Turbo C 2.0 or later.
   \item
         On most systems, the operating system and compiler can
         now be determined automatically, eliminating the need to
         edit \FN{machdefs.h}.  This is supported by a new header
         file, \FN{os.h}.
   \item
         ANSI C is the standard programming language.  Header files
         \FN{stdlib.h}, \FN{stddef.h}, and \FN{unixlib.h}, and
         several string utilities \FN{str*.c},  support
         the illusion of an ANSI environment on pre-ANSI C systems.
   \item
     \begin{sloppy}
         Dependency lists in makefiles are now generated
         automatically by a \UNIX{} script,
         \PGM{FIX\-MAKE\-FILES}, which uses a script,
         \PGM{fixmf}, plus \PGM{nawk} (using files
         \FN{include*.\-awk}), and \PGM{sed}.  This greatly
         facilitates makefile updating when the source files are
         often changing, and ensures that dependencies are always
         correct.
     \end{sloppy}
   \item
     \begin{sloppy}
         Handling of font magnifications has been revised by
         elimination of the floating-point \CN{mag_table[]}
         array from \FN{gblvars.h}, and its replacement by an
         integer table, \CN{stdmag[]}, in \FN{stdmag.h}.  That
         file is automatically generated by \FN{genmag.c}.  The
         contents of \CN{stdmag[]} can be replaced at
         compile-time, or at run-time, by definitions of the
         environment variable \CN{FONTMAGS}.  Revised code in
         \FN{openfont.h} will now find the closest matching
         magnification when font substitution is called for;
         previously, the \CN{mag_table[]} mechanism required an
         exact match, making it awkward to support magnification
         families that were not already represented in the
         \CN{mag_table[]} array.
     \end{sloppy}
   \item
         Environment variable handling and naming has been
         standardized across all operating systems, and the names
         are now set in the preprocessor macros, \CN{ENV_xxx}, in
         \FN{machdefs.h}.
   \item
         \CN{FASTZERO} and \CF{zerom} have been eliminated in
         favor of an implementation of the ANSI library routine,
         \CF{memset}, where required.
   \item
         Paper dimensions no longer are fixed in the
         \FN{dvixxx.c} files.  Instead, a general, programmable,
         and easily-extendable, mechanism for specification of
         paper characteristics has been implemented in
         \FN{paper.c}.  A list of all the standard paper sizes I
         could find is present in \FN{paper.dat}, and the more
         popular ones have been extracted and stored as
         initializing values for \CN{stdform[]} in
         \FN{gblvars.h}.  \FN{gensiz.c} can be used to generate
         much of \FN{paper.dat}.
   \item
         A startup file, \FN{dvi.ini}, is read in \FN{initglob.h}
         and options found there are parsed by \CF{fileargs} in
         \FN{filarg.c} and then set by calls to \CF{option}.
         After processing that file, driver \PGM{dvixxx} then
         does the same thing with \FN{dvixxx.ini}.  Both files
         are looked for in the \CN{DVIINPUTS} search path;
         neither file need exist.  This makes it simple to have
         private values of options that are used regularly,
         without having to specify them on the command line.  It
         also makes it possible to get around operating system
         limitations on command line arguments, and environment
         variable syntax.  The reason for having two
         initialization files is that some things, like paper
         types, can be defined for all drivers in one file,
         \FN{dvi.ini}.  The \FN{dvixxx.ini} file can then provide
         modifications specific to one output device.
   \item
         Private and library functions that are \CN{void} are
         no longer typecast as \CN{(void)} when called; some
         compilers (e.g.  Lattice C on IBM PC and VM/CMS, and
         Prime compilers) erroneously flag this as an error.
   \item
     \begin{sloppy}
         \CF{exit} is called with the ANSI standard arguments
         \CN{EXIT_SUCCESS} and \CN{EXIT_FAILURE}, instead of
         0 and 1.  \VAX{} \VMS{} unnecessarily changed the
         interpretation of \CF{exit}'s arguments, and the
         ANSI committee had to support it.  The private version,
         \CF{EXIT}, is no longer used in the DVI drivers.
     \end{sloppy}
   \item
         All \CF{main}  functions  are declared of type  \CN{int},
         and return \CN{EXIT_SUCCESS} or \CN{EXIT_FAILURE}.
   \item
         \FN{texidx.c}  has   been  fixed to   correctly handle
         out-of-core sorting.
   \item
         \CF{qsort} and \FN{qsort.c} (used in \PGM{texidx}) has
         been renamed \CF{shsort} and \FN{shsort.c}, avoiding
         conflicts with library functions of the same name, and
         more properly describing the underlying algorithm
         (shellsort, instead of quicksort).  Shellsort is stable,
         whereas quicksort is not, and a stable sort is required
         for correct ordering of index subfields.
   \item
     \begin{sloppy}
         Memory allocation and freeing is now handled in the DVI
         driver code by \FN{xalloc.c}, which contains functions
         \CF{xmalloc}, \CF{xcalloc}, \CF{xmemused},
         \CF{xrealloc}, and \CF{xfree}.  These provide
         work-arounds for some deficiencies in existing
         \CF{malloc}/\CF{free} implementations, additionally keep
         a record of memory utilitization, and provide for debug
         tracing of memory usage.  The \CF{x*alloc} functions do
         not return when memory is exhausted, removing the
         necessity for checking function return values in their
         callers; in the rare event that recovery is possible in
         such a case, \CF{malloc} can still be called.
     \end{sloppy}
   \item
         A new preprocessor symbol, \CN{DVI}, is defined at
         compile time; it is used in a few routines that are
         separately compiled, and need to know whether they are
         being used in the DVI drivers, or in other code.
   \item
         A new preprocessor symbol, \CN{TEST}, is used in some
         files to bracket built-in test code with a \CF{main}
         function.  This avoids having to carry around a second
         file that serves as a test program.  \FN{filarg.c},
         \FN{paper.c}, and \FN{xalloc.c} currently use this
         facility.
   \item
         When a font substitution is made, a Boolean flag,
         \CN{substitute}, is now set in the \CN{font_entry}
         structure.  In \FN{prtpage.h}, when that flag is set,
         \CF{setchar} is called instead of \CF{setstr}, so that
         single characters are set at a time, rather than strings
         of characters.  This will improve the positioning of
         substituted characters.
   \item
         Ten new device drivers have been added: \PGM{dviadx},
         \PGM{dvidsk}, \PGM{dvielq}, \PGM{dviep2}, \PGM{dvigp},
         \PGM{dvihl8}, \PGM{dviibm}, \PGM{dvilzr}, \PGM{dvisun},
         and \PGM{dviupc}.  One driver, \PGM{dvigd}, has been
         deleted.  The drivers \PGM{dvi*72} have been dropped;
         they can be produced by compiling the corresponding
         high-resolution versions with \CN{HIRES} undefined.
         This change reduces the amount of code to be maintained;
         in most cases, users will prefer the higher resolution
         version anyway, so that is the default.
   \item
     \begin{sloppy}
         Documentation files have been updated, and a new file,
         \FN{doc/\-dvistatus.\-ltx} (whose output you are now
         reading), will be kept up-to-date as a record of the
         current status of the DVI family.
     \end{sloppy}
   \item
         The definition of \CF{PIXROUND} in \FN{gendef.h} has
         been corrected; it was wrong for negative arguments, and
         would result in one-dot positioning errors.
   \item
         Support for the IBM VM/CMS operating system has been
         added, using the Waterloo C compiler.  Since the
         character set is EBCDIC, rather than ASCII, this
         entailed a redesign of how character string output is
         handled.  The output files created always contain ASCII
         text, so this means that all text characters, but not
         binary data, must go through EBCDIC to ASCII
         translation.  This has been done in such a way as to
         avoid any extra overhead on a native ASCII host.  The
         non-ASCII support also serves on Prime Primos, which
         uses an ASCII character set biased by 128.
   \item
     \begin{sloppy}
         References to the preprocessor symbols
         \CN{FIRSTPXLCHAR} and \CN{LASTPXLCHAR}
         everywhere except in \FN{charpxl.h}, \FN{gendefs.h}, and
         \FN{readpxl.h} have been replaced by \CN{FIRSTFONTCHAR}
         and \CN{LASTFONTCHAR}, which correctly reflect the range
         0\ldots{}255; \FN{PXL} format fonts remain restricted by
         their design to 0\ldots{}127.
     \end{sloppy}
   \item
         All  uses of C type \CN{float} have been replaced by
         type \CN{double}.  For \PGM{dvialw} in particular, this
         tends to ensure that identical coordinates are generated
         on different machines, at least to the precision they
         are output in.
   \item
         The \POSTSCRIPT{} header file, \FN{dvialw.ps}, has been
         extensively rewritten to remove device resolution dependence,
         and operators that conflict with the Adobe Encapsulated
         \POSTSCRIPT{} File (EPSF) guidelines.  Uses of the
         \verb|bind| operator have also been removed in order to
         make it possible for \verb|\special{}| code to redefine
         operators at print time.
 \end{itemize}

I have made substantial progress in enhancing the support for
\verb|\special{}|.  This work is currently being done with
\PGM{dvialw}, but in such a way that it will be easy to generalize it
to all other drivers.

The first step needed in this direction is to define a grammar
for what the \verb|\special{}| string looks like.  Previously,
most DVI drivers have defined this syntax completely {\em ad
hoc}, with no thought to rigorous parsing, or to future
extensions.

Most of the following description is extracted from the comments
in \PGM{dvialw}.

The contents of the \TeX{} \verb|\special{}| command is expected to
conform to a minilanguage in the same grammar as for paper
specifications.  The argument string should contain a series of
assignment statements for one or more of the keywords given in
Table~\ref{special-keywords}.

  \begin{table}[thb]
    \caption{{\tt \bs special\{\}} keywords.}\label{special-keywords}

    \begin{center}
      \begin{tabular}{|llp{2.3in}|}
        \hline
        Keyword &       Value &         Action\\
        \hline
        graphics &      string &        execute the generic graphics
                                        primitives in string
                                        (not yet defined)\\
        include &       filename &      insert file contents with
                                        relative page positioning\\
        literal &       string &        insert literal \POSTSCRIPT{}\\
        options &       string &        not yet defined\\
        overlay &       filename &      insert file contents with
                                        absolute page positioning\\
        \hline
      \end{tabular}
    \end{center}
  \end{table}

\noindent%
The order of these is not significant, except that if duplicate
keywords are specified, the value of the last one is used.  It is not
necessary to supply a final newline in the strings or files; one will
be provided automatically to ensure correct output.

Literal \POSTSCRIPT{} code from a file or a literal string is
expected to be well-behaved, and preferably, should conform to
Adobe's EPSF format version 1.2 or later, and to Adobe's
\POSTSCRIPT{} Document Structuring Conventions, version 2.0 or
later.  It may contain a \verb|showpage| (which is disabled
temporarily here), but it should not contain any of the operators
given in Table~\ref{bad-operators}.

  \begin{table}[thb]
  \caption{Deprecated \protect\POSTSCRIPT{} operators.}\label{bad-operators}
   \begin{center}
     \begin{tt}
       \begin{tabular}{|llll|}
         \hline
         banddevice &      grestoreall &     nulldevice &      setpageparams\\
         copypage &        initclip &        quit &            setsccbatch\\
         erasepage &       initgraphics &    renderbands &     setscreen\\
         exitserver &      initmatrix &      setdevice &       settransfer\\
         framedevice &     note &            setmatrix &       {}\\
         \hline
      \end{tabular}
     \end{tt}
   \end{center}
  \end{table}

\noindent%
If it does, erroneous output is virtually certain.  While these
commands could be disabled like \verb|showpage| is, Adobe's
EPSF guidelines do not recommend doing so.

The imported \POSTSCRIPT{} should write into its own dictionary
if it needs to define objects.  Because dictionary sizes must be
specified when they are created, it is not possible to define a
standard one in advance in the \verb|SB| (\verb|\special{}|
begin) and \verb|SE| (\verb|\special{}| end) macros to protect
from corruption of the dictionary, \verb|TeXdict|, used by
\PGM{dvialw}.

The language keyword should specify \verb|"PS"| or
\verb|"PostScript"|; letter case does not matter.  If any other
non-empty value is found, the \verb|\special{}| command is
ignored, since it presumably applies to some other output device,
and control returns immediately.  However, if no language keyword
is given, we assume \POSTSCRIPT{}, and continue.

Files specified by \verb|include| and \verb|overlay| keywords are
searched for in the \CN{DVIINPUTS} path.

In the common case of \verb|include "filename"|, the {\em
upper-left\/} corner of the bounding box will be placed at the current
point.  The \POSTSCRIPT{} file must then contain (usually near the
start) a comment of the form

\begin{verbatim}
%%BoundingBox: llx lly urx ury
\end{verbatim}

\noindent%
specifying the bounding box lower-left and upper-right
coordinates in standard \POSTSCRIPT{} units of big points (1/72
inch).  Alternatively, if the comment

\begin{verbatim}
%%BoundingBox: (atend)
\end{verbatim}

\noindent%
is found in  the file,  the last  4096 characters  of the  file will  be
searched to find a comment of the form:

\begin{verbatim}
%%BoundingBox: llx lly urx ury
\end{verbatim}

\noindent%
In the case of \verb|overlay "filename"|, the \POSTSCRIPT{} file to be
included will be mapped onto the page at precisely the coordinates it
specifies, where the page origin is in the lower-left corner, $y$
increasing upward, $x$ increasing to the right.  Any
\verb|%%BoundingBox| specification is ignored, since it is not
required for positioning.  This option might be used to print an
overlay page.  For actions that are to be done on every page, such as
printing a logo, or a string like {\em Draft\/} or {\em Company
Confidential\/}, it is more efficient to redefine \verb|showpage|
instead.

If the \POSTSCRIPT{} file cannot be opened, or the \verb|\special{}|
command string cannot be recognized, or for relative positioning, the
bounding box cannot be determined, a warning message is issued and the
\verb|\special{}| command is ignored.

Any literal string, and the section  of  the  \POSTSCRIPT{} file between the
comment lines

\begin{verbatim}
%begin(plot)
%end(plot)
\end{verbatim}

\noindent%
or the entire file, if the \verb|%begin(plot)| comment cannot be found,
is copied to the output file as

\begin{verbatim}
SB % filename
(xcp-llx) (ycp-ury) translate  % if relative positioning
...literal string...
...PostScript file contents...
SE % filename
\end{verbatim}

\noindent%
The \verb|SB| and \verb|SE| macros revert to standard
\POSTSCRIPT{} units of big points, and bracket the inserted
\POSTSCRIPT{} text with \verb|save| and \verb|restore| commands.
The \verb|translate| command positions the (0,0) origin of the
inserted \POSTSCRIPT{} such that the {\em upper-left\/} corner of
the bounding box is at \TeX{}'s current point.

For literal inserted \POSTSCRIPT{} without an \verb|include| or
\verb|overlay| command, the origin is moved to \TeX{}'s current
point.

The \verb|save| and \verb|restore| in \verb|SB| and \verb|SE|
ensure that the inserted \POSTSCRIPT{} code cannot change the
environment existing before the \verb|\special{}|.  Should it be
necessary to do so (e.g.  to remember things from one
\verb|\special{}| to the next, or to redefine an operator, like
\verb|showpage|), you should just output \verb|SE| followed by
your \POSTSCRIPT{}, followed by another \verb|SB|.  The
intervening \POSTSCRIPT{} will then apply to \PGM{dvialw}'s
private dictionary, \verb|TeXdict|.

In order to support things like landscape mode, change bars, and
grey shading, it is necessary to have paper dimensions, the
bounding box size, and the current point available to inserted
\POSTSCRIPT{} code.  These are stored in the \POSTSCRIPT{} macros
\verb|PaperHeight|, \verb|PaperWidth|, \verb|BoxHeight|,
\verb|BoxWidth|, \verb|CurrentX|, and \verb|CurrentY| in the
outer level dictionary, \verb|TeXdict|.  \verb|PaperHeight| and
\verb|PaperWidth| are set only once, at the beginning of the job.
The other four are redefined before each \verb|SB| is output.
Their values are all in standard \POSTSCRIPT{} units of big
points, {\em not\/} pixels.  For an \verb|overlay| command, the
size of the bounding box will be the page size.

The origin can be moved to the lower-left  page corner by the \POSTSCRIPT{}
sequence

\begin{verbatim}
CurrentX neg CurrentY neg translate
\end{verbatim}

\noindent%
This is useful in order to obtain absolute page positioning, such as for
a page logo overlay.

The size of the bounding box in big points is saved in
\POSTSCRIPT{} macros \verb|BoxWidth| and \verb|BoxHeight|.  They
can be used to perform geometric transformations on the included
\POSTSCRIPT{}.  For \verb|overlay "filename"|, they are set to
the page size.

Here are some examples:

\begin{small}
\hfuzz=10in                     %be quiet about overfull boxes here
\begin{verbatim}
% Display a picture with the upper-left corner at the current point
\special{language "PostScript", include "pict.eps"}

% Display a picture at its original absolute page position
\special{language "PostScript", overlay "pict.eps"}

% Use literal PostScript  to draw a 1in box  with lower-left corner at
% TeX's current point
\special{language "PostScript",
        literal "
            newpath
                0 -72 translate % move origin from upper-left to lower-left
                0 0 moveto
                0 72 rlineto
                72 0 rlineto
                0 -72 rlineto
                -72 0 rlineto
            closepath
            4 setlinewidth
            stroke
            showpage"}

% Display a figure at half size
\special{language "PostScript",
        literal "0.5 0.5 scale",
        include "pict.eps"}

% Display the  figure in landscape  mode  by rotating  the coordinates
% about the center of the bounding box
\special{language "PostScript",
        literal "BoxWidth 2 div BoxHeight 2 div translate
                90 rotate
                BoxWidth -2 div BoxHeight -2 div translate",
        include "pict.eps"}
\end{verbatim}
\end{small}

Landscape mode for a complete document is properly handled by a
paper type, and that is now working for \PGM{dvialw}.  Landscape mode
for a single page is tricky, because there is the question of which
way to rotate the page, and how to support portrait mode page headers
with a landscape mode table.  The latter cannot be accomplished on
most devices because of restrictions they impose.  However, it is
possible with \POSTSCRIPT{}, and I have a demonstration file that shows
how to do it.

\PGM{dvialw} has been revised to make it possible to output
\POSTSCRIPT{} conforming to Adobe's EPSF specifications.  To do
this, each page must be independent of every other page, and for
a job with downloaded fonts, this poses a very large overhead.
Normally, fonts are not reloaded every page, but apart from this,
the output \POSTSCRIPT{} follows the EPSF guidelines.  In
particular, none of the deprecated operators are used, and I have
demonstrations that show that it is possible to incorporate
\PGM{dvialw} output as input pictures that can be arbitrarily
transformed.  This can even be iterated to produce a figure
showing a \TeX{} page inside a \TeX{} page inside a \TeX{} page
inside a \ldots{}.

\PGM{dvialw} has also been changed to remove almost all dependence on
output device resolution.  Now, only a single parameter sets the
resolution in dots/inch.  This should make it easy to extend to
support \POSTSCRIPT{} printers of other resolutions, including the
NeXT 400-dpi laser printer, and phototypesetters.

With the assistance of in-line \POSTSCRIPT{} code, change bars proved
to be easy to implement; I thought about how to do it one evening,
wrote the code the next morning, and had it working almost
immediately.  The essential idea is to redefine the \POSTSCRIPT{}
\verb|showpage| operator to handle completion of an open change bar at
end-of-page, and provide for its continuation on the following page.
From the user's point of view, change bars merely involve bracketing
the changed text with \verb|\BeginChangeBar| and \verb|\EndChangeBar|
macros; no restrictions whatever are placed on the intervening text.

Grey shading proved harder to do, but the problem has now been
solved.  Because \POSTSCRIPT{} has an opaque painting model, it
is impossible to draw the shading after text has been set, since
the shading would replace the text.  Drawing the shading first
would be more convenient, since it could permit shading to be
handled like change bars, and flow automatically across page
boundaries.  Instead, it is necessary in the \TeX{} code to place
the text to be shaded in a box, then to calculate the box
dimensions, output \POSTSCRIPT{} code to draw a grey box slightly
larger than that, then output the box itself.  The tricky part is
to get both boxes correctly aligned.

I have written \POSTSCRIPT{} macros that make it easy to take an input
\POSTSCRIPT{} file and arbitrarily scale it to fit a rectangle of
specified size.  Here is an example that scales a figure to fit
a half-size page:

\begin{verbatim}
\special{language = "PS",
        literal = "PageWidth 2 div PageHeight 2 div RESIZE",
        include = "spec8a.eps"}
\end{verbatim}

\noindent%
The use of the predefined \verb|PageWidth| and \verb|PageHeight|
values ensures that this will work correctly for any paper size.

\FN{dvialw.ps} also contains a macro \verb|sx sy SCALE| to scale an input
figure by factors \verb|sx| and \verb|sy| from its natural size.

At INRS Telecommunications in Montr\'{e}al, Michael Ferguson has
implemented \TeX{} macros that actually read the \POSTSCRIPT{}
file to find the dimensions from the \verb|%%BoundingBox|
comment, and then automatically compute the space needed for the
figure, freeing the user of having to insert explicit \TeX{}
spacing requests around a \verb|\special{}|.  Those macros should
be easily adaptable to this new \verb|\special{}| support code in
\PGM{dvialw}.

In order to deal with the fact that \verb|\special{}| code is not
standardized, and each driver implementer has done it differently, it
may be desirable to provide a run-time regular expression editing
capability for \verb|\special{}| strings.  This would add the
not-insignificant code for regular expression parsing, which may
require excessive memory.  It would, however, make it fairly
straightforward to provide built-in (and user-definable) support for
syntaxes provided by other DVI drivers.  No code to do this has yet
been implemented, and it would probably be better instead to write a
separate DVI-to-DVI filter to do the job.  While such changes can
obviously also be done in the original \TeX{} manuscript, DVI files
have become a medium of documentation exchange on the Internet, and
will often be processed on a system other than the one they were
generated on.

Most of the preceding remarks seem to be dependent upon \POSTSCRIPT{},
and indeed, features like change bar support seem to need the
programmability of \POSTSCRIPT{}.  What about ordinary graphics files?
In the TUG DVI committee, we have been wrestling with this problem for
many months.  In May, 1989, I gave a talk in Paris on the topic of
\TeX{} and graphics, where I discussed various possibilities.  It is
published in {\em Cahiers GUTenberg\/}, No. 2, Mai 1989, pp. 13--53.

While simple pictures can be done (usually laboriously) with
\TeX{} macros, \TeX{} memory limits put a very severe restriction
on the complexity of pictures that can be handled, and \TeX{} is
almost completely lacking in graphics primitives.  Thus, handling
of complex pictures seems destined to be relegated to requests in
a \verb|\special{}| string.

The problem is then to decide on a format that can be generated
by graphics packages, produced by translation from popular
graphics file formats (e.g.\ Tektronix and HPGL), and written by
hand for simple cases.

After long thought, my inclination is not to invent something new
here, but instead to adopt a subset of \POSTSCRIPT{}.  A subset
is required to simplify the parser.  \POSTSCRIPT{} is a
stack-based extensible language, and parsing cannot be done
correctly until {\em every\/} operator can be interpreted; some
operators take variable numbers of arguments, and the stacks
cannot be managed without knowing how many arguments an operator
must consume.  I have therefore modified my \PLOT{} graphics
system to produce such a subset, and have produced a working
parser for that subset in about 220 lines of code and 130 lines
of comments.  With planned extensions to the subset, it seems
likely that an adequate parser may be around 1000 lines of code,
which represents about 10\% of the current size of a typical DVI
driver.

Although \POSTSCRIPT{} has a large vocabulary, a subset of 20
operators is sufficient for most line graphing applications, and it
should be possible to write the parser in such a way that a vector of
pointers to functions can be provided by the caller, so that the same
parsing code can be used by all the DVI drivers, with separate
implementations of the primitives for different drivers.  However, all
of the bitmap device drivers could use essentially identical code,
since in each case, the primitives merely have to be expanded into
dots in a bitmap of known resolution.

\end{document}
