summaryrefslogtreecommitdiff
path: root/info/digests/texline/no7/laurie.tex
diff options
context:
space:
mode:
authorNorbert Preining <norbert@preining.info>2019-09-02 13:46:59 +0900
committerNorbert Preining <norbert@preining.info>2019-09-02 13:46:59 +0900
commite0c6872cf40896c7be36b11dcc744620f10adf1d (patch)
tree60335e10d2f4354b0674ec22d7b53f0f8abee672 /info/digests/texline/no7/laurie.tex
Initial commit
Diffstat (limited to 'info/digests/texline/no7/laurie.tex')
-rw-r--r--info/digests/texline/no7/laurie.tex151
1 files changed, 151 insertions, 0 deletions
diff --git a/info/digests/texline/no7/laurie.tex b/info/digests/texline/no7/laurie.tex
new file mode 100644
index 0000000000..d5bfc08682
--- /dev/null
+++ b/info/digests/texline/no7/laurie.tex
@@ -0,0 +1,151 @@
+\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}
+