% This is the TeX source file for the DVItoVDU System Guide.
% Details peculiar to our site are indicated by the string "SYSDEP".
% Cross references are indicated by the string "XREF".
% Feel free to make modifications applicable to your site.

\input guidemacs

\null
\vfil
\centerline{\title \DVItoVDU~~System~~Guide}
\bigskip
\vskip\parskip
\centerline{\bigbf Version 3.1 for VAX/VMS}
\smallskip
\centerline{\bigbf Andrew Trevorrow, October 1989}
\bigskip

\noindent
This document explains how to install or modify \DVItoVDU,
a \TeX\ page previewer written in Modula-2.
Details on how to use the program can be found in the
{\sl \DVItoVDU\ User Guide}.
It is assumed you are familiar with \TeX\ under VAX/VMS\null.

\bigskip
\vskip\parskip
\centerline{\bigbf Contents}
\bigskip

\def\aligneddots{\leaders\hbox to .75em{\hss.\hss}\hfil}

% XREF: make sure titles and page numbers are up-to-date!!!

\line{Important files        \aligneddots\ 1}
\line{Installing \DVItoVDU\  \aligneddots\ 2}
\line{Overview               \aligneddots\ 3}
\line{Module map             \aligneddots\ 5}
\line{Modifying \DVItoVDU\   \aligneddots\ 6}
\line{Testing \DVItoVDU\     \aligneddots\ 7}
\line{Changes to version 1.5 \aligneddots\ 7}
\line{Changes to version 1.6 \aligneddots\ 8}
\line{Changes to version 1.7 \aligneddots\ 8}
\line{Changes to version 2.0 \aligneddots\ 8}
\line{Changes to version 3.0 \aligneddots\ 8}

\vfil
\eject

% The above is the title page; let's make a few adjustments to some parameters:
\footline={\hss\rm\folio\hss}      % turn page numbers back on
\pageno=1                          % and restart numbering

\subhead{Important files.}

We'll assume you've dumped the release tape into some directory, say
|tex_disk:[tex.dvitovdu]|, and are now looking at its contents.
The important files are:
\begindisplay
Modula-2 source files\cr\noalign{\medskip}
|dvitovdu.mod|&         the main module\cr
|screenio.def|/|mod|&   low-level terminal i/o routines\cr
|dclinterf.def|/|mod|&  DCL interface routines\cr
|dvireader.def|/|mod|&  DVI file translation routines and data structures\cr
|fontreade.def|/|mod|&  font file reading routines\cr
|vduinterf.def|/|mod|&  generic VDU parameters and routines\cr
|aed512vdu.def|/|mod|&  routines for AED 512\cr
|ansivdu.def|/|mod|&    routines for ANSI compatible VDUs\cr
|regisvdu.def|/|mod|&   routines for ReGIS compatible VDUs\cr
|tek4010vd.def|/|mod|&  routines for Tektronix 4010/4014 emulating VDUs\cr
|vis500vdu.def|/|mod|&  routines for VISUAL 500\cr
|vis550vdu.def|/|mod|&  routines for VISUAL 550\cr
|vt220vdu.def|/|mod|&   routines for VT220\cr
|vt640vdu.def|/|mod|&   routines for VT100 with Retrographics\cr
\noalign{\medskip}
Executable file\cr
\noalign{\medskip}
|dvitovdu.exe|&         \DVItoVDU\ built under VMS version 4.4\cr
\noalign{\medskip}
Object library\cr
\noalign{\medskip}
|modula.olb|&           Modula-2 system routines used by \DVItoVDU\cr
\noalign{\medskip}
Command files\cr
\noalign{\medskip}
|dvitovdu.cld|&         command language definition file for \DVItoVDU\cr
|build.com|&            used to build |dvitovdu.exe|\cr
\noalign{\medskip}
Test files\cr
\noalign{\medskip}
|trip.dvi|&             Knuth's torture test for \TeX\cr
|tripvdu.tex|&          the source for |tripvdu.dvi|\cr
|tripvdu.dvi|&          a torture test for \DVItoVDU\cr
\noalign{\medskip}
Documentation and help files\cr
\noalign{\medskip}
|help|&                 the text file read by \DVItoVDU's |?| command\cr
|dvitovdu.hlp|&         source file for on-line help library\cr
|guidemacs.tex|&        macros used by the following guides\cr
|sysguide.tex|&         the source for this document\cr
|userguide.tex|&        the source for the {\sl \DVItoVDU\ User Guide}\cr
|userguide.dvi|&        ready for users to print\cr
\enddisplay
For every |.def| file there should be a corresponding |.sym| file and
for every |.mod| file there should be a corresponding |.obj| file.
Note that you may have to relink \DVItoVDU\ under an earlier version of VMS;
just type `|@build|' and only answer `|yes|' to the |Link?| prompt.

