⟦eb4bc2503⟧

TextFile

% 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.
% Andrew Trevorrow, July 1986.

\input guidemacs

% \centerline{\crest}  % SYSDEP: University of Adelaide crest
\vfil
\centerline{\title \DVItoVDU~~System~~Guide}
\bigskip
\vskip\parskip
\centerline{\bigbf Version 1.0 for VAX/UNIX}
\smallskip
\centerline{\bigbf Andrew Trevorrow, July 1986}
\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/UNIX\null.
Please convey any problems or suggestions to:

\medskip
% SYSDEP
\centerline{Andrew Trevorrow}
\centerline{Computing Services, University of Adelaide}
\centerline{GPO Box 498, Adelaide, South Australia, 5001}
\centerline{ACSnet address: |akt@uacomsci.ua.oz|~~Phone: (08) 228 5984}

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

% XREF: make sure page numbers are up-to-date!!!
\line{Important files\leaders\hbox to .75em{\hss.\hss}\hfil 1}
\line{Installing \DVItoVDU\leaders\hbox to .75em{\hss.\hss}\hfil 2}
\line{Overview\leaders\hbox to .75em{\hss.\hss}\hfil 2}
\line{Module map\leaders\hbox to .75em{\hss.\hss}\hfil 5}
\line{Modifying \DVItoVDU\leaders\hbox to .75em{\hss.\hss}\hfil 6}
\line{Testing \DVItoVDU\leaders\hbox to .75em{\hss.\hss}\hfil 7}
\line{Revision history\leaders\hbox to .75em{\hss.\hss}\hfil 7}

\vfil
\centerline{\smallrm University of Adelaide Computing Services}   % SYSDEP
\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.}

\noindent
We'll assume you've dumped the release tape into some directory 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
                           (see also |unixio.def/c|)\cr
