\def\sect#1{\smallskip{\bf\leftline{#1}}\par\noindent\ignorespaces}
\centerline{\bf Preview in the Public Domain}
\medskip\noindent
This note describes a previewing system for \TeX\ on an {\sc ibm-pc} with a Hercules 
compatible graphics screen. 
The system is implemented as a pair of programs --- the first program creating 
the bitmap file for the screen and the second displaying it.  

\sect{Background}
The incentive for writing this tool was to allow me to preview the
\TeX\ |.dvi| files from the  {\sc c-tex} program 
written by Pat Monardo.
Having established that {\sc c-tex} worked in a {\sc pc-dos} environment, there was no 
way of examining the output on the screen without paying out hard cash for a 
commercial previewer.

The main priority in deciding how to implement a previewing system was that 
while the time taken to generate the |.dvi| and other intermediate files was to 
a certain extent immaterial, the speed of viewing of the output should be 
dictated by the user, rather than be restrained by the computational 
processing ability of the {\sc pc}.
My initial experiments with {\sc c-tex} showed that processing 
\TeX\  files was a fairly leisurely process on an {\sc xt}-class machine. The 
cpu-bound nature of the task was all the more apparent with the 
Beebe (University of Utah)
|dvi| driver code generating a bit map output.
Thus generating the screen in real-time could be intolerably slow. The notion 
of a post-previewer was formed.

The Beebe Apple Imagewriter driver is used as a base for the screen driver, as 
both the screen and that particular printer require a bit-mapped file.
The modifications required to convert to a new output format were minor. 
The new derivitive of the device driver is called {\sc dviherc}.

The prototype of the screen viewing program was a very crude minimal 
implementation. It just displayed a screen's worth at a time. A resolution of 
92 dpi was originally tried which would allow an A4 page to be represented as 
$n$ screens deep by one screen wide. Unfortunately however, the 
{\sc cmr\oldstyle10} font 
generated at that resolution was too squiggly --- any resemblance 
between this and the 300 dpi version was entirely accidental.  
As the Hercules card is capable of holding two screens in its display buffer,
it seemed logical to double the resolution by displaying a page as {\it n}
screens deep by two screens wide. With the two screens in the card's buffer, the
display could be flipped between the left and right halves of the page
virtually instantaneously. The modifications to both {\sc dviherc} and
{\sc hview} ({\sc texview}'s prototype) to allow this were
trivial.  The image quality at 174 dpi (the nearest legal setting to 180) was
vastly  superior to the previous test.


\sect{The system}
The previewer system is a tool developed for my own use of \TeX\ developed 
mostly in my spare time. The only screen adapter supported is the Hercules 
monochrome graphics type. To make the system portable I have removed the 
dependency of the pilot program for the Hercules {\sc graphx} toolkit utility.
{\sc texview} is not restricted to displaying files produced by 
{\sc dviherc}; any picture graphics files can be displayed so long as they conform 
to the file format used.

\sect{Description of {\sc texview}}
Upon loading, the program allocates all the available memory of the {\sc pc} for 
cache buffers. The aim of this is twofold.
Firstly, the file reader task within the program attempts to be two pages 
ahead of the screen. 
Pressing any key to activate a command will interrupt the file reader almost 
immediately.
If part of the file is already in the memory then the 
time writing a new screen is minimised. On a typical {\sc pc-xt} clone the screen 
update time takes about one second.
Secondly, a limited amount of reverse scrolling is possible if the cache data 
has not been overwritten. On a {\sc pc} with 640\,Kbytes of memory the screen can be 
rolled back by about four pages.

In addition to the file `cache' the program uses two tables. One is used to
hold the cache locations of the page boundaries seen, and the other to hold the
locations of the screen boundaries within the current page. 

A user normally views the file by moving down a screenful at a time. Whilst he 
is doing this the page and screen location descriptor tables are being built 
up. For explanation purposes, the furthest point down the file reached by 
moving a screenful at a time is known as the endpoint.
These tables enable a user to move backwards by either a screenful at a time 
until the top of the current page is reached, or directly to the start of the 
current page, or to the start of the previous page (assuming that it still 
exists within the cache).
Once the user has moved back, he can move forward either by pages until the 
endpoint has been reached, or normally by the screenful. 
Thus a limited amount of movement from the current page is possible.

The horizontal and vertical overlaps between screens are initially zero 
pixels. These can be set to any reasonable values to aid in legibility when 
viewing a file. If the horizontal overlap is changed, it is rounded to a 
multiple of eight pixels in order to eliminate bit shifting.

\sect{Using the system on a {\sc pc-xt}}
The usual cycle of commands in revising a document (analogous to the compile, 
load and fail process when programming) is:

\line{\quad{\sc virtex \it file}  \hfil create a {\tt .dvi} file} 
\line{\quad{\sc dviherc \it file \tt -m868}\hfil  create a screen pixel file}
\line{\quad{\sc texview \it file}\hfil  view it}

\sect{{\sc texview's} limitations}
This implementation is certainly not frugal in its use of disc storage. 
The set of {\tt .gf} files for magnifications up to magstep 2.0 occupy around 
3\,Mbyte of disc space. The pixel files produced by {\sc dviherc} average around 100\,Kbyte 
per full page of text.
{\sc texview} has some design limitations which I do not consider important
(because they don't affect me). These are detailed below.  

The screen descriptor tables are of a finite length. Thus should the vertical 
overlap value be set to too high a value then reverse scrolling within a page 
will be inaccurate.
A similar effect can be noticed with the page descriptor table. The length of 
this is such, that in normal circumstances the limiting factor for 
the number of pages that can be backscrolled is determined by the size of the 
cache area. However, if the pages are very short then the descriptor table 
would fill before the cache.  

The screen is reset to the left side after any screen movement. This could be 
annoying for a user working in two-column mode. The obvious remedy is to 
incorporate an additional command to enable or disable this effect.

If the vertical overlap parameter is changed, then scrolling back by 
screenfuls uses the value in force when the forward movements were executed 
rather than the new value.

A user cannot skip ahead either a page at a time (once the endpoint has been 
reached) or to a specified page. Considering the profligate amount of disc 
space used by the pixel files, the lack of such facilities is probably not of 
consequence.

\sect{Obtaining a copy}
Peter Abbott will be putting the set of files (sources, executables, |gf|s, and 
threadbare installation and operating documentation) into the Aston 
University \TeX-archive. 
An announcement will be made in the {\sc uktex} electronic bulletin when the files are
available.
For people not connected to {\sc janet} I would be willing to write the files to a 
set of supplied preformatted 1.2\,Mbyte or 360\,Kbyte diskettes.

\sect{Support}
Any bug reports would be welcome, as would suggestions for improving the 
viewing facilities. However, implementation of enhancements could be fairly 
slow in execution as work on this project is mostly undertaken in my spare 
time.  


\rightline{\sl Laurie Benfield}