\vfil\eject

\subhead{Installing \DVItoVDU.}

First read the section on qualifiers in the {\sl \DVItoVDU\ User Guide}.
You'll probably want to make some changes to |dvitovdu.cld| to suit your site:

\item{$\bullet$}
Change the |image| specification to indicate where you plan to store
|dvitovdu.exe|.

\item{$\bullet$}
Change the default value of |/vdu| to describe the type of terminal most
commonly used at your site.

\item{$\bullet$}
Change the default value of |/resolution| to match that of your printing device.

\item{$\bullet$}
Change the default values of |/xsize| and |/ysize| to define the dimensions of
the default paper used by your printer.

\item{$\bullet$}
Change the default value of |/help_file| to indicate the location
of |help|.  This is an ordinary text file.

\item{$\bullet$}
Change the default value of |/tfm_directory| to indicate the default location
of TFM files.

\item{$\bullet$}
Change the default value of |/font_directory| to indicate the location of
font files.
\DVItoVDU\ can read PXL or PK files in a variety of storage schemes.
See the |cld| file for details.

\item{$\bullet$}
The |/dummy_font| value must represent an unmagnified font
in |/font_directory|.

Individual users can of course override any of these defaults.
Once you are happy with the |cld| file, make the \DVItoVDU\ command permanently
available by installing it in the system DCL command tables:
\begintt
$ set command /tables=sys$library:dcltables-
$_  /output=sys$library:dcltables  -
$_  dvitovdu.cld
$ set proc/priv=cmkrnl
$ run sys$system:install
INSTALL> sys$library:dcltables/replace
INSTALL> /exit
\endtt
Any changes to |dvitovdu.cld| should be reflected in the user documentation
in |userguide.tex| and |dvitovdu.hlp|.  System-dependent information in these
files is flagged by the string ``|SYSDEP|'' so you can quickly locate where
changes need to be made.
If you want users to be able to type `|help dvitovdu|' then put
|dvitovdu.hlp| into an appropriate help library.

\vfil\eject

\subhead{Overview.}

As its name would imply, a Modula-2 program is typically built up from a
number of separately compiled modules.  Each module can import data and
procedures from other modules.  An imported module is further decomposed
into a definition module and an implementation module.
The definition part contains declarations for all exported objects and
serves as the interface to client modules.  The details of how exported
objects are actually realized are contained in the
implementation part (i.e., hidden from clients).
Rapid system regeneration is possible because
client modules only depend on the definition part; the implementation part
may be modified (e.g., optimized) without the need to recompile client modules.
The module map on page 5   % XREF
shows the importation dependencies of all the modules making
up \DVItoVDU\null.

Not only do modules allow a large program to be broken up into manageable
chunks, they also provide a sensible basis for describing a program:

\medskip
\noindent |DVItoVDU|

The main module is primarily concerned with the user interface.
It handles all the interactive command processing
and contains the high-level logic used to update the dialogue and window
regions.  Data and procedures are imported from the following modules to help
the main module carry out its many tasks.

\medskip
\noindent |DCLInterface|

This module provides the interface to the DCL interpreter.
The command line used to invoke \DVItoVDU\ is parsed and the DVI file name
extracted.  All the qualifiers are also initialized, either to explicit
values given in the command line or to site-dependent default values.

\medskip
\noindent |VDUInterface|

\DVItoVDU\ can work efficiently on different types of VDUs by letting
Modula-2 procedure variables act as generic VDU routines.
These routines are:
\begindisplay
|StartText|&       switch to ``text mode''\cr
|ClearTextLine|&   erase given line\cr
|MoveToTextLine|&  move cursor to start of given line\cr
|ClearScreen|&     erase the entire screen\cr
|StartGraphics|&   switch to ``graphics mode''\cr
|LoadFont|&        simulate the given font for future |ShowChar| calls\cr
|ShowChar|&        display a Terse mode character at given screen location\cr
|ShowRectangle|&   display a given rectangular region of screen pixels\cr
|ResetVDU|&        reset VDU to its normal state\cr
\enddisplay
Most of these are quite trivial to implement for a specific VDU.
The main module looks after all the tricky graphic operations such as the
clipping of characters and rules outside the current
window region, and the way in which visible paper pixels are scaled
to screen pixels.

From an efficiency point of view, the two most critical routines are
|ShowChar| and |ShowRectangle|.
|ShowChar| is used by the main module to display a character in Terse
mode.  The only information given is the \TeX\ character code
and its screen position.
Since characters are displayed one font at a time, some VDUs can use scaling
information sent by the most recent |LoadFont| routine to select an
appropriate hardware ``font''.

|ShowRectangle| is used for all other window graphics.
It is used to draw the paper edges, all rules (regardless of display mode),
all character boxes in a Box display, and the horizontal lines making up
all character bitmaps in a Full display.
The majority of rectangles are in fact horizontal or vertical lines just one
screen pixel thick.

\vfil\eject

\noindent |AED512VDU|, |ANSIVDU|, |REGISVDU|, etc.

Each specific VDU module exports an initialization routine
that will assign appropriate procedures to the generic VDU routines
and specific integers to the generic VDU parameters.
|VDUInterface| imports all these initialization routines and
uses the |/vdu| value set in |DCLInterface| to
execute one of them.

\medskip
\noindent |DVIReader|

This module exports the routines and data structures needed
to move about randomly in a DVI file and interpret selected pages.

Font, character and rule information is stored in dynamically allocated
lists to avoid imposing any limit on their numbers.
The length of the font list is determined soon after opening the DVI file by
reading all the font definitions in the postamble.
Each font node is a record made up of many fields; one of these fields is the
head of a character list.  The nodes in each character list will
store the positions and \TeX\ codes of all characters on a page.
Besides the font list, there is also a rule list.
The nodes in the rule list will store the positions and dimensions of
all rules on a page.
(Character and rule positions are stored as pairs of horizontal and vertical
paper pixel coordinates.
The manner in which |DVIReader| calculates such positions is based
firmly on Donald Knuth's |DVItype|.)

Just before interpreting a selected DVI page, the rule list and all the
character lists are deallocated if necessary.
During interpretation, |DVIReader| adds a new rule or character
node to the {\it tail\/} of an appropriate list.
When the main module processes such lists, rules and characters will be
displayed in somewhat the same sequence as seen in the DVI page; i.e.,
top-to-bottom and left-to-right.
(Since there is a separate rule list, as well as a character list for
each font, the precise sequence is not remembered.)
After interpretation, the nodes in the font list are sorted so
that fonts with the least number of characters ($>$ 0) will
be processed first.

The various lists contain most of the information needed to display the page;
they are traversed by the main module whenever the window region is updated.
If the page isn't empty then |DVIReader| will also determine the edges of the
page rectangle.  This is the smallest rectangle containing all black pixels in
characters and rules, as well as all character reference points
(needed for Terse displays).
The main module uses the page rectangle to decide if the page is off the paper,
and to restrict window movement.

\medskip
\noindent |FontReader|

\DVItoVDU\ gets all its character bitmap information from PXL or PK files.
The |/font_directory| and |/dummy_font| values determine which format to use,
as well as the location and naming convention of all files.
|FontReader| can cope with most storage schemes currently in use.

Font files contain crucial typesetting data needed by |DVIReader| to
correctly position characters when interpreting a DVI page.
These character metrics are loaded just once for each font
(the very first time the font is seen) and \DVItoVDU\ will
display `|Loading font data from ...|' in the message line.