|sysinterface.def|/|mod|&  command line interface routines\cr
|dvireader.def|/|mod|&     DVI file translation routines and data structures\cr
|pxlreader.def|/|mod|&     PXL file access routines\cr
|vduinterface.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
|tek4010vdu.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{\bigskip}
Executable files\cr
\noalign{\medskip}
|dv|&              \DVItoVDU; built under VAX/UNIX 4.2 BSD\cr
|build|&           to build |dv| from scratch\cr
|makefile|&        to make |dv| automatically\cr
\noalign{\bigskip}
Test files\cr
\noalign{\medskip}
|tripvdu.tex|&     the source for |tripvdu.dvi|\cr
|tripvdu.dvi|&     a torture test for \DVItoVDU\cr
\noalign{\bigskip}
Documentation and help files\cr
\noalign{\medskip}
|dvitovdu.hlp|&    the text file read by \DVItoVDU's |?| command\cr
|online.hlp|&      source file for on-line help\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
\enddisplay
If you don't have a Modula-2 compiler
(and don't intend getting one)
then you might as well delete all the |.o| files.
If you're not even interested in how \DVItoVDU\ works then delete
the |.def| and |.mod| files as well.

\vfil\eject
\subhead{Installing \DVItoVDU.}

\noindent
Since \DVItoVDU\ is too much of a fingerful, the executable file is called |dv|.
Before making |dv| publicly available, read the section on command options in
the {\sl \DVItoVDU\ User Guide}.
If you have a Modula-2 compiler, you may want to
make a few changes to |sysinterface.mod| to suit your site:

\item{$\bullet$}
Change the default value of |-r| to match the resolution
of your printer.

\item{$\bullet$}
Change the default values of |-x| and |-y| to define the dimensions of
the default paper used by your printer.

\item{$\bullet$}
Change the default value of |-f| to tell \DVItoVDU\ where to
look for PXL files.

\item{$\bullet$}
Change the default value of |-d| to indicate which PXL file to use
in case a requested one does not exist.

\item{$\bullet$}
Change the default value of |-h| to indicate the location of |dvitovdu.hlp|.

\noindent
Individual users can of course override any of these defaults.
(They may have to if you choose not to use our defaults but
don't have a Modula-2 compiler to implement your own.)
Any changes you make should be reflected in the user documentation
in |userguide.tex| and |online.hlp|
(the latter file provides a suitable basis for a |man| entry).
System-dependent information in these
files is flagged by the string ``|SYSDEP|'' so you can quickly locate where
changes need to be made.

\subhead{Overview.}

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

\noindent
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|

\nobreak\noindent
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 |SysInterface|

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

\medskip
\noindent |VDUInterface|

\nobreak\noindent
\DVItoVDU\ can work efficiently on different types of VDUs by letting
Modula-2 procedure variables act as generic VDU routines.
These routines, along with the generic VDU parameters, are defined in
|VDUInterface|.

\vfil
\eject
\noindent
The generic VDU 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.

\noindent
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 (currently
restricted to |\char0..\char127|) 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''.

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

\noindent
The generic VDU parameters are:
\begindisplay
|DVIstatusl|&      DVI status line, usually 1\cr
|windowstatusl|&   window status line, usually 2\cr
|messagel|&        message line, usually 3\cr
|commandl|&        command line, usually 4\cr
|bottoml|&         bottom text line in screen\cr
|windowh|&         window region's top left h coordinate\cr
|windowv|&         window region's top left v coordinate\cr
|windowwd|&        unscaled window width\cr
|windowht|&        unscaled window height\cr
\enddisplay
These ``parameters'' are actually integer variables.  The main module
treats them as constants.

\noindent
There are two screen coordinate systems used by \DVItoVDU:

\item{(1)}
When updating the screen in text mode (i.e., when updating the
dialogue region or during a |?| or |S| command), \DVItoVDU\ assumes
text lines start at 1 and increase downwards.  The bottom
text line on the screen is given by the parameter |bottoml|.

\item{(2)}
When updating the screen in graphics mode,
\DVItoVDU\ assumes the top left screen pixel
is positioned at (0,0).  Horizontal coordinates increase to the right
and vertical coordinates increase down the screen.  The top left pixel
in the window region is at (|windowh|,|windowv|).
Specific VDU modules may have to do a translation to the actual
coordinate scheme used by the VDU\null.
The size of the window region in screen pixels
is given by |windowwd| and |windowht|.

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

\nobreak\noindent
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 |-v| value set in |SysInterface| to
execute one of them.

\vfil\eject
\noindent |DVIReader|

\nobreak\noindent
This module exports the routines and data structures needed
to move about randomly in a DVI file and interpret selected pages.
Although the main module is currently the only client,
it is anticipated that |DVIReader| could just as well form the basis of a
more conventional DVI translator such as a non-interactive device driver.

\noindent
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|.)

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

\noindent
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 glyphs 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 |PXLReader|

\nobreak\noindent
\DVItoVDU\ gets all its character information from standard PXL files.
|PXLReader| exports routines for moving about in such files and
grabbing various bytes and words.
A PXL file contains the crucial TFM widths needed by |DVIReader| to
correctly position characters when interpreting a DVI page.  These widths,
along with other details about each glyph, are kept in a PXL file's font
directory.  A directory is 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.

\noindent
A PXL file also contains glyph shape information (in the form of bitmaps) for
all characters in a \TeX\ font.
\DVItoVDU\ uses these bitmaps during a Full display to draw
characters a font at a time.  Each time a PXL file is opened,
the message `|Drawing characters from ...|' will appear.

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

\medskip
\noindent |ScreenIO|

\nobreak\noindent
All low-level terminal i/o is handled by the routines defined in this module.
It uses some C routines written by Alex Dickinson (see |unixio.c|).

\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{|PXLReader|}
     \endbox
     \kern .3\unit
     \drawbox ht.4 wd1
         \centerline{|VDUInterface|}
     \endbox
     \kern .3\unit
     \drawbox ht.4 wd1
         \centerline{|SysInterface|}
     \endbox
     \kern .5\unit
     \drawbox ht.4 wd1.5
         \centerline{|ScreenIO|}
     \endbox
    }

\def\vdumodules
    {\drawbox ht1.2 wd1.3
         \centerline{\strut VDU modules:}
         \centerline{\strut |AED512VDU|}
         \centerline{\strut |ANSIVDU|}
         \centerline{\strut |REGISVDU|}
         \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

\noindent
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 1in

\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.4   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    % pxlreader to main
    \plot 1.9   1.3   \rline  1.2    \endplot
    \plot 2.6   1.1   \uarrow 1.9    \endplot    % vduinterface to main
    \plot 2.6   1.1   \rline  1.4    \endplot
    \plot 3.3   0.9   \uarrow 2.6    \endplot    % sysinterface 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 sysinterface
    \plot 4.0   3.8   \uline  1.3    \endplot    % screenio to vduinterface
    \plot 2.7   3.8   \larrow 0.3    \endplot
    \plot 3.9   3.8   \darrow 0.1    \endplot    % down arrow at point 6
    \plot 3.1   3.0   \uarrow 0.3    \endplot    % sysinterface to vduinterface
    \plot 2.5   4.4   \larrow 0.9    \endplot    % point 5 to vduinterface
    \plot 2.5   4.3   \rarrow 0.1    \endplot    % right arrow at point 5
    \plot 4.2   4.0   \rline  2.3    \endplot    % line to right of screenio
    \plot 4.2   6.3   \uline  3.0    \endplot    % screenio to vdus, pxl, dvi
    \plot 3.0   6.3   \larrow 0.6    \endplot    % screenio to vdus
    \plot 1.9   6.3   \larrow 2.8    \endplot    % screenio to pxlreader
    \plot 1.2   6.3   \larrow 2.8    \endplot    % screenio to dvireader
    % plot all the numbers:
    \plot 1.5   2.4   \llap{1}  \endplot
    \plot 2.4   2.4   \llap{2}  \endplot
    \plot 3.1   2.4   \llap{3}  \endplot
    \plot 2.9   3.1   \rlap{4}  \endplot
    \plot 2.3   4.3   \llap{5}  \endplot
    \plot 3.8   3.9   \rlap{6}  \endplot
   }

\vfill

\noindent Points of interest:

\item{1 }
|DVIReader| does not depend on |PXLReader|.
It does know that PXL files contain crucial typesetting data, but leaves it
up to the main module to specify how and where to get such information.

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

\item{3 }
|SysInterface| extracts the DVI file name and options from
the |dv| command line.

\item{4 }
|VDUInterface| needs the |-v| value to select an appropriate VDU
initialization routine.

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

\item{6 }
|ScreenIO| needs to use some |VDUInterface| routines to be able to
leave the VDU screen in a decent state after abnormal termination.

\eject
\subhead{Modifying \DVItoVDU.}

\noindent
\DVItoVDU\ was originally developed under VAX/VMS
using the Modula-2 system from Hamburg University.
The UNIX version of \DVItoVDU\ was developed using the
Modula-2 compiler from DEC WRL and can run under ULTRIX or UNIX 4.2 BSD\null.
The main module and all the supporting modules are
written in Modula-2, except for the C routines in |unixio.c|.

\noindent
If you wish to modify \DVItoVDU\ you'll obviously need Modula-2.
Unfortunately, the DEC compiler is not in the public domain, so I can't send
you a copy.
Conversion to another Modula-2 system should, however, 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 |PXLReader|.
(The VMS-to-UNIX conversion took me about two weeks.
A working version was up in less than a week; it then took another week
to fix some terminal i/o problems and produce a new {\sl User Guide}.
I was a bit surprised at just how easy the conversion was.)

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

\noindent
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 make any changes to
the main module.

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

\item{$\bullet$}
Read |vduinterface.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 help you
create |xxxvdu.def|.
Our Modula-2 system does not require |.def| files to be compiled.   % SYSDEP

\item{$\bullet$}
Look at some of the |*vdu.mod| files and use them to help you
create |xxxvdu.mod|.
Type `|mod -c xxxvdu.mod|' to create |xxxvdu.o|.   % SYSDEP

\item{$\bullet$}
Edit |vduinterface.mod| and add appropriate code in the recommended locations
(search for occurrences of ``|XXX|'').
Type `|mod -c vduinterface.mod|' to create a new |.o| file.   % SYSDEP

\item{$\bullet$}
Relink |dv| by typing `|mod -o dv *.o|'.   % SYSDEP

\item{$\bullet$}
Test the new version of |dv| (see the next section).

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

\vfil\eject
\subhead{Testing \DVItoVDU.}

\noindent
The file |tripvdu.dvi| was created to test \DVItoVDU\ using much the same
philosophy as Donald Knuth's torture test for \TeX\null.
Most pages exercise rarely-used parts of the program:
\begindisplay
page&     contents\cr
\noalign{\medskip}
1&        empty page (but with |\special| stuff that will be ignored)\cr
2&        one black pixel at (0{,}0)\cr
3&        entirely blackened A4 sheet of paper\cr
4&        like page 3 but one pixel wider\cr
5&        like page 3 but one pixel longer\cr
6&        has a rulelist with one full ruletable node (300 rules)\cr
7&        like page 6 but has one more rule\cr
8&        has a charlist with one full chartable node (3000 characters)\cr
9&        like page 8 but has 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 fonts, some of which have no PXL file\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
\enddisplay
Type `|dv tripvdu|'
and go through all the pages to verify that the program is working correctly.
You may need to specify a |-v| value to tell |dv| what type of terminal
you're using.
See the {\sl \DVItoVDU\ User Guide} for details on
what |-v| values are available and the special requirements of some VDUs.

\noindent
If a catastrophe occurs and \DVItoVDU\ actually crashes, please report
the problem back to me.  If the reason for the crash is not obvious,
and you have a Modula-2 compiler, you might try to rebuild |dv| after
editing the |.mod| files that contain debugging code.
Change all comments of the form |(* DEBUG ... GUBED *)| to
|(* DEBUG *) ... (* GUBED *)|.
Only a few modules have such code; use `|grep DEBUG *.mod|' to list them.
The extra code might provide additional clues as to what is going wrong.

\subhead{Revision history.}

\noindent
Version 1.0 of \DVItoVDU\ for VAX/UNIX is based on
version 1.5 for VAX/VMS (TUGboat vol.~7 no.~1 has an article
describing the VMS version).  The UNIX version is virtually identical
as far as the user is concerned.  The command option syntax is a little
different of course, and there are a couple of new VDU types,
but the interactive commands are exactly the same.

\noindent
A few improvements have been made to the UNIX version:

\item{$\bullet$}
Whenever a |\special| command is ignored, the first few bytes are
displayed in case some users need to see them.

\item{$\bullet$}
While updating the window region, the main module uses
|BusyRead| from |ScreenIO| to check for user input
after drawing each visible rule or character.
(The VMS version checked after every 8th rule or character; the overheads
for |BusyRead| seem to be much less under UNIX.)

\item{$\bullet$}
|ScreenIO| required significant changes to be able to handle
some of the more useful UNIX interrupts:
|^C| can be used to return quickly to the `|Command:|' level, and
|^Z| can be used to suspend |dv|.
(Thanks to Alex Dickinson who wrote the necessary |unixio.c| routines.)
These interrupts are only detected during |Read|, |ReadString| and
|BusyRead|.

\finishline
\bye
DataMuseum.dk

DKUUG/EUUG Conference tapes

⟦eb4bc2503⟧ TextFile

Derivation

TextFile
