diff options
author | Norbert Preining <norbert@preining.info> | 2019-09-02 13:46:59 +0900 |
---|---|---|
committer | Norbert Preining <norbert@preining.info> | 2019-09-02 13:46:59 +0900 |
commit | e0c6872cf40896c7be36b11dcc744620f10adf1d (patch) | |
tree | 60335e10d2f4354b0674ec22d7b53f0f8abee672 /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.tex | 151 |
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} + |