If |FontReader| sees a font name beginning with the |/psprefix| string
then the font is assumed to be resident in a PostScript printer and the
necessary character metrics are read from a TFM file.
If the font name is not prefixed with an explicit directory then the
location of the TFM file is given by the |/tfm_directory| value.
Since bitmap information for such a font is unavailable,
\DVItoVDU\ will draw filled rectangles to represent PostScript characters
in a Full display.  The location and size of these boxes are approximated.

PXL and PK files contain bitmap information for characters in a \TeX\ font.
These bitmaps are loaded on demand into dynamic memory; \DVItoVDU\ uses
them during a Full display to draw characters a font at a time.
Each time a new font is about to be drawn,
the message `|Drawing characters from ...|' will appear.
The font file will only be opened if a previously unused character bitmap
has to be loaded.

Because |DVIReader| creates a separate character list for each font used on
a page, there never needs to be more than one font file open at any given time.

\medskip
\noindent |ScreenIO|

All low-level terminal i/o is handled by the routines defined in this module.

\vfil\eject

\subhead{Module map.}

\font\arrowfont=linew10 at 10truept

% MACROS FOR MAP.
% \plot is based on \point macro described on page 389 of TeXbook.

\newdimen\unit
\unit=1in

\def\plot            % #1 is down, #2 is right, #3 is stuff to plot
       #1 #2 #3\endplot
   {\rlap{\kern#2\unit
          \vbox to 0pt
              {\parindent=0pt\offinterlineskip\kern#1\unit#3\vss}}}

\def\ulap#1{\vbox to 0pt{\vss#1}}      % vertical analog of \llap
\def\dlap#1{\vbox to 0pt{#1\vss}}      % vertical analog of \rlap

\def\cvlap#1{\vbox to 0pt{\vss#1\vss}} % centre vertically
\def\chlap#1{\hbox to 0pt{\hss#1\hss}} % centre horizontally

\def\drawbox ht#1 wd#2 #3\endbox
    {\vbox{\hsize=#2\unit
           \hrule height10sp
           \hbox to \hsize
               {\vrule width10sp
                \vbox to #1\unit
                    {\vfil #3\vfil}%
                \vrule width10sp
               }
           \hrule height10sp
          }
    }

\def\mainmodule
    {\drawbox ht.7 wd1.2
         \centerline{\strut |DVItoVDU|}
         \centerline{\strut (main module)}
     \endbox
    }

\def\midmodules
    {\drawbox ht.4 wd1
         \centerline{|DVIReader|}
     \endbox
     \kern .3\unit
     \drawbox ht.4 wd1
         \centerline{|FontReader|}
     \endbox
     \kern .3\unit
     \drawbox ht.4 wd1
         \centerline{|DCLInterface|}
     \endbox
     \kern .3\unit
     \drawbox ht.4 wd1
         \centerline{|VDUInterface|}
     \endbox
     \kern .5\unit
     \drawbox ht.4 wd1.5
         \centerline{|ScreenIO|}
     \endbox
    }

\def\vdumodules
    {\drawbox ht.8 wd1.3
         \centerline{\strut VDU modules:}
         \centerline{\strut |AED512VDU|}
         \centerline{\strut |ANSIVDU|}
         \centerline{\strut etc.}
     \endbox
    }

\def\uline#1  {\ulap{\hrule width 10sp height#1\unit}}
\def\dline#1  {\dlap{\hrule width 10sp height#1\unit}}
\def\lline#1  {\llap{\vrule height10sp width #1\unit}}
\def\rline#1  {\rlap{\vrule height10sp width #1\unit}}

\def\uarrow#1 {\ulap{\arrowfont\dlap{\hbox{\char'66 }}
               \hrule width10sp height#1\unit}}
\def\darrow#1 {\dlap{\arrowfont\hrule width10sp height#1\unit
               \ulap{\hbox{\char'77 }}}}
\def\rarrow#1 {\rlap{\vrule height10sp width#1\unit
               \setbox0=\hbox{\arrowfont\char'55 }\ht0=0pt\dp0=0pt
               \llap{\box0}}}
\def\larrow#1 {\llap{\setbox0=\hbox{\arrowfont\char'33 }\ht0=0pt\dp0=0pt
               \rlap{\box0}\relax
               \vrule height10sp width#1\unit}}

% START PLOTTING MAP

An arrow from module |A| to module |B| indicates the latter
imports data and/or procedures from the former.
Module |B| is said to be a {\it client\/} of module |A|\null.

\vskip 0.5in

\hbox
   {\kern-.3\unit    % shift 0,0 left
    % plot all the module boxes:
    \plot 0.0   0.5   \mainmodule    \endplot
    \plot 1.0   2.5   \midmodules    \endplot
    \plot 2.9   4.4   \vdumodules    \endplot
    % plot all the arrows:
    \plot 1.2   1.5   \uarrow 0.5    \endplot    % dvireader to main
    \plot 1.2   1.5   \rline  1.0    \endplot
    \plot 1.9   1.3   \uarrow 1.2    \endplot    % fontreader to main
    \plot 1.9   1.3   \rline  1.2    \endplot
    \plot 2.6   1.1   \uarrow 1.9    \endplot    % dclinterface to main
    \plot 2.6   1.1   \rline  1.4    \endplot
    \plot 3.3   0.9   \uarrow 2.6    \endplot    % vduinterface to main
    \plot 3.3   0.9   \rline  1.6    \endplot
    \plot 4.2   0.7   \uarrow 3.5    \endplot    % screenio to main
    \plot 4.2   0.7   \rline  1.8    \endplot
    \plot 4.0   3.0   \uarrow 0.5    \endplot    % screenio to vduinterface
    \plot 1.4   3.0   \darrow 0.3    \endplot    % dvireader to fontreader
    \plot 2.4   3.0   \uarrow 0.3    \endplot    % dclinterface to fontreader
    \plot 2.8   3.0   \darrow 0.3    \endplot    % dclinterface to vduinterface
    \plot 3.3   4.4   \larrow 0.9    \endplot    % point 7 to vduinterface
    \plot 3.3   4.3   \rarrow 0.1    \endplot    % right arrow at point 7
    \plot 4.2   4.0   \rline  2.3    \endplot    % line to right of screenio
    \plot 4.2   6.3   \uline  2.3    \endplot    % screenio to vdus, dcl, font
    \plot 1.9   6.3   \larrow 2.8    \endplot    % screenio to fontreader
    \plot 2.6   6.3   \larrow 2.8    \endplot    % screenio to dclinterface
    \plot 3.3   6.3   \larrow 0.6    \endplot    % screenio to vdus
    \plot 2.5   3.5   \rline  0.3    \endplot    % dclinterface to dvireader
    \plot 2.5   3.8   \uline  0.55   \endplot
    \plot 1.85  3.8   \uline  0.65   \endplot
    \plot 1.2   3.8   \larrow 0.3    \endplot
    % plot all the numbers:
    \plot 1.7   2.4   \llap{1}  \endplot
    \plot 1.5   3.1   \rlap{2}  \endplot
    \plot 2.4   2.4   \llap{3}  \endplot
    \plot 2.2   3.1   \rlap{4}  \endplot
    \plot 3.1   2.4   \llap{5}  \endplot
    \plot 2.9   3.1   \rlap{6}  \endplot
    \plot 3.1   4.0   \llap{7}  \endplot
    \plot 1.0   3.6   \rlap{8}  \endplot
   }

\vskip 5in   % leave space for figure

\noindent Points of interest:

\item{1 }
|FontReader| contains all the font-dependent code.
It is possible to add a new font format without changing any other module.

\item{2 }
|FontReader| needs access to some of the data structures defined in |DVIReader|.
|DVIReader| does not, however, depend on |FontReader|;
it does know that font files contain crucial typesetting data, but leaves it
up to the main module to specify how and where to get such information.

\item{3 }
|DCLInterface| extracts the DVI file name and qualifiers from
the {\DVItoVDU} command line.

\item{4 }
|FontReader| needs the |/psprefix|, |/tfm_directory|, |/font_directory|
and |/dummy_font| values to decide on which font format to use,
as well as the location and naming convention of all font files.

\item{5 }
|VDUInterface| exports the generic VDU routines and parameters
for use in the main module.

\item{6 }
|VDUInterface| needs the |/vdu| value to select an appropriate VDU
initialization routine.

\item{7 }
Specific VDU modules import the generic VDU routines and parameters from
|VDUInterface|.  In return, each VDU module exports an initialization routine.

\item{8 }
|DVIReader| needs the |/hoffset| and |/voffset| values to shift page
coordinates.

\vfil\eject

\subhead{Modifying \DVItoVDU.}

\DVItoVDU\ was developed using the Modula-2 system from Hamburg University.
The main module and all the supporting modules are
written entirely in Modula-2.
If you wish to modify \DVItoVDU\ you'll obviously need Modula-2.
Unfortunately, the Hamburg compiler is not in the public domain,
so I can't send you a copy.
I believe it is available for US\$300 from

\medskip
\centerline{Dr.~Joachim W.~Schmidt}
\centerline{Fachbereich Informatik}
\centerline{Universitaet Hamburg}
\centerline{D-2000 Hamburg 13}
\centerline{Deutschland}

Conversion to another Modula-2 system should be quite easy.
All the source files avoid non-standard compiler features, and system-dependent
code is flagged by the string ``|SYSDEP|''\null.
Terminal i/o is isolated in the |ScreenIO| module and most file operations are
restricted to |DVIReader| and |FontReader|.

What about conversion to another language?
An obvious candidate is Pascal.
The similarities in syntax would allow any decent text editor to
carry out much of the conversion automatically.
The major difficulty in translation to standard Pascal would be
the lack of procedure variables;
it might be easier to implement just one type of VDU before
attempting anything more sophisticated.

\medskip
\noindent IMPLEMENTING A NEW VDU.

Assuming you have Modula-2, the most likely change you'll want to
make is to add a new type of VDU to the program's capabilities.
I've taken advantage of Modula-2's separate compilation facilities
so that such a task can be undertaken without having to recompile
the main module.

It should be pointed out that \DVItoVDU\ is currently targeted towards
relatively primitive terminals.  Significant changes to both the display
logic and page data structures would probably
be needed to take full advantage of the latest graphic work\-stations.
For instance, a large amount of bit-mapped memory could store an entire
rasterized page and allow much more sophisticated updating of
the window region.
Pan and zoom operations would also be much easier using a mouse or thumbwheel
cursor controls.

The steps required to implement a new VDU (which we'll call brand XXX) are:

\item{$\bullet$}
Read |vduinterf.def| to see if the task is even possible.  \DVItoVDU\ requires
XXX to be able to carry out a number of primitive graphic operations
such as clearing the screen, addressing individual pixels etc.
As little as possible is assumed about the capabilities of a VDU\null.
In particular, the availability of a graphic input device is ignored.
\DVItoVDU\ should be able to work on any terminal that can:

\itemitem{---} Mix text and graphics on the screen
(some VDUs make no distinction).
{\parskip=0pt
\itemitem{---} Erase all of the screen, or individual text lines.
\itemitem{---} Move the cursor to any given screen pixel.
\itemitem{---} Display a rectangular region of screen pixels
(possibly just one).

} % reset \parskip

\item{$\bullet$}
Look at some of the |*vdu.def| files and use them to
create a new definition module called |xxxvdu.def|.
Type `|modula/nocheck xxxvdu.def|' to create |xxxvdu.sym|.

\item{$\bullet$}
Look at some of the |*vdu.mod| files and use them to
create a new implementation module called |xxxvdu.mod|.
Type `|modula/nocheck xxxvdu|' to create |xxxvdu.obj|.

\item{$\bullet$}
Edit |vduinterf.mod| and add appropriate code in the recommended locations
(search for occurrences of ``|XXX|'').
Type `|modula/nocheck vduinterf|' to create a new |obj| file.

\item{$\bullet$}
Edit |build.com| and add |xxxvdu.obj| to the link stage.
Use this interactive command procedure to rebuild |dvitovdu.exe|.
Since the main module hasn't been altered, you need only answer `|yes|'
to the |Link?| prompt.

\item{$\bullet$}
Type `|set command dvitovdu|' and test the new version of \DVItoVDU.

\vfil\eject

\subhead{Testing \DVItoVDU.}

The file |tripvdu.dvi| was created to test \DVItoVDU\ using much the same
philosophy as Donald Knuth's torture test for \TeX\null.
The pages are designed to exercise rarely-used parts of the program:
\begindisplay
page&     contents\cr
\noalign{\medskip}
1&        empty page\cr
2&        empty page with a few |\special| commands\cr
3&        one black pixel at (0{,}0)\cr
4&        entirely blackened A4 sheet of paper\cr
5&        as above but one pixel wider and longer\cr
6&        has a rulelist with one full ruletable node (300 rules)\cr
7&        as above but one more rule\cr
8&        has a charlist with one full chartable node (3000 characters)\cr
9&        as above but one more character\cr
10&       multiple \TeX\ page counters\cr
11&       negative \TeX\ page counter\cr
12&       characters from many fonts\cr
13&       characters from many non-existent fonts\cr
14&       paragraph using most characters from standard roman font\cr
15&       page in bottom half of A4 paper\cr
16&       page entirely above and to the left of A4 paper\cr
17&       page entirely below and to the right of A4 paper\cr
18&       page extending beyond all edges of A4 paper\cr
19&       aligned verbatim |\tt| strings\cr
20&       page with blank character\cr
21&       page with PostScript fonts\cr
\enddisplay
Type `|dvitovdu tripvdu|'
and go through all the pages to verify that the program is working correctly.
You may need to specify a |/vdu| value to tell {\DVItoVDU} what type of
terminal you're using---see the {\sl \DVItoVDU\ User Guide} for details.

\subhead{Changes to version 1.5}

\item{$\bullet$}
The |/font_directory| value is restricted to a single directory rather than
a list of directories.  The main module uses the last two characters
of the given value to decide on how to build PXL file specifications.
See |dvitovdu.cld| for the reasons behind this hack.
The |/dummy_font| file is now assumed to reside in |/font_directory|.

\item{$\bullet$}
Some of the default values in |dvitovdu.cld| have been changed because we
replaced our Imagen IMPRINT-10 with an Apple LaserWriter.

\item{$\bullet$}
There are two new |/vdu| values.  |VT220| is no longer a synonym for
|ANSI|\null.  This new implementation uses down-loaded chunky graphics and
was done by John Mann at Monash University.  |VIS240| (or |VIS241|) is a
ReGIS VDU with a larger window region.

\item{$\bullet$}
Amendments to Modula-2 have required minor syntactic changes
to a few source files.

\item{$\bullet$}
The page position and first few bytes of each |\special| command
are now displayed.

\item{$\bullet$}
\DVItoVDU\ makes fewer assumptions about the correctness of PXL files.
Such pessimism should not be necessary, but some programs
don't do the right thing
(e.g., |GFread| and |GFtoPXL| in Kellerman \& Smith's 2.0.1 distribution).

\vfil\eject

\subhead{Changes to version 1.6}

\item{$\bullet$}
All font-dependent code has been moved out of the main module and into
|FontReader|.  This module replaces |PXLReader| and can read PXL or PK files
in a variety of storage schemes, depending on the |/font_directory| and
|/dummy_font| values.  See |dvitovdu.cld| for more details.

\item{$\bullet$}
The main module's Full display routines have been changed to handle the
new method of loading character bitmaps into dynamic memory.
Some changes to the data structures in |DVIReader| were also needed.
\DVItoVDU\ is now slightly faster, but uses more memory.

\item{$\bullet$}
\DVItoVDU\ can now handle all \TeX\ character codes from 0 to 255.

\item{$\bullet$}
|VT200| is now a synonym for |VT220|.

\item{$\bullet$}
A few minor changes were made to coincide with the release of PSPRINT 1.1.
Now that \TeX\ under VAX/VMS has reached its final state, the current
versions of \DVItoVDU\ and PSPRINT are unlikely to change.

\subhead{Changes to version 1.7}

\item{$\bullet$}
These changes were made while I was working in the UK at The Open University.
The current version (which has leapt to 2.0) is now displayed in the
message line of the initial screen display.

\item{$\bullet$}
Added |ZI| (Zoom In) and |ZO| (Zoom Out) commands.  The former halves the
current window dimensions and the latter doubles them.  Although the
same effects can be achieved by appropriate use of |H| and |V|, the new
commands require less contemplation.

\item{$\bullet$}
Any |\special| commands on a page are now displayed by the |S| command
rather than at the time the page is interpreted.  This is much less
annoying for those documents with lots of |\special| commands.

\item{$\bullet$}
\DVItoVDU\ can now handle PostScript fonts (for which only TFM files exist).
The major changes:
new |/tfm_directory| qualifier;
new |psfont| flag in |fontinfo| record;
new code in |FontReader| to recognize such a font, build a TFM file
specification and extract character metrics from that file;
new |FullCharPS| routine in main module to handle the Full display of
PostScript characters.

\subhead{Changes to version 2.0}

\item{$\bullet$}
These changes were made while I was working at Aston University.
The current version of \DVItoVDU\ is now 3.0.

\item{$\bullet$}
Added |/psprefix| qualifier so that sites can specify the
TFM file name prefix used to indicate PostScript fonts.
(The default prefix is ``|ps-|''; see |dvitovdu.cld|.)

\item{$\bullet$}
Modified the |BuildFontSpec| routine in |FontReader| to
remove the limitation requiring all font files to contain a size substring
of the same length.  Sites that had to include a leading zero
in some font names to overcome this limitation must now
rename them (e.g., |$rename *.0635pk *.635pk|).

\item{$\bullet$}
Added |/hoffset| and |/voffset| qualifiers to allow shifting of page.

\subhead{Changes to version 3.0}

\item{$\bullet$}
These changes were made while I was working at Aston University
(for a second time).
The current version of \DVItoVDU\ is now 3.1.

\item{$\bullet$}
The |S| command now lists any |\special|s on a page in the order they
appear in the DVI file (instead of in reverse order).

\item{$\bullet$}
Fixed bug in |FixToDVI| routine in |FontReader.MOD| that prevented fonts
being scaled to more than 128pt.
Thanks to Niel Kempson for spotting this.

\finishline
\bye
