summaryrefslogtreecommitdiff
path: root/dviware/driv-standard
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 /dviware/driv-standard
Initial commit
Diffstat (limited to 'dviware/driv-standard')
-rw-r--r--dviware/driv-standard/level-0/dvi.tex570
-rw-r--r--dviware/driv-standard/level-0/dvistd0.dvibin0 -> 141268 bytes
-rw-r--r--dviware/driv-standard/level-0/dvistd0.pdfbin0 -> 273745 bytes
-rw-r--r--dviware/driv-standard/level-0/dvistd0.tex886
-rw-r--r--dviware/driv-standard/level-0/fileform.sty579
-rw-r--r--dviware/driv-standard/level-0/gf.tex381
-rw-r--r--dviware/driv-standard/level-0/pk.tex606
-rw-r--r--dviware/driv-standard/level-0/tfm.tex391
-rw-r--r--dviware/driv-standard/papers/alltt.sty32
-rw-r--r--dviware/driv-standard/papers/draft-8904-tub.tex57
-rw-r--r--dviware/driv-standard/papers/draft-8907-tub.tex434
-rw-r--r--dviware/driv-standard/papers/dvistd.bib128
-rw-r--r--dviware/driv-standard/papers/high-quality-dvi-drivers.tex1328
-rw-r--r--dviware/driv-standard/papers/report-9105-tub.tex100
-rw-r--r--dviware/driv-standard/papers/report-9106-board.tex607
-rw-r--r--dviware/driv-standard/papers/special-beebe-1.02/bibnames.sty149
-rw-r--r--dviware/driv-standard/papers/special-beebe-1.02/pathname.tex54
-rw-r--r--dviware/driv-standard/papers/special-beebe-1.02/special.bib344
-rw-r--r--dviware/driv-standard/papers/special-beebe-1.02/special.sty65
-rw-r--r--dviware/driv-standard/papers/special-beebe-1.02/special.tex1491
-rw-r--r--dviware/driv-standard/papers/special-hosek.tex653
21 files changed, 8855 insertions, 0 deletions
diff --git a/dviware/driv-standard/level-0/dvi.tex b/dviware/driv-standard/level-0/dvi.tex
new file mode 100644
index 0000000000..acff75ceb0
--- /dev/null
+++ b/dviware/driv-standard/level-0/dvi.tex
@@ -0,0 +1,570 @@
+% $Id: dvi.tex,v 3.4.1.1 1991/08/08 16:03:50 schrod Released schrod $
+%------------------------------------------------------------
+% taken from DVItype 3.4
+
+%
+% definition of DVI format
+% LaTeX markup
+%
+
+
+% $Log: dvi.tex,v $
+% Revision 3.4.1.1 1991/08/08 16:03:50 schrod
+% CHANGES BY DON HOSEK:
+% -- Inserted \subsection's.
+% -- Deleted WEB defines.
+% -- `e.g.' now in italics, to be consistent with the rest of the
+% standard.
+%
+% CHANGES BY JOACHIM SCHROD:
+% -- Changed \bigbreak between WEB sections to \medbreak.
+% -- Added + signs to length specifications in \cmd tags, to show that
+% the param is signed.
+% -- Make formulas look more `math-like' and less `Pascal-like.'
+% -- DVItype not mentioned any more in the text.
+%
+% Revision 3.4 1990/10/31 00:00:00 schrod
+% updated from DVItype 3.2 to 3.4
+%
+% Revision 3.2.1.1 90/07/16 00:00:00 schrod
+% inserted \endinput
+%
+% Revision 3.2 90/07/04 00:00:00 schrod
+% extracted from DVItype 3.2
+%
+
+
+
+
+\section{Device-Independent File Format}
+\label{dvi-format}
+
+\subsection{Introduction}
+
+The form of \str{DVI} files was designed by {\sc David R. Fuchs} in
+1979. Almost any reasonable typesetting device can be driven by a
+program that takes \str{DVI} files as input, and a lot of such
+\str{DVI}-to-whatever programs have been written. Thus, it is
+possible to print the output of document compilers like \TeX\ on many
+different kinds of equipment.
+
+A \str{DVI} file is a stream of 8-bit bytes, which may be regarded as
+a series of commands in a machine-like language. The first byte of
+each command is the operation code, and this code is followed by zero
+or more bytes that provide parameters to the command. The parameters
+themselves may consist of several consecutive bytes; for example, the
+`\id{set\_rule}' command has two parameters, each of which is four
+bytes long. Parameters are usually regarded as nonnegative integers;
+but four-byte-long parameters, and shorter parameters that denote
+distances, can be either positive or negative. Such parameters are
+given in two's complement notation. For example, a two-byte-long
+distance parameter has a value between $-2^{15}$ and $2^{15}-1$.
+
+A \str{DVI} file consists of a ``preamble,'' followed by a sequence
+of one or more ``pages,'' followed by a ``postamble.'' The preamble
+is simply a \id{pre} command, with its parameters that define the
+dimensions used in the file; this must come first. Each ``page''
+consists of a \id{bop} command, followed by any number of other
+commands that tell where characters are to be placed on a physical
+page, followed by an \id{eop} command. The pages appear in the order
+that they were generated, not in any particular numerical order. If
+we ignore \id{nop} commands and \id{fnt\_def} commands (which are
+allowed between any two commands in the file), each \id{eop} command
+is immediately followed by a \id{bop} command, or by a \id{post}
+command; in the latter case, there are no more pages in the file, and
+the remaining bytes form the postamble. Further details about the
+postamble will be explained later.
+
+Some parameters in \str{DVI} commands are ``pointers.'' These are
+four-byte quantities that give the location number of some other byte
+in the file; the first byte is number~0, then comes number~1, and so
+on. For example, one of the parameters of a \id{bop} command points
+to the previous \id{bop}; this makes it feasible to read the pages in
+backwards order, in case the results are being directed to a device
+that stacks its output face up. Suppose the preamble of a \str{DVI}
+file occupies bytes 0 to 99. Now if the first page occupies bytes 100
+to 999, say, and if the second page occupies bytes 1000 to 1999, then
+the \id{bop} that starts in byte 1000 points to 100 and the \id{bop}
+that starts in byte 2000 points to 1000. (The very first \id{bop},
+i.e., the one that starts in byte 100, has a pointer of $-1$.)
+
+\medbreak
+
+The \str{DVI} format is intended to be both compact and easily
+interpreted by a machine. Compactness is achieved by making most of
+the information implicit instead of explicit. When a
+\str{DVI}-reading program reads the commands for a page, it keeps
+track of several quantities: (a)~The current font $f$ is an integer;
+this value is changed only by \id{fnt} and \id{fnt\_num} commands.
+(b)~The current position on the page is given by two numbers called
+the horizontal and vertical coordinates, $h$ and $v$. Both
+coordinates are zero at the upper left corner of the page; moving to
+the right corresponds to increasing the horizontal coordinate, and
+moving down corresponds to increasing the vertical coordinate. Thus,
+the coordinates are essentially Cartesian, except that vertical
+directions are flipped; the Cartesian version of $(h,v)$ would be
+$(h,-v)$. (c)~The current spacing amounts are given by four numbers
+$w$, $x$, $y$, and $z$, where $w$ and~$x$ are used for horizontal
+spacing and where $y$ and~$z$ are used for vertical spacing.
+(d)~There is a stack containing $(h,v,w,x,y,z)$ values; the \str{DVI}
+commands \id{push} and \id{pop} are used to change the current level
+of operation. Note that the current font~$f$ is not pushed and
+popped; the stack contains only information about positioning.
+
+The values of $h$, $v$, $w$, $x$, $y$, and $z$ are signed integers
+having up to 32 bits, including the sign. Since they represent
+physical distances, there is a small unit of measurement such that
+increasing $h$ by~1 means moving a certain tiny distance to the
+right. The actual unit of measurement is variable, as explained
+below.
+
+
+
+\subsection{Summary of {\tt DVI} commands}
+
+Here is a list of all the commands that may appear in a \str{DVI}
+file. Each command is specified by its symbolic name ({\it e.g.},
+\id{bop}), its opcode byte ({\it e.g.}, 139), and its parameters (if any).
+The parameters are followed by a bracketed number telling how many
+bytes they occupy; for example, `$p[4]$' means that parameter $p$ is
+four bytes long.
+
+\cmd \id{set\_char\_0} 0,.
+ Typeset character number~0 from font~$f$ such that the reference
+point of the character is at $(h,v)$. Then increase $h$ by the width
+of that character. Note that a character may have zero or negative
+width, so one cannot be sure that $h$ will advance after this
+command; but $h$ usually does increase.
+
+\cmd \id{set\_char\_1} through \id{set\_char\_127} (opcodes 1 to 127),.
+ Do the operations of \id{set\_char\_0}; but use the character whose
+number matches the opcode, instead of character~0.
+
+\cmd \id{set1} 128, c[1].
+ Same as \id{set\_char\_0}, except that character number~$c$ is
+typeset. \TeX82 uses this command for characters in the range $128\le
+c<256$.
+
+\cmd \id{set2} 129, c[2].
+ Same as \id{set1}, except that $c$~is two bytes long, so it is in
+the range $0\le c<65536$. \TeX82 never uses this command, which is
+intended for processors that deal with oriental languages; but a
+\DVI{} processor should allow character codes greater than 255. The
+processor may then assume that these characters have the same width
+as the character whose respective codes are $c \bmod 256$.
+
+\cmd \id{set3} 130, c[3].
+ Same as \id{set1}, except that $c$~is three bytes long, so it can be
+as large as $2^{24}-1$.
+
+\cmd \id{set4} 131, c[+4].
+ Same as \id{set1}, except that $c$~is four bytes long, possibly even
+negative. Imagine that.
+
+\cmd \id{set\_rule} 132, a[+4] b[+4].
+ Typeset a solid black rectangle of height $a$ and width $b$, with
+its bottom left corner at $(h,v)$. Then set $h\gets h+b$. If either
+$a\le 0$ or $b\le 0$, nothing should be typeset. Note that if $b<0$,
+the value of $h$ will decrease even though nothing else happens.
+Programs that typeset from \str{DVI} files should be careful to make
+the rules line up carefully with digitized characters, as explained
+in connection with the \id{rule\_pixels} subroutine below.
+
+\cmd \id{put1} 133, c[1].
+ Typeset character number~$c$ from font~$f$ such that the reference
+point of the character is at $(h,v)$. (The `put' commands are exactly
+like the `set' commands, except that they simply put out a character
+or a rule without moving the reference point afterwards.)
+
+\cmd \id{put2} 134, c[2].
+ Same as \id{set2}, except that $h$ is not changed.
+
+\cmd \id{put3} 135, c[3].
+ Same as \id{set3}, except that $h$ is not changed.
+
+\cmd \id{put4} 136, c[+4].
+ Same as \id{set4}, except that $h$ is not changed.
+
+\cmd \id{put\_rule} 137, a[+4] b[+4].
+ Same as \id{set\_rule}, except that $h$ is not changed.
+
+\cmd \id{nop} 138,.
+ No operation, do nothing. Any number of \id{nop}'s may occur between
+\str{DVI} commands, but a \id{nop} cannot be inserted between a
+command and its parameters or between two parameters.
+
+\cmd \id{bop} 139, c_0[+4] c_1[+4] \ldots c_9[+4] p[+4].
+ Beginning of a page: Set $(h,v,w,x,y,z)\gets (0,0,0,0,0,0)$ and set
+the stack empty. Set the current font $f$ to an undefined value. The
+ten $c_i$ parameters can be used to identify pages, if a user wants
+to print only part of a \str{DVI} file; \TeX82 gives them the values
+of \str{\\count0} $\ldots$ \str{\\count9} at the time \str{\\shipout}
+was invoked for this page. The parameter $p$ points to the previous
+\id{bop} command in the file, where the first \id{bop} has $p=-1$.
+
+\cmd \id{eop} 140,.
+ End of page: Print what you have read since the previous \id{bop}.
+At this point the stack should be empty.
+
+\cmd \id{push} 141,.
+ Push the current values of $(h,v,w,x,y,z)$ onto the top of the
+stack; do not change any of these values. Note that $f$ is not
+pushed.
+
+\cmd \id{pop} 142,.
+ Pop the top six values off of the stack and assign them to
+$(h,v,w,x,y,z)$. The number of pops should never exceed the number of
+pushes, since it would be highly embarrassing if the stack were empty
+at the time of a \id{pop} command.
+
+\cmd \id{right1} 143, b[+1].
+ Set $h\gets h+b$, i.e., move right $b$ units. The parameter is a
+signed number in two's complement notation, $-128\le b<128$; if
+$b<0$, the reference point actually moves left.
+
+\cmd \id{right2} 144, b[+2].
+ Same as \id{right1}, except that $b$ is a two-byte quantity in the
+range $-32768\le b<32768$.
+
+\cmd \id{right3} 145, b[+3].
+ Same as \id{right1}, except that $b$ is a three-byte quantity in the
+range $-2^{23}\le b<2^{23}$.
+
+\cmd \id{right4} 146, b[+4].
+ Same as \id{right1}, except that $b$ is a four-byte quantity in the
+range $-2^{31}\le b<2^{31}$.
+
+\cmd \id{w0} 147,.
+ Set $h\gets h+w$; i.e., move right $w$ units. With luck, this
+parameterless command will usually suffice, because the same kind of
+motion will occur several times in succession; the following commands
+explain how $w$ gets particular values.
+
+\cmd \id{w1} 148, b[+1].
+ Set $w\gets b$ and $h\gets h+b$. The value of $b$ is a signed
+quantity in two's complement notation, $-128\le b<128$. This command
+changes the current $w$~spacing and moves right by $b$.
+
+\cmd \id{w2} 149, b[+2].
+ Same as \id{w1}, but $b$ is a two-byte-long parameter, $-32768\le
+b<32768$.
+
+\cmd \id{w3} 150, b[+3].
+ Same as \id{w1}, but $b$ is a three-byte-long parameter, $-2^{23}\le
+b<2^{23}$.
+
+\cmd \id{w4} 151, b[+4].
+ Same as \id{w1}, but $b$ is a four-byte-long parameter, $-2^{31}\le
+b<2^{31}$.
+
+\cmd \id{x0} 152,.
+ Set $h\gets h+x$; i.e., move right $x$ units. The `$x$' commands are
+like the `$w$' commands except that they involve $x$ instead of $w$.
+
+\cmd \id{x1} 153, b[+1].
+ Set $x\gets b$ and $h\gets h+b$. The value of $b$ is a signed
+quantity in two's complement notation, $-128\le b<128$. This command
+changes the current $x$~spacing and moves right by $b$.
+
+\cmd \id{x2} 154, b[+2].
+ Same as \id{x1}, but $b$ is a two-byte-long parameter, $-32768\le
+b<32768$.
+
+\cmd \id{x3} 155, b[+3].
+ Same as \id{x1}, but $b$ is a three-byte-long parameter, $-2^{23}\le
+b<2^{23}$.
+
+\cmd \id{x4} 156, b[+4].
+ Same as \id{x1}, but $b$ is a four-byte-long parameter, $-2^{31}\le
+b<2^{31}$.
+
+\cmd \id{down1} 157, a[+1].
+ Set $v\gets v+a$, i.e., move down $a$ units. The parameter is a
+signed number in two's complement notation, $-128\le a<128$; if
+$a<0$, the reference point actually moves up.
+
+\cmd \id{down2} 158, a[+2].
+ Same as \id{down1}, except that $a$ is a two-byte quantity in the
+range $-32768\le a<32768$.
+
+\cmd \id{down3} 159, a[+3].
+ Same as \id{down1}, except that $a$ is a three-byte quantity in the
+range $-2^{23}\le a<2^{23}$.
+
+\cmd \id{down4} 160, a[+4].
+ Same as \id{down1}, except that $a$ is a four-byte quantity in the
+range $-2^{31}\le a<2^{31}$.
+
+\cmd \id{y0} 161,.
+ Set $v\gets v+y$; i.e., move down $y$ units. With luck, this
+parameterless command will usually suffice, because the same kind of
+motion will occur several times in succession; the following commands
+explain how $y$ gets particular values.
+
+\cmd \id{y1} 162, a[+1].
+ Set $y\gets a$ and $v\gets v+a$. The value of $a$ is a signed
+quantity in two's complement notation, $-128\le a<128$. This command
+changes the current $y$~spacing and moves down by $a$.
+
+\cmd \id{y2} 163, a[+2].
+ Same as \id{y1}, but $a$ is a two-byte-long parameter, $-32768\le
+a<32768$.
+
+\cmd \id{y3} 164, a[+3].
+ Same as \id{y1}, but $a$ is a three-byte-long parameter, $-2^{23}\le
+a<2^{23}$.
+
+\cmd \id{y4} 165, a[+4].
+ Same as \id{y1}, but $a$ is a four-byte-long parameter, $-2^{31}\le
+a<2^{31}$.
+
+\cmd \id{z0} 166,.
+ Set $v\gets v+z$; i.e., move down $z$ units. The `$z$' commands are
+like the `$y$' commands except that they involve $z$ instead of $y$.
+
+\cmd \id{z1} 167, a[+1].
+ Set $z\gets a$ and $v\gets v+a$. The value of $a$ is a signed
+quantity in two's complement notation, $-128\le a<128$. This command
+changes the current $z$~spacing and moves down by $a$.
+
+\cmd \id{z2} 168, a[+2].
+ Same as \id{z1}, but $a$ is a two-byte-long parameter, $-32768\le
+a<32768$.
+
+\cmd \id{z3} 169, a[+3].
+ Same as \id{z1}, but $a$ is a three-byte-long parameter, $-2^{23}\le
+a<2^{23}$.
+
+\cmd \id{z4} 170, a[+4].
+ Same as \id{z1}, but $a$ is a four-byte-long parameter, $-2^{31}\le
+a<2^{31}$.
+
+\cmd \id{fnt\_num\_0} 171,.
+ Set $f\gets 0$. Font 0 must previously have been defined by a
+\id{fnt\_def} instruction, as explained below.
+
+\cmd \id{fnt\_num\_1} through \id{fnt\_num\_63} (opcodes 172 to 234),.
+ Set $f\gets 1$, \dots, $f\gets 63$, respectively.
+
+\cmd \id{fnt1} 235, k[1].
+ Set $f\gets k$. \TeX82 uses this command for font numbers in the
+range $64\le k<256$.
+
+\cmd \id{fnt2} 236, k[2].
+ Same as \id{fnt1}, except that $k$~is two bytes long, so it is in
+the range $0\le k<65536$. \TeX82 never generates this command, but
+large font numbers may prove useful for specifications of color or
+texture, or they may be used for special fonts that have fixed
+numbers in some external coding scheme.
+
+\cmd \id{fnt3} 237, k[3].
+ Same as \id{fnt1}, except that $k$~is three bytes long, so it can be
+as large as $2^{24}-1$.
+
+\cmd \id{fnt4} 238, k[+4].
+ Same as \id{fnt1}, except that $k$~is four bytes long; this is for
+the really big font numbers (and for the negative ones).
+
+\cmd \id{xxx1} 239, k[1] x[k].
+ This command is undefined in general; it functions as a $(k+2)$-byte
+\id{nop} unless special \str{DVI}-reading programs are being used.
+\TeX82 generates \id{xxx1} when a short enough \str{\\special}
+appears, setting $k$ to the number of bytes being sent. It is
+recommended that $x$ be a string having the form of a keyword
+followed by possible parameters relevant to that keyword.
+
+\cmd \id{xxx2} 240, k[2] x[k].
+ Like \id{xxx1}, but $0\le k<65536$.
+
+\cmd \id{xxx3} 241, k[3] x[k].
+ Like \id{xxx1}, but $0\le k<2^{24}$.
+
+\cmd \id{xxx4} 242, k[4] x[k].
+ Like \id{xxx1}, but $k$ can be ridiculously large. \TeX82 uses
+\id{xxx4} when \id{xxx1} would be incorrect.
+
+\cmd \id{fnt\_def1} 243, k[1] c[4] s[4] d[4] a[1] l[1] n[a+l].
+ Define font $k$, where $0\le k<256$; font definitions will be
+explained shortly.
+
+\cmd \id{fnt\_def2} 244, k[2] c[4] s[4] d[4] a[1] l[1] n[a+l].
+ Define font $k$, where $0\le k<65536$.
+
+\cmd \id{fnt\_def3} 245, k[3] c[4] s[4] d[4] a[1] l[1] n[a+l].
+ Define font $k$, where $0\le k<2^{24}$.
+
+\cmd \id{fnt\_def4} 246, k[+4] c[4] s[4] d[4] a[1] l[1] n[a+l].
+ Define font $k$, where $-2^{31}\le k<2^{31}$.
+
+\cmd \id{pre} 247, i[1] \id{num}[4] \id{den}[4] \id{mag}[4] k[1] x[k].
+ Beginning of the preamble; this must come at the very beginning of
+the file. Parameters $i$, \id{num}, \id{den}, \id{mag}, $k$, and $x$
+are explained below.
+
+\cmd \id{post} 248,.
+ Beginning of the postamble, see below.
+
+\cmd \id{post\_post} 249,.
+ Ending of the postamble, see below.
+
+\smallskip
+
+\noindent Commands 250--255 are undefined at the present time.
+
+
+
+\subsection{The preamble}
+
+The preamble contains basic information about the file as a whole. As
+stated above, there are six parameters:
+ $$
+ i[1]\ \id{num}[4]\ \id{den}[4]\ \id{mag}[4]\ k[1]\ x[k].
+ $$
+ The $i$ byte identifies \str{DVI} format; currently this byte is
+always set to~2. (The value $i=3$ is currently used for an extended
+format that allows a mixture of right-to-left and left-to-right
+typesetting. Some day we will set $i=4$, when \str{DVI} format makes
+another incompatible change---perhaps in the year 2048.)
+
+The next two parameters, \id{num} and \id{den}, are positive integers
+that define the units of measurement; they are the numerator and
+denominator of a fraction by which all dimensions in the \str{DVI}
+file could be multiplied in order to get lengths in units of
+$10^{-7}$ meters. (For example, there are exactly 7227 \TeX\ points
+in 254 centimeters, and \TeX82 works with scaled points where there
+are $2^{16}$ sp in a point, so \TeX82 sets $\id{num}=25400000$ and
+$\id{den}= 7227 \cdot 2^{16} =473628672$.)
+
+The \id{mag} parameter is what \TeX82 calls \str{\\mag}, i.e., 1000
+times the desired magnification. The actual fraction by which
+dimensions are multiplied is therefore $mn/1000d$. Note that if a
+\TeX\ source document does not call for any `\str{true}' dimensions,
+and if you change it only by specifying a different \str{\\mag}
+setting, the \str{DVI} file that \TeX\ creates will be completely
+unchanged except for the value of \id{mag} in the preamble and
+postamble. (Fancy \str{DVI}-reading programs allow users to override
+the \id{mag}~setting when a \str{DVI} file is being printed.)
+
+Finally, $k$ and $x$ allow the \str{DVI} writer to include a comment,
+which is not interpreted further. The length of comment $x$ is $k$,
+where $0\le k<256$.
+
+
+
+\subsection{Font definitions}
+
+Font definitions for a given font number $k$ contain further
+parameters
+ $$
+ c[4]\ s[4]\ d[4]\ a[1]\ l[1]\ n[a+l].
+ $$
+ The four-byte value $c$ is the check sum that \TeX\ (or whatever
+program generated the \str{DVI} file) found in the \str{TFM} file for
+this font; $c$ should match the check sum of the font found by
+programs that read this \str{DVI} file.
+
+Parameter $s$ contains a fixed-point scale factor that is applied to
+the character widths in font $k$; font dimensions in \str{TFM} files
+and other font files are relative to this quantity, which is always
+positive and less than $2^{27}$. It is given in the same units as the
+other dimensions of the \str{DVI} file. Parameter $d$ is similar to
+$s$; it is the ``design size,'' and (like~$s$) it is given in
+\str{DVI} units. Thus, font $k$ is to be used at
+$\id{mag} \cdot s/1000d$ times its normal size.
+
+The remaining part of a font definition gives the external name of
+the font, which is an ASCII string of length $a+l$. The number $a$ is
+the length of the ``area'' or directory, and $l$ is the length of the
+font name itself; the standard local system font area is supposed to
+be used when $a=0$. The $n$ field contains the area in its first $a$
+bytes.
+
+Font definitions must appear before the first use of a particular
+font number. Once font $k$ is defined, it must not be defined again;
+however, we shall see below that font definitions appear in the
+postamble as well as in the pages, so in this sense each font number
+is defined exactly twice, if at all. Like \id{nop} commands,
+font definitions can appear before the first
+\id{bop}, or between an \id{eop} and a \id{bop}.
+
+
+
+\subsection{The postamble}
+
+The last page in a \str{DVI} file is followed by `\id{post}'; this
+command introduces the postamble, which summarizes important facts
+that \TeX\ has accumulated about the file, making it possible to
+print subsets of the data with reasonable efficiency. The postamble
+has the form
+%
+ \begin{center}
+ \begin{tabular}{l}
+ $\id{post}\ p[4]\ \id{num}[4]\ \id{den}[4]\ \id{mag}[4]\
+ l[4]\ u[4]\ s[2]\ t[2]$\\
+ $\langle\,$font definitions$\,\rangle$\cr
+ $\id{post\_post}\ q[4]\ i[1]\ \hbox{223's}[\ge 4]$\\
+ \end{tabular}
+ \end{center}
+%
+ Here $p$ is a pointer to the final \id{bop} in the file. The next
+three parameters, \id{num}, \id{den}, and \id{mag}, are duplicates of
+the quantities that appeared in the preamble.
+
+Parameters $l$ and $u$ give respectively the height-plus-depth of the
+tallest page and the width of the widest page, in the same units as
+other dimensions of the file. These numbers might be used by a
+\str{DVI}-reading program to position individual ``pages'' on large
+sheets of film or paper; however, the standard convention for output
+on normal size paper is to position each page so that the upper
+left-hand corner is exactly one inch from the left and the top.
+Experience has shown that it is unwise to design \str{DVI}-to-printer
+software that attempts cleverly to center the output; a fixed
+position of the upper left corner is easiest for users to understand
+and to work with. Therefore $l$ and~$u$ are often ignored.
+
+Parameter $s$ is the maximum stack depth (i.e., the largest excess of
+\id{push} commands over \id{pop} commands) needed to process this
+file. Then comes $t$, the total number of pages (\id{bop} commands)
+present.
+
+The postamble continues with font definitions, which are any number
+of \id{fnt\_def} commands as described above, possibly interspersed
+with \id{nop} commands. Each font number that is used in the
+\str{DVI} file must be defined exactly twice: Once before it is first
+selected by a \id{fnt} command, and once in the postamble.
+
+\medbreak
+
+The last part of the postamble, following the \id{post\_post} byte
+that signifies the end of the font definitions, contains $q$, a
+pointer to the \id{post} command that started the postamble. An
+identification byte, $i$, comes next; this currently equals~2, as in
+the preamble.
+
+The $i$ byte is followed by four or more bytes that are all equal to
+the decimal number 223 (i.e., \O{337} in octal). \TeX\ puts out four
+to seven of these trailing bytes, until the total length of the file
+is a multiple of four bytes, since this works out best on machines
+that pack four bytes per word; but any number of 223's is allowed, as
+long as there are at least four of them. In effect, 223 is a sort of
+signature that is added at the very end.
+
+This curious way to finish off a \str{DVI} file makes it feasible for
+\str{DVI}-reading programs to find the postamble first, on most
+computers, even though \TeX\ wants to write the postamble last. Most
+operating systems permit random access to individual words or bytes
+of a file, so the \str{DVI} reader can start at the end and skip
+backwards over the 223's until finding the identification byte. Then
+it can back up four bytes, read $q$, and move to byte $q$ of the
+file. This byte should, of course, contain the value 248 (\id{post});
+now the postamble can be read, so the \str{DVI} reader discovers all
+the information needed for typesetting the pages. Note that it is
+also possible to skip through the \str{DVI} file at reasonably high
+speed to locate a particular page, if that proves desirable. This
+saves a lot of time, since \str{DVI} files used in production jobs
+tend to be large.
+
+
+
+
+\endinput
diff --git a/dviware/driv-standard/level-0/dvistd0.dvi b/dviware/driv-standard/level-0/dvistd0.dvi
new file mode 100644
index 0000000000..ff870d5e06
--- /dev/null
+++ b/dviware/driv-standard/level-0/dvistd0.dvi
Binary files differ
diff --git a/dviware/driv-standard/level-0/dvistd0.pdf b/dviware/driv-standard/level-0/dvistd0.pdf
new file mode 100644
index 0000000000..5bc00d2ca3
--- /dev/null
+++ b/dviware/driv-standard/level-0/dvistd0.pdf
Binary files differ
diff --git a/dviware/driv-standard/level-0/dvistd0.tex b/dviware/driv-standard/level-0/dvistd0.tex
new file mode 100644
index 0000000000..8b1814d274
--- /dev/null
+++ b/dviware/driv-standard/level-0/dvistd0.tex
@@ -0,0 +1,886 @@
+% $Id: dvistd0.tex,v 5.1 1991/08/06 15:12:07 schrod Released schrod $
+%----------------------------------------------------------------------
+
+%
+% The TUG DVI driver standards committee:
+%
+% DVI driver standard, level 0
+%
+% [LaTeX with ltugboat, fileform]
+
+
+%
+% Revision history at end, search for $Log
+%
+% Editorial remarks and hints, and a special style option are about
+% to be written,
+
+
+
+\documentstyle[ltugboat,fileform]{article}
+
+\title{The \DVI\ Driver Standard, Level 0}
+\author{The TUG \DVI\ Driver Standards Committee}
+
+\newcommand{\versionno}{0.05}
+\newcommand{\docdate}{06~August~1991}
+\date{Version \versionno\\Last revised \docdate}
+
+\font\tensl=cmsl10
+
+\let\App=\appendix
+\def\appendix{\App\small} % tighten up the ending pages of the standard.
+
+\hbadness=9999 % Cut down the amount of annoying messages generated...
+\parindent=10pt % I prefer the traditional 1em parindent.
+
+% For file format descriptions:
+\def\res#1{{\bf #1\/}}
+\def\sty#1{{\it #1\/}}
+
+% Some code to add standard, explicate, and rationale environments:
+
+\newenvironment{standard}{\ifvmode\else\par\fi}{}
+
+% Must be reworked, the everypar restauration is brute force...
+
+\newenvironment{explicate}{%
+ \vskip1pt
+% \leavevmode{\setbox0=\lastbox}\small
+ \everypar{%
+ {\setbox0 \lastbox}%
+ \small
+ {\bf Explanation:}\quad \ignorespaces
+ \global\everypar{}%
+ }%
+ }{\par}
+
+% Ignore rationale environments for the moment.
+% Do it simple, they are not so long.
+
+\begingroup
+ \catcode`\[=1
+ \catcode`\]=2
+ \catcode`\{=11
+ \catcode`\}=11
+ \long\gdef\gobbleRationale#1\end{rationale}[%
+ \end[rationale]%
+ ] % <-- bracket!
+\endgroup
+\def\rationale{%
+ \catcode`\[=1 % <--- WHITE SPACE!
+ \catcode`\]=2
+ \catcode`\{=11
+ \catcode`\}=11
+ \gobbleRationale
+ }
+
+
+
+\def\percent{\,\%}
+\def\DVI{{\tt DVI}}
+\def\TFM{{\tt TFM}}
+\def\pt{\,pt}
+\def\KB{\,KB}
+\def\mm{\,mm}
+\def\in{\,in}
+\def\PK{{\tt PK}}
+\def\abs{\mathop{\rm abs}}
+\def\round{\mathop{\rm pixel\_round}}
+\def\sign{\mathop{\rm sign}}
+
+\begin{document}
+\maketitle
+
+\begin{abstract}
+
+The TUG {\tt DVI} Driver Standard defines functional and interface
+requirements for computer programs (\DVI{} processors)
+that read and translate files in the \DVI{} page description language.
+This document is the subset of the \DVI{} standard (level~0)
+applying to minimally functional \DVI{} processors.
+The specifications here should be considered a minimum requirement;
+developers are encouraged to write drivers exceeding these
+specifications.
+
+(The version of the Level~0 Standard presented here is
+draft~\versionno. It has been reviewed by the TUG \DVI{} Driver
+Standards Committee and is now being presented to the TUG membership
+at large for review.)
+
+The complete standard will be presented as a series of ``tiers''
+requiring increasingly stringent control over the output of \DVI\
+processors.
+
+%%%% FIXME: One may not mention the trip test in the abstract if it is
+%%%% not mentioned in the text at all...
+%%%% A trip test for \DVI\ processors will be created which will allow
+%%%% developers of \DVI\ processors to ensure that their programs meet the
+%%%% standards developed here.
+
+\end{abstract}
+
+\section{Purpose of the level-0 standard}
+
+The level-0 standard (henceforth called {\it standard\/}) is meant to
+be a base standard to which all \DVI-processing programs must adhere.
+It provides a base level of support for both \DVI-to-output-device
+translators (so called {\it drivers\/}) and \DVI-to-\DVI\
+preprocessors ({\em e.g.,\/} {\tt dviselect\/}). The standard
+hereafter calls such \DVI-processing programs ``\DVI{} {\it
+processors\/}'' or just ``{\it processors}.'' This standard allows
+all reasonable documents to be rendered (i.e., printed or displayed)
+accurately. When we refer to accurate rendering, we mean that the
+when the data generated by the \DVI{} processor(s) are transmitted to
+a output device the latter shall produce a page accurately depicting
+the page described by the \DVI{} file (disregarding resolution
+effects and output technology).
+
+
+The basis for many of the specifications in this standard is the
+possible output of \TeX82\ although some requirements are based on
+assumptions that cannot occur with \TeX82-based output; functions
+which can be implemented via a pre-processor are generally omitted
+({\em e.g.,\/} page selection and sorting).
+
+
+
+
+
+\section{The \DVI\ file}
+
+\begin{standard}
+
+As a rule, \DVI\ processors must be able to read and {\it
+interpret\/} any valid \DVI{} file as specified in
+appendix~\ref{dvi-format}. They shall also correctly {\it render\/}
+any {\tt DVI} file which falls within the following limits. If these
+requirements cannot be met due to limitations of the computer or the
+output device they shall be fulfilled as completely as possible and
+the limitations documented.
+ \label{escape-clause}
+ Aside from this exception, these specifications are a {\em
+minimum\/}; good processors will probably be able to handle \DVI\
+files exceeding these limits ({\tt DVI} files which exceed the limits
+are likely to be rare, but might still occur).
+
+\end{standard}
+
+\begin{explicate}
+
+This exception above is necessary because certain popular output
+devices have varying capacity depending on the amount of on-board
+memory or similar conditions. For example, an HP LaserJet Plus with
+512\KB\ of memory is capable of holding in memory only 3056 distinct
+downloaded characters; a full page bitmap is also not possible with
+this configuration.
+
+\end{explicate}
+
+
+
+
+\subsection{\DVI\ commands}
+
+\begin{standard}
+The \DVI\ processor must be able to interpret every \DVI\ command
+listed in Appendix~\ref{dvi-format}.
+\end{standard}
+
+\begin{explicate}
+Some commands, {\em e.g.,\/} \sty{put4}, are generally
+used for conditions outside those enumerated below; despite this,
+\DVI-translating programs are expected to accurately interpret
+these commands and execute them if they do specify an action
+within the specified minimum limits.
+\end{explicate}
+
+\subsection{Characters}
+
+\subsubsection{Number of characters in a font}
+
+\begin{standard}
+The \DVI\ processor must be able to handle fonts which have characters
+at any code in the range $0\le c<256$.
+\end{standard}
+
+\begin{explicate}
+Some printers with download possibilities will
+require fonts with more than a given number of
+characters to be broken into two or more device fonts when
+downloaded to the printer. Please note that this requirement is
+not subject to the exception for device limitations
+of section~\ref{escape-clause}.
+\end{explicate}
+
+
+
+\subsubsection{Character size}
+
+\begin{standard}
+
+The \DVI\ processor must be able to render any character up to a size of
+600\pt\ (horizontal) by 800\pt\ (vertical) unless this is not
+possible due to device constraints as outlined in
+section~\ref{escape-clause}.
+
+\end{standard}
+
+
+\begin{explicate}
+
+This size is the glyph size, not the size given in the \TFM{} files.
+These two sizes are not connected; especially it's important that the
+glyph might be outside the bounding box given by the dimensions of the
+\TFM{} files.
+
+\end{explicate}
+
+
+\begin{rationale}
+
+On many output devices, rendering of very large characters is
+possible by breaking down such a character into smaller characters or
+drawing the character in graphics mode.
+
+%%%% FIXME: Insert text below after change to 850 pt.
+%%%% The sizes above covers both the common US paper size of $8.5 \times
+%%%% 11\in$ and the A4 paper size used almost elsewhere in the world.
+
+\end{rationale}
+
+
+
+\subsubsection{Number of characters per page}
+
+\begin{standard}
+The \DVI\ processor must be able to render a page containing as many as
+20\,000 characters unless this is not
+possible due to device constraints as outlined in
+section~\ref{escape-clause}.
+\end{standard}
+
+\subsubsection{Unusual characters}
+
+\begin{standard}
+The \DVI\ processor must correctly render (a)~characters with empty
+bitmaps ({\em e.g.,\/} the \SliTeX\ fonts) including characters
+whose horizontal escapement is~0, (b)~characters whose
+printable image is wider than its horizontal escapement, and
+(c)~characters with a negative horizontal escapement.
+\end{standard}
+
+\subsection {Rules}
+\subsubsection{Rule size}
+
+\begin{standard}
+The \DVI\ processor must be able to render rules of any size up to 600\pt\
+(horizontal) by 800\pt\ (vertical) unless this is not
+possible due to device constraints as outlined in
+section~\ref{escape-clause}.
+\end{standard}
+
+
+
+\subsubsection{Placement of rules on the page}
+
+\begin{standard}
+
+The lower left corner of a rule is to be placed on the page at the
+location given by rounding the current \DVI\ coordinates as indicated
+in section~\ref{rounding-algorithm}. The height and width of the rule
+is given by the formula $\lceil Kn\rceil$ where $n$ is the dimension
+in \DVI\ units and $K$ is a constant which converts from \DVI\ units
+to device units.%
+ \footnote{Devices with aspect ratios unequal to one will need to
+maintain separate constants for vertical and horizontal dimensions.}
+
+\end{standard}
+
+
+\begin{explicate}
+
+It's important to remember that no rule is rendered if $n \le 0$, as
+specified in appendix~\ref{dvi-format}.
+
+\end{explicate}
+
+
+
+
+\subsection{Number of rules per page}
+
+\begin{standard}
+
+The \DVI\ processor must be able to render a page containing as many
+as 1000~rules unless this is not possible due to device constraints
+as outlined in section~\ref{escape-clause}.
+
+\end{standard}
+
+\begin{rationale}
+
+Doug McDonald \email{mcdonald@aries.scs.uiuc.edu} mentioned that one
+might need 20\,000 rules, because GNUplot generates \LaTeX{} files
+with that many rules, and more. This might be added in a future tier.
+
+\end{rationale}
+
+
+
+
+\subsection{Stack}
+
+\begin{standard}
+
+The \DVI\ processor must be able to handle \DVI\ files whose
+{\it push}\slash{\it pop\/} stack is up to 100 levels deep.
+
+\end{standard}
+
+
+\begin{rationale}
+
+Why 100?
+
+\end{rationale}
+
+
+
+
+\subsection{Positioning on the page}
+
+\subsubsection{Location of the origin}
+
+\begin{standard}
+The point $(0,0)$ in \DVI\ coordinates is to be located
+at a point one inch (25.4\mm) from the top of the page and one
+inch (25.4\mm) from
+the left side of the page.
+\end{standard}
+
+\begin{explicate}
+While the default margin given in this circumstance is somewhat
+inconvenient for users of non-U.S.-sized paper, the advantage of
+having a universally standard default location of $(0,0)$ and the
+widespread assumption of the given default margin in most macro
+packages outweighs the inconveniences. For some \DVI\
+processors ({\em e.g.,\/} screen previewers),
+this specification refers to a virtual page and not
+the physical output.
+\end{explicate}
+
+\subsubsection{Changes in position due to characters and rules}
+\label{rounding-algorithm}
+
+\begin{standard}
+The definition of \DVI\ files refers to six registers,
+$(h,v,w,x,y,z)$, which hold integer values in \DVI\ units. In
+practice, we also need registers ${\it hh}$ and ${\it vv}$, the
+pixel analogs of $h$ and $v$, since it is not always true that
+${\it hh}=\round(h)$ or ${\it vv}=\round(v)$ where $\round(n)$ is
+defined as $\sign(Kn) \cdot \lfloor \abs(Kn) + 0.5 \rfloor$ with
+$\sign(i)$ resulting in~$-1$ if~$i<0$ and in~$1$ otherwise.
+
+Whenever the \DVI{} processor encounters an instruction that changes
+the current position, it updates $h$ and $v$ using pure \DVI\ units.
+If the change in position is due to a command which sets a character,
+the processor adds the horizontal escapement value from the {\tt PK}
+or {\tt GF} file to $\it hh$ to get the new value for $\it hh$.
+
+For a horizontal movement of $x$ \DVI\ units from any other command,
+{\it hh\/} will be set to ${\it hh}+\round(x)$ if
+$x < {\it word\_space}$ for a horizontal movement to the right or if
+$x > -{\it back\_space}$ for a horizontal movement to the left. {\it
+word\_space\/} is defined as $\it space - space\_shrink$, and {\it
+back\_space\/} is defined as $\it 0.9 quad$ if the processors uses {\tt
+TFM} files. If the processors does not use {\tt TFM} files the design
+size of the current font in the {\tt DVI} file (after all necessary
+magnifications have been applied) may be used for a {\it quad}, and
+{\it word\_space\/} may be approximated by $\it 0.2 quad$.
+If $x$ exceeds the bounds outlined above, ${\it hh}$ is
+set to be $\round(h+x)$. In this way, rounding
+errors are absorbed by interword spaces.
+
+For a vertical movement of $y$ \DVI\ units, {\it vv\/} is set
+similarly except that {\it vv\/} is set to ${\it vv}+\round(y)$ if
+$-0.8 {\it quad} < y < 0.8 {\it quad}$ and set to $\round(v+y)$
+otherwise. This allows vertical rounding errors to be absorbed in the
+interline spacing while still allowing fractions and super- and
+subscripts to be printed consistently.
+
+After any horizontal movement, a final check is made as to
+whether $\it dist > max\_drift$ with $\it dist$ defined as
+$\abs({\it hh}-\round(Kh))$. If it is, then $\it hh$ is set to
+$\round(Kh) + \sign({\it dist}) \cdot {\it max\_drift}$.
+A similar check is made with $\it vv$ and $v$. $\it
+max\_drift$ should be set to~2 for output devices with device
+units smaller than or equal to 0.005\in\ (0.127\mm), 1~for output
+devices with device units greater than 0.005\in\
+(0.127\mm) but less than or equal to 0.01\in\ (0.254\mm) and
+$0$~for output devices with device units greater than 0.01\in\
+(0.254\mm).
+\end{standard}
+
+\begin{explicate}
+
+This method for tracking the positions is oriented towards the
+typesetting of text. It does not fix positioning problems with lines
+consisting completely of characters of a fixed-width font, where one
+line consists only of characters without any movements and the next
+line contains movements. Other problematic areas are the creation
+of line graphics with fonts with line segments. These line segments
+may not align.
+
+\end{explicate}
+
+\begin{rationale}
+
+An example for the fixed-width problem:
+
+******************************************************************************
+* *
+******************************************************************************
+
+The example is not a wild one; it is typical of text found
+in program comments that is exhibited in computer-related
+documents.
+
+The problem with mismatch of the horizontal rules and the root signs
+in large roots is not connected to the max drift algorithm.
+
+\end{rationale}
+
+
+
+\subsubsection{Range of movement}
+
+\begin{standard}
+The \DVI{} processor should be able to handle movements in the {\tt DVI}
+file up to a total of $2^{31}-1$ \DVI\ units in any direction
+from the origin.
+\end{standard}
+
+\subsubsection{Objects off the page}
+
+\begin{standard}
+Any printable object which would lie entirely off the physical
+page should not be rendered but any changes to positioning should
+still be taken into consideration. Any printable object which
+would lie partially off the physical page should either be
+clipped so that portion of the object that lies off the page is
+not printed or omitted entirely, unless this is not
+possible due to device constraints as outlined in
+section~\ref{escape-clause}.
+\end{standard}
+
+\begin{explicate}
+Because some output devices do unpredictable things when objects
+are rendered partially or completely off the edge of the page, it
+is up to the \DVI{} processor writer to make sure that objects
+printed partially off the page are handled correctly.
+%%%% FIXME: Only if the processors knows about the physical page. Resp.,
+%%%% this holds only for the area which the processors thinks it's the
+%%%% physical page. (Problem mentioned by Karl Berry \email{karl@cs.umb.edu}.)
+\end{explicate}
+
+\subsection{Fonts}
+
+\subsubsection{Font numbers}
+
+\begin{standard}
+The \DVI{} processor must be able to accept font numbers (the parameter
+$k$ given by a {\it fnt\_def\/} command) in the range $0\le
+k<256$.
+\end{standard}
+
+\subsubsection{Distinct fonts}
+
+\begin{standard}
+The \DVI{} processor must be able to handle any document containing 64 or fewer
+distinct fonts.
+\end{standard}
+
+\subsection{Specials}
+
+\begin{standard}
+Specials are the parameters to the \DVI{} commands \id{xxx1},
+\id{xxx2}, \id{xxx3}, and \id{xxx4}. This standard
+does not define the meaning of any special, future tiers may.
+Specials not officially defined by the \DVI\ processor standards
+committee should be flagged with a warning when read from the \DVI\
+file. If any specials are encountered that are ignored by the
+processor, the processor must issue a warning message. These warning
+messages may optionally be turned off at run time.
+\end{standard}
+
+\section{Configuration}
+
+\begin{standard}
+It must be possible for the installer of a \DVI{} processor to
+configure such things as the location and naming scheme of fonts,
+default paper size, etc.\ without having to recompile or relink the processor.
+\end{standard}
+
+\begin{explicate}
+``etc.''\ means ``make as many things configurable as possible.''
+This should be more detailled (Hint due to Karl Berry).
+\end{explicate}
+
+\section{Font files}
+
+\subsection{Font formats}
+
+\begin{standard}
+
+The \DVI{} processor must be able to read {\tt PK} fonts with the
+location specifiable at run time. The {\tt PK}
+format is given in appendix~\ref{pk-format}. {\tt GF} support is
+optional. The {\tt GF} format is given in
+appendix~\ref{gf-format}.
+
+\end{standard}
+
+
+\begin{explicate}
+
+The \PK\ format is the preferred format for bitmap fonts because
+(a)~it is the most compact format in the \TeX\ world and
+(b)~included in the \PK\ format are pieces of information about
+the font ({\em e.g.,\/} the horizontal escapement in pixels for
+each character) which are essential for fulfilling the
+typesetting requirements of section~\ref{rounding-algorithm}.
+
+\end{explicate}
+
+
+\begin{rationale}
+
+The support of \PK{} files is mandatory because in this
+way at least one common font format is available. Of course, this
+should not discourage the support for more font formats, including,
+but not limited to, the support of non-bitmapped fonts.
+
+Arthur Ogawa \email{ogawa@saturn.arc.nasa.gov} recommends the
+following addition:
+%
+ \begin{quote}
+
+Alternatively, the driver's installation may support PK format
+bitmap fonts by converting them to a system-supported format,
+with the driver supporting system fonts.
+
+
+ \end{quote}
+%
+ Might be senseful.
+
+\end{rationale}
+
+
+
+
+\subsection{The scaling number}
+
+\begin{standard}
+
+The magnification and resolution of a font are combined into
+a scaling number in one of two ways:
+\begin{description}
+
+\item[Resolution number]
+The resolution number is given by ${\it resolution} \times {\it
+magnification}$ where both values are as above. This is the
+preferred specification for {\tt GF} and {\tt PK} files.
+
+\item[Magnification number]
+The magnification number is given by $5\times {\it resolution}
+\times {\it magnification\/}$ where the resolution is given in
+dots per inch (on devices with a aspect ratio unequal to one, the
+horizontal resolution should be used) and a magnification of~1
+indicates normal sizing.
+
+\end{description}
+
+\end{standard}
+
+\begin{rationale}
+
+The magnification number is an old naming scheme derived from the old
+200~dpi output devices which used {\tt PXL} files. Explanation should
+follow.
+
+\end{rationale}
+
+
+
+
+\subsection{Magnifications}
+
+\subsubsection{Minimum set of magnifications}
+
+\begin{standard}
+
+The \DVI{} processor must be able to use at least fonts at the
+following magnifications of its target resolution: 1.0 ({\tt
+magstep\/}0), 1.095 ({\tt magstep\/}0.5), 1.2 ({\tt magstep\/}1),
+1.44 ({\tt magstep\/}2), 1.728 ({\tt magstep\/}3), 2.074 ({\tt
+magstep\/}4), 2.488 ({\tt magstep\/}5), 2.986 ({\tt magstep\/}6),
+3.583 ({\tt magstep\/}7), 4.300 ({\tt magstep\/}8), and 5.160 ({\tt
+magstep\/}9).
+
+\end{standard}
+
+\begin{explicate}
+
+The term {\tt magstep\/}$n$ stems from the \TeX{} and \MF{} control
+sequence with the same name. It's meaning is $1.2^n$.
+
+This list should not be taken as an exhaustive list. \DVI\ processor
+authors are encouraged to support all possible magnifications.
+
+\end{explicate}
+
+
+
+\subsubsection{Margin of error}
+
+\begin{standard}
+If a \DVI\ file requests a font at a size that does not
+exist, but the requested size is within 0.2\percent\ of a
+supported magnification with the font at that size existing, the
+\DVI{} processor must use the latter font without warning.
+\end{standard}
+\begin{explicate}
+\TeX\ and \MF\ compute font magnifications with different
+precisions. Further, calculations done by \TeX\ and/or a \DVI\
+processor are subject to roundoff errors. The margin
+prescribed is sufficient for accomodating most of these errors. It is
+{\em not\/}
+intended to compensate for fonts requested at an incorrect size.
+\end{explicate}
+
+\subsection{Missing fonts}
+
+\begin{standard}
+If a font is missing the \DVI{} processor must continue processing and,
+after issuing an appropriate warning message,
+deal with the missing font in one of three ways:
+\begin{enumerate}
+\item Insert appropriate white space where characters of the font would
+ appear.
+\item Insert black rectangles of the size of the character given in
+ the {\tt TFM} file for the font.
+\item Print the characters from that font at a different size or
+ from another font at the same size.
+\end{enumerate}
+If methods 1 or 2 are used and the processor is unable to locate
+size information for the font in question, then the processor may
+simply ignore any character setting command
+that occur while the current font is that font.
+
+Under no circumstances should a missing font cause a fatal error.
+\end{standard}
+
+\appendix
+
+\input{dvi}
+\input{gf}
+\input{pk}
+\input{tfm}
+\end{document}
+
+
+======================================================================
+
+
+%
+% $Log: dvistd0.tex,v $
+% Revision 5.1 1991/08/06 15:12:07 schrod
+% draft 0.05a
+%
+%
+% A LOT OF CHANGES; DRIV-L POSTINGS OF THE LAST YEAR COLLECTED AND PARTLY
+% INCORPORATED.
+%
+%
+% EDITORIAL CHANGES:
+%
+% Did not use style option mf any more. This style option needed the
+% NFSS, which is not in use at all sites. The draft must be TeXable
+% with a `standard' LaTeX system.
+%
+% The `author' of the draft is now the TUG DVI Driver Standards Committee.
+%
+% Added distinction between standard text, explication, and rationale.
+% The standard text is just the `pure,' definitive, short statement to
+% be made. An explication pinpoints important consequences or
+% implications of the standard text. Both are published in one document
+% and are already finished. The rationale is an additional document
+% describing why this standard text was chosen and names other
+% possibilities discussed, but not included. The reason for the
+% possibilities which were not included are usually outlined. The
+% rationale is not written yet. All three parts will be within one
+% \TeX{} source, although the rationale will be published as a separate
+% document. (This conforms more to the standard documents I've read up
+% to now, this structure may change again in the future.)
+%
+% Completed replacement of `should' with `shall' and `must.' (`should'
+% is no good term in a standard...) There's still one `should': In the
+% section on specials, on the definition when warnings should be
+% issued. But this section needs clarification anyhow.
+%
+% Completed replacement of `DVI driver' with `DVI processor.' (At least
+% on those occasions where not explicitely a device-driving program is
+% meant.)
+%
+% Exchanged item `Magnification number' and `Resolution number' (now
+% first) since the latter should be the canonical form by now.
+%
+%
+% CHANGES OF CONTENTS:
+%
+% Abstract slightly rewritten, it conforms now more to usual conventions
+% (see, e.g., Mark Wegman's paper in SIGPLAN, Vol. 21, No. 5).
+% Commented out the trip test statement in the abstract. A trip test
+% is not mentioned in the report. If it is mentioned it will be added
+% back.
+%
+% Enhanced the introductionary paragraph to define a few terms (render,
+% etc.) used later on.
+%
+% The term `DVI font' was defined nowhere and is therefore discarded.
+% Just `font' is enough, since it concerns all fonts a DVI processor
+% must handle. The same holds for `DVI character size,' it's renamed to
+% `character size.'
+%
+% A paragraph was added to the explication of the section `character
+% size' which states explicitely that the `character size' is the size
+% of the glyph, not the TFM bounding box. This explication was demanded
+% by Pierre MacKay on driv-l and generally aggreed on.
+%
+% The term `non-unit aspect ratio' does not exist. Renamed to `aspect
+% ratio unequal to one.'
+%
+% Added explication which points out that no rule is set if the width or
+% the height is less than 0pt.
+%
+% Added an explication that the maxdrift algorithm does not solve all
+% problems with positioning. Mentioned a few problems.
+%
+% Added escape-clause (realization of functionality perhaps not possible
+% due to device contraints) to the section `Objects off the page'
+% (formerly named `Objects off of the page'). It was forgotten when
+% accepting ammendment 06.
+%
+% Defined the term `special.' Says explicitely that level 0 does not
+% define the meaning of any special.
+%
+% In section `Configuration' changed `without having to recompile the
+% processor' to `without having to recompile or relink the processor.'
+% Added explication what `etc.' in this paragraph means (`make as many
+% things configurable as possible'). But this explication should be
+% changed anyhow...
+%
+% In section `Minimum set of magnifications,' added explication which
+% defines the term `magstep.' Moved the encouragement to support all
+% possible magnifications to the explication, it's implicitely contained
+% in the standards text.
+%
+%
+% ACKNOWLEDGEMENTS:
+%
+% Small changes for correction of spelling errors and inserting better
+% phrases (contributed by Nelson Beebe, Karl Berry, Friedrich
+% Haubensak, Berthold Horn, Pierre MacKay, Doug McDonald, Arthur Ogawa,
+% Greg(?) Platt, Liam Quin, and Thomas Reid).
+%
+% Revision 4.4 1991/03/25 00:00:00 hosek
+% draft 0.04c
+%
+% Merged in ammendments 09 and 10. Ammendment topics:
+% 09: definition of round() (S2.6.2)
+% [introduces and defines pixel_round()]
+% 10: change of max_drift correction (S2.6.2)
+% [move only one pixel]
+%
+% Corrects some typographic errors of draft 0.04b, but again, this
+% document is not TeXable.
+%
+% Revision 4.3 1991/01/24 00:00:00 hosek
+% draft 0.04b
+%
+% Typos sent in by me and others are corrected.
+%
+% But still some typographic errors remain...
+%
+% Revision 4.2 1990/11/13 00:00:00 hosek
+% draft 0.04a
+%
+% Merged in a lot, but not all of my changes sent to driv-l.
+% Inserted stuff which was sent as ammendment 11, making the ammendment
+% obsolete in this way. This covers the limits for DVI units, specification
+% of movement, unconditional warning if fonts are missing.
+%
+% But still some typographic errors remain. This draft was even not TeXable
+% when it arrived...
+%
+% Revision 4.1 1990/10/06 00:00:00 hosek
+% draft 0.04
+%
+% Merged in a lot of minor changes, e.g., render instead of print,
+% must instead of should, etc.
+% Added difference between standard text and explication (for a future
+% rationale document).
+%
+% Merged in ammendments 01, 05--08. Ammendments topics:
+% 01: Change margin of error tolerance (S4.3.2)
+% [font mag epsilon: 0.2% instead of 2%]
+% 05: Change to wording of minimum stack depth (S2.5)
+% [allow dynamic stacks]
+% 06: DVI limits only for devices which may support it (S2)
+% [some limits were not *possible* to print]
+% 07: Change to definition of limits for maxdrift (App E, now S2.6.2)
+% [now TFM independent, since driver may not read TFM files]
+% 08: Change to maxdrift value (App E, now S2.6.2)
+% [0 at 100dpi]
+%
+% Moved maxdrift algorithm from Appendix E into the core text.
+%
+% Revision 3.1 1990/07/19 00:00:00 hosek
+% draft 0.03
+%
+% Official draft enumeration changed from just a number to x.y with x as a
+% designation for the standard part and y as a designation of the version.
+% Adopted the notion of ``tiers'' for the future structure of other
+% standard levels. Added appendices with max drift algorithm and file format
+% specifications.
+% (CAVEAT: The max drift appendix is wrong!)
+%
+% Revision 2.1 1990/06/23 00:00:00 hosek
+% draft #002
+%
+% This draft was the first one which was written with LaTeX markup,
+% and in complete sentences, not just phrases.
+%
+% Revision 1.1 1990/02/26 00:00:00 hosek
+% Initial revision
+%
+
+
+======================================================================
+
+
+
+The TRIP test problem: How to cover this in level 0?
+
+Still to be solved.
+
+John Gourlay made the following suggestion:
+ To clarify these issues I'd like to propose an ammendment to the
+ effect that drivers should follow the character and rule placement
+ algorithm given or they should produce printed results equivalent to
+ such a driver on a standard set of test documents prescribed by the
+ committee (the driver ``trip'' test that has been brought up now and
+ then).
+
diff --git a/dviware/driv-standard/level-0/fileform.sty b/dviware/driv-standard/level-0/fileform.sty
new file mode 100644
index 0000000000..f58e3af0a2
--- /dev/null
+++ b/dviware/driv-standard/level-0/fileform.sty
@@ -0,0 +1,579 @@
+% fileform.doc 18 Jul 91
+%------------------------------------------------------------
+% Copyright 1990 by J.Schrod.
+
+%
+% fileformats for TeX and MF (usage of WEAVE like output in LaTeX)
+%
+% [LaTeX style option, in MAKEPROG]
+
+%
+% VERSION HISTORY (MSCF -- most significant change first)
+%
+% DATE WHO REMARK
+% 91-07-18 js define \MF only if it is not already defined
+% 90-12-05 js no line break between \cmd definition and explanation
+% ragged right within \cmd definition
+% 90-12-03 js allows a line break within \cmd definition
+% 90-11-07 js added PL support, paintletter environment
+% 90-07-05 js first release
+
+% author's current address:
+%
+% Technical University of Darmstadt
+% Institut f\"ur Theoretische Informatik
+% Joachim Schrod
+% Alexanderstr. 10
+%
+% D-W-6100 Darmstadt
+% FR Germany
+%
+% Tel. (+6151) 16-3711
+% Email: xitijsch@ddathd21.bitnet
+
+
+
+%%%%
+%%%%
+%%%% These TeX macros were documented with the documentation system
+%%%% MAKEPROG and automatically converted to the current form.
+%%%% If you have MAKEPROG available you may transform it back to
+%%%% the original input: Remove every occurence of three percents
+%%%% and one optional blank from the beginning of a line and remove
+%%%% every line which starts with four percents. The following lex
+%%%% program will do this:
+%%%%
+%%%% %%
+%%%%
+%%%% ^%%%\ ? ;
+%%%% ^%%%%.*\n ;
+%%%%
+%%%% MAKEPROG may be obtained over the net from the Bitnet-Listserver
+%%%% LISTSERV@DHDURZ1 (filelist WEBWARE) or via ftp from ftp.th-darmstadt.de
+%%%% in the directory /pub/tex/src-webware.
+%%%%
+%%%%
+%%% \documentstyle[progltx]{article}
+
+
+%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%% %
+%%% % local macros
+%%% %
+%%% \makeatletter
+
+%%% \let\mc=\small % for names like GNU
+
+%%% \@onesizefont\logo{logo10}
+%%% \def\MF{{\logo META}\-{\logo FONT\/}}
+
+%%% \def\WEB{{\tt WEB\/}}
+%%% \def\WEAVE{{\tt WEAVE\/}}
+%%% \def\GNU{{\mc GNU}}
+
+%%% \makeatother
+%%% %
+%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+
+%%% \begin{document}
+
+
+%%% % \title{\TeX{} and \MF{} File Formats} % should be done in this way
+%%% \title{\TeX{} and METAFONT File Formats} % blame LaTeX!!
+%%% \author{\sc Joachim Schrod}
+
+%%% \maketitle
+
+
+%%% \chap Introduction.
+
+%%% The {\tt DVI\/} Driver Standard contains the description of common
+%%% file formats ({\tt DVI}, {\tt TFM}, {\tt PK}, etc.)\ as appendices.
+%%% These descriptions are taken from \WEB{} programs. Weaving the \WEB{}
+%%% programs results in a \TeX{} source, but sprinkled with macros from
+%%% {\tt webmac}. These macros are not only used for typesetting symbolic
+%%% identifiers needed for the definition of opcodes, in the definition
+%%% of the {\tt PK\/} format even a whole Pascal program must be typeset
+%%% -- the description of decoding run counts is given as a Pascal {\bf
+%%% function}.
+
+%%% The macros defined below allow such a typesetting. They were
+%%% developped in 1988 as a part of a general macro package called {\mc
+%%% WEBSET} which allows the direct inclusion of \WEAVE{} output in
+%%% several macro packages (among others \LaTeX{}). But {\sc Don Hosek}
+%%% has asked for a \LaTeX{} markup so that we cannot use these macros
+%%% directly. (A \LaTeX{} markup has the advantage that it may be altered
+%%% by more people than a \WEB{} markup.) The macros defined here are
+%%% renamed for better readability, and they are only those few macros
+%%% needed for typesetting the file formats.
+
+%%% At the First European TUG Conference in Cork 1990 Barbara Beeton asked
+%%% me if I would like to supply a brochure with {\it all\/} file formats
+%%% formally defined in context with the systems \TeX{} and \MF{}. The
+%%% file formats of the |DVI| driver standard were more than half of the
+%%% needed definitions, but the rest require additional markups. So this
+%%% macro file was enhanced and renamed from ``File Formats For the {\tt
+%%% DVI\/} Driver Standard'' to ``\TeX{} and \MF{} File Formats''
+
+%%% If you want to incorporate \WEB{} programs or parts of them into
+%%% documents which are to be published you should contact me. In my
+%%% opinion the macros below are no starting point for such a task.
+
+%%% \beginprog
+\immediate\message{TeX and MF file formats <18 Jul 91>}
+%%% \endprog
+
+
+%%% \sect This style option is free software; you can redistribute it
+%%% and/or modify it under the terms of the \GNU{} General Public License
+%%% as published by the Free Software Foundation; either version~1, or
+%%% (at your option) any later version.
+
+%%% This style option is distributed in the hope that it will be useful,
+%%% but {\bf without any warranty\/}; without even the implied warranty
+%%% of {\bf merchantability\/} or {\bf fitness for a particular purpose}.
+%%% See the \GNU{} General Public License for more details.
+
+%%% You should have received a copy of the \GNU{} General Public License
+%%% along with this style option; if not, write to the Free Software
+%%% Foundation, Inc., 675~Mass Ave, Cambridge, MA~02139, USA.
+
+
+%%% \sect \begin{sloppypar}
+%%% Before we start we declare some shorthands for category codes. By
+%%% declaring the underscore~`(|_|)' as a letter we can use it in our
+%%% macro names. (I agree with D.~Knuth that
+%%% |\identifier_several_words_long| is more readable than
+%%% |\IdentifierSeveralWordsLong| and in every case better than
+%%% |\p@@@s|.) But as we have to restore the category codes at the end of
+%%% this macro file we store its former value in the control sequence
+%%% |\uscode|. This method is better than the usage of a group because
+%%% not all macros have to be defined global this way.
+%%% \end{sloppypar}
+
+%%% \beginprog
+\chardef\letter=11
+
+\chardef\uscode=\catcode`\_
+
+\catcode`\_=\letter
+%%% \endprog
+
+
+%%% \sect We have to typeset typical tokens like string elements or
+%%% identifiers, descriptions of the commands found in the files.
+%%% Furthermore we have to define the |webprog| environment which allows
+%%% to typeset the Pascal function {\it pk\_packed\_num\/} -- but {\it
+%%% only this\/} function\,\dots
+
+%%% But before we start to implement the above we just define the logo
+%%% |\MF| (\MF{}) needed e.g.\ by the {\tt GF\/} format text. This
+%%% definition is only needed if it was not done before by other style
+%%% options.
+
+%%% \beginprog
+\ifx \MF\undefined
+ \@onesizefont\logo{logo10}
+ \def\MF{{\logo META}\-{\logo FONT\/}}
+\fi
+%%% \endprog
+
+
+
+
+%%% \chap Tokens.
+
+%%% String elements will be typeset with |\str|. This allows to print all
+%%% special \TeX{} characters with a preceding backslash. To implement
+%%% this we use character definitions of {\tt webmac\/} -- which are in
+%%% uppercase so that they are hopefully not in conflict with other
+%%% macros. These character definitions will be used locally in~|\str|.
+
+%%% \beginprog
+\chardef\AM=`\& % ampersand character in a string
+\def\AT!{@} % at sign for control text
+\def\BS{{\tt\char`\\}} % backslash
+\chardef\HA=`\^ % hat in a string
+\chardef\LB=`\{ % left brace in a string
+\def\LQ{{\tt\char'22}} % left quote in a string
+\chardef\RB=`\} % right brace in a string
+\def\RQ{{\tt\char'23}} % right quote in a string
+\def\SP{{\tt\char`\ }} % (visible) space in a string
+\chardef\TL=`\~ % tilde in a string
+\chardef\UL=`\_ % underline character in a string
+
+\def\str#1{% % strings (in typewriter)
+ \leavevmode
+ \hbox{\tt
+ \let\\\BS % backslash in a string
+ \let\'\RQ % right quote in a string
+ \let\`\LQ % left quote in a string
+ \let\{\LB % left brace in a string
+ \let\}\RB % right brace in a string
+ \let\~\TL % tilde in a string
+ \let\^\HA % hat in a string
+ \let\ \SP % space in a string
+ \let\_\UL % underline in a string
+ \let\&\AM % ampersand in a string
+ #1%
+ }%
+ }
+%%% \endprog
+
+
+%%% \sect Keywords are only needed in the {\tt TFM\/} description for the
+%%% specification of the header -- this is done in a Pascal notation with
+%%% {\bf array\/}'s.
+
+%%% Often needed are identifiers.
+
+%%% \beginprog
+\def\res#1{% % reserved words (in bold)
+ \leavevmode
+ \hbox{\bf #1\/}%
+ }
+
+\def\id#1{% % identifiers (in italics)
+ \leavevmode
+ \hbox{\it #1\/\kern.05em}%
+ }
+%%% \endprog
+
+
+%%% \sect We do not introduce new names for typesetting non-decimal
+%%% constants.
+
+%%% \beginprog
+\def\H#1{%
+ \leavevmode
+ \hbox{\rm\char"7D\tt #1}%
+ }
+
+\def\O#1{%
+ \leavevmode
+ \hbox{\rm\char'23\kern-.2em\it #1\/\kern.05em}%
+ }
+%%% \endprog
+
+
+
+
+%%% \chap Definition of Commands.
+
+%%% Commands will be marked with |\cmd|. Following this markup will be a
+%%% description of the opcode, usually both symbolic and numeric, which
+%%% is to be terminated by a comma. The Operand description follows and
+%%% is terminated by a dot. The operand description is typeset in math
+%%% mode, with active spaces. After this command specification comes the
+%%% next paragraph: a verbal description of the command.
+
+%%% The implementation is simple: we establish a hanging indentation for
+%%% the command specification and start with the opcode itself,
+%%% unindented. Since during the typesetting of the operands blanks shall
+%%% be active we establish them first and call |\get_operands|
+%%% afterwards. So during the tokenization of the parameter of
+%%% |\get_operands| we will regard all blanks.
+
+%%% \beginprog
+\def\cmd #1,{%
+ \endgraf
+ \smallbreak
+ \bgroup
+ \rightskip \z@ plus 1em % may be typeset raggedright
+ \hangindent 4em
+ \noindent #1%
+ \obeyspaces
+ \get_operands
+ }
+%%% \endprog
+
+
+%%% \sect We must define the active blank to work like `{\tt
+%%% \char`\\\char`\ }' but our macros should be written indented according
+%%% to their structure. So we just establish the meaning of active blank
+%%% and call |\set_operands| with the parameter token list.
+
+%%% \beginprog
+\begingroup\obeyspaces
+\gdef\get_operands#1.{\def {\allowbreak\ }\set_operands{#1}}
+\endgroup
+%%% \endprog
+
+
+%%% \sect If there are no operands for this command we have finished the
+%%% command specification. Afterwards we delimit the operands from the
+%%% opcode by a quad and typeset them in math mode. Closing the group
+%%% removes the special meaning of the active blank.
+
+%%% The command description is typeset with only half the indentation of
+%%% the specification but with no vertical skip between. (\TeX{} inserts
+%%% the |\parskip| at the beginning of a new paragraph, so we just begin
+%%% the new paragraph inside a group where |\parskip| is~0\,pt.)
+
+%%% \beginprog
+\def\set_operands#1{%
+ \def\op{#1}%
+ \ifx \op\empty
+ \else \quad \ignorespaces $#1$%
+ \fi
+ \par
+ \egroup
+ \nobreak
+ \hangindent 2em
+ \hangafter \z@
+ {\parskip\z@skip \noindent}%
+ \ignorespaces
+ }
+%%% \endprog
+
+
+%%% \sect Belonging to the command descriptions is a collection of all
+%%% opcodes to get an overview. They are typeset like \WEB{} defines
+%%% (what they originally were). We have to supply comments which will be
+%%% enclosed in braces; the corresponding macro |\C| will always be
+%%% called outside of math mode.
+
+%%% Both macros are smaller versions of those found in {\tt webmac}.
+
+%%% \beginprog
+\def\define{% % begin `define'
+ \endgraf
+ \hangindent 8em
+ \res{define }%
+ }
+\def\C#1{% % comments
+ $\hfil\penalty-\@ne\hfilneg
+ \quad \lbrace \,$#1$\, \rbrace
+ $%
+ }
+%%% \endprog
+
+
+%%% \sect The Pascal Function.
+
+%%% All macros we have to define for the Pascal function are defined
+%%% inside the |webprog| environment. This is different to {\mc WEBSET\/}
+%%% where these macros are defined globally.
+
+%%% At first we start with the definition of the amount of indentation for
+%%% each part of a compound statement. A few supplementary boxes for
+%%% realizing the ``{\it outdent\/}'' of one statement are needed (here we
+%%% follow the implementation of {\tt webmac\/}).
+
+%%% \beginprog
+\newdimen\indsize % one indentation unit
+ \indsize=2em
+\newdimen\ind % current indentation
+\newbox\bak
+ \setbox\bak=\hbox to -\indsize{} % backspace one unit
+\newbox\bakk
+ \setbox\bakk=\hbox to -2\indsize{} % backspace two units
+%%% \endprog
+
+
+%%% \sect The |webprog| environment defines all macros needed to typeset
+%%% the function {\it pk\_packed\_num}. Strings, reserverd words,
+%%% identifiers (one and more letters long), and a few math symbols are
+%%% needed in their \WEB{} markup. The beginning of the program part with
+%%% |\P| is realized by |\WEB_prog_mode| which will be implemented in the
+%%% next section.
+
+%%% At last the \WEB{} macros for controling the indentation are needed,
+%%% their names consist of one digit: |\1|~increases, |\2|~decreases the
+%%% current indentation, |\3|~is an optional break within a statement,
+%%% |\4|~backspaces one indentation unit (used at the beginning of a
+%%% line), |\5|~is an optional break between two statements, and |\6|~is a
+%%% forced break between two statements.
+
+%%% \beginprog
+\def\webprog{%
+ \endgraf
+ \medbreak
+ \let\.\str
+ \let\&\res
+ \let\\\id
+ \def\|##1{% % identifiers with one letter
+ \leavevmode
+ \hbox{$##1$}%
+ }%
+ \let\I\ne
+ \let\K\gets
+ \let\L\le
+ \let\P\WEB_prog_mode
+ \def\1{%
+ \global\advance \ind by \indsize
+ \hangindent\ind
+ }%
+ \def\2{\global\advance \ind by -\indsize}
+ \def\3##1{\hfil \penalty ##10 \hfilneg}%
+ \def\4{\copy\bak}%
+ \def\5{%
+ \hfil \penalty-\@ne \hfilneg
+ \kern .5em
+ \kern \tw@\indsize \copy\bakk
+ \ignorespaces
+ }%
+ \def\6{%
+ \ifmmode
+ \else\endgraf
+ \hangindent \ind
+ \noindent \kern\ind \copy\bakk
+ \ignorespaces
+ \fi
+ }%
+ }
+%%% \endprog
+
+
+%%% \sect Typesetting Pascal programs requires other paragraph shape
+%%% values than typesetting text. |\WEB_prog_mode| establishes them and
+%%% starts the program in horizontal mode; it will be called within a
+%%% group.
+
+%%% The values established are no paragraph skip and no indentations
+%%% because each major part (delimited by |\6|) of a program will be a
+%%% paragraph. Statements may not reach the right margin or they may even
+%%% stick a bit into. After the statement separator (`|;|') we just let a
+%%% little bit more space. Hyphenation is of no sense within programs.
+
+%%% \beginprog
+\def\WEB_prog_mode{%
+ \parskip\z@skip
+ \parindent\z@
+ \rightskip \z@ plus 100\p@ minus 10\p@
+ \sfcode`; 3000
+ \pretolerance\@m
+ \hyphenpenalty\@m
+ \exhyphenpenalty\@m
+ \global\ind \thr@@\indsize % standard indentation
+ \hangindent\ind
+ \ifvmode
+ \noindent \kern\ind \copy\bakk % go in horizontal mode
+ \fi
+ }
+%%% \endprog
+
+
+
+
+
+%%% \chap Letter shapes.
+
+%%% Sometimes letters with their pixels are shown as an example. Then the
+%%% |letter| environment may be used: Every line is a pixel row and must
+%%% start with `|&|'. White pixels are input as blanks, black pixels are
+%%% as stars. Tabs must not be used. A `|+|' is used for the reference
+%%% point of a character. The rest of the line after |\begin{letter}| is
+%%% ignored.
+
+%%% The output is centered, every line is preceded with a line number.
+
+%%% \beginprog
+\newcount \letter_lines
+
+\def\paintletter{%
+ \center \noindent
+ \vtop\bgroup
+ \setup_letter
+ \global\letter_lines\z@
+ \ialign\bgroup
+ \global\advance\letter_lines\@ne
+ \hfil \number\letter_lines ##\quad &%
+ ##\hfil\crcr
+ }
+
+\def\endpaintletter{%
+ \crcr
+ \egroup
+ \egroup
+ \endcenter
+ }
+%%% \endprog
+
+
+%%% \sect |\setup_letter| sets up the new meaning of all required
+%%% characters. The general font is Roman in footnote size, used only for
+%%% the row numbers. The lines are exactly 10pt apart.
+
+%%% \beginprog
+\def\setup_letter{%
+ \let\par\crcr \obeylines
+ \setup_letter_blank
+ \setup_letter_star
+ \setup_letter_plus
+ \footnotesize
+ \baselineskip 10\p@
+ }
+
+\begingroup
+\catcode`\ =\active
+\gdef\setup_letter_blank{\obeyspaces \let \letter_white}
+\endgroup
+
+\begingroup
+\catcode`\*=\active
+\gdef\setup_letter_star{\catcode`\* \active \let*\letter_black}
+\endgroup
+
+\begingroup
+\catcode`\+=\active
+\gdef\setup_letter_plus{\catcode`\+ \active \let+\letter_reference}
+\endgroup
+%%% \endprog
+
+
+%%% \sect Every pixel in the letter is typeset 10\,pt high and 10\,pt
+%%% wide, black pixels are painted by a square of $7\times 7\,pt$. The
+%%% height of the pixels is already set by the |\baselineskip|, we have to
+%%% take care of the width.
+
+%%% \beginprog
+\def\letter_white{\hbox to 10pt{\hfil}}
+\def\letter_black{\hbox to 10pt{\vrule height 7pt width 7pt depth 0pt \hfil}}
+\def\letter_reference{\hbox to 10pt{\tentt +\hfil}}
+%%% \endprog
+
+
+
+
+
+%%% \chap Specialities for property lists.
+
+%%% There are two formally defined file formats in textual
+%%% representation, property lists for |TFM|~files (|PL|), and property
+%%% lists for |VF|~files (|VPL|). The last are nearly a superset of the
+%%% former ones. Therefore we give the \TeX{}er the opportunity to discard
+%%% the |PL|~definition parts in the |VPL|~definition. Appropriate
+%%% references are inserted then. This is controlled by the switch
+%%% |\ifPL|.
+
+%%% \beginprog
+\newif\ifPL
+%%% \endprog
+
+
+%%% \sect But there is a minor problem: The definition of a decimal number
+%%% in a property list is not the same. We provide a token variable which
+%%% will hold the respective description.
+
+%%% \beginprog
+\newtoks\DecimalDescription
+%%% \endprog
+
+
+
+%%% \sect We are finished and just have to restore the category code of
+%%% the underscore. As usually, we add an |\endinput| so that garbage may
+%%% follow.
+
+%%% \beginprog
+\catcode`\_=\uscode
+
+\endinput
+%%% \endprog
+
+
+
+
+%%% \end{document}
diff --git a/dviware/driv-standard/level-0/gf.tex b/dviware/driv-standard/level-0/gf.tex
new file mode 100644
index 0000000000..245439707c
--- /dev/null
+++ b/dviware/driv-standard/level-0/gf.tex
@@ -0,0 +1,381 @@
+% $Id: gf.tex,v 3.0.1.2 1991/08/08 15:56:31 schrod Exp schrod $
+%------------------------------------------------------------
+% taken from GFtype 3.0
+
+%
+% definition of GF format
+% to be included
+%
+% [LaTeX with fileform]
+
+
+% $Log: gf.tex,v $
+% Revision 3.0.1.2 1991/08/08 15:56:31 schrod
+% CHANGES BY DON HOSEK:
+% -- Inserted \subsection's.
+% -- Deleted WEB defines.
+% -- `e.g.' now in italics, to be consistent with the rest of the
+% standard.
+%
+% CHANGES BY JOACHIM SCHROD:
+% -- Changed \bigbreak between WEB sections to \medbreak.
+% -- Added + signs to length specifications in \cmd tags, to show that
+% the param is signed.
+% -- Make formulas look more `math-like' and less `Pascal-like.'
+%
+% Revision 3.0.1.1 1990/07/16 00:00:00 schrod
+% changed \& to \res.
+% appended \endinput.
+%
+% Revision 3.0 90/07/04 00:00:00 schrod
+% extracted from GFtype 3.0
+%
+
+
+
+\section{Generic Font File Format}
+\label{gf-format}
+
+\subsection{Introduction}
+
+The most important output produced by a typical run of \MF\ is the
+``generic font'' (\str{GF}) file that specifies the bit patterns of
+the characters that have been drawn. The term {\sl generic\/}
+indicates that this file format doesn't match the conventions of any
+name-brand manufacturer; but it is easy to convert \str{GF} files to
+the special format required by almost all digital phototypesetting
+equipment. There's a strong analogy between the \str{DVI} files
+written by \TeX\ and the \str{GF} files written by \MF; and, in fact,
+the file formats have a lot in common.
+
+A \str{GF} file is a stream of 8-bit bytes that may be regarded as a
+series of commands in a machine-like language. The first byte of each
+command is the operation code, and this code is followed by zero or
+more bytes that provide parameters to the command. The parameters
+themselves may consist of several consecutive bytes; for example, the
+`\id{boc}' (beginning of character) command has six parameters, each
+of which is four bytes long. Parameters are usually regarded as
+nonnegative integers; but four-byte-long parameters can be either
+positive or negative, hence they range in value from $-2^{31}$ to
+$2^{31}-1$. As in \str{TFM} files, numbers that occupy more than one
+byte position appear in BigEndian order, and negative numbers appear
+in two's complement notation.
+
+A \str{GF} file consists of a ``preamble,'' followed by a sequence of
+one or more ``characters,'' followed by a ``postamble.'' The preamble
+is simply a \id{pre} command, with its parameters that introduce the
+file; this must come first. Each ``character'' consists of a
+\id{boc} command, followed by any number of other commands that
+specify ``black'' pixels, followed by an \id{eoc} command. The
+characters appear in the order that \MF\ generated them. If we ignore
+no-op commands (which are allowed between any two commands in the
+file), each \id{eoc} command is immediately followed by a \id{boc}
+command, or by a \id{post} command; in the latter case, there are no
+more characters in the file, and the remaining bytes form the
+postamble. Further details about the postamble will be explained
+later.
+
+Some parameters in \str{GF} commands are ``pointers.'' These are
+four-byte quantities that give the location number of some other byte
+in the file; the first file byte is number~0, then comes number~1,
+and so on.
+
+\medbreak
+
+The \str{GF} format is intended to be both compact and easily
+interpreted by a machine. Compactness is achieved by making most of
+the information relative instead of absolute. When a \str{GF}-reading
+program reads the commands for a character, it keeps track of two
+quantities: (a)~the current column number,~$m$; and (b)~the current
+row number,~$n$. These are 32-bit signed integers, although most
+actual font formats produced from \str{GF} files will need to curtail
+this vast range because of practical limitations. (\MF\ output will
+never allow $\vert m\vert$ or $\vert n\vert$ to get extremely large,
+but the \str{GF} format tries to be more general.)
+
+How do \str{GF}'s row and column numbers correspond to the
+conventions of \TeX\ and \MF? Well, the ``reference point'' of a
+character, in \TeX's view, is considered to be at the lower left
+corner of the pixel in row~0 and column~0. This point is the
+intersection of the baseline with the left edge of the type; it
+corresponds to location $(0,0)$ in \MF\ programs. Thus the pixel in
+\str{GF} row~0 and column~0 is \MF's unit square, comprising the
+region of the plane whose coordinates both lie between 0 and~1. The
+pixel in \str{GF} row~$n$ and column~$m$ consists of the points whose
+\MF\ coordinates $(x,y)$ satisfy $m\le x\le m+1$ and $n\le y\le n+1$.
+Negative values of $m$ and~$x$ correspond to columns of pixels {\sl
+left\/} of the reference point; negative values of $n$ and~$y$
+correspond to rows of pixels {\sl below\/} the baseline.
+
+Besides $m$ and $n$, there's also a third aspect of the current
+state, namely the \id{paint\_switch}, which is always either
+\id{black} or \id{white}. Each \id{paint} command advances $m$ by a
+specified amount~$d$, and blackens the intervening pixels if
+$\id{paint\_switch}=\id{black}$; then the \id{paint\_switch} changes
+to the opposite state. \str{GF}'s commands are designed so that $m$
+will never decrease within a row, and $n$ will never increase within
+a character; hence there is no way to whiten a pixel that has been
+blackened.
+
+
+\subsection{Summary of {\tt GF} commands}
+
+Here is a list of all the commands that may appear in a \str{GF}
+file. Each command is specified by its symbolic name ({\it e.g.},
+\id{boc}), its opcode byte ({\it e.g.}, 67), and its parameters (if any).
+The parameters are followed by a bracketed number telling how many
+bytes they occupy; for example, `$d[2]$' means that parameter $d$ is
+two bytes long.
+
+\cmd \id{paint\_0} 0,.
+ This is a \id{paint} command with $d=0$; it does nothing but change
+the \id{paint\_switch} from \id{black} to \id{white} or vice~versa.
+
+\cmd \id{paint\_1} through \id{paint\_63} (opcodes 1 to 63),.
+ These are \id{paint} commands with $d=1$ to~63, defined as follows:
+If $\id{paint\_switch}=\id{black}$, blacken $d$~pixels of the current
+row~$n$, in columns $m$ through $m+d-1$ inclusive. Then, in any case,
+complement the \id{paint\_switch} and advance $m$ by~$d$.
+
+\cmd \id{paint1} 64, d[1].
+ This is a \id{paint} command with a specified value of~$d$; \MF\
+uses it to paint when $64\le d<256$.
+
+\cmd \id{paint2} 65, d[2].
+ Same as \id{paint1}, but $d$~can be as high as~65535.
+
+\cmd \id{paint3} 66, d[3].
+ Same as \id{paint1}, but $d$~can be as high as $2^{24}-1$. \MF\
+never needs this command, and it is hard to imagine anybody making
+practical use of it; surely a more compact encoding will be desirable
+when characters can be this large. But the command is there, anyway,
+just in case.
+
+\cmd \id{boc} 67, c[+4] p[+4] \id{min\_m}[+4] \id{max\_m}[+4]
+ \id{min\_n}[+4] \id{max\_n}[+4].
+ Beginning of a character: Here $c$ is the character code, and $p$
+points to the previous character beginning (if any) for characters
+having this code number modulo 256. (The pointer $p$ is $-1$ if
+there was no prior character with an equivalent code.) The values of
+registers $m$ and $n$ defined by the instructions that follow for
+this character must satisfy $\id{min\_m}\le m\le \id{max\_m}$ and
+$\id{min\_n}\le n\le \id{max\_n}$. (The values of \id{max\_m} and
+\id{min\_n} need not be the tightest bounds possible.) When a
+\str{GF}-reading program sees a \id{boc}, it can use \id{min\_m},
+\id{max\_m}, \id{min\_n}, and \id{max\_n} to initialize the bounds of
+an array. Then it sets $m\gets \id{min\_m}$, $n\gets \id{max\_n}$,
+and $\id{paint\_switch}\gets \id{white}$.
+
+\cmd \id{boc1} 68, c[1] \id{del\_m}[1] \id{max\_m}[1] \id{del\_n}[1]
+ \id{max\_n}[1].
+ Same as \id{boc}, but $p$ is assumed to be~$-1$; also
+$\id{del\_m}=\id{max\_m}-\id{min\_m}$ and
+$\id{del\_n}=\id{max\_n}-\id{min\_n}$ are given instead of
+\id{min\_m} and \id{min\_n}. The one-byte parameters must be between
+0 and 255, inclusive. \ (This abbreviated \id{boc} saves 19~bytes per
+character, in common cases.)
+
+\cmd \id{eoc} 69,.
+ End of character: All pixels blackened so far constitute the pattern
+for this character. In particular, a completely blank character might
+have \id{eoc} immediately following \id{boc}.
+
+\cmd \id{skip0} 70,.
+ Decrease $n$ by 1 and set $m\gets \id{min\_m}$,
+$\id{paint\_switch}\gets \id{white}$. \ (This finishes one row and
+begins another, ready to whiten the leftmost pixel in the new row.)
+
+\cmd \id{skip1} 71, d[1].
+ Decrease $n$ by $d+1$, set $m\gets \id{min\_m}$, and set
+$\id{paint\_switch}\gets \id{white}$. This is a way to produce $d$
+all-white rows.
+
+\cmd \id{skip2} 72, d[2].
+ Same as \id{skip1}, but $d$ can be as large as 65535.
+
+\cmd \id{skip3} 73, d[3].
+ Same as \id{skip1}, but $d$ can be as large as $2^{24}-1$. \MF\
+obviously never needs this command.
+
+\cmd \id{new\_row\_0} 74,.
+ Decrease $n$ by 1 and set $m\gets \id{min\_m}$,
+$\id{paint\_switch}\gets \id{black}$. \ (This finishes one row and
+begins another, ready to {\sl blacken\/} the leftmost pixel in the
+new row.)
+
+\cmd \id{new\_row\_1} through \id{new\_row\_164} (opcodes 75 to 238),.
+ Same as \id{new\_row\_0}, but with $m\gets \id{min\_m}+1$ through
+$\id{min\_m}+164$, respectively.
+
+\cmd \id{xxx1} 239, k[1] x[k].
+ This command is undefined in general; it functions as a $(k+2)$-byte
+\id{no\_op} unless special \str{GF}-reading programs are being used.
+\MF\ generates \id{xxx} commands when encountering a \res{special}
+string; this occurs in the \str{GF} file only between characters,
+after the preamble, and before the postamble. However, \id{xxx}
+commands might appear anywhere in \str{GF} files generated by other
+processors. It is recommended that $x$ be a string having the form of
+a keyword followed by possible parameters relevant to that keyword.
+
+\cmd \id{xxx2} 240, k[2] x[k].
+ Like \id{xxx1}, but $0\le k<65536$.
+
+\cmd \id{xxx3} 241, k[3] x[k].
+ Like \id{xxx1}, but $0\le k<2^{24}$. \MF\ uses this when sending a
+\res{special} string whose length exceeds~255.
+
+\cmd \id{xxx4} 242, k[4] x[k].
+ Like \id{xxx1}, but $k$ can be ridiculously large; $k$ mustn't be
+negative.
+
+\cmd \id{yyy} 243, y[+4].
+ This command is undefined in general; it functions as a 5-byte
+\id{no\_op} unless special \str{GF}-reading programs are being used.
+\MF\ puts \id{scaled} numbers into \id{yyy}'s, as a result of
+\res{numspecial} commands; the intent is to provide numeric parameters
+to \id{xxx} commands that immediately precede.
+
+\cmd \id{no\_op} 244,.
+ No operation, do nothing. Any number of \id{no\_op}'s may occur
+between \str{GF} commands, but a \id{no\_op} cannot be inserted
+between a command and its parameters or between two parameters.
+
+\cmd \id{char\_loc} 245, c[1] \id{dx}[+4] \id{dy}[+4] w[+4] p[+4].
+ This command will appear only in the postamble, which will be
+explained shortly.
+
+\cmd \id{char\_loc0} 246, c[1] \id{dm}[1] w[+4] p[+4].
+ Same as \id{char\_loc}, except that \id{dy} is assumed to be zero,
+and the value of~\id{dx} is taken to be $65536\ast\id{dm}$, where
+$0\le \id{dm}<256$.
+
+\cmd \id{pre} 247, i[1] k[1] x[k].
+ Beginning of the preamble; this must come at the very beginning of
+the file. Parameter $i$ is an identifying number for \str{GF} format,
+currently 131. The other information is merely commentary; it is not
+given special interpretation like \id{xxx} commands are. (Note that
+\id{xxx} commands may immediately follow the preamble, before the
+first \id{boc}.)
+
+\cmd \id{post} 248,.
+ Beginning of the postamble, see below.
+
+\cmd \id{post\_post} 249,.
+ Ending of the postamble, see below.
+
+\smallskip
+
+\noindent Commands 250--255 are undefined at the present time.
+
+
+\subsection{The postamble}
+
+The last character in a \str{GF} file is followed by `\id{post}';
+this command introduces the postamble, which summarizes important
+facts that \MF\ has accumulated. The postamble has the form
+ %
+ \begin{center}
+ \begin{tabular}{l}
+ $\id{post}\ p[4]\ \id{ds}[4]\ \id{cs}[4]\ \id{hppp}[4]\ \id{vppp}[4]\
+ \id{min\_m}[+4]$\\
+ \qquad $\id{max\_m}[+4]\ \id{min\_n}[+4]\ \id{max\_n}[+4]$\\
+ $\langle\,$character locators$\,\rangle$\\
+ $\id{post\_post}\ q[4]\ i[1]\ \hbox{223's}[\ge 4]$\\
+ \end{tabular}
+ \end{center}
+%
+ Here $p$ is a pointer to the byte following the final \id{eoc} in
+the file (or to the byte following the preamble, if there are no
+characters); it can be used to locate the beginning of \id{xxx}
+commands that might have preceded the postamble. The \id{ds} and
+\id{cs} parameters give the design size and check sum, respectively,
+which are exactly the values put into the header of any \str{TFM}
+file that shares information with this \str{GF} file. Parameters
+\id{hppp} and \id{vppp} are the ratios of pixels per point,
+horizontally and vertically, expressed as \id{scaled} integers (i.e.,
+multiplied by $2^{16}$); they can be used to correlate the font with
+specific device resolutions, magnifications, and ``at sizes.'' Then
+come \id{min\_m}, \id{max\_m}, \id{min\_n}, and \id{max\_n}, which
+bound the values that registers $m$ and~$n$ assume in all characters
+in this \str{GF} file. (These bounds need not be the best possible;
+\id{max\_m} and \id{min\_n} may, on the other hand, be tighter than
+the similar bounds in \id{boc} commands. For example, some character
+may have $\id{min\_n}=-100$ in its \id{boc}, but it might turn out
+that $n$ never gets lower than $-50$ in any character; then
+\id{min\_n} can have any value $\le -50$. If there are no characters
+in the file, it's possible to have $\id{min\_m}>\id{max\_m}$ and/or
+$\id{min\_n}>\id{max\_n}$.)
+
+\medbreak
+
+Character locators are introduced by \id{char\_loc} commands, which
+specify a character residue~$c$, character escapements
+($\id{dx},\id{dy}$), a character width~$w$, and a pointer~$p$ to the
+beginning of that character. (If two or more characters have the same
+code~$c$ modulo 256, only the last will be indicated; the others can
+be located by following backpointers. Characters whose codes differ
+by a multiple of 256 are assumed to share the same font metric
+information, hence the \str{TFM} file contains only residues of
+character codes modulo~256. This convention is intended for oriental
+languages, when there are many character shapes but few distinct
+widths.)
+
+The character escapements ($\id{dx},\id{dy}$) are the values of \MF's
+\res{chardx} and \res{chardy} parameters; they are in units of
+\id{scaled} pixels; i.e., \id{dx} is in horizontal pixel units times
+$2^{16}$, and \id{dy} is in vertical pixel units times $2^{16}$.
+This is the intended amount of displacement after typesetting the
+character; for \str{DVI} files, \id{dy} should be zero, but other
+document file formats allow nonzero vertical escapement.
+
+The character width~$w$ duplicates the information in the \str{TFM}
+file; it is $2^{24}$ times the ratio of the true width to the font's
+design size.
+
+The backpointer $p$ points to the character's \id{boc}, or to the
+first of a sequence of consecutive \id{xxx} or \id{yyy} or
+\id{no\_op} commands that immediately precede the \id{boc}, if such
+commands exist; such ``special'' commands essentially belong to the
+characters, while the special commands after the final character
+belong to the postamble (i.e., to the font as a whole). This
+convention about $p$ applies also to the backpointers in \id{boc}
+commands, even though it wasn't explained in the description
+of~\id{boc}.
+
+Pointer $p$ might be $-1$ if the character exists in the \str{TFM}
+file but not in the \str{GF} file. This unusual situation can arise
+in \MF\ output if the user had $\id{proofing}<0$ when the character
+was being shipped out, but then made $\id{proofing}\ge 0$ in order to
+get a \str{GF} file.
+
+\medbreak
+
+The last part of the postamble, following the \id{post\_post} byte
+that signifies the end of the character locators, contains $q$, a
+pointer to the \id{post} command that started the postamble. An
+identification byte, $i$, comes next; this currently equals~131, as
+in the preamble.
+
+The $i$ byte is followed by four or more bytes that are all equal to
+the decimal number 223 (i.e., \H{DF} in hexadecimal). \MF\ puts out
+four to seven of these trailing bytes, until the total length of the
+file is a multiple of four bytes, since this works out best on
+machines that pack four bytes per word; but any number of 223's is
+allowed, as long as there are at least four of them. In effect, 223
+is a sort of signature that is added at the very end.
+
+This curious way to finish off a \str{GF} file makes it feasible for
+\str{GF}-reading programs to find the postamble first, on most
+computers, even though \MF\ wants to write the postamble last. Most
+operating systems permit random access to individual words or bytes
+of a file, so the \str{GF} reader can start at the end and skip
+backwards over the 223's until finding the identification byte. Then
+it can back up four bytes, read $q$, and move to byte $q$ of the
+file. This byte should, of course, contain the value 248 (\id{post});
+now the postamble can be read, so the \str{GF} reader can discover
+all the information needed for individual characters.
+
+
+
+
+\endinput
diff --git a/dviware/driv-standard/level-0/pk.tex b/dviware/driv-standard/level-0/pk.tex
new file mode 100644
index 0000000000..2577a49a65
--- /dev/null
+++ b/dviware/driv-standard/level-0/pk.tex
@@ -0,0 +1,606 @@
+% $Id: pk.tex,v 2.3.1.1 1991/08/08 16:21:26 schrod Released schrod $
+%------------------------------------------------------------
+% taken from PKtype 2.3
+
+%
+% definition of PK format
+% LaTeX markup
+%
+
+
+% $Log: pk.tex,v $
+% Revision 2.3.1.1 1991/08/08 16:21:26 schrod
+% CHANGES BY DON HOSEK:
+% -- Inserted \subsection's.
+% -- Deleted WEB defines.
+% -- `e.g.' now in italics, to be consistent with the rest of the
+% standard.
+%
+% CHANGES BY JOACHIM SCHROD:
+% -- Changed \bigbreak between WEB sections to \medbreak.
+% -- Added + signs to length specifications in \cmd tags, to show that
+% the param is signed.
+% -- Make formulas look more `math-like' and less `Pascal-like.'
+% -- Example and `packed number decoding algorithm' as figures.
+% -- Exchange this crude example picture with the explicite halign with
+% an environment for drawing letter examples.
+%
+% Revision 2.3 1990/11/15 19:03:50 schrod
+% integrated changes of 18 Nov 89 by Don: The weight of bits were specified
+% wrong and a few phrases were changed.
+% Please note that these changes make version 2.3, even if this is not
+% noted in the version history of PKtype. But the version change was made
+% both on the title page and in the banner message.
+%
+% Revision 2.2.1.2 90/07/17 00:00:00 schrod
+% two \& were forgotten.
+%
+% Revision 2.2.1.1 90/07/16 00:00:00 schrod
+% adapted to PKtype change of Don (Hosek? Knuth? -- 21 Oct 89).
+% changed \& to \res in documentation parts.
+% appended \endinput.
+%
+% Revision 2.2 90/07/04 00:00:00 schrod
+% extracted from PKtype 2.2
+%
+
+
+
+\section{Packed File Format}
+\label{pk-format}
+
+\subsection{Introduction}
+
+The packed file format is a compact representation of the data
+contained in a \str{GF} file. The information content is the same,
+but packed (\str{PK}) files are almost always less than half the size
+of their \str{GF} counterparts. They are also easier to convert into
+a raster representation because they do not have a profusion of
+\id{paint}, \id{skip}, and \id{new\_row} commands to be separately
+interpreted. In addition, the \str{PK} format expressedly forbids
+\res{special} commands within a character. The minimum bounding box
+for each character is explicit in the format, and does not need to be
+scanned for as in the \str{GF} format. Finally, the width and
+escapement values are combined with the raster information into
+character ``packets,'' making it simpler in many cases to process a
+character.
+
+A \str{PK} file is organized as a stream of 8-bit bytes. At times,
+these bytes might be split into 4-bit nybbles or single bits, or
+combined into multiple byte parameters. When bytes are split into
+smaller pieces, the `first' piece is always the most significant of
+the byte. For instance, the first bit of a byte is the bit with value
+128; the first nybble can be found by dividing a byte by 16.
+Similarly, when bytes are combined into multiple byte parameters, the
+first byte is the most significant of the parameter. If the parameter
+is signed, it is represented by two's-complement notation.
+
+The set of possible eight-bit values is separated into two sets,
+those that introduce a character definition, and those that do not.
+The values that introduce a character definition range from 0 to 239;
+byte values above 239 are interpreted as commands. Bytes that
+introduce character definitions are called flag bytes, and various
+fields within the byte indicate various things about how the
+character definition is encoded. Command bytes have zero or more
+parameters, and can never appear within a character definition or
+between parameters of another command, where they would be interpeted
+as data.
+
+A \str{PK} file consists of a preamble, followed by a sequence of one
+or more character definitions, followed by a postamble. The preamble
+command must be the first byte in the file, followed immediately by
+its parameters. Any number of character definitions may follow, and
+any command but the preamble command and the postamble command may
+occur between character definitions. The very last command in the
+file must be the postamble.
+
+\medbreak
+
+The packed file format is intended to be easy to read and interpret
+by device drivers. The small size of the file reduces the
+input/output overhead each time a font is loaded. For those drivers
+that load and save each font file into memory, the small size also
+helps reduce the memory requirements. The length of each character
+packet is specified, allowing the character raster data to be loaded
+into memory by simply counting bytes, rather than interpreting each
+command; then, each character can be interpreted on a demand basis.
+This also makes it possible for a driver to skip a particular
+character quickly if it knows that the character is unused.
+
+
+
+\subsection{Summary of {\tt PK} commands}
+
+First, the command bytes will be presented; then the format of the
+character definitions will be defined. Eight of the possible sixteen
+commands (values 240 through 255) are currently defined; the others
+are reserved for future extensions. The commands are listed below.
+Each command is specified by its symbolic name ({\it e.g.},
+\id{pk\_no\_op}), its opcode byte, and any parameters. The parameters
+are followed by a bracketed number telling how many bytes they
+occupy, with the number preceded by a plus sign if it is a signed
+quantity. (Four byte quantities are always signed, however.)
+
+\cmd \id{pk\_xxx1} 240, k[1] x[k].
+ This command is undefined in general; it functions as a $(k+2)$-byte
+\id{no\_op} unless special \str{PK}-reading programs are being used.
+\MF\ generates \id{xxx} commands when encountering a \res{special}
+string. It is recommended that $x$ be a string having the form of a
+keyword followed by possible parameters relevant to that keyword.
+
+\cmd \id{pk\_xxx2} 241, k[2] x[k].
+ Like \id{pk\_xxx1}, but $0\le k<65536$.
+
+\cmd \id{pk\_xxx3} 242, k[3] x[k].
+ Like \id{pk\_xxx1}, but $0\le k<2^{24}$. \MF\ uses this when sending
+a \res{special} string whose length exceeds~255.
+
+\cmd \id{pk\_xxx4} 243, k[4] x[k].
+ Like \id{pk\_xxx1}, but $k$ can be ridiculously large; $k$ musn't be
+negative.
+
+\cmd \id{pk\_yyy} 244, y[4].
+ This command is undefined in general; it functions as a five-byte
+\id{no\_op} unless special \str{PK} reading programs are being used.
+\MF\ puts \id{scaled} numbers into \id{yyy}'s, as a result of
+\res{numspecial} commands; the intent is to provide numeric
+parameters to \id{xxx} commands that immediately precede.
+
+\cmd \id{pk\_post} 245,.
+ Beginning of the postamble. This command is followed by enough
+\id{pk\_no\_op} commands to make the file a multiple of four bytes
+long. Zero through three bytes are usual, but any number is allowed.
+This should make the file easy to read on machines that pack four
+bytes to a word.
+
+\cmd \id{pk\_no\_op} 246,.
+ No operation, do nothing. Any number of \id{pk\_no\_op}'s may appear
+between \str{PK} commands, but a \id{pk\_no\_op} cannot be inserted
+between a command and its parameters, between two parameters, or
+inside a character definition.
+
+\cmd \id{pk\_pre} 247, i[1] k[1] x[k] \id{ds}[4] \id{cs}[4] \id{hppp}[4] %
+\id{vppp}[4].
+ Preamble command. Here, $i$ is the identification byte of the file,
+currently equal to 89. The string $x$ is merely a comment, usually
+indicating the source of the \str{PK} file. The parameters \id{ds}
+and \id{cs} are the design size of the file in $1/2^{20}$ points, and
+the checksum of the file, respectively. The checksum should match the
+\str{TFM} file and the \str{GF} files for this font. Parameters
+\id{hppp} and \id{vppp} are the ratios of pixels per point,
+horizontally and vertically, multiplied by $2^{16}$; they can be used
+to correlate the font with specific device resolutions,
+magnifications, and ``at sizes.''
+
+
+
+\subsection{Packing algorithms}
+
+The \str{PK} format has two conflicting goals: to pack character
+raster and size information as compactly as possible, while retaining
+ease of translation into raster and other forms. A suitable
+compromise was found in the use of run-encoding of the raster
+information. Instead of packing the individual bits of the character,
+we instead count the number of consecutive `black' or `white' pixels
+in a horizontal raster row, and then encode this number. Run counts
+are found for each row from left to right, traversing rows from the
+top to bottom. This is essentially the way the \str{GF} format works.
+Instead of presenting each row individually, however, we concatenate
+all of the horizontal raster rows into one long string of pixels, and
+encode this row. With knowledge of the width of the bit-map, the
+original character glyph can easily be reconstructed. In addition, we
+do not need special commands to mark the end of one row and the
+beginning of the next.
+
+Next, we place the burden of finding the minimum bounding box on the
+part of the font generator, since the characters will usually be used
+much more often than they are generated. The minimum bounding box is
+the smallest rectangle that encloses all `black' pixels of a
+character. We also eliminate the need for a special end of character
+marker, by supplying exactly as many bits as are required to fill the
+minimum bounding box, from which the end of the character is
+implicit.
+
+Let us next consider the distribution of the run counts. Analysis of
+several dozen pixel files at 300 dots per inch yields a distribution
+peaking at four, falling off slowly until ten, then a bit more
+steeply until twenty, and then asymptotically approaching the
+horizontal. Thus, the great majority of our run counts will fit in a
+four-bit nybble. The eight-bit byte is attractive for our run-counts,
+as it is the standard on many systems; however, the wasted four bits
+in the majority of cases seem a high price to pay. Another
+possibility is to use a Huffman-type encoding scheme with a variable
+number of bits for each run-count; this was rejected because of the
+overhead in fetching and examining individual bits in the file. Thus,
+the character raster definitions in the \str{PK} file format are
+based on the four-bit nybble.
+
+\medbreak
+
+An analysis of typical pixel files yielded another interesting
+statistic: Fully 37\,\% of the raster rows were duplicates of the
+previous row. Thus, the \str{PK} format allows the specification of
+repeat counts, which indicate how many times a horizontal raster row
+is to be repeated. These repeated rows are taken out of the character
+glyph before individual rows are concatenated into the long string of
+pixels.
+
+For elegance, we disallow a run count of zero. The case of a null
+raster description should be gleaned from the character width and
+height being equal to zero, and no raster data should be read. No
+other zero counts are ever necessary. Also, in the absence of repeat
+counts, the repeat value is set to be zero (only the original row is
+sent.) If a repeat count is seen, it takes effect on the current
+row. The current row is defined as the row on which the first pixel
+of the next run count will lie. The repeat count is set back to zero
+when the last pixel in the current row is seen, and the row is sent
+out.
+
+This poses a problem for entirely black and entirely white rows,
+however. Let us say that the current row ends with four white pixels,
+and then we have five entirely empty rows, followed by a black pixel
+at the beginning of the next row, and the character width is ten
+pixels. We would like to use a repeat count, but there is no legal
+place to put it. If we put it before the white run count, it will
+apply to the current row. If we put it after, it applies to the row
+with the black pixel at the beginning. Thus, entirely white or
+entirely black repeated rows are always packed as large run counts
+(in this case, a white run count of 54) rather than repeat counts.
+
+\medbreak
+
+Now we turn our attention to the actual packing of the run counts and
+repeat counts into nybbles. There are only sixteen possible nybble
+values. We need to indicate run counts and repeat counts. Since the
+run counts are much more common, we will devote the majority of the
+nybble values to them. We therefore indicate a repeat count by a
+nybble of 14 followed by a packed number, where a packed number will
+be explained later. Since the repeat count value of one is so common,
+we indicate a repeat one command by a single nybble of 15. A 14
+followed by the packed number 1 is still legal for a repeat one
+count. The run counts are coded directly as packed numbers.
+
+For packed numbers, therefore, we have the nybble values 0 through
+13. We need to represent the positive integers up to, say,
+$2^{31}-1$. We would like the more common smaller numbers to take
+only one or two nybbles, and the infrequent large numbers to take
+three or more. We could therefore allocate one nybble value to
+indicate a large run count taking three or more nybbles. We do this
+with the value 0.
+
+\medbreak
+
+We are left with the values 1 through 13. We can allocate some of
+these, say \id{dyn\_f}, to be one-nybble run counts. These will work
+for the run counts $1, \ldots, \id{dyn\_f}$. For subsequent run counts, we
+will use a nybble greater than \id{dyn\_f}, followed by a second
+nybble, whose value can run from 0 through 15. Thus, the two-nybble
+values will run from
+$\id{dyn\_f}+1, \ldots, (13-\id{dyn\_f})\ast16+\id{dyn\_f}$. We have our
+definition of large run count values now, being all counts greater
+than $(13-\id{dyn\_f})\ast16+\id{dyn\_f}$.
+
+We can analyze our several dozen pixel files and determine an optimal
+value of \id{dyn\_f}, and use this value for all of the characters.
+Unfortunately, values of \id{dyn\_f} that pack small characters well
+tend to pack the large characters poorly, and values that pack large
+characters well are not efficient for the smaller characters. Thus,
+we choose the optimal \id{dyn\_f} on a character basis, picking the
+value that will pack each individual character in the smallest number
+of nybbles. Legal values of \id{dyn\_f} run from 0 (with no
+one-nybble run counts) to 13 (with no two-nybble run counts).
+
+\medbreak
+
+Our only remaining task in the coding of packed numbers is the large
+run counts. We use a scheme suggested by {\sc D.\,E.~Knuth} that
+simply and elegantly represents arbitrarily large values. The general
+scheme to represent an integer $i$ is to write its hexadecimal
+representation, with leading zeros removed. Then we count the number
+of digits, and prepend one less than that many zeros before the
+hexadecimal representation. Thus, the values from one to fifteen
+occupy one nybble; the values sixteen through 255 occupy three, the
+values 256 through 4095 require five, etc.
+
+For our purposes, however, we have already represented the numbers
+one through $(13-\id{dyn\_f})\ast16+\id{dyn\_f}$. In addition, the
+one-nybble values have already been taken by our other commands,
+which means that only the values from sixteen up are available to us
+for long run counts. Thus, we simply normalize our long run counts,
+by subtracting $(13-\id{dyn\_f})\ast16+\id{dyn\_f}+1$ and adding 16,
+and then we represent the result according to the scheme above.
+
+
+
+\subsection{Decoding {\tt PK} files}
+
+The final algorithm for decoding the run counts based on the above
+scheme might look like the Pascal routine in
+figure~\ref{fig:pk_packed_num}, assuming that a procedure called
+\id{pk\_nyb} is available to get the next nybble from the file, and
+assuming that the global \id{repeat\_count} indicates whether a row
+needs to be repeated. Note that this routine is recursive, but since
+a repeat count can never directly follow another repeat count, it can
+only be recursive to one level.
+
+\begin{figure*}
+\begin{webprog}
+\P\4\&{function}\1\ \37\\{pk\_packed\_num}: \37\\{integer};\6
+\4\&{var} \37$\|i,\39\|j$: \37\\{integer};\2\6
+\&{begin}\5
+$\|i\K\\{get\_nyb}$;\6
+\&{if} $\|i=0$ \1\&{then}\6
+\&{begin}\6
+\1\&{repeat}\5
+$\|j\K\\{get\_nyb}$;\5
+$\\{incr}(\|i)$;\6
+\4\&{until}\5
+$\|j\I0$;\2\6
+\&{while} $\|i>0$ \1\&{do}\6
+\&{begin}\5
+$\|j\K\|j\ast16+\\{get\_nyb}$;\5
+$\\{decr}(\|i)$;\6
+\&{end};\2\6
+$\\{pk\_packed\_num}\K\|j-15+(13-\\{dyn\_f})\ast16+\\{dyn\_f}$;\6
+\&{end}\6
+\4\&{else} \&{if} $\|i\L\\{dyn\_f}$ \1\&{then}\5
+$\\{pk\_packed\_num}\K\|i$\6
+\4\&{else} \&{if} $\|i<14$ \1\&{then}\5
+$\\{pk\_packed\_num}\K(\|i-\\{dyn\_f}-1)\ast16+\\{get\_nyb}+\\{dyn\_f}+1$\6
+\4\&{else} \&{begin}\6
+\&{if} $\\{repeat\_count}\I0$ \1\&{then}\5
+$\\{abort}(\.{\'Second\ repeat\ count\ for\ this\ row!\'})$;\2\6
+$\\{repeat\_count}\K1$;\C{prevent recursion more than one level}\6
+\&{if} $\|i=14$ \1\&{then}\5
+! $\\{repeat\_count}\K\\{pk\_packed\_num}$;\2\6
+$\\{send\_out}(\\{true},\39\\{repeat\_count})$;\5
+$\\{pk\_packed\_num}\K\\{pk\_packed\_num}$;\6
+\&{end};\2\2\2\6
+\&{end};\par
+\end{webprog}
+\caption{Algorithm for decoding run counts in a \protect\str{PK} file}
+\label{fig:pk_packed_num}
+\end{figure*}
+
+\medbreak
+
+For low resolution fonts, or characters with `gray' areas, run
+encoding can often make the character many times larger. Therefore,
+for those characters that cannot be encoded efficiently with run
+counts, the \str{PK} format allows bit-mapping of the characters.
+This is indicated by a \id{dyn\_f} value of 14. The bits are packed
+tightly, by concatenating all of the horizontal raster rows into one
+long string, and then packing this string eight bits to a byte. The
+number of bytes required can be calculated by $\lfloor
+(\id{width}\ast\id{height}+7) / 8 \rfloor$. This format should only
+be used when packing the character by run counts takes more bytes
+than this, although, of course, it is legal for any character. Any
+extra bits in the last byte should be set to zero.
+
+\medbreak
+
+At this point, we are ready to introduce the format for a character
+descriptor. It consists of three parts: a flag byte, a character
+preamble, and the raster data. The most significant four bits of the
+flag byte yield the \id{dyn\_f} value for that character. (Notice
+that only values of 0 through 14 are legal for \id{dyn\_f}, with 14
+indicating a bit mapped character; thus, the flag bytes do not
+conflict with the command bytes, whose upper nybble is always 15.)
+The next bit (with weight 8) indicates whether the first run count
+is a black count or a white count, with a one indicating a black
+count. For bit-mapped characters, this bit should be set to a zero.
+The next bit (with weight 4) indicates whether certain later
+parameters (referred to as size parameters) are given in one-byte or
+two-byte quantities, with a one indicating that they are in two-byte
+quantities. The last two bits are concatenated on to the beginning of
+the packet-length parameter in the character preamble, which will be
+explained below.
+
+However, if the last three bits of the flag byte are all set
+(normally indicating that the size parameters are two-byte values and
+that a 3 should be prepended to the length parameter), then a long
+format of the character preamble should be used instead of one of the
+short forms.
+
+Therefore, there are three formats for the character preamble; the
+one that is used depends on the least significant three bits of the
+flag byte. If the least significant three bits are in the range zero
+through three, the short format is used. If they are in the range
+four through six, the extended short format is used. Otherwise, if
+the least significant bits are all set, then the long form of the
+character preamble is used. The preamble formats are explained below.
+
+\begin{description}
+\let\sp=\ % % save meaning of `\ ' in this env
+\everymath{\def\ {\allowbreak\sp}} % allow line break within math list
+
+\item[Short form]
+ $\id{flag}[1]\ \id{pl}[1]\ \id{cc}[1]\ \id{tfm}[3]\
+ \id{dm}[1]\ w[1]\ h[1]\ \id{hoff}[+1]\ \id{voff}[+1]$.\\
+ If this format of the character preamble is used, the above
+parameters must all fit in the indicated number of bytes, signed or
+unsigned as indicated. Almost all of the standard \TeX\ font
+characters fit; the few exceptions are fonts such as \str{cminch}.
+
+\item[Extended short form]
+ $\id{flag}[1]\ \id{pl}[2]\ \id{cc}[1]\ \id{tfm}[3]\ \id{dm}[2]\ w[2]\ h[2]\
+ \id{hoff}[+2]\ \id{voff}[+2]$.\\
+ Larger characters use this extended format.
+
+\item[Long form]
+ $\id{flag}[1]\ \id{pl}[4]\ \id{cc}[4]\ \id{tfm}[4]\ \id{dx}[4]\ \id{dy}[4]\
+ w[4]\ h[4]\ \id{hoff}[4]\ \id{voff}[4]$.\\
+ This is the general format which allows all of the parameters of the
+\str{GF} file format, including vertical escapement.
+
+\end{description}
+%
+ The \id{flag} parameter is the flag byte. The parameter \id{pl}
+(packet length) contains the offset of the byte following this
+character descriptor, with respect to the beginning of the \id{tfm}
+width parameter. This is given so a \str{PK} reading program can,
+once it has read the flag byte, packet length, and character code
+(\id{cc}), skip over the character by simply reading this many more
+bytes. For the two short forms of the character preamble, the last
+two bits of the flag byte should be considered the two
+most-significant bits of the packet length. For the short format, the
+true packet length might be calculated as
+$(\id{flag} \bmod 4)\cdot 256+\id{pl}$; for the short
+extended format, it might be calculated as
+$(\id{flag} \bmod 4)\cdot 65536+\id{pl}$.
+
+The $w$ parameter is the width and the $h$ parameter is the height in
+pixels of the minimum bounding box. The \id{dx} and \id{dy}
+parameters are the horizontal and vertical escapements, respectively.
+In the short formats, \id{dy} is assumed to be zero and \id{dm} is
+\id{dx} but in pixels; in the long format, \id{dx} and \id{dy} are
+both in pixels multiplied by $2^{16}$. The \id{hoff} is the
+horizontal offset from the upper left pixel to the reference pixel;
+the \id{voff} is the vertical offset. They are both given in pixels,
+with right and down being positive. The reference pixel is the pixel
+that occupies the unit square in \MF; the \MF\ reference point is the
+lower left hand corner of this pixel. (See the example below.)
+
+\medbreak
+
+\TeX\ requires all characters that have the same character codes
+modulo 256 to have also the same \id{tfm} widths and escapement
+values. The \str{PK} format does not itself make this a requirement,
+but in order for the font to work correctly with the \TeX\ software,
+this constraint should be observed. (The standard version of \TeX\
+cannot output character codes greater than 255, but extended versions
+do exist.)
+
+Following the character preamble is the raster information for the
+character, packed by run counts or by bits, as indicated by the flag
+byte. If the character is packed by run counts and the required
+number of nybbles is odd, then the last byte of the raster
+description should have a zero for its least significant nybble.
+
+
+
+\subsection{An example character}
+
+As an illustration of the \str{PK} format, the character \char4\ from
+the font {\tt amr10\/} at 300 dots per inch will be encoded. This
+character was chosen because it illustrates some of the borderline
+cases. The raster for the character is shown in
+figure~\ref{fig:pk-char-pic}.
+%
+ \begin{figure*}[tb]
+\begin{paintletter}
+& ********************
+& ********************
+& ********************
+& ********************
+& ** **
+& ** **
+& ** **
+&
+&
+& ** **
+& ** **
+& ** **
+& ****************
+& ****************
+& ****************
+& ****************
+& ** **
+& ** **
+& ** **
+&
+&
+&
+& ** **
+& ** **
+& ** **
+& ********************
+& ********************
+& ********************
+&+ ********************
+\end{paintletter}
+\caption{Character \char4{} of {\tt amr10} (the row numbers are
+ chosen for convenience, and are not \protect\MF's row numbers.)}
+\label{fig:pk-char-pic}
+\end{figure*}
+%
+ The width of the minimum bounding box for this character is 20; its
+height is 29. The `+' represents the reference pixel; notice how it
+lies outside the minimum bounding box. The \id{hoff} value is $-2$,
+and the \id{voff} is~28.
+
+The first task is to calculate the run counts and repeat counts. The repeat
+counts are placed at the first transition (black to white or white to black)
+in a row, and are enclosed in brackets. White counts are enclosed in
+parentheses. It is relatively easy to generate the counts list:
+%
+ \begin{center}
+ 82 [2] (16) 2 (42) [2] 2 (12) 2 (4) [3]\\
+ 16 (4) [2] 2 (12) 2 (62) [2] 2 (16) 82\\
+ \end{center}
+%
+ Note that any duplicated rows that are not all white or all black
+are removed before the run counts are calculated. The rows thus
+removed are rows 5, 6, 10, 11, 13, 14, 15, 17, 18, 23, and 24.
+
+\medbreak
+
+The next step in the encoding of this character is to calculate the
+optimal value of \id{dyn\_f}. The details of how this calculation is
+done are not important here; suffice it to say that there is a simple
+algorithm that can determine the best value of \id{dyn\_f} in one
+pass over the count list. For this character, the optimal value turns
+out to be 8 (atypically low). Thus, all count values less than or
+equal to 8 are packed in one nybble; those from nine to $(13-8)*16+8$
+or 88 are packed in two nybbles. The run encoded values now become
+(in hex, separated according to the above list):
+%
+ \begin{center}
+ \tt
+ D9 E2 97 2 B1 E2 2 93 2 4 E3\\
+ 97 4 E2 2 93 2 C5 E2 2 97 D9\\
+ \end{center}
+%
+ which comes to 36 nybbles, or 18 bytes. This is shorter than the 73
+bytes required for the bit map, so we use the run count packing.
+
+\medbreak
+
+The short form of the character preamble is used because all of the
+parameters fit in their respective lengths. The packet length is
+therefore 18 bytes for the raster, plus eight bytes for the character
+preamble parameters following the character code, or 26. The \id{tfm}
+width for this character is 640796, or {\tt 9C71C} in hexadecimal.
+The horizontal escapement is 25 pixels. The flag byte is 88 hex,
+indicating the short preamble, the black first count, and the
+\id{dyn\_f} value of 8. The final total character packet, in
+hexadecimal, is given in figure~\ref{fig:pk-char-xd}.
+
+\begin{figure}
+\begin{center}
+\begin{tabular}{r@{\qquad}lll}
+ Flag byte& \tt 88\\
+ Packet length& \tt 1A\\
+ Character code& \tt 04\\
+ \id{tfm} width& \tt 09& \tt C7& \tt 1C\\
+ Horizontal escapement (pixels)& \tt 19\\
+ Width of bit map& \tt 14\\
+ Height of bit map& \tt 1D\\
+ Horizontal offset (signed)& \tt FE\\
+ Vertical offset& \tt 1C\\
+ Raster data& \tt D9& \tt E2& \tt 97\\
+ & \tt 2B& \tt 1E& \tt 22\\
+ & \tt 93& \tt 24& \tt E3\\
+ & \tt 97& \tt 4E& \tt 22\\
+ & \tt 93& \tt 2C& \tt 5E\\
+ & \tt 22& \tt 97& \tt D9\\
+\end{tabular}
+\end{center}
+\caption{\protect\str{PK} character packet for \char4{} of {\tt amr10}}
+\label{fig:pk-char-xd}
+\end{figure}
+
+
+
+
+\endinput
diff --git a/dviware/driv-standard/level-0/tfm.tex b/dviware/driv-standard/level-0/tfm.tex
new file mode 100644
index 0000000000..ef0ed2d417
--- /dev/null
+++ b/dviware/driv-standard/level-0/tfm.tex
@@ -0,0 +1,391 @@
+% $Id: tfm.tex,v 3.1.1.1 1991/08/08 16:04:39 schrod Released schrod $
+%------------------------------------------------------------
+% taken from TFtoPL 3.1
+
+%
+% definition of TFM format
+% LaTeX markup
+%
+
+
+% $Log: tfm.tex,v $
+% Revision 3.1.1.1 1991/08/08 16:04:39 schrod
+% CHANGES BY DON HOSEK:
+% -- Inserted \subsection's.
+% -- Deleted WEB defines.
+% -- `e.g.' now in italics, to be consistent with the rest of the
+% standard.
+%
+% CHANGES BY JOACHIM SCHROD:
+% -- Changed \bigbreak between WEB sections to \medbreak.
+% -- Added + signs to length specifications in \cmd tags, to show that
+% the param is signed.
+% -- Make formulas look more `math-like' and less `Pascal-like.'
+% -- Reformatted table of TFM header to fit in a TUGboat column. The
+% same with the definition of the |lf| entry.
+%
+% Revision 3.1 1990/11/15 17:51:05 schrod
+% corrected comment which explains where this text comes from.
+% (TFtoPL 3.1 instead of VFtoVP 1.0). Updated version number accordingly.
+%
+% Revision 1.0.1.1 90/07/16 00:00:00 schrod
+% appended \endinput.
+%
+% Revision 1.0 90/07/04 00:00:00 schrod
+% Initial revision
+%
+
+
+
+\section{Font metric data}
+\label{tfm-format}
+
+\subsection{Introduction}
+
+The idea behind \str{TFM} files is that typesetting routines like
+\TeX\ need a compact way to store the relevant information about
+several dozen fonts, and computer centers need a compact way to store
+the relevant information about several hundred fonts. \str{TFM} files
+are compact, and most of the information they contain is highly
+relevant, so they provide a solution to the problem.
+
+The information in a \str{TFM} file appears in a sequence of 8-bit
+bytes. Since the number of bytes is always a multiple of 4, we could
+also regard the file as a sequence of 32-bit words; but \TeX\ uses
+the byte interpretation, and so do we. Note that the bytes are
+considered to be unsigned numbers.
+
+
+
+\subsection{Summary of {\tt TFM} files}
+
+\subsubsection{The header}
+
+The first 24 bytes (6 words) of a \str{TFM} file contain twelve
+16-bit integers that give the lengths of the various subsequent
+portions of the file. These twelve integers are, in order:
+ %
+ \begin{center}
+ \begin{tabular}{r@{${}={}$}l}
+ \id{lf} & length of the entire file, in words;\\
+ \id{lh} & length of the header data, in words;\\
+ \id{bc} & smallest character code in the font;\\
+ \id{ec} & largest character code in the font;\\
+ \id{nw} & number of words in the width table;\\
+ \id{nh} & number of words in the height table;\\
+ \id{nd} & number of words in the depth table;\\
+ \id{ni} & number of words in the\\
+ \multicolumn2{r}{italic correction table;}\\
+ \id{nl} & number of words in the lig/kern table;\\
+ \id{nk} & number of words in the kern table;\\
+ \id{ne} & number of words in the\\
+ \multicolumn2{r}{extensible character table;}\\
+ \id{np} & number of font parameter words.\\
+\end{tabular}
+\end{center}
+%
+ They are all nonnegative and less than $2^{15}$. We must have
+$\id{bc}-1\le \id{ec}\le 255$, $\id{ne}\le 256$, and
+$$
+ \displaylines{
+ \quad \id{lf} = 6+\id{lh}+(\id{ec}-\id{bc}+1)+\id{nw}+\id{nh}\hfill\cr
+\noalign{\nobreak}
+ \hfill {} +\id{nd}+\id{ni}+\id{nl}+\id{nk}+\id{ne}+\id{np}.\quad\cr
+ }
+$$
+ Note that a font may contain as many as 256 characters (if
+$\id{bc}=0$ and $\id{ec}=255$), and as few as 0 characters (if
+$\id{bc}=\id{ec}+1$).
+
+Incidentally, when two or more 8-bit bytes are combined to form an
+integer of 16 or more bits, the most significant bytes appear first
+in the file. This is called BigEndian order.
+
+
+
+\subsubsection{{\tt TFM} data}
+
+The rest of the \str{TFM} file may be regarded as a sequence of ten
+data arrays having the informal specification
+$$
+ \def\arr$[#1]#2${$\colon \res{array}\ [#1]$ \res{of} #2}
+\vbox{\ialign{\hfil\id{#}& \arr#\hfil\cr
+ header&$[0\to\id{lh}-1]\id{stuff}$\cr
+ char\_info&$[\id{bc}\to\id{ec}]\id{char\_info\_word}$\cr
+ width&$[0\to\id{nw}-1]\id{fix\_word}$\cr
+ height&$[0\to\id{nh}-1]\id{fix\_word}$\cr
+ depth&$[0\to\id{nd}-1]\id{fix\_word}$\cr
+ italic&$[0\to\id{ni}-1]\id{fix\_word}$\cr
+ lig\_kern&$[0\to\id{nl}-1]\id{lig\_kern\_command}$\cr
+ kern&$[0\to\id{nk}-1]\id{fix\_word}$\cr
+ exten&$[0\to\id{ne}-1]\id{extensible\_recipe}$\cr
+ param&$[1\to\id{np}]\id{fix\_word}$\cr
+}}
+$$
+ The most important data type used here is a \id{fix\_word}, which is
+a 32-bit representation of a binary fraction. A \id{fix\_word} is a
+signed quantity, with the two's complement of the entire word used to
+represent negation. Of the 32 bits in a \id{fix\_word}, exactly 12
+are to the left of the binary point; thus, the largest \id{fix\_word}
+value is $2048-2^{-20}$, and the smallest is $-2048$. We will see
+below, however, that all but one of the \id{fix\_word} values will
+lie between $-16$ and $+16$.
+
+\medbreak
+
+The first data array is a block of header information, which contains
+general facts about the font. The header must contain at least two
+words, and for \str{TFM} files to be used with Xerox printing
+software it must contain at least 18 words, allocated as described
+below. When different kinds of devices need to be interfaced, it may
+be necessary to add further words to the header block.
+
+\begin{description}
+
+\item[{$\id{header}[0]$}] is a 32-bit check sum that \TeX\ will
+copy into the \str{DVI} output file whenever it uses the font. Later
+on when the \str{DVI} file is printed, possibly on another computer,
+the actual font that gets used is supposed to have a check sum that
+agrees with the one in the \str{TFM} file used by \TeX. In this way,
+users will be warned about potential incompatibilities. (However, if
+the check sum is zero in either the font file or the \str{TFM} file,
+no check is made.) The actual relation between this check sum and
+the rest of the \str{TFM} file is not important; the check sum is
+simply an identification number with the property that incompatible
+fonts almost always have distinct check sums.
+
+\item[{$\id{header}[1]$}] is a \id{fix\_word} containing the design
+size of the font, in units of \TeX\ points (7227 \TeX\ points = 254
+cm). This number must be at least 1.0; it is fairly arbitrary, but
+usually the design size is 10.0 for a ``10 point'' font, i.e., a font
+that was designed to look best at a 10-point size, whatever that
+really means. When a \TeX\ user asks for a font `\str{at} $\delta$
+\str{pt}', the effect is to override the design size and replace it
+by $\delta$, and to multiply the $x$ and~$y$ coordinates of the
+points in the font image by a factor of $\delta$ divided by the
+design size. {\sl All other dimensions in the\/ \str{TFM} file are
+\id{fix\_word}\kern-1pt\ numbers in design-size units.} Thus, for
+example, the value of $\id{param}[6]$, one \str{em} or \str{\\quad},
+is often the \id{fix\_word} value $2^{20}=1.0$, since many fonts have
+a design size equal to one em. The other dimensions must be less than
+16 design-size units in absolute value; thus, $\id{header}[1]$ and
+$\id{param}[1]$ are the only \id{fix\_word} entries in the whole
+\str{TFM} file whose first byte might be something besides 0 or 255.
+
+\item[{$\id{header}[2\ldots11],$}] if present, contains 40 bytes that
+identify the character coding scheme. The first byte, which must be
+between 0 and 39, is the number of subsequent ASCII bytes actually
+relevant in this string, which is intended to specify what
+character-code-to-symbol convention is present in the font. Examples
+are \str{ASCII} for standard ASCII, \str{TeX text} for fonts like
+\str{cmr10} and \str{cmti9}, \str{TeX math extension} for
+\str{cmex10}, \str{XEROX text} for Xerox fonts, \str{GRAPHIC} for
+special-purpose non-alphabetic fonts, \str{UNSPECIFIED} for the
+default case when there is no information. Parentheses should not
+appear in this name. (Such a string is said to be in {\small BCPL}
+format.)
+
+\item[{$\id{header}[12\ldots16]$,}] if present, contains 20 bytes that
+name the font family ({\it e.g.}, \str{CMR} or \str{HELVETICA}), in {\small
+BCPL} format. This field is also known as the ``font identifier.''
+
+\item[{$\id{header}[17]$,}] if present, contains a first byte
+called the \id{seven\_bit\_safe\_flag}, then two bytes that are
+ignored, and a fourth byte called the \id{face}. If the value of the
+fourth byte is less than 18, it has the following interpretation as a
+``weight, slope, and expansion'': Add 0 or 2 or 4 (for medium or
+bold or light) to 0 or 1 (for roman or italic) to 0 or 6 or 12 (for
+regular or condensed or extended). For example, 13 is 0+1+12, so it
+represents medium italic extended. A three-letter code ({\it e.g.},
+\str{MIE}) can be used for such \id{face} data.
+
+\item[{$\id{header}[18\ldots{\rm whatever}]$}] might also be present;
+the individual words are simply called $\id{header}[18]$,
+$\id{header}[19]$, etc., at the moment.
+
+\end{description}
+
+\medbreak
+
+Next comes the \id{char\_info} array, which contains one
+\id{char\_info\_word} per character. Each \id{char\_info\_word}
+contains six fields packed into four bytes as follows.
+
+\begin{description}
+
+\item[first byte] \id{width\_index} (8 bits)
+
+\item[second byte] \id{height\_index} (4 bits) times 16, plus
+\id{depth\_index} (4~bits)
+
+\item[third byte] \id{italic\_index} (6 bits) times 4, plus \id{tag}
+(2~bits)
+
+\item[fourth byte] \id{remainder} (8 bits)
+
+\end{description}
+%
+ The actual width of a character is $\id{width}[\id{width\_index}]$,
+in design-size units; this is a device for compressing information,
+since many characters have the same width. Since it is quite common
+for many characters to have the same height, depth, or italic
+correction, the \str{TFM} format imposes a limit of 16 different
+heights, 16 different depths, and 64 different italic corrections.
+
+Incidentally, the relation
+$\id{width}[0]=\id{height}[0]=\id{depth}[0]=\id{italic}[0]=0$ should
+always hold, so that an index of zero implies a value of zero. The
+\id{width\_index} should never be zero unless the character does not
+exist in the font, since a character is valid if and only if it lies
+between \id{bc} and \id{ec} and has a nonzero \id{width\_index}.
+
+\medbreak
+
+The \id{tag} field in a \id{char\_info\_word} has four values that
+explain how to interpret the \id{remainder} field.
+
+\begin{description}
+
+\item[$\id{tag}=0\ (\id{no\_tag})$] means that \id{remainder} is
+unused.
+
+\item[$\id{tag}=1\ (\id{lig\_tag})$] means that this character has a
+ligature/kerning program starting at
+$\id{lig\_kern}[\id{remainder}]$.
+
+\item[$\id{tag}=2\ (\id{list\_tag})$] means that this character is
+part of a chain of characters of ascending sizes, and not the largest
+in the chain. The \id{remainder} field gives the character code of
+the next larger character.
+
+\item[$\id{tag}=3\ (\id{ext\_tag})$] means that this character code
+represents an extensible character, i.e., a character that is built
+up of smaller pieces so that it can be made arbitrarily large. The
+pieces are specified in $\id{exten}[\id{remainder}]$.
+
+\end{description}
+
+\medbreak
+
+The \id{lig\_kern} array contains instructions in a simple
+programming language that explains what to do for special letter
+pairs. Each word is a \id{lig\_kern\_command} of four bytes.
+
+\begin{description}
+
+\item[first byte] \id{skip\_byte}, indicates that this is the
+final program step if the byte is 128 or more, otherwise the next
+step is obtained by skipping this number of intervening steps.
+
+\item[second byte] \id{next\_char}: ``if \id{next\_char} follows the
+current character, then perform the operation and stop, otherwise
+continue.''
+
+\item[third byte] \id{op\_byte}, indicates a ligature step if less
+than~128, a kern step otherwise.
+
+\item[fourth byte] \id{remainder}.
+
+\end{description}
+%
+ In a kern step, an additional space equal to
+$\id{kern}[256(\id{op\_byte}-128)+\id{remainder}]$ is inserted
+between the current character and \id{next\_char}. This amount is
+often negative, so that the characters are brought closer together by
+kerning; but it might be positive.
+
+There are eight kinds of ligature steps, having \id{op\_byte} codes
+$4a+2b+c$ where $0\le a\le b+c$ and $0\le b,c\le 1$. The character whose
+code is \id{remainder} is inserted between the current character and
+\id{next\_char}; then the current character is deleted if $b=0$, and
+\id{next\_char} is deleted if $c=0$; then we pass over $a$~characters
+to reach the next current character (which may have a
+ligature/kerning program of its own).
+
+Notice that if $a=0$ and $b=1$, the current character is unchanged;
+if $a=b$ and $c=1$, the current character is changed but the next
+character is unchanged.
+
+If the very first instruction of the \id{lig\_kern} array has
+$\id{skip\_byte}=255$, the \id{next\_char} byte is the so-called
+right boundary character of this font; the value of \id{next\_char}
+need not lie between \id{bc} and~\id{ec}. If the very last
+instruction of the \id{lig\_kern} array has $\id{skip\_byte}=255$,
+there is a special ligature/kerning program for a left boundary
+character, beginning at location
+$256\id{op\_byte}+\id{remainder}$. The interpretation is that
+\TeX\ puts implicit boundary characters before and after each
+consecutive string of characters from the same font. These implicit
+characters do not appear in the output, but they can affect ligatures
+and kerning.
+
+If the very first instruction of a character's \id{lig\_kern} program
+has $\id{skip\_byte}>128$, the program actually begins in location
+$256\id{op\_byte}+\id{remainder}$. This feature allows access to
+large \id{lig\_kern} arrays, because the first instruction must
+otherwise appear in a location $\le 255$.
+
+Any instruction with $\id{skip\_byte}>128$ in the \id{lig\_kern}
+array must have $256\id{op\_byte}+\id{remainder}<\id{nl}$. If
+such an instruction is encountered during normal program execution,
+it denotes an unconditional halt; no ligature command is performed.
+
+\medbreak
+
+Extensible characters are specified by an \id{extensible\_recipe},
+which consists of four bytes called \id{top}, \id{mid}, \id{bot}, and
+\id{rep} (in this order). These bytes are the character codes of
+individual pieces used to build up a large symbol. If \id{top},
+\id{mid}, or \id{bot} are zero, they are not present in the built-up
+result. For example, an extensible vertical line is like an
+extensible bracket, except that the top and bottom pieces are
+missing.
+
+\medbreak
+
+\noindent The final portion of a \str{TFM} file is the \id{param}
+array, which is another sequence of \id{fix\_word} values.
+
+\begin{description}
+
+\item[{$\id{param}[1]=\id{slant}$}] is the amount of italic slant,
+which is used to help position accents. For example,
+$\id{slant}=0.25$ means that when you go up one unit, you also go
+0.25 units to the right. The \id{slant} is a pure number; it's the
+only \id{fix\_word} other than the design size itself that is not
+scaled by the design size.
+
+\item[{$\id{param}[2]=\id{space}$}] is the normal spacing between words
+in text. Note that character \str{"\ "} in the font need not have
+anything to do with blank spaces.
+
+\item[{$\id{param}[3]=\id{space\_stretch}$}] is the amount of glue
+stretching between words.
+
+\item[{$\id{param}[4]=\id{space\_shrink}$}] is the amount of glue
+shrinking between words.
+
+\item[{$\id{param}[5]=\id{x\_height}$}] is the height of letters for
+which accents don't have to be raised or lowered.
+
+\item[{$\id{param}[6]=\id{quad}$}] is the size of one em in the font.
+
+\item[{$\id{param}[7]=\id{extra\_space}$}] is the amount added to
+$\id{param}[2]$ at the ends of sentences.
+
+\end{description}
+
+When the character coding scheme is \str{TeX math symbols}, the font
+is supposed to have 15 additional parameters called \id{num1},
+\id{num2}, \id{num3}, \id{denom1}, \id{denom2}, \id{sup1}, \id{sup2},
+\id{sup3}, \id{sub1}, \id{sub2}, \id{supdrop}, \id{subdrop},
+\id{delim1}, \id{delim2}, and \id{axis\_height}, respectively. When
+the character coding scheme is \str{TeX math extension}, the font is
+supposed to have six additional parameters called
+\id{default\_rule\_thickness} and \id{big\_op\_spacing1} through
+\id{big\_op\_spacing5}.
+
+
+
+
+\endinput
diff --git a/dviware/driv-standard/papers/alltt.sty b/dviware/driv-standard/papers/alltt.sty
new file mode 100644
index 0000000000..b7290b7563
--- /dev/null
+++ b/dviware/driv-standard/papers/alltt.sty
@@ -0,0 +1,32 @@
+% ALLTT DOCUMENT-STYLE OPTION - released 17 December 1987
+% for LaTeX version 2.09
+% Copyright (C) 1987 by Leslie Lamport
+
+% Defines the `alltt' environment, which is like the `verbatim'
+% environment except that `\', `\{', and `\}' have their usual meanings.
+% Thus, other commands and environemnts can appear within an `alltt'
+% environment. Here are some things you may want to do in an `alltt'
+% environment:
+%
+% * Change fonts--e.g., by typing `{\em empasized text\/}'.
+%
+% * Insert text from a file foo.tex by typing `input{foo}'. Beware that
+% each <return> stars a new line, so if foo.tex ends with a <return>
+% you can wind up with an extra blank line if you're not careful.
+%
+% * Insert a math formula. Note that `$' just produces a dollar sign,
+% so you'll have to type `\(...\)' or `\[...\]'. Also, `^' and `_'
+% just produce their characters; use `\sp' or `\sb' for super- and
+% subscripts, as in `\(x\sp{2}\)'.
+
+\def\docspecials{\do\ \do\$\do\&%
+ \do\#\do\^\do\^^K\do\_\do\^^A\do\%\do\~}
+
+\def\alltt{\trivlist \item[]\if@minipage\else\vskip\parskip\fi
+\leftskip\@totalleftmargin\rightskip\z@
+\parindent\z@\parfillskip\@flushglue\parskip\z@
+\@tempswafalse \def\par{\if@tempswa\hbox{}\fi\@tempswatrue\@@par}
+\obeylines \tt \catcode``=13 \@noligs \let\do\@makeother \docspecials
+ \frenchspacing\@vobeyspaces}
+
+\let\endalltt=\endtrivlist
diff --git a/dviware/driv-standard/papers/draft-8904-tub.tex b/dviware/driv-standard/papers/draft-8904-tub.tex
new file mode 100644
index 0000000000..eee291e855
--- /dev/null
+++ b/dviware/driv-standard/papers/draft-8904-tub.tex
@@ -0,0 +1,57 @@
+% draft-8904-tub.tex 11 Jul 91
+%------------------------------------------------------------
+
+%
+% Draft of the first report from the DVI driver standards committee
+%
+% Published in TUGboat Vol. 10, No. 1, April 1989, page 56.
+%
+% [LaTeX, plus tugboat macros]
+
+%% js: changed by Joachim Schrod <xitijsch@ddathd21.bitnet> on 11 Jul 91.
+%% js: It now uses ltugboat instead of ltugbot
+%% js: (I used ltugboat version 1.04 / tugboat.com version 1.05).
+
+
+\documentstyle[ltugboat]{article}
+
+%% js: \newcommand{\TUG}{\TeX\ Users Group} % already defined
+\newcommand{\contactperson}{Robert McGaffey (internet: {\tt
+ Mcgaffey\%Orn.Mfenet@Nmfecc.Arpa})}
+
+\title{First report from the {\tt DVI} driver standards committee}
+%% js: added author name like given in TUGboat
+\author{Don Hosek}
+
+\begin{document}
+\maketitle
+The \TUG\ {\tt DVI} driver standards committee has been working on the
+development of standards for device drivers since the fall of~1988. This
+article is a first report on our status to the membership of \TUG.
+
+At the time of this writing, we are in the midst of discussion of
+\verb+\special+ standards for device drivers. By the \TUG\ meeting this August,
+we should have a preliminary report on this topic available for distribution to
+all interested parties. We welcome all input from members of the \TeX\
+community; if you have any suggestions, comments, etc. regarding the issue of
+\verb+\special+ handling, we would appreciate it if you could send these to
+\contactperson\ for distribution to the members of the committee.
+
+The members of the committee are: Robert McGaffey, chair, Oak Ridge National
+Laboratory;
+David P. Babcock, Hewlett-Packard;
+Elizabeth Barnhart, TV Guide;
+Stephan v.~Bechtolsheim, Integrated Computer Software Inc.;
+Nelson Beebe, University of Utah;
+Jackie Damrau, University of New Mexico;
+Donald Goldhammer, University of Chicago;
+Don Hosek, University of Illinois at Chicago;
+David Ness, TV Guide;
+Thomas J.~Reid, Texas A\&M University;
+David Rodgers, Arbortext, Inc.;
+Brian Skidmore, Addison-Wesley Publishing Co.;
+Glenn Vanderburg, Texas A\&M University;
+and
+Ralph Youngen, American Mathematical Society.
+
+\end{document}
diff --git a/dviware/driv-standard/papers/draft-8907-tub.tex b/dviware/driv-standard/papers/draft-8907-tub.tex
new file mode 100644
index 0000000000..38a424d7e6
--- /dev/null
+++ b/dviware/driv-standard/papers/draft-8907-tub.tex
@@ -0,0 +1,434 @@
+% draft-8907-tub.tex 21 Jun 91
+%------------------------------------------------------------
+
+%
+% Second DVI driver standards committee report.
+%
+% Published in TUGboat Vol. 10, No. 2, July 1989, pages 188-191.
+%
+% [LaTeX, plus tugboat macros, plus alltt]
+
+%% js: changed by Joachim Schrod <xitijsch@ddathd21.bitnet> on 21 Jun 91.
+%% js: It now uses ltugboat instead of ltugbot
+%% js: (I used ltugboat version 1.04 / tugboat.com version 1.05).
+
+
+\documentstyle[ltugboat,alltt]{article}
+
+\title{Report from the \DVI\ Driver Standards Committee}
+\author{Tom Reid \\ Don Hosek} % This SHOULD be \and but it don't
+ % work with ltugbot.sty
+
+\newcommand{\DVI}{{\tt DVI}}
+\newcommand{\contactperson}{Robert McGaffey,
+ address on page~\addresspage,}
+\newcommand{\Special}{{\tt\char"5Cspecial}}
+\newcommand{\addresspage}{999}
+%% js: \newcommand{\TeXhax}{\TeX{\sc hax}}
+\newcommand{\GDF}{{\tt GDF}}
+%% js: \newcommand{\TeXMaG}{T\kern-.1667em\lower.5ex\hbox{E}\kern-.125emX%
+%% js: M\kern-.1667em\lower.5ex\hbox{A}\kern-.2267emG}
+
+\hbadness=9999 % Don't bother me with details
+
+\begin{document}
+\maketitle
+The first few months of 1989 have shown a healthy increase in the
+discussion in the \DVI\ driver standards discussion. For those people
+with network access, much has been done to provide for the dissemination
+of the information which has come through our hands.
+
+The group has a {\tt LISTSERV} discussion group, {\tt DRIV-L}, which
+is the primary means of communication between its members. The list
+is set up so that anyone who wants to contribute ideas may do so by
+sending mail to {\tt DRIV-L@TAMVM1} (Bitnet) or
+{\tt DRIV-L@TAMVM1.TAMU.EDU} (Internet). These notes will be
+automatically be distributed to the membership of the group.
+
+Archives of past discussions as well as papers on the topic and
+the current versions of standards documentation, programs, and macros
+are stored on the Clarkson archive in the {\tt dvi-standard} group.
+Individuals with FTP access may obtain the files from
+{\tt sun.soe.clarkson.edu} in the directory {\tt pub/dvi-standard}.
+Those without FTP access may still obtain the files via e-mail using
+the same mechanism as is used by the \LaTeX\ style collection,
+substituting {\tt dvi-standard} for {\tt latex-style} where appropriate.
+For example, to obtain the file {\tt driv-l.log8809} and a list of other
+files, one might send a message to
+{\tt archive-server@sun.soe.clarkson.edu} which looks like:
+\begin{small}
+\begin{verbatim}
+path fschwartz%hmcvax.bitnet@clvm.clarkson.edu
+get dvi-standard driv-l.log8809
+index dvi-standard
+\end{verbatim}
+\end{small}
+By the TUG meeting in August, we hope to have much of the proposed
+standard documented and available from the archive.
+
+Bitnet users may also obtain log files from {\tt Listserv@tamvm1}
+by sending the command
+\begin{small}
+\begin{alltt}
+get driv-l log{\it yymm}
+\end{alltt}
+\end{small}
+to {\tt Listserv@tamvm1} where {\it yy\/} is the last two digits of the
+year and {\it mm\/} is the month, expressed as a two digit number. For
+example, to obtain the log from September, 1988, one would send the
+command {\tt get driv-l log8809} to {\tt Listserv}. Listserv commands
+should be sent either as the first line of a single-line mail message
+or as an interactive message ({\tt TELL} on CMS, {\tt SEND} on VMS).
+
+For those without network access, the files may be obtained on
+a floppy disk from John Radel for his usual fees (see the
+article, ``Contents of the Archive Server'' in this issue for
+information on obtaining these files). % Editor: Could you insert
+ % a page number for this article into this sentence?
+
+The remainder of this article outlines some preliminary results of
+the committee's work. Persons interested in implementing portions
+of this standard should contact check the Clarkson archive or contact
+\contactperson\ to obtain the most recent information on the standard.
+
+\section{\Special\ commands}
+The committee has decided that the \Special\ commands defined to date
+will be labeled as ``experimental'' and later classified as
+``production'' after they've undergone sufficient testing to justify
+the reclassification. Experimental \Special\ commands are distinguished
+by the prefix \verb+X_+.
+
+Further work on the precise syntactical rules for \Special\ are under
+development.
+
+\subsection{Interface}
+One of the early decisions of the committee was that \Special\ will be
+treated as a primitive command which the end user should never need
+to type. Instead, \Special\ should be accessed through a high level
+macro set. This has the additional advantage that users at beta test sites
+will usually not be affected by changes to the syntax or names
+of \Special\ commands. This is important since when a \Special\ changes
+status from ``experimental'' to ``production,'' its name will change
+as noted above.
+
+The committee is developing macros for both plain \TeX\ and \LaTeX\
+to interface with the developing standard.
+At the present time, only preliminary versions of these macros have been
+written, but a full macro set for both plain \TeX\ and \LaTeX\
+should be be available by the publication
+time of this article.
+
+\subsection{Scope}
+\Special\ commands have been broken down into six classes depending
+on what portion of the \DVI\ output they would affect.
+\begin{description}
+\item[Global] These \Special\ commands affect the entire document.
+ Examples of this class of \Special\ include commands for
+ selecting duplex printing or setting the printing orientation
+ (portrait, landscape, etc.).
+\item[Page] These \Special\ commands affect only the page on which they
+ are printed. Examples of this class include requests for
+ feeding of special paper from an auxiliary tray ({\it e.g.,\/}
+ for a cover sheet) or a single-page change in orientation.
+\item[Box] These \Special\ commands affect a block of output that is
+ enclosed in a \TeX\ box (and thus is, by necessity on a
+ single page). For example, a command to rotate a block of
+ text would fall under this class.
+\item[Delimited] These \Special\ commands are those that affect
+ a block of output which is not necessarily enclosed by
+ a \TeX\ box or contained entirely on a single page. For
+ example, a \Special\ command to set color would fall into this
+ class.
+\item[Output generating] These \Special\ commands are those which
+ generate self-contained output of some sort. For example,
+ the \verb+X_vec+ \Special\ of Section~\ref{sc:graphics} falls
+ into this class.
+\item[Attribute setting] These \Special\ commands modify the next
+ output generating command which appears on the current page.
+ If no output generating command follows an output modifying
+ command, the command is ignored and the \DVI\ driver program
+ should issue a warning. An example of this class of commands
+ would be the \verb+X_linewidth+ \Special\ described in
+ Section~\ref{sc:graphics}.
+\end{description}
+The remainder of this section will consist of additional notes on
+those classes of \Special\ commands which need additional
+comment.
+
+\subsubsection*{Global specials}
+Global specials, it has been decided, will be required to appear on the
+first page of the document. They will either be identified with
+a prefix (\verb-X_global:-), delimited by a pair of \Special\ commands
+(\verb-X_begin_globals- \ldots \verb-X_end_globals-) or some similar
+scheme.
+
+One issue that has not been decided is whether the first page containing
+the global \Special\ commands should be the first page of text or a
+special page on its own. Having global options specified as part of the
+actual first page of text minimizes the impact on existing drivers.
+However, it does present some problems with existing macro packages in
+regard to ensuring that the options are output at the right place.
+This problem stems from the fact that the \Special\ commands used to
+convey the options to the drivers are normally placed in the body of
+the document. Macro packages which place headline text or entirely
+separate title pages prior to writing the first part of the ``body'' of
+the document will cause text to appear in the \DVI\ file before the global
+options. Headline text may or may not have any impact upon the global
+options, but separate title pages will prevent the global options from
+being on the first page of the \DVI\ file. To get around this problem, the
+mechanism used for passing global information will need to ``cooperate''
+with the output routine within the macro package.
+
+Requiring an entirely separate page at the start of the \DVI\ file avoids
+the need for special interaction with the output routines of various
+macro packages. Instead of placing \Special\ commands in the body of the
+first page, a separate macro is used which issues a separate
+\verb|\shipout| containing the \Special\ commands. This approach makes
+things easier for programs which sort or otherwise reorganize a \DVI\
+file since no culling of global options from the first text page is
+necessary. However, the separate page technique has an undesired effect:
+it produces a blank page on existing drivers which do not understand the
+options page.
+
+\subsubsection*{Box specials}
+A box \Special\ command, since it will always be entirely
+typeset on a single page, will be enclosed in a \TeX\ box (\verb+\hbox+
+or \verb+\vbox+). In the \DVI\ output, box structure is reflected by
+surrounding {\it push\/} and {\it pop\/} commands. For example,
+the \TeX\ commands:
+\begin{verbatim}
+normal
+\hbox{\special{abc} special}
+text
+\end{verbatim}
+generate the following \DVI\ code:
+\begin{verse}
+{\tt "normal"}\\
+{\it push}\\
+{\it right}\\
+{\it xxx} {\tt "abc"}\\
+{\tt "special"}\\
+{\it pop}\\
+{\it right}\\
+{\tt "text"}
+\end{verse}
+A \DVI\ driver can exploit this for a command such as \verb+X_rotate+
+by maintaining on the \DVI\ stack, values for items such as
+{\it rotation\_angle}.
+
+\subsubsection*{Delimited specials}
+The committee has not found an effective way to deal with open
+block \Special\ commands yet. They will probably need to be issued in
+cooperation with the output routine, to insure that every delimited
+command is broken down into matching pairs of \Special\ commands on
+each page within its bounds.
+
+This approach is necessary for two reasons:
+\begin{itemize}
+\item If pages are reordered for any reason ({\it e.g.,\/} reverse
+ ordering for laser printers which stack output face up) the
+ driver should not need to have to scan the entire file to
+ insure that it does not inadvertently break up a pair
+ of \Special\ commands producing a delimited command.
+\item Without special care being taken, an delimited command which
+ spans pages may inadvertently affect page headers and footers
+ which are typeset between the beginning and ending blocks.
+\end{itemize}
+
+\subsection{Graphics commands}
+\label{sc:graphics}
+Three techniques for including graphics have been discussed.
+These are:
+\begin{enumerate}
+\item Make graphics entirely with \TeX\ primitives.
+\item Use \MF\ to build a graphic as a font.
+\item Allow the driver to include a device-specific graphic.
+\end{enumerate}
+
+\subsubsection*{Graphics by \TeX}
+Handling graphics entirely with \TeX\ macros and primitives which use
+dots or characters from a special graphics font is a technique which has
+been in use for some time.
+The \LaTeX\ picture environment and \PiCTeX\ work in this way with the
+former assembling characters from a graphic font and the latter using
+closely spaced dots.
+
+In {\it TUGboat\/}~{\bf10}(1),\footnote{This article also appeared
+in \TeXhax~{\bf89}(7).} David F.~Rogers proposed a series of \TeX\ macros
+to provide plotting primitives; these macros would generally be used
+by \TeX\ input generated by some graphics package.
+The macros which were proposed created graphics by closely spacing dots
+along each line in the same manner as \PiCTeX.
+
+The problem posed by creating graphics in this manner is
+that \TeX\ must store all of the graphic elements in memory at once for an
+entire page quickly exceeding \TeX's capacity.
+
+To calculate the memory needs, the technique for positioning each dot
+was defined.
+This is:
+\begin{verbatim}
+\kern\DX \raise\Y \hbox{\DOT}%
+\end{verbatim}
+where \verb|\DX| is a dimension register giving the displacement in the
+``x'' direction from the previous point and \verb|\Y| is a dimension
+register giving the displacement in the ``y'' direction from the reference
+point of the graph.
+\verb|\DOT| defines the plotting symbol and \verb|\DX| accounts for the
+width of this symbol.
+
+In memory, \TeX\ saves \verb|\kern\DX| in a {\it kern\/} node, the raised
+hbox in an {\it hlist\/} node, and the plotting symbol in a
+{\it char\_node.}
+These take two words, seven words, and one word of memory, respectively,
+for a total of ten words per dot.
+A normal-size implementation of \TeX\ with 64\,k-words of memory allows
+about 6000 dots to be positioned before it runs out of memory
+(assuming that no other macros are loaded and neglecting other text on the
+page).
+Spacing the dots at 100 per inch, this gives about 60 inches which is not
+sufficient for many graphs.
+
+To enhance the capacity of this graphics technique, we decided to use a
+\verb|\special| to add a vector drawing capability to \TeX\ and DVI drivers
+and use the \verb|\special| instead of closely-spaced dots.
+This changes the \TeX\ command sequence to:
+\begin{verbatim}
+\kern\DX \raise\Y \hbox{%
+\special{X_vec \number\XC \space
+ \number\YC}%
+\end{verbatim}
+where \verb|\XC| and \verb|\YC| are dimension registers giving the components
+of the vector.
+Component values in scaled points are likely to be six-digit numbers with an
+additional minus sign for negative numbers.
+Thus, an average length for the \verb|\special| string is likely to be
+around 18 characters.
+In memory, a \verb|\special| is saved in a two-word {\it whatsit\/} node
+which points to the \verb|\special| string.
+Thus the total memory needs, counting the {\it kern\/} and {\it hlist\/}
+nodes, will average 29 words per vector which allows roughly 2000 vectors.
+This may be sufficient for many graphs, but falls somewhat short for
+complex three-dimensional surface plots.
+(One sample 3D surface plot consisted of 13,000 vectors.)
+
+Two \Special\ commands have been defined for graphics of this sort (and
+specialized commands for more complicated graphic elements will be
+defined in the future). The commands defined are:
+\begin{description}
+\item[\tt X\_linewidth $n$] Specify that the following vector is to be
+ drawn with a line width of $n$ \DVI\ units (scaled points for
+ \TeX). Vectors are
+ normally 1~point in width. If no vector follows the
+ \verb+X_linewidth+ \Special\ on this page, the command is
+ ignored and the \DVI\ driver program should issue a warning.
+\item[\tt X\_vec $\Delta x$ $\Delta y$] Draw a diagonal line from the
+ current point to the point which is offset by $\Delta x$ and
+ $\Delta y$ from the current point. $\Delta x$ and $\Delta y$
+ are specified in terms of \DVI\ units.
+\end{description}
+
+\subsubsection*{Graphics by \MF}
+A different approach to graphics inclusion is to use \MF\ to produce the
+graphic as a character of a font and position it using \TeX's normal
+character positioning capabilities.
+The advantage of this technique is that the graphic is in a format which
+many drivers will already accept.
+
+METAPLOT by Pat Wilcox\footnote{See the Amiga\TeX\ notes of March~12,
+1989 or \TeXMaG~{\bf3}(3) for information about this package.}
+is one example of a package which takes this approach.
+
+However, the technique has a number of drawbacks:
+Graphic fonts are resolution-dependent; a separate graphic font is
+needed for different resolution devices.
+\MF\ records changes in pixel values across a scan line when it builds a
+character.
+Thus, the memory needs depend upon the complexity of the graphic in
+addition to the size and resolution of the device.
+To circumvent this limitation, it is necessary to break the whole graphic
+into smaller pieces.
+It is important to ensure that the heights and widths of each piece
+are integral numbers of pixels to
+allow them to be reassembled without the alignment problems which occur
+for letters within words.
+
+\subsubsection*{Including device-dependent files}
+With this approach, the \DVI\ driver processes a special Graphics Description
+File (\GDF) which, among other things, indicates the names and formats of
+separate graphic files in device-dependent format.
+A driver searches this list to find a file in a format appropriate for the
+device it supports.
+This allows a greatly simplified graphic files to be defined for previewing
+purposes while a detailed, higher resolution version is used when the
+\DVI\ file is printed.
+
+\GDF\ files are processed both by \TeX\ and by the \DVI\ driver.
+\TeX\ \verb+\input+s the file and executes code at the start of the
+file. This code sets some dimension and box registers giving the size
+of the graphic then terminates with an \verb+\endinput+ to return
+control to the macro which did the \verb+\input+. The portion of the
+\GDF\ file following the \verb+\endinput+ is processed by the driver.
+
+The driver section of the file consists of a series of keywords which
+identify lines that apply to a particular graphics format, rotation, etc.
+The driver scans these lines searching for a format which it understands.
+Depending on the driver and the graphics format, additional lines may
+have to be searched for other attributes such as rotation. Eventually,
+the name of the graphics file to be included will be found and the
+driver will incorporate it into the output file.
+
+In {\it TUGboat\/}~{\bf10}(1), Bart Childs, Alan Stolleis, and Don
+Berryman suggested another scheme for using \Special\ for inclusion
+of device-dependent graphics files in ``A portable graphics inclusion.''
+
+% Section removed at Tom Reid's suggestion since most of it has yet
+% to be discussed in depth on driv-l.
+%\subsection{Miscellaneous commands}
+%In addition to the commands listed above, the following miscellaneous
+%\Special\ commands have been proposed:
+%\begin{description}
+%\item[\tt X\_duplex] Specifies that printing is to be on both sides
+% of the sheet. This can be either a global or a page command.
+% If it is a page command, it causes the following page to be
+% printed on the back of the current page.
+%\item[\tt X\_landscape] Specifies that printing is to be done in
+% landscape (as opposed to portrait) style. This can be either
+% a global or a page command.
+%\item[\tt X\_portrait] Specifies that printing is to be done in portrait
+% style. This can be either a global or a page command.
+%\item[\tt X\_rotate $n$] Rotate the current box by $65536n^\circ$.
+% Conversion of traditional units such as degrees and radians
+% is easily accomplished through \TeX\ macros. This is a closed
+% block command.
+%\item[\tt X\_simplex] Specifies that printing is to be on one side of
+% the sheet. This can be either a global or a page command.
+% If it is a page command and the \Special\ occurs on a page
+% that would be printed on the
+% front side of the sheet then the current page is printed
+% simplex; if the \Special\ occurs on a page that would occur on
+% the back side of a sheet, a blank page is printed on the back
+% side of that sheet and the current page is then printed
+% simplex.\footnote{This seemingly complex scheme prevents
+% drivers from needing to scan more than a page at a time.}
+%\end{description}
+%Additional macros will be defined as more discussion on the topic
+%transpires.
+%
+\section{Additional reference material}
+In addition to the works mentioned in the Editor's note at the end
+of our last report, the following may also be of interest:
+\begin{itemize}
+\item Guntermann, Klaus and Joachim Schrod. ``High quality \DVI\
+ drivers'' Available from the Clarkson archive as the file
+ {\tt schrod-}\discretionary{}{}{}
+ {\tt guntermann1.tex}
+\item Hosek, Don. ``Proposed \DVI\ \Special\ command standard''
+ Available from the Clarkson archive as the file
+ {\tt hosek1.tex}.
+\end{itemize}
+In addition, anyone interested in implementing any portion of the
+developing standard should read the logs available from the Clarkson
+archive or {\tt Listserv@tamvm1}.
+
+\end{document}
diff --git a/dviware/driv-standard/papers/dvistd.bib b/dviware/driv-standard/papers/dvistd.bib
new file mode 100644
index 0000000000..76f167f6f2
--- /dev/null
+++ b/dviware/driv-standard/papers/dvistd.bib
@@ -0,0 +1,128 @@
+% $Id: dvistd.bib,v 1.1 1991/07/26 18:18:45 schrod Exp schrod $
+%---------------------------------------------------------------------------
+% compiled by Joachim Schrod <xitijsch@{}ddathd21.bitnet>
+% ^^ DON'T TYPE THESE! BibTeX demand!
+
+%
+% references concerning the TUG DVI Driver Standard
+%
+
+
+%
+% $Log: dvistd.bib,v $
+% Revision 1.1 1991/07/26 18:18:45 schrod
+% Initial revision
+%
+
+
+
+%
+% abbrevations
+%
+
+% often not needed, but anyhow:
+@preamble{
+ "\def\DVI{{\tt DVI\/}}"
+}
+
+@string{ tub = "TUGboat"}
+@string{ committee = "The TUG {\DVI} Driver Standards Committee"}
+
+
+
+
+%
+% from the committee
+%
+
+@article{dvistd:report-tub:8904,
+ author = {Don Hosek},
+ title = {First report from the {\DVI} driver standards committee},
+ journal = tub,
+ volume = 10,
+ number = 1,
+ month = apr,
+ year = 1989,
+ pages = {56},
+ annote = {Announcement of the committee existence.}
+}
+
+@article{dvistd:report-tug:8907
+ author = {Don Hosek and Thomas J. Reid},
+ title = {Report from the {\DVI} Driver Standards Committee},
+ journal = tub,
+ volume = 10,
+ number = 2,
+ month = jul,
+ year = 1989,
+ pages = {188-191},
+ annote = {Announcement of {\tt driv-l\/} and the Listserver at Texas
+A\,\&\,M. Discussion of Specials.}
+}
+
+@article{dvistd:report-tug:9105,
+ author = {Joachim Schrod},
+ title = {Report on the {\DVI} Driver Standard},
+ journal = tub,
+ volume = 12,
+ number = 2,
+ month = may,
+ year = 1991,
+ pages = {},
+ annote = {Claims that the level-0 draft is nearly finished for the
+presentation to the membership-at-large. Explains the structure of
+the standard.}
+}
+
+@unpublished{dvistd:report-board:9106,
+ author = committee,
+ title = {Report on the year June 1990 -- May 1991},
+ month = jun,
+ year = 1991,
+ note = {(For the TUG Board of Directors, compiled by Joachim Schrod,
+Secretary.)},
+ annote = {Names the voting members and explains the voting
+procedure. Announces the ftp-Server at Darmstadt. Describes the work
+done and future topics to discuss.}
+}
+
+
+
+%
+% other stuff (will be expanded!)
+%
+
+@inproceedings{dvistd:guntermann-schrod:quality-drivers,
+ author = {Klaus Guntermann and Joachim Schrod},
+ title = {High Quality {\DVI} Drivers},
+ editor = {Malcolm Clark},
+ booktitle = {{\TeX}: Applications, Uses, Methods. Proceedings of the
+{\TeX}88 Conference},
+ address = {Exeter, UK},
+ publisher = {Ellis Horwood Publishers},
+ year = 1990,
+ pages = {43-60},
+ annote = {}
+}
+
+@article{dvistd:mcgaffey:ideal,
+ author = {Robert W. McGaffey},
+ title = {The Ideal {\TeX} Driver},
+ journal = tub,
+ volume = 8,
+ number = 2,
+ year = 1987,
+ pages = {161-163},
+ annote = {It is still questionable if this is the ``Ideal \TeX{}
+Driver''\,\dots}
+}
+
+@inproceedings{dvistd:mcgaffey:standards,
+ author = {Robert W. McGaffey},
+ title = {Developing {\TeX} {\DVI} Driver Standards},
+ booktitle = {TUG VIII Conference Proceedings},
+ year = 1987,
+ pages = {69-70},
+ organization = {{\TeX} User Group},
+ annote = {},
+}
diff --git a/dviware/driv-standard/papers/high-quality-dvi-drivers.tex b/dviware/driv-standard/papers/high-quality-dvi-drivers.tex
new file mode 100644
index 0000000000..ef8932c033
--- /dev/null
+++ b/dviware/driv-standard/papers/high-quality-dvi-drivers.tex
@@ -0,0 +1,1328 @@
+% This is EXETER.TEX as of 30 Aug 88
+%---------------------------------------------------------
+% (c) 1988 by K.Guntermann and J.Schrod.
+
+%
+% ``High Quality DVI Drivers''
+% European TUG Conference TeXeter, 1988
+% Final version
+%
+
+
+%\documentstyle[names,dina4,draft]{article}
+ \documentstyle{article}
+
+
+%%%%%%%%%%%%%%%
+% NAMES.STY as of 09.08.88
+%-------------------------------------------------
+% (c) 1988 by C.Detig, J.Schrod.
+%
+% Verfuegbarkeit von haeufigen Abkuerzungen/Logos in
+% LaTeX und Formate
+
+
+% \def\TeX{{\rm T\kern-.1667em\lower.5ex\hbox{E}\kern-.125emX}}
+\def\INITeX{{\rm INI\TeX}}
+
+\def\Plain{{\rm Plain}}
+
+\def\LaTeX{{\rm L\kern-.36em\raise.3ex\hbox{\sc a}\kern-.15em\TeX}}
+\def\BibTeX{{\rm B\kern-.05em{\sc i\kern-.025em b}\kern-.08em\TeX}}
+\def\SliTeX{{\rm S\kern-.06em{\sc l\kern-.035em i}\kern-.06em\TeX}}
+\def\MakeIndex{{\it MakeIndex\/}}
+
+\def\AmSTeX{%
+ $\cal A\kern-.1667em\lower.5ex\hbox{$\cal M$}\kern-.125em S$%
+ -\TeX
+ }
+
+
+% ACHTUNG: nur fuer 10pt
+
+\font\logo=logo10
+\ifx \mc\undefined \let\mc=\ninrm \fi % fuer LaTeX
+\def\MF{{\logo META}\-{\logo FONT\/}}
+\def\INIMF{{\mc INI}{\logo MF}}
+
+
+\def\LOG{{\tt LOG\/}}
+\def\DVI{{\tt DVI\/}}
+\def\FMT{{\tt FMT\/}}
+\def\TFM{{\tt TFM\/}}
+
+
+\def\GF{{\tt GF\/}}
+\def\PK{{\tt PK\/}}
+\def\PXL{{\tt PXL\/}}
+
+
+\def\WEB{{\tt WEB\/}}
+\def\CWEB{{\mc CWEB\/}}
+%%%%%%%%%%%%%%%
+
+
+\def\fract#1/#2.{% % borrowed from manmac.tex
+ \leavevmode
+ \kern .1em
+ \raise.5ex \hbox{\the\scriptfont0 #1}%
+ \kern -.1em /\kern-.15em
+ \lower.25ex \hbox{\the\scriptfont0 #2}%
+ }
+
+
+
+
+\title{High Quality \DVI{} Drivers}
+
+\author{
+ Klaus Guntermann\\
+ TH Darmstadt
+ \and
+ Joachim Schrod\\
+ TH Darmstadt
+ }
+
+\date{July 1988}
+%\date{\today}
+
+
+
+
+\begin{document}
+
+
+
+
+\maketitle
+
+
+
+
+\begin{abstract}
+
+Document preparation with \TeX{} is done in two steps---first
+\TeX{} formats the document, afterwards a \DVI{}
+driver creates the final output. While \TeX{} is reliable
+and produces the same results in each implementation,
+\DVI{} drivers remain to be the critical part of the
+document preparation process. To specify a high-quality
+\DVI{} driver the circumstances of its usage must be
+analysed. We identify four groups of persons which are
+concerned with the handling of a driver: users, (\TeX{})
+system administrators, distributors, and
+developers/maintainers.
+
+The demands on a \DVI{} driver are mainly high reliability
+(the device must remain in a consistent state), a uniform
+user interface (previews and printer drivers should behave
+similar), and a standardisized treatment of extensions
+(e.g., handling of graphics inclusion). Other matters of
+interest are available features, accuracy of output,
+throughput, font handling, portability, and maintainability.
+This analysis yields in criteria for the judgement of a \DVI{}
+driver's quality---furthermore these criteria constitute a
+contribution to the standardization process.
+
+\end{abstract}
+
+
+
+
+\section{Introduction}
+
+``High Quality \DVI{} Drivers'' will not discuss the latest
+high resolution output devices and the drivers that can be
+used to make them print the most beautiful documents.
+Instead we will stress drivers for any output device and
+enlighten their usage and features, to see whether they can
+be considered high quality. This will not lead to ``the
+ideal driver,'' but result in better drivers that become as
+reliable as \TeX{} is.
+
+Of course the requirements for a driver are different for
+all the people that come in touch with it. We will start
+with an investigation of the life of a driver, then we will
+go into details of user interfaces, output creation, and
+implementation issues. Finally we will propose standards
+for extensions via the \verb|\special| command.
+
+
+
+
+\section{Who Is Involved?}
+
+To identify the groups of persons who get in contact with
+a driver we look at the ``life'' of a driver. It must be
+taken into account that these groups are distinguished by
+the functionality they have during the driver's life not by
+the identity of subjects. Of course, this covers the
+widespread situation that the persons who implement a driver
+write the user manuals, too, and are therefore also users of
+the driver. As with every software product the life of a
+driver is not a straight forward sequence of actions.
+Nevertheless stages can be characterized with the model of
+the {\it software life cycle\/} \cite{peters:life-cycle}.
+%
+\begin{itemize}
+\item The driver must be documented, implemented, and
+tested, afterwards (or in parallel) a user manual must be
+written. We call this phase the development and
+documentation phase and the persons concerned the {\it
+developers}.
+
+\item Then the driver must be sent to its user by a {\it
+distributor}. There is neither a big difference whether
+this distributor is a commercial one or not, nor is there a
+big difference what kind of media is used for the
+distribution---the principal work of sharing all files that
+resembles a driver is the same. In this context we want to
+call your attention to the assumption that the driver is
+distributed as a system ready to use, i.e.\ in executable
+form including a set of fonts, without any sources. If the
+sources shall also be distributed, arrangements must be made
+for the creation of a consistent, running system.
+
+\item The next step is the receipt of the driver by those
+who want to use it. This driver must now be installed; if
+the user is a single person this will be done by himself.
+But in many cases a (\TeX{}) system administrator will have
+to do it. These system administrators most often want to
+adapt the driver to local requirements, too. Therefore we
+distinguish the installation phase and call the persons
+concerned {\it installers}.
+
+\item After the driver has been installed it can be run
+by {\it users}. During this phase errors will be detected
+(no software system is free of errors) and hints for changes
+or extensions will evolve.
+
+\item The feedback of the users will be treated by the
+{\it maintenance group}. If they change the driver due to
+this feedback the cycle is entered at the point where the
+test and the documentation has been done.
+%
+\end{itemize}
+%
+During the stages of the software life cycle different
+people work on the driver. All those people have different
+requirements---these can even be contradictory. But because
+the system is made for usage the requirements of the users
+must have a strong preference over the other ones, our study
+will start with the user's point of view. In the rest of
+this paper we will distinguish from whom the specific
+requirement will come. Only if all groups have the same
+requirements or if the context clarifies the persons
+concerned we omit the distinction.
+
+
+
+
+\section{User Interface}
+
+The most interesting part of a driver is of course a list of
+its capabilities. These make it more or less usable.
+Looking around in the scientific community most people have
+to deal with heterogeneous computing environments.
+Documents are often enough moved from one computer to
+another in the different stages of document preparation. In
+this case it is mandatory for satisfactory results that
+drivers in the different environments behave similar. This
+user requirement splits up into several conditions:
+%
+\begin{itemize}
+%
+\item The drivers must offer the same set of options with a
+uniform command language interface---as far as reasonable
+interpretation is possible; see the list below.
+Additionally there may be alternate command language
+interfaces that are compatible to the computing environment
+in question: e.g.\ a menu and buttons for systems with a
+graphical shell or any other command language specific
+option method with prompts for mandatory options etc. These
+site specific additions make usage easier for people that
+are restricted to one environment and help them to become
+familiar with the driver. This may also hold for support
+staff that has to maintain command scripts for all programs
+and prepare additional user documentation.
+
+\item The drivers must create the same visual output on all
+devices---with respect to resolutions. This condition is
+extremely important to make previewing reasonable.
+
+\item The drivers must handle exceptions the same way. Of
+course it is the responsibility of the people that install a
+driver to make the same set of fonts available for all
+drivers and output devices.
+
+\item Activation of any extensions through the
+\verb|\special| command must be standardized. Otherwise
+misinterpretations of commands will lead to unexpected
+results. Extensions that are not handled must have no
+effect other than creating a warning message.
+%
+\end{itemize}
+
+Printer drivers must be able to run unattended (in
+``batchmode''). Requiring interaction in exceptional cases
+is not tolerable when drivers are processing output files in
+a spool queue.
+
+Now we list a number of options that is to be included. We
+start with those options that are considered to be a minimal
+set:
+%
+\begin{itemize}
+%
+\item Partial output of a \DVI{} file.\\
+ The selection must allow to give at least the
+ %
+ \begin{enumerate}
+ \item starting page number
+ %
+ \begin{enumerate}
+ \item referring to \TeX's \verb|\count0|, which
+ designates the printed ``page number'' in most macro
+ packages,
+
+ \item with respect to the order of pages in the \DVI{} file.
+ \end{enumerate}
+ %
+ This distinction is necessary because some macro packages
+ use the same counter values in several parts of a document.
+ Thus a selection using \verb|\count0| does not lead to the
+ desired page in all cases.
+
+ \item a maximum number of pages to print (not reasonable
+ for preview drivers) or
+ \item an end page number, also either referring to \verb|\count0|
+ or with respect to the order of pages,
+ \item an increment used to step through the document
+ (with the reasonable default value 1, but not required
+ for preview drivers, see below)
+ \end{enumerate}
+%
+For printer drivers multiple ranges in one run of a driver are
+required.
+Otherwise the initial overhead of a driver run can cumulate.
+
+\item Override the magnification for the document to obtain
+a zoomed output. Of course this will also affect all
+``true'' dimensions.
+
+\item Specification of the number of copies---selectable as
+the number of copies of each page or the number of times the
+selected page ranges are repeated.
+
+\item Placement of the output on the page: values for top
+and left margin. The default margins must depend on the
+paper format. In the US the standard margins are 1\,in for
+legal paper. For the European A4 paper 2\,cm margins have
+proved reasonable.
+%
+\end{itemize}
+%
+Additionally the following options can enhance the
+versatility of a driver:
+%
+\begin{itemize}
+\item Selection of pages with respect to the other counters
+\verb|\count1| to \verb|\count9|. (These counters are
+seldomly used by macro packages because they usually
+allocate their counters dynamically.)
+
+\item Processing of multiple files in one activation. This
+reduces the overhead for initialization in printer drivers
+and allows switches from one document to another without
+leaving in preview drivers.
+
+\item Selection of orientation---portrait or landscape.
+\end{itemize}
+%
+Printer drivers have additional features which should be
+part of a high quality driver:
+%
+\begin{itemize}
+\item Selection of processing order for the pages to
+override default. Default must be the reading order when
+the pages are taken from the output stacker, i.e.\ reverse
+for face up output, forward for face down or sorter output.
+
+\item For devices that allow multiple input stacks or sorter
+output these must be controllable by driver options. In a
+multiuser environment operating procedures may require that
+some of these features can be disabled for the normal user.
+Otherwise an output job might block the queue waiting for
+insertion of a sheet in a single sheet feeder.
+
+\item Selection of paper format.
+
+\item Placement of multiple pages on larger sheets is a
+requirement for professional output.
+%
+\end{itemize}
+%
+Preview drivers require another degree of interactivity.
+Thus some of the options from above show up again as dynamic
+selections in the following list:
+%
+\begin{itemize}
+\item For small screens allow reduction of the output to see
+a whole page on the fly (and switch back again), even if the
+text is not readable any more.
+
+\item Show information about the current page including page
+number (it may not be written on the page), relative
+position of the page and the total number of pages in the
+document.
+
+\item For small screens allow the user to select the
+displayed part freely.
+
+\item Let the user scan a page with simple commands if it
+does not fit on the screen. These commands move the
+displayed part in discrete steps across the page, there must
+be an overlap between the actual and the next page notch.
+
+\item Let the user select interactively the next page to be
+seen, but make the default easy without boring interactions
+for
+%
+ \begin{enumerate}
+ \item move to the next or the previous page,
+ \item skip to any page by page number,
+ \item skip to any page by relative distance (forward or backward),
+ \item skip to a page relative to start or end of document.
+ \end{enumerate}
+
+\item If the host operating system supports a multi-tasking
+window system, the driver must be able to use it.
+%
+\end{itemize}
+%
+Again there are some options that are not required in each case
+but make things easier under many circumstances:
+%
+\begin{itemize}
+\item Let the user select the size of a virtual output sheet
+and handle offset parameters like the printer drivers. Thus
+positioning of output can be checked completely on the
+screen.
+
+\item Allow display of a ruler to measure distances in the
+document. The labeling must be user selectable using all
+the units provided by \TeX{}.
+
+\item Override the magnification during the session for
+closer inspection.
+
+\item Let the user scan the page in a natural way, if it
+does not fit on the screen. The same command goes right as
+long as there is something not seen and then return to the
+left base for the next slice; skip to the next page when the
+bottom right part was seen.
+
+\item Let the user interactively specify the home position
+on the screen, i.e.\ the position in the page which will be
+shown first for a new page.
+
+\item Let the user select foregound and background colour if
+the display is not monochrome.
+%
+\end{itemize}
+
+The principles of operation, any drawbacks or limitations and the
+user interface must be described in a manual.
+It must contain
+%
+\begin{itemize}
+\item the environment requirements of the driver (main
+memory, disk space, special hardware or interfaces),
+
+\item precise specifications for all options and their
+default settings,
+
+\item any other way to change the behaviour, e.g.\
+environment controls,
+
+\item a reference to all error messages and suggestions for
+user reaction,
+
+\item a description of installation procedures in a separate
+section, and
+
+\item an index.
+%
+\end{itemize}
+%
+To help casual users either online documentation through
+help or online manual features of the host should be
+available. These must include all possible options with
+short explanations. If no help system or online manual is
+available, the driver must give the necessary information
+when asked. A cryptic list of option switches without
+explanation is not sufficient.
+
+Developers become users of their drivers when they prepare
+their documentation. For driver families it is rather
+straightforward to create one document and select the host
+specific sections through conditional parts included in
+\TeX's \verb|\if| and \verb|\fi|.
+
+
+
+
+\section{Expected Characteristics}
+
+Beyond all bells and whistles there are a few overall
+characteristics a driver is expected to have. The most
+important one is its reliability. A driver must not crash
+down nor must it leave the computer system or the device in
+an inconsistent state.
+%
+\begin{itemize}
+\item Printers must be reset to a usable state, a following
+job must be able to use it without difficulties. If there
+doesn't exist a font management independent of application
+software the driver must delete all fonts it has downloaded.
+
+\item Previews must leave a usable terminal which accepts
+user input.
+\end{itemize}
+
+The other side of reliability is a good error recovery. The
+driver should try to output as much as possible---and the
+output should be the best approximation to the \DVI{}
+document which can be made. If the device storage isn't
+large enough to hold the contents of one page, if a font or
+a character is missing, or if some components cannot be
+output due to hardware drawbacks: in each case the driver
+should try to discard the page component which leads to the
+error and should leave the space for it if this is possible.
+
+The error messages should be precise and include information
+for the user (or the maintainer) to identify the source of
+the problem. All error messages should be written to a log
+file, too---the user doesn't want to copy it to paper by
+pencil.
+
+These points are much more important than every feature of
+the driver and even more important than performance. A very
+fast driver with a bunch of features which doesn't produce
+correct output and crashes leaving the system in an
+inconsistent state (and supplying cryptic error messages) is
+of no use for realistic productive document preparation.
+
+Nevertheless performance is an important {\it feature}, too.
+A high quality driver should not be the ``bottleneck'' of
+the printing process---devices and communication lines are
+usually very slow. Under some circumstances it can be
+prefered to discard the support of some features of the user
+interface while featuring performance issues, e.g.\ for a
+production driver for high resolution devices where only
+final printing is done.
+
+
+
+
+\section{Output}
+
+The essential task of a driver is to create the most
+satisfying output which is possible using the intended
+device. This output is described in the \DVI{}
+file~\cite{tug:dvi}. As the name expresses the
+representation of the document is device independent, which
+is achieved by the following characteristics:
+%
+\begin{enumerate}
+\item The characters are not regarded as an element of
+(device-specific) fonts but as an element of a type in a
+specified magnification. The assignment to fonts (and then
+to font files) must be done by the \DVI{} driver.
+
+\item The positions of these characters (and rules) are
+given in scaled point (sp), with $2^{16}$~sp in 1~pt and
+72.27~pt in 1~in. Because there is no device available
+with such a resolution (and surely will not be in the
+future) a driver has to transform the position details in
+minute raster into the coarsemeshed raster of the device.
+%
+\end{enumerate}
+%
+The consequences of these items for a \DVI{} driver
+are discussed in this section.
+
+
+
+\subsection{Fonts}
+
+Fonts, i.e.\ collections of character images for a specific
+output device, are one of the main resources a driver must
+handle. For each group of persons different views of the
+font handling can be stated. The primary interest of the
+developers who must implement, document and maintain a
+couple of drivers is a uniform handling of these fonts,
+i.e., a uniform naming scheme. System administrators have
+to install the driver---they want to adapt the naming scheme
+to the existing system environment. The user of the \DVI{}
+driver wants to have a complete set of fonts so that he can
+create documents with the usual \TeX{} macro packages and
+doesn't have to be concerned with the availability of fonts.
+
+
+\subsubsection{The Format of a Font}
+
+Fonts are stored in font files. Currently, three different
+``official'' formats of these font files have been published:
+%
+\begin{enumerate}
+\item The \GF{} (generic font file) format \cite{tug:gf} is
+output by \MF{}.
+
+\item In the older \PXL{} format \cite{tug:pxl} each
+character is represented as a bitmap with each bitrow padded
+to 32~bits. This format has the drawback that an important
+information (the device dependent width) is not included.
+
+\item The \PK{} (packed font file) format \cite{tug:pk} was
+introduced to achieve savings in the demands for disk space.
+With this \PK{} format the needed disk space is reduced to
+about 40\,\% of the demands of fonts stored in the \PXL{}
+format.
+%
+\end{enumerate}
+%
+A driver must at least be able to process fonts in
+the \PK{} format, the support of the \GF{} format is highly
+recommended. The \PXL{} format is---due to its space
+requirements and its lack of device dependent
+widths---not as important as the other two formats,
+but a high quality driver should also support it because
+many old drivers use it and their fonts can be used in this
+way. If one of the two formats \GF{} or \PXL{} cannot be
+used conversion programs to the \PK{} format should be
+part of the driver delivery. High quality \DVI{} drivers
+may add another capability: the usage of fonts which reside
+in the device itself.
+
+
+\subsubsection{The Name of a Font File}
+
+It can be assumed that every operating system where a \DVI{}
+driver can run allows to organize files hierarchically. We
+can regard such a hierarchy as a directed graph with filled
+nodes. A node contains files and other nodes that are
+at a hierarchically lower level.
+
+The full name of a font file consists of the name of the
+node in which the file is stored and the file name itself.
+Most often, these parts are concatenated with a delimiter in
+between. It is very usual that file names are treated as a
+composition of two parts, connected by a dot: the name
+and the extension. These syntactical elements must be
+restricted in their length to achieve exchangeability
+between many systems; the names of the nodes and the name
+part of the file name must have at most eight characters,
+file extensions must be limited to three characters
+\cite[p.~89]{beebe:driver}.
+
+These restrictions---which are necessary to get a uniform
+naming convention on many different computer systems---have
+a strong impact on the organization of the whole bunch of
+font files. The fonts come along in different
+magnifications, magnified fonts are often used as a (bad)
+replacement for nonexisting sizes of the requested type.
+%
+\begin{itemize}
+\item The name of the font file must contain its type name.
+Its extension can indicate the font file format. But this
+indication should only be of relevance for the human, \DVI{}
+drivers must look at the magic numbers inside the font file
+to decide if this file represents a font and to determine
+the format of the font representation. Since the extension
+must have at most three characters it is not possible to
+include the coding of an arbitrary magnification in it.
+
+\item The fonts with the same magnification should be
+collected in one node at the lowest level of the font file
+hierarchy. The name of this node must represent the
+magnification since it cannot be included in the file names.
+
+\item All fonts in all magnifcations for one output device
+should be clustered in one node at the next higher level in the
+font file hierarchy. If the fonts are generated by \MF{}
+the node that represents all fonts for one device should be
+named with the identifier of the {\it mode\/} parameter
+(shortened to eight characters).
+%
+\end{itemize}
+%
+This proposed structure of the font file allows the
+developers to handle different fonts for different devices
+on different computer systems in the same way.
+
+System administrators have to install the driver---during
+this installation process the most time will be spent by
+copying the fonts. An estimation of this time and a
+specification of the needed disk space must be found in the
+documentation to allow scheduling the administrator's work.
+The font file names will be fixed but the other parts of the
+full file name can be subject to change.
+%
+\begin{itemize}
+\item At least it must be allowed to specify the placement
+of the node that represents all fonts for one device, e.g.\
+by prefixing it or by locating it in a directory structure.
+
+\item The names of nodes containing all fonts with the same
+magnification must contain the magnification of these fonts
+but high quality drivers should allow to adapt the naming
+conventions to local circumstances. We propose to allow
+alternations in two ways:
+%
+\begin{enumerate}
+\item \label{enum:mag-types}
+It should be possible to influence the digit
+representation of the font magnification; at least two
+representations are widely spread, the scale factor in
+per mille relative to 200~dpi and the font resolution which
+can be associated with this magnification.
+
+\item It should be possible to insert the representation of
+the magnification as of~(\ref{enum:mag-types}), in an
+arbitrary string to form the node name.
+%
+\end{enumerate}
+\end{itemize}
+%
+With these provisions it is easy to embed a \DVI{} driver
+into an existing environment.
+
+Another important point for the system administrator is the
+ability to share the font files beween computers in a
+network, which results in reduced consumptions of computer
+resources and a reduced handling time. A high quality
+driver should support the file access over networks.
+
+
+\subsubsection{Additional Fonts}
+
+The set of fonts delivered with a driver is subject to a
+future step of standardization. In any case there will be
+documents which require additional fonts, be it complete new
+fonts or unusual magnifications of fonts. If \TeX{} is used
+in a multiuser environment the writer seldom has the
+opportunity to install these fonts at the place where the
+complete font set is located. But even if he could he often
+wishes to distinguish the delivered ``standard'' fonts from
+the documentspecific ones, i.e., he wants to store them in a
+different place.
+
+Every driver must allow to hold documentspecific fonts near
+by the written document, i.e., to install the magnification
+nodes of these fonts in the same node where the document is
+placed. Furthermore high quality drivers will accept a list
+of nodes in the file hierarchy where fonts are searched.
+The user should be able to define this node-list either in
+the command line or via the host system in which the list
+is associated with a name if the host system supports that
+kind of string mapping (e.g.\ the environment variables of
+UNIX or the logicals of VMS)\@. The name of this list must
+be device specific because each device will have a different
+search list. With this capability it is possible to install
+fonts that are used by a team or only by one person and to
+have enough flexibility for the management of documents.
+
+
+\subsubsection{Missing Fonts}
+
+But, what if a font file cannot be found? First it must be
+guaranteed that a correct magnification value has been
+used; incorrect magnifications can be introduced due to the
+fact that they are partly represented as integers in per
+mille. If this can be assured replacement fonts should be
+looked for.
+
+Every driver must replace nonexistent fonts at least with an
+unmagnified font of the device---of course, the same
+type should be used. High quality drivers will also
+look for other magnifications to choose a font which comes
+closest to that the user has wanted. If still no font can
+be found the \TFM{} files (normally used by \TeX{} only) may
+serve as a source for informaton about the dimensions of
+these font's characters, so that an appropriate space can be
+left. All this should be done in the spirit of ``don't
+cancel the output---the writer wants to see as much as is
+available.''
+
+We strongly recommend not to scale bitimage characters to
+the desired size within the driver. Either the
+document is important, then the desired font should be
+created by \MF\@. Or it is a document for which this
+small work is still too much, then another font can be
+chosen.
+
+
+
+\subsection{Typesetting Is At Least Setting Types}
+
+The quality of the output must not be determined by the
+driver. The user of a driver expects that the output is as
+accurate as the device can do it and that equivalent results
+are received on other computer systems and other devices
+(with respect to different resolutions and deficiencies in
+the printing engines). The program {\tt DVItype\/}
+\cite{tug:dvitype} claims to create {\it the\/} correct
+output and that every \DVI{} driver must not differ in its
+positioning results. Therefore {\tt DVItype\/} shall be a
+kind of ``prototype'' for each \DVI{} driver and the
+developer can check his implementation.
+
+To produce satisfying results a font designer can decide to
+choose for a character an other device dependent width than
+the equivalent of the device independent width. E.g., the
+device dependent width of `{\tt m\/}' in the unmagnified
+font {\tt cmr10\/} made for the printing engine {\tt
+imagen\/} is one pixel wider than the equivalent of the
+device independent width in pixels. Therefore the \DVI{}
+driver must not ignore the device dependent width. The {\it
+only\/} exception of this fact comes along with the usage of
+substituted fonts: the device dependent widths are wrong
+(because it's an other magnification) but the device
+independent widths can be scaled to the desired
+magnification and can be used as {\it the\/} width of the
+respective character. Please note, that this implies a
+necessary change in {\tt DVItype\/} because the usage of
+fonts in the \GF{} or \PK{} format must be supported that
+include this information.
+
+The differences between device dependent and device
+independent widths result in different positions in the
+`device raster' and the `device independent (\DVI{})
+raster.' Furthermore differences are established due to
+rounding errors, as explained in {\tt DVItype}. These
+differences must be adjusted at defined places and must not
+be allowed to diverge beyond a given limit. Both situations
+are covered in {\tt DVItype\/}---and the treatment of both
+is not completely satisfying.
+%
+\begin{enumerate}
+\item The adjustment of the horizontal difference should
+only occur between words, so that the distances between
+characters in one word are not altered. A similar policy
+should be used for the adjustment of the vertical
+differences, they should disappear only between lines. This
+will lead to the same vertical position of the character's
+baselines in one line even if a fraction is inserted in it.
+Therefore we have to identify the place where a word ends
+and we have to distinguish the dividing space between two
+lines from a vertical movement within a line.
+%
+\begin{itemize}
+\item It is a typesetting standard that words are divided by
+approximately \fract 1/3.~quad. This may vary usually by
+\fract 1/9.~quad, bigger differences are seldom used.
+Therefore a right movement of 0.2~quad or above can be
+considered as the dividing space between two words.
+
+The same amount must not be taken for left movements,
+because \TeX{} does relatively wide left movements to
+position accents above characters. The relevant characters
+are the small ones, capitals are only used at the beginning
+of a word. An acceptable limit is 0.9~quad, no non-capitals
+are beyond this limit.
+
+\item Baselines are approximately 1.2~quad apart, 0.8~quad
+seems to be a suitable limit for leaving the line area.
+%
+\end{itemize}
+%
+The difference to {\tt DVItype\/} is not the method but the
+values. Especially the limit for the left movement is too
+small in {\tt DVItype}, it doesn't cover all non-capitals.
+
+\item Version 2.6 of {\tt DVItype\/} introduces the concept
+of a ``maximal drift'' to limit the difference between the
+device position and the \DVI{} position: if a maximal
+difference is exceeded the device position is corrected. The
+problem with the realization of this concept is twofold:
+%
+\begin{enumerate}
+\item The maximal difference {\it max\_drift\/} is expressed
+as a fixed dimension, i.e.\ its current value is two pixels
+(for a standard device with 300~dpi, originally 200~dpi).
+If the same value will be used for another device with a
+different resolution the correction of the device positions
+will be done at different \DVI{} positions---resulting in a
+different output that is gone beyond the difference caused
+by the different rasters. Therefore we propose to choose a
+value in a device dependent unit, e.g.\ one percent of the
+resolution's dpi-value. This value will still be used as a
+dimension in pixel.
+
+\item If the device position must be corrected, {\tt
+DVItype\/} does this by a movement of {\it max\_drift\/}
+pixels towards the \DVI{} position. This always results in
+a device position one pixel next to the pixel equivalent of
+the \DVI{} position, regardless of the resolution. This
+movement (and also a direct movement to the \DVI{} position)
+is not satisfactory because it will eventually get too large
+and will disturb the eye of the reader. We propose to
+position half-way between the device and the \DVI{}
+position, i.e.\ to move $\lceil {\it max\_drift\/} / 2
+\rceil$~pixels towards the \DVI{} position. For the current
+value of {\it max\_drift\/} (two~pixels) this doesn't change
+the behaviour of {\tt DVItype}.
+%
+\end{enumerate}
+\end{enumerate}
+
+
+
+
+\section{Implementation}
+
+The requirement of similar behaviour is achieved best by
+drivers derived from the same source. The best known
+example of such a set of drivers is the driver family by
+Nelson F. Beebe~\cite{beebe:driver}. Furthermore this
+simplifies the implementation of a driver for a new device,
+if the device can be handled similar to one already in the
+set of supported devices.
+
+In the following section we will distinguish between the
+host computer and the output device itself. Usually they
+will be connected by a communication channel. The bandwidth
+may range from a serial line with rather poor throughput to
+a very closely coupled system where the device has access to
+the internal bus of the host and transfers can be made via
+direct memory access (DMA)\@.
+
+In general one has to distinguish two different types
+of hardcopy output devices:
+%
+\begin{itemize}
+\item Some need the output as a complete bitmapped page
+image. In this case a huge amount of data (increasing very
+rapidly with growing resolution) must be transferred from
+the controlling host to the output device. This leads in
+general to serious performance restrictions unless there is
+a high bandwidth communication channel between the host and
+the device.
+
+To reduce the size of the bitmap that has to be stored and
+transmitted one wishes to reduce the size of the buffer
+used. Unfortunately it is not possible to use the size from
+the \DVI{} file postamble, that is supposed to give the
+dimensions for the largest page of the document. But the
+values do not reflect any parts that were added when \TeX{}
+composed the page image and included the head and footlines,
+nor does it contain all overfull lines.
+
+Into this category we also take devices that need the
+printing information not as a dot matrix, but as a list of
+vectors that must be painted.
+
+\item Other devices can use local memory to store downloaded
+font sets. This can lead to reasonable throughput e.g.\ in
+a workstation environment even when the device is linked to
+the host by a serial line. This holds only for the current
+desk top printers with resolutions of 300~dpi. Higher
+resolutions again require higher throughput unless the
+patterns of the characters are sent encoded instead of
+indicating the bit patterns.
+
+There may be differences whether the download of a character
+may occur at any time, only between pages or only at the
+very beginning of an output job. Furthermore often the size
+of downloadable characters is limited and larger characters
+must be inserted as bitmaps anyway. Also the number of
+downloadable characters may be limited on a per page or per
+job base, and these limits may vary when the description of
+a page grows large, or large graphics images are included.
+
+The movement of the virtual output cursor may be limited,
+such that output for a page must be sorted in either
+vertical or also horizontal order. This holds especially
+for devices that can move their output medium only in one
+direction and are not capable of storing the contents for a
+full page in local memory.
+%
+\end{itemize}
+
+For screen previewers another categorization must be made.
+Vector displays are of limited usability, when single bit
+addressing capabilities are required to display dot
+matrices. In current workstations or personal computers the
+screen image is composed of bitmapped memory regions, even
+multiple bitplanes are used for colour output or greyscale
+displays. These bit planes are usually addressable by the
+controling host, at least at the system level. The main
+difference in system throughput is, whether there exist
+special purpose processors (``blitters'') that can move
+rectangles of these bit planes with high efficiency. This
+is due to the fact that the character images must be moved
+to arbitrary bit positions on the screen, but the master
+processor can address the memory only in 8 bit quantities,
+or even larger chunks, and thus image lines for each
+character must be shifted to the proper position before they
+can be inserted. The blitter processors are designed to
+handle these shifts internally and can change arbitrary
+regions.
+
+When the display is not connected to the host's bus, but
+through a slow terminal line, one needs local intelligence
+in the ``terminal'' to emulate a downloadable device to
+achieve reasonable throughput if bit images shall be
+displayed. If this intelligence is absent or not
+programmable, one has to live with output that cannot show
+accurate positions, because the proper fonts cannot be used.
+Such output can only be considered as a preliminary solution
+and does by no means lead to high quality output.
+
+
+
+\subsection{Language Issues}
+
+The main problems for implementation of a driver family are
+caused by the need to implement drivers for different
+devices in a variety of computer architectures and operating
+systems. To make such a family manageable it is necessary
+that the ``base'' implementation language allows
+modularization. Without software modules the resulting
+software system becomes too large to maintain or even to
+compile on small computers.
+
+An implementation for a new device can require basic changes
+in strategy for some parts of the driver. These can be
+handled best by replacing certain modules with versions
+specific to devices or device families. Of course the
+interface of the module in question must be clearly defined
+and obeyed by all implementations.
+
+To make it easy to port the driver to a variety of computer
+systems the language must be available with a reasonable
+amount of standardization. From the developer's point of
+view it is important that the language has a literate
+programming extension. This will, by the way, make the
+developer a user of the driver even during implementation
+and maintenance.
+
+Changes required by different operating systems or
+architectures can be made using a change file mechanism, as
+Knuth introduced it with \WEB{} for \TeX\@. This mechanism
+was first only available for all the ``literate
+programming'' language extensions; but it has been
+implemented recently by a small tool~\cite{tug:tie} for any
+base language.
+
+
+
+\subsection{Host requirements}
+
+Due to hardware drawbacks it may be necessary to be able to
+limit the amount of main memory required for the driver or
+parts of its internal tables in certain environments (e.g.,
+in the Intel processor line with their 64~KB addressing
+limitation). Also the number of files usable in parallel
+may be limited, or the output channel to the device might be
+of low throughput. On the other hand it may be useful to
+provide features for operation of the driver in a networking
+environment, where the font files reside on file servers and
+the output may be spooled to print servers. At least the
+driver should be able to access the files over a network
+when the operating system allows this.
+
+
+
+\subsection{Device Features}
+
+\subsubsection{Device ``Hardware'' Features}
+
+Another Pandora's box opens when you ask for the variety of
+special features of hardcopy output devices. There exist
+lots of different concepts for paper handling:
+%
+\begin{itemize}
+\item multiple input stacks,
+\item single sheet feeders,
+\item output in different bins or through sorters,
+\item both sides printing,
+\item changes of paper sizes and output placement.
+\end{itemize}
+%
+And even on dot matrix printers it is almost impossible to
+find two models that use the same single sheet processing
+commands.
+
+Not all of these features can be reasonable in each
+environment. E.g., it is not wise to allow single sheet
+insertion for an unattended device that is connected to a
+spool queue. Such features must be disabled for spool
+operation.
+
+For printer drivers, but even more for preview drivers it is
+necessary that the driver program clips any parts of the
+output page that do not fit onto the current page resp.\ fit
+into the current output window or the whole screen, if the
+device does not support clipping by itself.
+
+A time consuming part of device customization is the
+selection of parameters for the creation of fonts with
+\MF{}. This problem cannot be neglected, because especially
+for new output devices it seems to be very hard to find out
+how to create satisfactory fonts. Unfortunately it is not
+sufficient to feed the device resolution into \MF{}. Other
+parameters that reflect the appearance of output created by
+the device must be determined. This becomes even more
+complicated when a device has a knob to change its printing
+parameters (e.g.\ darkness). In this case different
+software packages might require different positions of the
+knob to produce optimal results and thus different
+parameters for \MF{} are necessary. Similar problems occur
+if the appearance of output depends on the quality of paper
+inserted.
+
+
+\subsubsection{Device ``Software'' Features}
+
+The situation is in no case better for the software
+features. The feature most requested by users is the
+possibility to integrate graphics into documents. The
+following formats for graphics are currently found:
+%
+\begin{itemize}
+\item Most printers can handle graphics in bitmap format.
+But the encoding of the bit image to the printer formats is
+more or less obscure and by no means generalized. Also the
+rapidly growing size of bitmap images with increasing
+resolution makes the usage of this kind of graphic inclusion
+not very attractive.
+
+\item For diagrams etc.\ the use of vector graphics may be
+more appropriate.
+
+\item The most flexible solution can be achieved by use of a
+page description language such as PostScript. This offers a
+broad range of applications.
+%
+\end{itemize}
+%
+But one must be aware, that all these extensions lead to non
+portable documents. One of the main advantages of the
+\TeX{} \DVI{} output is lost.
+
+For devices with the same font parameters but different
+bitmap encodings it is possible to integrate a uniform
+raster image support. This format can be driver family
+dependent (unless standardized) but allow at least a limited
+portability of graphics. The format must include the
+dimensions of the graphic anyway and even preview drivers
+that use a different resolution can display a frame in the
+size of the graphic insert to allow checking of correct
+positions. Additionally the raster can be stored in a
+compressed format, like the one used in the \PK{} format and
+thus at least the disk's storage requirements can be
+reduced. If the device requires the full bitmap no savings
+can be achieved for the transfer. But if it supports a
+special encoding with reduced amount of data the graphic
+data can be transformed to achieve best throughput.
+
+
+
+
+\section{Support of extensions by {\tt\char"5C special}}
+
+A driver may allow activation of device specific features
+through the \verb|\special| command provided by \TeX's
+\DVI{} output.
+
+When such extensions are supported by a driver, it is
+necessary that they are clearly tagged such that other
+drivers will not attempt to interpret them inadvertedly.
+The following form for the \verb|\special| string is
+recommended:
+%
+\begin{quote}
+\verb|<tag>: <action>|
+\end{quote}
+%
+The \verb|<tag>| is supposed to indicate the type of
+extension. This can resemble driver specific or device
+specific tags. Each driver may handle more than one tag.
+Special strings starting with tags that are unknown to the
+driver must be ignored. A warning message should be issued.
+To get a uniform handling among different drivers all tags
+must be registered---the appropriate place for this seems to
+be TUG\@. TUG can control that new tags are mnemonic and
+that their meaning is properly specified.
+
+The \verb|<action>| entry defines the action that shall be
+performed. It's recommended form is
+%
+\begin{quote}
+\verb|<function> [ :<parameters> ]|
+\end{quote}
+%
+where all legal functions must be specified with the
+registration of the tag. The entries \verb|<tag>| and
+\verb|<function>| must not be case sensitive. The optional
+\verb|<parameters>| section specifies additional information
+for the function (the delimiting colon is needed to allow
+parameter lists that start with white space).
+
+To include a picture file \verb|myfile.pic| in the format
+described above one may write e.g.
+%
+\begin{quote}
+\verb|\special{picfile: include: myfile.pic}|
+\end{quote}
+
+Often \verb|\special|s are demanded that activate any
+directive for the driver and document it in the \DVI{} file,
+e.g.
+%
+\begin{itemize}
+\item page orientation and placement,
+\item horizontal and vertical offset,
+\item number of copies,
+\item sheet feeder input,
+\item output stacker or sorter selection,
+\item processing order, and
+\item colour selection (where appropriate).
+\end{itemize}
+%
+But the current \DVI{} file format does not allow
+\verb|\special|s to appear outside of pages, i.e., they are
+only allowed between {\it bop\/} and {\it eop}. If one of
+the above directives is within a page then parts of this
+page can already be output. Furthermore other pages can be
+output before, therefore an implementable specification of
+this \verb|\special|s will be rather difficult.
+
+For documentation purposes an additional {\tt comment\/} tag
+should be included. This allows to add information about
+the source and status of the \DVI{} file, which is tied to
+the file, but not printed in the document.
+
+Also device specific functions can be made available. If a
+device offers a ``local'' command language (e.g.\ PostScript
+or PreScribe), escapes can be made through the
+\verb|\special| mechanism. They must be tagged by the name
+of the local command language or the device name to avoid
+misinterpretation by other devices. The required functions
+may be {\tt command\/} for the execution of an immediate
+local command given in \verb|<parameters>| or {\tt
+include\/} for copying a local command sequence from a file.
+
+The user should not have to write these \verb|\special|
+commands by himself. In most cases it is more appropriate
+to offer additional command definition files with macros
+that map logically structured functions to the proper
+\verb|\special| sequences. E.g., in the case of graphics
+inclusion the macro should also take parameters for the
+desired space for the picture and add all the necessary
+positioning commands to make the placement of the picture
+correct.
+
+
+
+
+\section{Installation}
+
+During the installation of a driver the following
+actions must be undertaken:
+%
+\begin{itemize}
+\item check the completeness of the distribution,
+\item setup the programs and customize search paths for the files used,
+\item enable or disable selectable features, and
+\item finally contain a test run to make sure that at least the easy
+ things work properly. This test should exercise also
+ all extensions of the driver.
+\end{itemize}
+%
+The installation procedure must be described in the manual.
+If the host computer is a multi user system, the
+installation part of the manual must be separable. For
+update versions a replacement installation must be supplied.
+
+
+
+
+\section{Conclusion}
+
+In this article we have listed the main issues for reliable
+drivers of high quality. Currently most existing drivers do
+not meet all points. The distinction between minimal subset
+of functions and additional features may serve as a measure
+of quality. It is intended that the discussion of this
+article will carry on the standardization
+process~\cite{gaffey:standards} and thus finally lead to
+more conforming drivers which make life easier for everybody
+who creates, maintains or uses them.
+
+
+
+
+%\bibliographystyle{plain}
+%\bibliography{tex,exeter}
+
+%%%%%%%%%%%%%%%%
+% exeter.bbl
+\begin{thebibliography}{1}
+
+\bibitem{tug:dvi}
+Device independent file format.
+\newblock {\it TUGboat}, 3(2):14--19, 1982.
+
+\bibitem{tug:gf}
+Generic font file format.
+\newblock {\it TUGboat}, 6(1):8--11, 1985.
+
+\bibitem{beebe:driver}
+Nelson~H.~F. Beebe.
+\newblock A {\TeX} {\DVI} driver family.
+\newblock In {\it TUG VIII Conference Proceedings}, pages~71--113, \TeX{} User
+ Group, 1987.
+
+\bibitem{tug:pxl}
+David~R. Fuchs.
+\newblock The format of {\PXL} files.
+\newblock {\it TUGboat}, 2(3):8--12, 1981.
+
+\bibitem{tug:dvitype}
+David~R. Fuchs.
+\newblock {\it The {\tt DVItype} Processor (Version 2.7)}.
+\newblock {\WEB} Program, Stanford University, August 1984.
+
+\bibitem{tug:tie}
+Klaus Guntermann and Wolfgang R{\"u}lling.
+\newblock Another approach to multiple changefiles.
+\newblock {\it TUGboat}, 7(3):134, 1986.
+
+\bibitem{gaffey:standards}
+Robert~W. McGaffey.
+\newblock Developing {\TeX} {\DVI} driver standards.
+\newblock In {\it TUG VIII Conference Proceedings}, pages~69--70, \TeX{} User
+ Group, 1987.
+
+\bibitem{peters:life-cycle}
+J.~L. Peters and L.~L. Trip.
+\newblock A model of software engineering.
+\newblock In {\it Proc.\ 3rd International Conference on Software Engineering},
+ pages~63--70, Institute of Electrical and Electronics Engineers, New York,
+ 1978.
+
+\bibitem{tug:pk}
+Tomas Rockicki.
+\newblock Packed ({\PK}) font file format.
+\newblock {\it TUGboat}, 6(3):115--120, 1985.
+
+\end{thebibliography}
+%%%%%%%%%%%%%%%
+
+
+
+
+\end{document}
diff --git a/dviware/driv-standard/papers/report-9105-tub.tex b/dviware/driv-standard/papers/report-9105-tub.tex
new file mode 100644
index 0000000000..0adb69fe9d
--- /dev/null
+++ b/dviware/driv-standard/papers/report-9105-tub.tex
@@ -0,0 +1,100 @@
+% report-9105-tub.tex 21 Jun 91
+%------------------------------------------------------------
+
+%
+% Report on the DVI Driver Standard
+%
+% [Plain]
+
+
+\input tugboat.sty
+
+\def\DVI{{\tt DVI}}
+\def\GF{{\tt GF}}
+
+\title * Report on the \DVI{} Driver Standard *
+\author * Joachim Schrod\\
+ Secretary\\
+ TUG \DVI{} Driver Standards Committee *
+\netaddress [\network{Bitnet}] * xitijsch@ddathd21 *
+
+\pagexref{schrod}
+
+\article
+
+The \DVI{} Driver Standard will be available in several stages. The
+basic stage is now called level~0. It covers only those driver
+capabilities which are really necessary to output a \DVI{} document
+on an output device. All other driver capabilities will be called
+features (and may even be realized outside a driver). In the future
+we will publish several additional standard documents which will cover
+ranges of features; those documents will represent ``tiers'' built upon
+level~0 or on previous tiers. In this way they will be available as
+future stages of a complete standard. (One may doubt whether the standard
+will ever be complete as there may be always new features to
+standardize.)
+
+The basic stage, level~0, consists of three parts:
+\list
+\item[\tag{(1)}] The pure standard document telling what a driver must
+ be able to do.
+\item[\tag{(2)}] Definitions of all file formats spoken of in part~1.
+\item[\tag{(3)}] A rationale describing why the committee has chosen
+ the given definition in part~1, recalling discussions that led to
+ particular decisions.
+\endlist
+%
+A draft of the level~0 document is about to be published for public review.
+Part~1 of the draft is (almost) ready; a few spelling errors and such
+have to be removed. Part~2 was ready, but D.\,E.~Knuth has changed
+the \GF{} documentation, and this change must be incorporated.
+Part~3 exists only in part.
+
+The committee will publish the draft as soon as possible. It may be
+that the draft of the rationale will not be finished in time; in that
+event we will publish part~1 by itself. This is considered to be useful
+(although not desirable) so that we will get responses very soon\Dash
+and especially to change the status from ``draft'' to ``released'' as
+soon as possible. The file formats will not be published in \TUB; they
+are available on several file servers. For people who do not have access
+to file servers I've prepared a brochure covering all file formats.
+
+When complete, the standard will be published in the {\sl \TeX{}niques\/}
+series. The style will be modified slightly to follow formal standards
+conventions. The body of the standard will form the main text; this
+will be followed by a number of ``annexes''. The file formats will come
+immediately after the main text, as ``normative'' annexes; that is, these
+format specifications are an integral part of the standard, but the
+presentation of each is self-contained and too large to be appropriate
+in the main text. Finally, the rationale will appear as an
+``informative'' annex, to present information that is not an integral
+part of the standard, but is intended to help a user in understanding it.
+
+\head * Future work *
+
+What tier will come next, i.e., what driver feature will be looked at
+next, is still unclear. There is public pressure to tackle the area of
+graphics inclusion at an early date; others want to touch areas such as
+page selection, etc., first. So this remains an open problem. We
+%invite all parties to feed work into the committee. My personal
+invite all parties to bring proposals to the committee. My personal
+opinion is that a proposal for a new tier received early will be
+handled early. So if someone is eager to see a specific topic
+addressed, he or she should do work on this topic and send us the
+result of the work. (We will be glad to acknowledge contributors.)
+
+\signature{\signaturemark
+ Joachim Schrod\\
+ Technical University of Darmstadt\\
+ Institut f\"ur Theoretische Informatik\\
+ Alexanderstra\ss{}e 10\\
+ W-6100 Darmstadt\\
+ Federal Republic of Germany\\
+ \thenetaddress1}
+\makesignature
+
+\endarticle
+
+
+
+\bye
diff --git a/dviware/driv-standard/papers/report-9106-board.tex b/dviware/driv-standard/papers/report-9106-board.tex
new file mode 100644
index 0000000000..65a002333d
--- /dev/null
+++ b/dviware/driv-standard/papers/report-9106-board.tex
@@ -0,0 +1,607 @@
+% report-9106-board.tex 12 Jul 91
+%------------------------------------------------------------
+% Copyright 1991 by Joachim Schrod.
+
+%
+% Report from the DVI Driver Standards Committee
+% (about the year June 1990 -- May 1991)
+% for the TUG Board
+%
+% [LaTeX]
+
+
+\documentstyle{article}
+
+
+
+\def\committee{\DVI{} Driver Standards Committee}
+\def\dvistd{\DVI{} Driver Standard}
+
+\def\LaTeX{{\rm L\kern-.36em\raise.3ex\hbox{\sc a}\kern-.15em\TeX}}
+\def\BibTeX{{\rm B\kern-.05em{\sc i\kern-.025em b}\kern-.08em\TeX}}
+\def\PiCTeX{P\kern-.12em\lower.5ex\hbox{I}\kern-.075emC\kern-.11em\TeX}
+
+\font\eightlogo=logo8
+\font\tenlogo=logo10
+\def\MF{{\logo META}\-{\logo FONT\/}}
+\def\MFfn{{\eightlogo META}\-{\eightlogo FONT\/}} % MF in footnote
+
+\def\DVI{{\tt DVI\/}}
+\def\TFM{{\tt TFM\/}}
+\def\GF{{\tt GF\/}}
+\def\PK{{\tt PK\/}}
+\def\VF{{\tt VF\/}}
+
+\def\PS{{\sc Post\-Script}}
+
+
+
+
+\begin{document}
+
+
+
+\title{Report on the year June 1990 -- May 1991}
+\author{%
+ The \committee{}%
+ \thanks{%
+ This report was compiled by {\sc Joachim Schrod}, Secretary.%
+ }%
+ }
+\date{June 1991}
+
+\maketitle
+
+
+
+
+\begin{abstract}
+
+In July~1990 the \committee{} changed most of its members. Afterwards
+it revised a first draft of the \dvistd{}, level~0. The draft is
+almost finished and will be published in the next TUGboat issue.
+Future parts of the standard are already under discussion; but it is
+not decided up to now which part will be handled next.
+
+This report describes the structure of the forthcoming standard, which
+topics were under discussion for the last year, who is in the
+committee, and which information the committee may provide for the
+membership-at-large. Future work is outlined.
+
+\end{abstract}
+
+
+
+
+\section{Introduction}
+\label{sec:introduction}
+
+The \DVI{} Driver Standard will be available in several stages. The
+basic stage is now called level~0. It covers only those driver
+capabilities which are really necessary to output a \DVI{} document
+on an output device. All other driver capabilities will be called
+features (and may even be realized outside a driver). In the future
+we will publish several additional standard documents which will cover
+ranges of features; those documents will represent ``tiers'' built upon
+level~0 or on previous tiers. In this way they will be available as
+future stages of a complete standard. (One may doubt whether the standard
+will ever be complete as there may be always new features to
+standardize.)
+
+The basic stage, level~0, consists of three parts:
+%
+\begin{enumerate}
+
+\item The pure standard document telling what a driver must be able
+to do.
+
+\item Definitions of all file formats spoken of in part~1.
+
+\item A rationale describing why the committee has chosen the given
+definition in part~1, recalling discussions that led to particular
+decisions.
+
+\end{enumerate}
+%
+ A draft of the level~0 document is about to be published for public
+review. Part~1 of the draft is (almost) ready; a few spelling errors
+and such have to be removed. Part~2 was ready, but Donald Knuth has
+changed the \GF{} documentation, and this change must be
+incorporated. Part~3 exists only in part.
+
+\bigskip
+
+The outline of this report is as follows: Section~\ref{sec:committee}
+presents the committee, how it works, and how information on former
+discussions may be fetched. Section~\ref{sec:level0} presents the
+process which led to the first draft. Section~\ref{sec:discussion}
+names the discussion topics the group encountered but which are not
+covered by the standard up to now. Section~\ref{sec:future} names
+future work which remains to be done.
+
+
+
+
+\section{The Committee}
+\label{sec:committee}
+
+\subsection{The Voting Members}
+
+Effective June 1, 1991, the \committee{} has the (voting)
+members as given in table~\ref{tab:members}.
+
+\begin{table}
+
+ \begin{center}
+ \hfuzz=20pt % the table is 19.83186pt too wide
+ \begin{tabular}{ll}
+ \sc Name & \sc Organization /\\
+ & \qquad \sc Email\\
+ Don Hosek (Chair) &
+ Quixote Digital Typography\\
+ & \qquad \tt dhosek@ymir.claremont.edu\\
+ Joachim Schrod (Secretary) &
+ Technical University of Darmstadt\\
+ & Representative of DANTE e.V.\\
+ & \qquad \tt xitijsch@ddathd21.bitnet\\
+ Nelson Beebe &
+ University of Utah\\
+ & \qquad \tt beebe@science.utah.edu\\
+ Bart Childs &
+ Texas A\,\&\,M University\\
+ & \qquad \tt bart@cssun.tamu.edu\\
+ Adrian Clark &
+ University of Essex\\
+ & Representative of uk\TeX{}ug\\
+ & \qquad \tt alien@essex.ac.uk\\
+ Andrew Dobrowolski &
+ Arbortext, Inc.\\
+ & \qquad \tt aed@arbortext.com\\
+ Bernard Gaulle &
+ Representative of GUTenberg\\
+ & \qquad \tt ucir001@frors31.bitnet\\
+ Robert McGaffey &
+ Oak Ridge National Laboratory\\
+ & \qquad \tt mcgaffey\%orn.mfenet@ccc.mfecc.llnl.gov\\
+ Tomas G. Rokicki &
+ Radical Eye Software\\
+ & \qquad \tt rokicki@polya.stanford.edu\\
+ Jan Michael Rynning &
+ Royal Institute of Technology, Stockholm\\
+ & Representative of the Nordic Group\\
+ & \qquad \tt jmr@nada.kth.se\\
+ Ralph Youngen &
+ AMS\\
+ & \qquad \tt rey@seed.ams.com\\
+ \end{tabular}
+ \end{center}
+ \caption{Voting members of the \committee{}. (Apologies if
+organizations are wrong, they were collected by me from the email
+exchange.)}
+ \label{tab:members}
+
+\end{table}
+
+The group of the voting members was established on July~19, 1990, with
+Don Hosek as chair. We did not have a secretary then. In the
+report year the following changes occured:
+%
+ \begin{itemize}
+
+\item Adrian Clark entered the committee at July~31, 1990, as a
+representative for the uk\TeX{}ug.
+
+\item Andrew Dobrowolski is a committee member since January 21,
+1991.
+
+\item Joachim Schrod is secretary since February 3, 1991.
+
+ \end{itemize}
+%
+ There are no members belonging to the NTG, to the Japanese \TeX{}
+Users Group (if there exists one at all), to the Italic \TeX{} Users
+Group, or to one of the newly founded groups from Eastern Europe
+(e.g., from Poland).
+
+We would like to thank former members of the committee, which resigned
+on July~19, 1990:
+David P. Babcock (Hewlett-Packard),
+Elizabeth Barnhart (TV~Guide),
+Stephan v.~Bechtolsheim (Integrated Computer Software, Inc.),
+Jackie Damrau (University of New Mexico),
+Donald Goldhammer (University of Chicago),
+David Ness (TV~Guide),
+Thomas J.~Reid (Texas A\,\&\,M University),
+David Rodgers (Arbortext, Inc.),
+Brian Skidmore (Addison-Wesley Publishing Co.),
+and
+Glenn Vanderburg (Texas A\,\&\,M University).
+John Gourlay (Arbortext, Inc.) left the committee on January~21, 1991.
+
+
+
+\subsection{The Voting Procedure}
+
+The committee has no charter up to now. It will create and vote on
+drafts of the \DVI{} driver standard (structured as outlined in
+section~\ref{sec:introduction}). Ammendments on the drafts may be
+made, the process is as follows:
+%
+ \begin{enumerate}
+
+\item The chair will be considered a voting member, but only in the
+case of a tie vote.
+
+\item Anyone may propose an ammendment, but an ammendment not
+proposed by one of the voting members of the group needs a second by
+one of the voting members of the group. An ammendment by a voting
+member does {\it not\/} need a second. An ammendment should be
+clearly labelled as such and sent to the secretary. He will
+redistribute it to the voting members.
+
+\item While an ammendment is on the floor, voting members may vote
+``{\sl Yes},'' ``{\sl No},'' or ``{\sl Abstain}.'' A reminder will
+be sent out once every 48~hours for every ammendment they have not
+yet voted on.
+
+\item An ammendment will be considered ``{\sl on the floor\/}'' until
+%
+ \begin{enumerate}
+
+\item it has received a number of ``{\sl Yes\/}'' votes greater than
+half the total number of voters,
+
+\item it has received a number of ``{\sl No\/}'' votes greater than
+half the total number of voters,
+
+\item it has been explicitly withdrawn by its original proposer,
+
+\item all voting members of the group have voted on it, or
+
+\item it has been out for four weeks and has not been settled. Then
+it will be considered voted on with those votes received. A tie vote
+by the chair may be necessary then.
+
+ \end{enumerate}
+%
+
+\item If two ammendments are submitted which would modify the same
+portion of the draft, the second received by the secretary will be
+tabled while the first is on the floor. In the event of the passage
+of the first, the proposer will be asked if he wants to withdraw the
+ammendment before it is submitted for a vote.
+
+ \end{enumerate}
+%
+
+
+
+\subsection{Retrieving Information}
+
+The discussion takes place on a Bitnet discussion list, {\tt
+driv-l@tamvm1.bitnet}. All postings for one month are saved and may
+be retrieved from the Bitnet listserver (as described in our report
+of April~1989).
+
+\medskip
+
+In addition I began to store all information which is available and
+which seems to be of interest on the anonymous ftp server {\tt
+ftp.th-darmstadt.de\/} in the directory {\tt /pub/tex/dvi-standard}.
+
+In the subdirectory {\tt driv-l\/} all postings to {\tt driv-l\/} are
+stored -- this is a mirror to the service of the listserver. But
+there are two more important files there: {\tt Index\/} contains the
+important topics of each month as one-liners. This will help the
+retrieval of earlier contributions to the ongoing discussion. In
+addition {\tt Index.last-three-months\/} is a copy of the last three
+months of {\tt Index}, such giving a fast access to the last handled
+topics.
+
+The standard texts itself are placed in the subdirectory {\tt
+standards}, each tier in a single file. Ammendments are stored in
+this directory, too. For people which have RCS at hand (it's
+available for free), a corresponding RCS file is stored in the
+subdirectory {\tt standards/RCS}. This RCS file enables the retrieval
+of former revisions of this tier.
+
+In the subdirectory {\tt papers\/} all reports of the committee will
+be found. In addition other important papers are stored here (if they
+are available and redistributable free of charge). Furthermore a
+\BibTeX{} database with relevant publications on \DVI{} drivers is
+available there in the file {\tt dvistd.bib}.
+
+In the subdirectory {\tt verification\/} the {\tt DVIASM} processor
+may be found (see page~\pageref{sec:dviasm}). In future, information
+on a verification suite (a so-called ``trip test'') will be placed
+here, too.
+
+
+
+
+\section{The Standard, Level~0}
+\label{sec:level0}
+
+On June~1, 1990, a first release of the draft was in existence. This
+release was not in \TeX{} form, and was not written in sentences,
+there were only item lists.
+
+On June 23, 1990, draft~\#\,2 was announced. This was the first draft
+in \LaTeX{} markup and with complete sentences. It was reviewed in the
+following discussion which led to severe changes.
+
+The next release, as of July 19, 1990, changed the name of the draft
+from just a number to $x.y$ with $x$ as a designation for the
+standard part and $y$ as a designation of the release. So this new
+draft was named~0.03. It adopted the notion of ``tiers'' for the
+future structure of other standard levels. This structure was
+proposed by Joachim Schrod and Klaus Guntermann. Furthermore
+appendices were added with file format specifications%
+ \footnote{%
+ These appendices were created by Joachim Schrod during a work
+on a brochure on all file formats which are defined in the context of
+\TeX{} and \MFfn{}. This work is not connected to the \DVI{} driver
+standards committee.
+ }
+ and with the specification how to handle the ``maximal drift
+problem.'' The step from draft~\#\,2 to draft~0.03 was not made with
+a formal decision, Don Hosek simply collected all relevant
+contributions and put them in the draft.
+
+Almost three months full of discussion passed until the next release
+(named draft~0.04) was ready on October~6, 1990. The language style
+of the document was changed more towards a ``standards document
+style,'' i.e., the usage of ``must'' instead of ``should,'' etc. A
+difference between standard text and explication was added -- this
+has been the first (and only) step towards a rationale document. The
+rationale was proposed by Nelson Beebe; Thomas Reid did the final
+outline for the now-planned document. The step from draft~0.03 to
+draft~0.04 was a formal one, eight ammendments were presented (four
+by Don Hosek, one by Thomas Reid, and three by Joachim Schrod), and
+five of these eight change requests were accepted.
+
+A month later, on November~13, 1990, the next release was ready.
+Since no formal changes took place, the draft was named~0.04a (such
+introducing branches to releases). The changes were mainly spelling
+errors, typographic errors, etc., which were sent to Don Hosek
+via email (partly via {\tt driv-l\/}). A bunch of these changes was
+covered additionally by an ammendment by Joachim Schrod, which was
+withdrawn then. But since Don Hosek forgot to merge {\it all\/}
+corrections sent to him he had to release draft~0.04b on January~24,
+1991.
+
+On March~25, 1991, the last two ammendments up to now (sent in on
+November~14, 1990 [sic!] by Joachim Schrod) passed. They would have
+resulted in the draft~0.05. But the job of managing the drafts has
+passed to the newly appointed secretary Joachim Schrod, who uses RCS
+(the {\sl Revision Control System\/}) for the management task.
+Therefore we now have the draft~0, release~5.1. The old releases are
+available via RCS, they were inserted in the system in an appropriate
+form.
+
+Since then no ammendments have arrived, so the level~0 may be
+considered as settled and will be published in the next TUGboat issue
+for further discussion by the membership-at-large.
+
+
+
+
+\section{Further Topics of Discussion}
+\label{sec:discussion}
+
+In addition to the referee process of the draft, discussions on other
+topics took place. I want to name the most important of them in this
+section.%
+ \footnote{%
+ Please note that only those topics are listed which are not
+found in the standard up to now and which will be addressed in a
+future tier. If you remember an important topic which is not listed
+here it may be that it is already part of draft~0.
+ }
+
+General things worth to mention are:
+%
+ \begin{itemize}
+
+\item The publication of draft~0 was planned for the last regular
+TUGboat issue in~1990. We hope now that the end of the year~1991 will
+see the final approval.
+
+\item The problem of incomplete \DVI{} files was discussed. It was
+raised by the question if one may assume that a driver may randomly
+position within \DVI{} files and that \DVI{} files always have a
+postamble.
+
+\item A change to file formats was planned: Padding should have been
+accepted due to transfer problems between different computer systems.
+This change was rejected. The reason was not only the technical
+problems, organizational problems must be taken into account, too
+(the changes would not have been approved by Donald Knuth).
+
+ \end{itemize}
+%
+
+
+\paragraph{Fonts:}
+
+\begin{sloppy}
+
+A lot of discussions handled the fonts issue. In the meantime the
+discussion of this topic takes place on the email discussion list
+{\tt tex-fonts@math.utah.edu}, this topic has now nearly disappeared
+on {\tt driv-l}. But still important background information and
+important proposals may be fetched from our discussion backlogs.
+
+\end{sloppy}
+
+\begin{itemize}
+
+\item Font naming proposals were discussed in depth (and in breadth).
+
+\item How the user may control font searches.
+
+\item What to do if a font is missing:
+%
+ \begin{itemize}
+
+\item Due to a rounding error? I.e., up till when a font should be
+considered the same even when it has an other font resolution.
+Calculations on the possible range of rounding errors may be found in
+the discussion backlog. (This will perhaps be included in the
+rationale.)
+
+\item Algorithms were presented how such fonts may be searched without
+doing a full directory search.
+
+\item When to issue error messages and what contents they should
+have. (This will perhaps be included in the rationale.)
+
+ \end{itemize}
+%
+
+\item There is still an undefined topic in the draft: What to do with
+fonts which have a checksum of zero. (The \TFM{} definition
+contradicts with other definitions, e.g., the \PK{} definition.)
+
+\item Mappings for fonts with other codings than Computer Modern (or
+the new codings developped by the committee on 8-bit chars) may be
+presented by \VF{} files. These are not covered in the level~0 (as
+they are not directly needed for the output of a \DVI{} document) but
+will be added in one of the next tiers.
+
+\end{itemize}
+
+
+\paragraph{Specials:}
+
+They are always a hot topic. Two groups may be identified: The
+first one fears a pandora's box to be opened, the second thinks it's
+the most important thing to do. The most important submissions
+discussed:
+
+\begin{itemize}
+
+\item When should a driver issue a warning? Always if it comes to a
+non-standard special or only if it comes to an unknown special?
+
+\item How to specify global specials was still discussed. This
+discussion was already mentioned in the report of April~1989.
+
+\item Teresa A. Ehling and Berthold K. P. Horn called for the
+standardization of specials for inclusion of \PS{} graphics. This was
+rejected at the moment: It does not belong to level~0. Of course, it
+will be mentioned in a future tier, but then it will be more general
+than just for \PS{} inclusions.
+
+\item Nelson Beebe presented a ``keyword-value'' approach for
+specials, which was widely applaused.
+
+\end{itemize}
+
+
+
+\paragraph{Maximal Drift:}
+
+Maximal drift is a concept how to spread divergences between the
+device position and the device-indepedent position as given in the
+\DVI{} file. The aim is that a reader is not to be disturbed too
+much. Maximal drift is covered in the level~0, as it is one of the
+basic functionalities of a driver. But still some important comments
+are worth to mention:
+
+\begin{itemize}
+
+\item \PS{} drivers should do the maximal drift handling by
+themselves. To quote Stephan v.~Bechtolsheim: ``One of the things
+{\it I don't like\/} about \PS{} is that when it comes down to it you
+{\it never\/} know precisely what happens.'' But this is the task of
+a driver. In fact, this means that a true device independent \PS{}
+driver is not possible to make. (This will perhaps be included in the
+rationale.)
+
+\item Enhanced maximal drift algorithms were proposed. They cover a
+special handling of mono-spaced fonts (and how to discover them),
+problems in \PiCTeX{}-style graphics, etc.
+
+\item How to align rules consistently (without overlapping and such)
+was disscussed in length. Solutions are available, they are a mixture
+of \TeX{} macros and driver care.
+
+\end{itemize}
+
+
+\paragraph{A Trip Test:}
+
+Very early the demand for a trip test, i.e., a standard conformance
+verification suite, was outspoken. But a lot of problems arise here:
+
+\begin{itemize}
+
+\item How may one control that the output of a driver is correct?
+Perhaps there must be special versions of conformant drivers which
+output protocol stuff to which the correct results may be compared.
+
+\item A special subproblem of the item above is: How may one assert
+the correct maximal drift handling when source code is not available?
+
+\item What cases must be handled by a trip test?
+
+\end{itemize}
+
+As a first step towards the creation of such a test, Thomas Reid wrote
+{\tt DVIASM},
+ \label{sec:dviasm}
+ a processor which takes a textual description of a \DVI{} file and
+compiles it into the binary form. (A processor for the other
+direction which produces an output to be read by {\tt DVIASM\/} would
+be of use, too.)
+
+
+
+
+\section{Future Work}
+\label{sec:future}
+
+A lot of work remains to do:
+%
+ \begin{itemize}
+
+\item The draft~0 must still be published, and approved.
+
+\item The rationale for the draft~0 must be written (and published).
+
+\item The committee should write a charter for itself so that it's
+clearer which tasks it will handle and which not.
+
+\item The committee must decide which tier will be handled next and
+must formulate a first draft for it. (Public pressure calls for the
+tier on specials.)
+
+\item The trip test must be worked out.
+
+\item The available information on \DVI{} drivers and the standard
+must be more structured and must be made available on a wider base.
+The newly created ftp-server in Darmstadt is a first step in this
+direction. After it has consolidated it will be distributed to other
+interested sites.
+
+ \end{itemize}
+%
+
+
+
+
+\section*{Acknowledgements}
+
+A lot of people sent their helpful comments. But we must mention a
+few which do not belong to the voting members and which spend a large
+amount of work on the standard (more than most voting members): First
+of all, Thomas Reid, without whom this standard would never exist.
+Stephan v.~Bechtolsheim, Karl Berry, Pierre MacKay, and Jan Michael
+Rynning made substantial contributions, too.
+
+
+
+
+
+\end{document}
diff --git a/dviware/driv-standard/papers/special-beebe-1.02/bibnames.sty b/dviware/driv-standard/papers/special-beebe-1.02/bibnames.sty
new file mode 100644
index 0000000000..7d49297434
--- /dev/null
+++ b/dviware/driv-standard/papers/special-beebe-1.02/bibnames.sty
@@ -0,0 +1,149 @@
+%/u/sy/beebe/tex/bib/bibnames.sty, Tue Jul 10 14:19:57 1990
+%Edit by Nelson H.F. Beebe <beebe@plot79.math.utah.edu>
+%%
+%% @texfile{
+%% author = "Nelson H. F. Beebe",
+%% version = "1.03",
+%% date = "01 August 1991",
+%% filename = "bibnames.sty",
+%% address = "Center for Scientific Computing
+%% and Department of Mathematics
+%% South Physics Building
+%% University of Utah
+%% Salt Lake City, UT 84112
+%% USA
+%% Tel: (801) 581-5254",
+%% checksum = "143 393 4284",
+%% email = "beebe@science.utah.edu (Internet)",
+%% codetable = "ISO/ASCII",
+%% supported = "yes",
+%% docstring = "This file provides standard definitions of
+%% proper names needed in TeX-related
+%% bibliographies. The definitions are a
+%% significant extension of those in Rick
+%% Futura's texnames.sty; the latter is not
+%% used directly here, because not all sites
+%% have it.
+%% The checksum field above contains the
+%% standard UNIX wc (word count) utility
+%% output of lines, words, and characters;
+%% eventually, a better checksum scheme should
+%% be developed."
+%% }
+%
+%=======================================================================
+% The TeX-related program names that are not defined already in LaTeX
+%
+% Richard Furuta
+% Department of Computer Science
+% University of Maryland
+% College Park, MD 20742
+%
+% furuta@mimsy.umd.edu
+% seismo!umcp-cs!furuta
+%
+% October 22, 1986, first release
+%
+% April 1, 1987: modified by William LeFebvre, Rice University
+% Now includes definitions for BibTeX and SLiTeX, as they appear in the
+% LaTeX Local User's Guide.
+%
+% April 10, 1989: modified by NHFB: added use of \ifundefined so as to
+% preserve any existing definitions.
+%=======================================================================
+% TeXbook, p. 308:
+\def\ifundefined#1{\expandafter\ifx\csname#1\endcsname\relax}
+%
+% The following comes from Mike Spivak
+\ifundefined{AMSTEX}
+ \newcommand{\AMSTEX}{$\cal A$\kern-.1667em\lower.5ex\hbox{$\cal M$}
+ \kern-.125em$\cal S$-\TeX}
+\fi
+% Letter case variants:
+\ifundefined{AmSTeX}
+ \newcommand{\AmSTeX}{\AMSTEX{}}
+\fi
+%
+\ifundefined{AMSTeX}
+ \newcommand{\AMSTeX}{\AMSTEX{}}
+\fi
+%
+% \BibTeX and \SLiTeX, taken from the top of the local user's guide (--wnl)
+\ifundefined{BibTeX}
+ \newcommand{\BibTeX}{{\rm B\kern-.05em{\sc i\kern-.025em b}\kern-.08em
+ T\kern-.1667em\lower.7ex\hbox{E}\kern-.125emX}}
+\fi
+%
+\ifundefined{CMR}
+ \newcommand{\CMR}{{Computer Modern}}
+\fi
+%
+\ifundefined{CWEB}
+ \newcommand{\CWEB}{{\tt CWEB}}
+\fi
+%
+\ifundefined{emdash}
+ \newcommand{\emdash}{\penalty\exhyphenpenalty---\penalty\exhyphenpenalty}
+\fi
+%
+\ifundefined{LAMSTeX}
+\newcommand{\LAMSTeX}{L\raise.42ex\hbox{\kern-.3em\the\scriptfont2 A}%
+ \kern-.2em\lower.376ex\hbox{\the\textfont2 M}\kern-.125em
+ {\the\textfont2 S}-\\Tex{}}
+\fi
+%
+\ifundefined{FWEB}
+ \newcommand{\FWEB}{{\tt FWEB}}
+\fi
+%
+\ifundefined{METAFONT}
+ \font\mf=logo10
+% \hyphenchar\mf=-1
+ \newcommand{\METAFONT}{{\mf META{\rm{}\-{}}FONT}}
+\fi
+%
+\ifundefined{MF}
+ \newcommand{\MF}{\METAFONT}
+\fi
+%
+\ifundefined{ndash}
+ \newcommand{\ndash}{\penalty\exhyphenpenalty--\penalty\exhyphenpenalty}
+\fi
+%
+\ifundefined{noopsort}
+ \newcommand{\noopsort}[1]{}
+\fi
+%
+\ifundefined{PLOT}
+ \newcommand{\PLOT}{{\mbox{\raise.2ex\hbox{$<$}\kern-.06em\hbox{PLOT79}
+ \kern-.3em\hbox{\raise.2ex\hbox{$>$}}}}}
+\fi
+%
+\ifundefined{POSTSCRIPT}
+ \newcommand{\POSTSCRIPT}{{\sc Post\-Script}}
+\fi
+%
+\ifundefined{PS}
+ \newcommand{\PS}{\POSTSCRIPT}
+\fi
+%
+\ifundefined{singleletter}
+ \newcommand{\singleletter}[1]{#1}
+\fi
+%
+\ifundefined{SLiTeX}
+ \newcommand{\SLiTeX}{{\rm S\kern-.06em{\sc l\kern-.035emi}\kern-.06em
+ T\kern -.1667em\lower.7ex\hbox{E}\kern-.125emX}}
+\fi
+%
+\ifundefined{tubissue}
+ \newcommand{\tubissue}[2]{\TUB~#1, no.~#2}
+\fi
+%
+\ifundefined{TUB}
+ \newcommand{\TUB}{{\em TUG\-boat\/}}
+\fi
+%
+\ifundefined{WEB}
+ \newcommand{\WEB}{{\tt WEB}}
+\fi
diff --git a/dviware/driv-standard/papers/special-beebe-1.02/pathname.tex b/dviware/driv-standard/papers/special-beebe-1.02/pathname.tex
new file mode 100644
index 0000000000..73a392290c
--- /dev/null
+++ b/dviware/driv-standard/papers/special-beebe-1.02/pathname.tex
@@ -0,0 +1,54 @@
+%/u/sy/beebe/tex/pathname.tex, Sat Oct 15 14:07:20 1988
+%Edit by Nelson H.F. Beebe (beebe at plot79.utah.edu)
+%
+% Computer filenames, host names, and mail addresses tend to be long
+% strings that cause line breaking problems for TeX. This file
+% defines a macro that automatically inserts discretionary hyphens in
+% its argument at potential breakpoints, and sets the text in the
+% typewriter font. It is invoked simply by enclosing the string in
+% vertical bars (chosen because they do not appear in mail addresses,
+% and are rare in filenames):
+%
+% |Friesland\%rz.informatik.uni-hamburg.dbp.de\%germany.csnet@relay.cs.net|
+% |MIGHTY-MOUSE-GW.SCRC.SYMBOLICS.COM| (longest name in Arpanet host table)
+%
+% Note that the characters $%_#^\{}| in the string still have to be
+% protected against other interpretation by prefixed backslashes.
+%
+% Discretionary hyphens are inserted BEFORE the characters @!%/.
+%
+% This code was inspired by the reversing macro in Donald E. Knuth and
+% Pierre MacKay, ``Mixing right-to-left texts with left-to-right texts'',
+% TUGboat 8(1)14-25 (1987) and the LaTeX \verb macro.
+%
+\catcode`\|=\active%
+\def|#1|{\catcode`\@=11\catcode`\%=12 {\tt \pathname#1\empty\emanhtap}%
+ \catcode`\@=12\catcode`\%=14}%
+%\def|#1|{{\tt \pathname#1\empty\emanhtap}}%
+%
+\def\pathname#1#2\emanhtap{%
+ \ifx#1\empty%
+ \else%
+ \ifx#1.%
+ \-#1%
+ \else%
+ \ifx#1/%
+ \-#1%
+ \else%
+ \ifx#1@%
+ \-#1%
+ \else%
+ \ifx#1!%
+ \-#1%
+ \else%
+ \ifx#1\%%
+ \-#1%
+ \else%
+ #1%
+ \fi%
+ \fi%
+ \fi%
+ \fi%
+ \fi%
+ \pathname#2\emanhtap%
+ \fi}%
diff --git a/dviware/driv-standard/papers/special-beebe-1.02/special.bib b/dviware/driv-standard/papers/special-beebe-1.02/special.bib
new file mode 100644
index 0000000000..b7c67f807f
--- /dev/null
+++ b/dviware/driv-standard/papers/special-beebe-1.02/special.bib
@@ -0,0 +1,344 @@
+%% /u/sy/beebe/tex/talks/special/special.bib, Mon Nov 12 08:49:31 1990
+%% Edit by Nelson H.F. Beebe <beebe at plot79.math.utah.edu>
+
+%% texfile{
+%% author = "Nelson H. F. Beebe",
+%% version = "1.01",
+%% date = "12 Nov 1990",
+%% filename = "special.bib",
+%% address = "Center for Scientific Computing
+%% Department of Mathematics
+%% South Physics Building
+%% University of Utah
+%% Salt Lake City, UT 84112
+%% USA
+%% Tel: (801) 581-5254",
+%% checksum = "345 1159 10160",
+%% email = "beebe at science.utah.edu (Internet)",
+%% codetable = "ISO/ASCII",
+%% keywords = "",
+%% supported = "yes",
+%% docstring = "This is the bibliography file for special.ltx.
+%% The checksum field above contains the
+%% standard UNIX wc (word count) utility
+%% output of lines, words, and characters;
+%% eventually, a better checksum scheme should
+%% be developed."
+%% }
+
+@preamble{"\input{bibnames.sty}"
+ # "\input{pathname}"
+ # "\hyphenation{Ker-n-i-ghan Port-able Post-Script Pren-tice Richt-er
+ Spring-er}"
+}
+
+@string{Adobe:adr = "1585 Charleston Road, P.~O. Box 7900, Mountain
+ View, CA 94039-7900, USA, Tel: (415) 961-4400"}
+
+@string{Adobe:org = "Adobe Systems Incorporated"}
+
+@string{AMS = "American Mathematical Society"}
+
+@string{ANSI = "American National Standards Institute"}
+
+@string{ANSI:adr = "1430 Broadway, New York, N. Y., 10018"}
+
+@string{AP = "Academic Press"}
+
+@string{AH = "Adam Hilger Ltd., Bristol"}
+
+@string{AW = "Ad\-di\-son-Wes\-ley"}
+
+@string{BH = "Birkh{\"{a}}user"}
+
+@string{BN = "Barnes and Noble"}
+
+@string{BSTJ = "The Bell System Technical Journal"}
+
+@string{CACM = "Communications of the Association for Computing Machinery"}
+
+@string{COL = "Collier Books, Macmillan Publishing Company"}
+
+@string{CJ = "The Computer Journal"}
+
+@string{COMPLANG = "Computer Language"}
+
+@string{CP = "Clarendon Press, Oxford"}
+
+@string{CSP = "Computer Science Press"}
+
+@string{CUP = "Cambridge University Press"}
+
+@string{CGIP = "Computer Graphics and Image Processing"}
+
+@string{DDJ = "Dr. Dobb's Journal"}
+
+@string{DOV = "Dover"}
+
+@string{DP = "Digital Press"}
+
+@string{EH = "Ellis Horwood"}
+
+@string{ELS = "Elsevier"}
+
+@string{FSF = "{F}ree {S}oftware {F}oundation"}
+
+@string{HBJ = "Harcourt Brace Jovanovich"}
+
+@string{HRW = "Holt, Reinhart, and Winston"}
+
+@string{HWS = "Howard W. Sams"}
+
+@string{IC = "Intel Corporation"}
+
+@string{ISO = "International Organization for Standardization"}
+
+@string{IEEE = "IEEE Computer Society"}
+
+@string{JH = "The Johns Hopkins University Press"}
+
+@string{JW = "John Wiley"}
+
+@string{MAC = "Macmillan Publishing Company"}
+
+@string{MC = "Motorola Corporation"}
+
+@string{MH = "Mc\-Graw-Hill"}
+
+@string{MIT = "MIT Press"}
+
+@string{MK = "Morgan Kaufmann Publishers"}
+
+@string{NH = "North-Hol\-land"}
+
+@string{OMH = "Osborne\slash Mc\-Graw-Hill"}
+
+@string{OR = "O'Reilly \& {Associates, Inc.}"}
+
+@string{OR:adr = "981 Chestnut Street, Newton, MA 02164"}
+
+@string{OX = "Oxford University Press"}
+
+@string{PH = "Pren\-tice-Hall"}
+
+@string{PHI = "Pren\-tice-Hall International"}
+
+@string{PUP = "Princeton University Press"}
+
+@string{REK = "Robert E. Krieger Publishing Company"}
+
+@string{SF = "Scott, Foresman and Company"}
+
+@string{SIAM = "Society for Industrial and Applied Mathematics, Philadelphia"}
+
+@string{SIAM-J-COMP = "SIAM Journal of Computing"}
+
+@string{SIGPLAN = "ACM SIG\-PLAN Notices"}
+
+@string{SIGGRAPH = "ACM SIG\-GRAPH\emdash Com\-puter Graphics"}
+
+@string{SPE = "Soft\-ware\emdash Prac\-tice and Experience"}
+
+@string{SV = "Spring\-er-Ver\-lag"}
+
+@string{TEXHAX = "{\TeX{}\-hax}"}
+
+@string{TOGS = "ACM Transactions on Graphics"}
+
+@string{TUGboat = "{\TUB{}}"}
+
+@string{USGPO = "United States Government Printing Office"}
+
+@string{VNR = "Van Nostrand Reinhold"}
+
+@string{W = "Wiley"}
+
+@string{WAB = "W. A. {Benjamin, Inc.}"}
+
+@string{WI = "Wiley-In\-ter\-sci\-ence"}
+
+@string{WRC = "W. and R. Chambers Ltd."}
+
+@Misc{Abraxas:pcyacc,
+ author = "{Abraxas Software, Inc.}",
+ title = "{PCYACC} 2.0",
+ note = "7033 SW Macadam Ave., Portland, OR 97219.",
+ year = "1987",
+}
+
+@TechReport{Adobe:epsf-spec,
+ author = "PostScript Developer Support Group",
+ title = "{Encapsulated PostScript Files} Specification Version 2.0",
+ institution = Adobe:org,
+ year = "1989",
+ number = "PN LPS5002",
+ address = Adobe:adr,
+ month = jun # " 5",
+ note = "Available electronically from {\tt
+ ps-file-server@adobe.com} in response to an e-mail
+ request {\tt send Documents EPSF.ps.Zba}. The
+ request {\tt send Index} will return a complete
+ index for the server.",
+}
+
+@TechReport{Adobe:docstruct-spec,
+ author = "PostScript Developer Support Group",
+ title = "{Document Structuring Conventions} Specification,
+ Version 2.1",
+ institution = Adobe:org,
+ year = "1989",
+ number = "PN LPS5001",
+ address = Adobe:adr,
+ month = jan # " 16",
+ note = "Available electronically from {\tt
+ ps-file-server@adobe.com} in response to an e-mail
+ request {\tt send Documents struct.ps.Zba}. The
+ request {\tt send Index} will return a complete
+ index for the server.",
+}
+
+@Book{Aho:green-dragon,
+ author = "Aho, Alfred V. and Ullman, Jeffrey D.",
+ title = "Principles of Compiler Design",
+ publisher = AW,
+ year = "1977",
+ note = "See also the much expanded subsequent book
+ \cite{Aho:red-dragon}.",
+}
+
+@Book{Aho:red-dragon,
+ author = "Aho, Alfred V. and Sethi, Ravi and Ullman, Jeffrey D.",
+ title = "Compilers\emdash Prin\-ci\-ples, Techniques, and Tools",
+ publisher = AW,
+ year = "1986",
+}
+
+@Manual{ANSI:c89,
+ title = "American National Standard Programming Language C,
+ ANSI X3.159-1989",
+ organization = ANSI,
+ address = ANSI:adr,
+ year = "1989",
+ month = dec # " 14",
+}
+
+@Article{Beebe:TB8-1-41,
+ author = "Nelson H. F. Beebe",
+ title = "{{Public domain \TeX\ DVI driver family}}",
+ journal = TUGboat,
+ year = "1987",
+ volume = "8",
+ number = "1",
+ pages = "41",
+ month = Apr,
+}
+
+@TechReport{Donnelly:bison,
+ author = "Charles Donnelly and Richard M. Stallman",
+ title = "BISON\emdash The YACC-com\-pat\-i\-ble Parser Generator",
+ institution = FSF,
+ address = "675 Mass Ave, Cambridge, MA 02139, Tel: (617) 876-3296",
+ year = "1988",
+ note = "Bison was largely written by Robert Corbett, and made
+ yacc-com\-pat\-i\-ble by Richard Stallman. Electronic
+ mail: |rms@prep.ai.mit.edu|. Software also available
+ via ANONYMOUS FTP to |prep.ai.mit.edu|. See also
+ \cite{Paxson:flex}.",
+}
+
+@InProceedings{Gray:lex,
+ author = "Robert W. Gray",
+ title = "$\gamma$-{GLA}\emdash A Generator for Lexical Analyzers
+ that Programmers Can Use",
+ booktitle = "Summer USENIX '88",
+ year = "1988",
+ pages = "147--160",
+ month = jun # " 20--24",
+}
+
+@Book{Harbison:carm-2,
+ author = "Samuel P. Harbison and Guy L. {Steele Jr.}",
+ title = "C\emdash A Reference Manual",
+ publisher = PH,
+ year = 1987,
+ edition = "Second",
+}
+
+@Book{Holub:compiler-design,
+ author = "Allen I. Holub",
+ title = "Compiler Design in {C}",
+ publisher = PH,
+ year = "1990",
+ note = PH # " Software Series, Editor: Brian W. Kernighan.",
+ ISBN = "0-13-155045-4",
+}
+
+@InCollection{Johnson:yacc,
+ author = "Steven C. Johnson",
+ title = "Yacc: Yet Another Compiler Compiler",
+ booktitle = "{UNIX} Programmer's Manual",
+ publisher = HRW,
+ year = "1979",
+ volume = "2",
+ pages = "353--387",
+ note = "AT\&T Bell Laboratories Technical Report July 31, 1978.",
+}
+
+@Book{Knuth:texbook,
+ author = "Donald E. Knuth",
+ title = "The {\TeX}book",
+ publisher = AW,
+ year = "1984",
+ ISBN = "0-201-13448-9",
+}
+
+@Article{Knuth:TB11-4-???-???,
+ author = "Donald E. Knuth",
+ title = "The Future of {\TeX} and {\MF}",
+ journal = TUGboat,
+ year = "1990",
+ volume = "11",
+ number = "4",
+ pages = "???--???",
+ month = dec,
+}
+
+@InCollection{Lesk:lex,
+ author = "Michael E. Lesk and Eric Schmidt",
+ title = "Lex\emdash A Lexical Analyzer Generator",
+ booktitle = "{UNIX} Programmer's Manual",
+ publisher = HRW,
+ year = "1979",
+ volume = "2",
+ pages = "388--400",
+ note = "AT\&T Bell Laboratories Technical Report in 1975.",
+}
+
+@Misc{MKS:yacc,
+ author = "{Mortice Kern Systems, Inc.}",
+ title = "{MKS LEX \& YACC}",
+ year = "1987",
+ note = "35 King Street North, Waterloo, Ontario, Canada, Tel:
+ (519) 884-2251.",
+}
+
+@Misc{Paxson:flex,
+ author = "Vern Paxson",
+ title = "flex\emdash fast lexical analyzer generator",
+ howpublished = FSF # ", 675 Mass Ave, Cambridge, MA 02139,
+ Tel: (617) 876-3296",
+ year = "1988",
+ note = "Electronic mail: |vern@lbl-csam.arpa| or
+ |vern@lbl-rtsg.arpa|).
+ Software also available via ANONYMOUS FTP to
+ |lbl-csam.arpa|, |lbl-rtsg.arpa|, or
+ |prep.ai.mit.edu|. See also \cite{Donnelly:bison}.",
+}
+
+@Book{Schreiner:compiler,
+ author = "Axel T. Schreiner and H. George {Friedman, Jr.}",
+ title = "Introduction to Compiler Construction Under {UNIX}",
+ publisher = PH,
+ year = "1985",
+}
+
diff --git a/dviware/driv-standard/papers/special-beebe-1.02/special.sty b/dviware/driv-standard/papers/special-beebe-1.02/special.sty
new file mode 100644
index 0000000000..05456209b0
--- /dev/null
+++ b/dviware/driv-standard/papers/special-beebe-1.02/special.sty
@@ -0,0 +1,65 @@
+%/u/sy/beebe/tex/talks/special/special.sty, Sun Nov 11 12:31:33 1990
+%Edit by Nelson H.F. Beebe <beebe@magna.math.utah.edu>
+
+%% @texfile{
+%% author = "Nelson H. F. Beebe",
+%% version = "1.00",
+%% date = "12 Nov 1990",
+%% filename = "special.sty",
+%% address = "Center for Scientific Computing
+%% Department of Mathematics
+%% South Physics Building
+%% University of Utah
+%% Salt Lake City, UT 84112
+%% USA
+%% Tel: (801) 581-5254",
+%% checksum = "65 302 2684",
+%% email = "beebe@science.utah.edu (Internet)",
+%% codetable = "ISO/ASCII",
+%% keywords = "",
+%% supported = "yes",
+%% docstring = "This LaTeX style file is for special.ltx.
+%%
+%% The checksum field above contains the
+%% standard UNIX wc (word count) utility
+%% output of lines, words, and characters;
+%% eventually, a better checksum scheme should
+%% be developed."
+%% }
+
+\newcommand{\makeunderscorenormal}{\catcode`\_=8}
+\newcommand{\makeunderscoreletter}{\catcode`\_=11}
+\newcommand{\CODE}[1]{{\tt{}#1}}
+\newcommand{\CTL}[1]{{\tt{}Ctl-#1}}
+\newcommand{\DVI}{{\tt dvi}}
+\newcommand{\FN}[1]{{\tt #1}}
+\newcommand{\OPTION}[1]{{\tt{}-#1}} % for option switches
+\newcommand{\POSTSCRIPT}{Post\-Script}
+
+\makeunderscoreletter %need them as chars here
+
+% The standard LaTeX definition of \sloppy sets \tolerance to 10000.
+% This gives spacing that is too stretchable, with the result that
+% wide white spaces appear in order to give right- justified output.
+% We reset the tolerance to a more reasonable value. We also allow a
+% little \emergencystretch (a TeX 3.0 feature) to allow individual
+% lines to be slightly longer; if that name is unknown, the code
+% avoids its use, so as to work with earlier versions of TeX.
+
+% TeXbook, p. 308:
+\def\ifundefined#1{\expandafter\ifx\csname#1\endcsname\relax}
+
+% Original version from latex.tex:
+% \def\sloppy{\tolerance 10000 \hfuzz .5\p@ \vfuzz .5\p@}
+\renewcommand{\sloppy}{
+ % \emergencystretch is a new feature of TeX 3.0; use it only if known
+ \ifundefined{emergencystretch}
+ \relax
+ \else
+ \emergencystretch=3pt
+ \fi
+ \tolerance=4000 % graph.ltx needs no more looseness than this
+ \hbadness=10000 % no underfull messages -- we expect them
+}
+
+\overfullrule=3pt % to catch problems in the output.
diff --git a/dviware/driv-standard/papers/special-beebe-1.02/special.tex b/dviware/driv-standard/papers/special-beebe-1.02/special.tex
new file mode 100644
index 0000000000..653b2f7281
--- /dev/null
+++ b/dviware/driv-standard/papers/special-beebe-1.02/special.tex
@@ -0,0 +1,1491 @@
+% -*-latex-*-
+% Document name: /u/sy/beebe/tex/talks/special/special.ltx
+% Creator: Nelson H.F. Beebe [beebe@magna.math.utah.edu]
+% Creation Date: Sun Nov 11 07:06:19 1990
+% 1.02 -- [04-Jun-1991] fix two small typos
+% 1.01 -- [12-Nov-1990] last major changes in original version
+
+%% @texfile{
+%% author = "Nelson H. F. Beebe",
+%% version = "1.02",
+%% date = "04 June 1991",
+%% filename = "special.ltx",
+%% address = "Center for Scientific Computing
+%% Department of Mathematics
+%% South Physics Building
+%% University of Utah
+%% Salt Lake City, UT 84112
+%% USA
+%% Tel: (801) 581-5254",
+%% checksum = "1491 6916 48967",
+%% email = "beebe@math.utah.edu (Internet)",
+%% codetable = "ISO/ASCII",
+%% keywords = "",
+%% supported = "yes",
+%% docstring = "This document contains a proposal for the
+%% handling of \\special and paper
+%% specifications by DVI drivers.
+%%
+%% The checksum field above contains the
+%% standard UNIX wc (word count) utility
+%% output of lines, words, and characters;
+%% eventually, a better checksum scheme should
+%% be developed."
+%% }
+
+\documentstyle[special,ltugboat]{article}
+
+\title{A Proposal for \protect\TeX{}
+ {\tt\char92special} Commands and
+ \protect\DVI{} Driver Paper
+ Specification}
+
+\author{Nelson H. F. Beebe}
+
+\address{Center for Scientific Computing\\
+ Department of Mathematics\\
+ 220 South Physics Building\\
+ University of Utah\\
+ Salt Lake City, UT 84112\\
+ USA\\
+ Tel: (801) 581-5254\\
+ FAX: (801) 581-4148}
+
+\netaddress[\network{Internet}]{Beebe@math.utah.edu}
+
+\begin{document}
+
+\maketitle
+
+\bibliographystyle{plain}
+
+\section{Introduction}
+
+\TeX{} is now a {\em de facto\/} standard; its
+source code development is now frozen, with the
+version number converging to $\pi$ as increasingly
+rare bugs are fixed \cite{Knuth:TB11-4-???-???}.
+\TeX{} has been implemented on nearly every
+computer architecture commercially available
+today, from personal computers to supercomputers,
+on a wide variety of operating systems.
+
+\TeX{}'s principal output is a {\em
+device-independent file}, the \DVI{} file, which
+contains a compact description of where to set
+characters on the page. It does not contain any
+descriptions of the characters themselves, only a
+reference to the fonts in which they are found.
+A few other programs besides \TeX{} also produce
+\DVI{} files.
+
+It is the job of separate programs, known as
+\DVI{} drivers, to translate this description into
+a form suitable for some output device, which
+might be a printer, a display screen, a
+phototypesetter, or even another \DVI{} file.
+
+Because a separate \DVI{} driver is needed for
+each output device, and each operating system,
+there is the potential for an explosion in the
+number of auxiliary programs that may be required
+to obtain usable output from \TeX{}, and
+regrettably, that seems to have happened.
+
+\section{The \protect\DVI{} driver problem}
+
+I have previously espoused the view
+\cite{Beebe:TB8-1-41} that prevention of \DVI{}
+driver program proliferation is properly addressed
+by writing a {\em family} of drivers that supports
+a wide variety of output devices, sharing common
+source code as much as possible. The code must
+be highly portable, so as to work on a wide
+variety of operating systems. My implementation
+of such a family of drivers has been
+well-received, and many thousands of copies of the
+programs are in use around the world.
+
+The last public release, version 2.10 of October
+1988, consists of about 30~000 lines of code for
+19 drivers, together with about 8400 lines of
+documentation, corresponding to about 150 typeset
+pages. Five major operating environments (Atari,
+DEC TOPS-20, DEC \VAX{} VMS, IBM PC, and \UNIX{})
+%
+\typeout{EDITOR: small caps on UNIX looks odd}
+%
+are supported, with several different compilers.
+Ports have been carried out to other operating
+systems as well, but the changes have not been
+made generally available.
+
+The widespread use of those programs has confirmed
+my thesis, but has also demonstrated that they
+have some deficiencies. This is to be expected in
+any software product, whether public or
+commercial. Even \TeX{} has evolved from its
+original design.
+
+Consequently, in the fall of 1988 I set out to
+redesign the driver family to remedy all of the
+deficiencies, to further enhance portability to
+new operating systems and new compilers, to make
+it easier to modify existing driver code to
+support other output devices, and to extend and
+enhance the documentation. The development
+version is known as 3.0.
+
+This work is, alas, far from complete, and I
+sometimes wonder whether Don Knuth will finish
+Volume 4 of the {\em Art of Computer Programming}
+before I finish the new driver family. However,
+considerable progress has been made. The number
+of output devices and operating environments
+supported has more than doubled. The source code
+is now over 55~000 lines; for comparison, \TeX{}
+and \MF{} are each about 20~000 lines when
+prettyprinted. There are 23~500 lines of
+documentation, corresponding to about
+% dvidrive 256
+% dviman 53
+% dviman2 37
+% dvistatu 20
+% dvi.ps 33
+% Total = 399
+400 typeset pages. The `manual pages' are written
+in a subset of \LaTeX{}, then converted
+automatically to \UNIX{} \verb|troff| format,
+\VAX{} VMS \verb|help| file format, Emacs
+\TeX{}info format, and a simple ASCII text file
+format.
+
+\section{Standardization of \protect\DVI{}
+drivers}
+
+As should be expected, the proliferation of \DVI{}
+driver code written by many authors has led to
+considerable variation in driver interfaces and
+operation. While human interfaces unavoidably
+depend somewhat on the operating environment, one
+can demand that the same {\em capabilities\/}
+(e.g.\ page selection and order, paper sizes, page
+origin offset, file paths, startup-file support,
+\ldots{}) be available in all drivers.
+
+Operational differences are less excusable. For
+example, most programs, including \TeX{}, have
+fixed limits arising from compile-time choices of
+internal storage sizes. User annoyance and
+frustration results when those limits are reached
+prematurely. Even on the same output device,
+slight variations in page positioning, and
+placement of rules and characters will be found in
+different drivers. Worse, some drivers may refuse
+to print certain \DVI{} files, because internal
+limits are reached, or a particular font cannot be
+found.
+
+To address these problems, a committee of the
+\TeX{} Users Group was established to develop a
+standard for \DVI{} drivers. Completion of a
+level-0 draft is imminent.
+
+This draft is intended to define minimal standards
+that all \DVI{} drivers should adhere to. It does
+not address some of the thornier issues,
+particularly the \TeX{} \verb|\special| command,
+which will be covered in a higher-level draft
+standard yet to be prepared.
+
+\section{The \protect\TeX{} {\tt\char92special}
+ command}
+
+When \TeX{} was first defined in 1977--78, its
+author realized that there would be a need for
+extensibility. He chose to provide this in a very
+simple form---an arbitrary string provided as the
+argument to the \verb|\special| command is
+macro-expanded, then passed verbatim to the \DVI{}
+file without further interpretation.
+
+To guide \TeX{} users and authors of \DVI{}
+drivers, he offered this advice
+\cite[pp.~228--229]{Knuth:texbook}:
+%
+ \begin{quote}
+The $\langle$token list$\rangle$ in a
+\verb|\special| command should consist of a
+keyword followed if necessary by a space and
+appropriate arguments. For example,
+%
+\begin{verbatim}
+\special{halftone pic1}
+\end{verbatim}
+%
+might mean that a picture on the file \verb|pic1|
+should be inserted on the current page, with its
+reference point at the current position.
+
+$\vdots$
+
+\noindent
+Software programs that convert \verb|dvi| files to
+printed or display output should be able to fail
+gracefully when they don't recognize your special
+keywords.
+
+$\vdots$
+
+\noindent
+However, the author anticipates that certain
+standards for common graphics operations will
+emerge in the \TeX{} user community, after careful
+experiments have been made by groups of people;
+then there will be a chance for some uniformity in
+the use of \verb|\special| extensions.
+ \end{quote}
+
+As Knuth noted, the most common use of
+\verb|\special| is to inform the \DVI{} driver
+that a graphics file is to be inserted in the
+output. Many other possibilities exist, including
+paper specification, operator messages, grey
+shading, change bars, color selection, page
+overlays, and output device control.
+
+With very few exceptions, existing drivers,
+including my own 2.10 version, have adopted {\em
+ad hoc\/} syntax for the \verb|\special| string.
+The result is that the \DVI{} file is no longer
+device-independent; it depends both on the output
+device, and {\em on the particular driver
+that is expected to process it}.
+
+\section{Improving the handling of
+ {\tt\char92special} commands}
+
+In the 3.0 \DVI{} driver development, I had to
+solve the \verb|\special| problem. This section
+will describe how, and why, I did so.
+
+While the complete source code for the 3.0 drivers
+will not be released for some time, the part
+described in this article for \verb|\special|
+strings and paper specifications is complete, and
+{\bf I am making it available immediately, and
+without any restrictions whatsoever, to authors of
+\DVI{} drivers for incorporation in their
+programs.}
+
+The source code is written in ANSI C
+\cite{ANSI:c89}. C is already used for many
+\DVI{} driver programs; for drivers that are not
+written in C, it should be considerably easier to
+start with this code and reprogram it in some
+other modern language, such as Pascal or Modula-2,
+than to redevelop equivalent code from scratch.
+
+The previous section observed that most existing
+drivers have chosen an arbitrary syntax for the
+\verb|\special| strings they support.
+This is undesirable, for at least these reasons:
+%
+ \begin{itemize}
+ \item
+ The chosen syntax is mostly unique to a
+ particular driver, and therefore
+ seriously compromises document
+ portability.
+ \item
+ The syntax is not obviously extensible.
+ \item
+ The syntax cannot always be
+ unambiguously parsed.
+ \item
+ The output device, or driver, to which
+ the \verb|\special| applies is not
+ determinable.
+ \item
+ The capabilities are weak, and fail to
+ address many of the potential uses of
+ the \verb|\special| command.
+ \end{itemize}
+
+The syntax that I have developed completely
+resolves these objections. It has the following
+features:
+%
+ \begin{itemize}
+ \item
+ The \verb|\special| command string is
+ defined to contain a program written in
+ a small language that consists of
+ sequences of assignment statements,
+ possibly with embedded comments.
+ \item
+ The \verb|\special| language is {\em
+ rigorously defined\/} by a programming
+ language grammar, based on the C
+ language grammar
+ \cite{ANSI:c89,Harbison:carm-2}.
+ Correct parsers for the language can be
+ developed using any of several standard
+ methods that are well-known in computer
+ science
+ \cite{Aho:red-dragon,Aho:green-dragon,%
+ Holub:compiler-design,%
+ Schreiner:compiler}
+ and the \UNIX{} world
+ \cite{Johnson:yacc,Lesk:lex}.
+ Implementations of some of these are
+ available from several sources, and for
+ several operating systems
+ \cite{Abraxas:pcyacc,Donnelly:bison,%
+ Gray:lex,Holub:compiler-design,%
+ MKS:yacc,Paxson:flex}.
+ \item
+ The language is {\em extensible}. An
+ assignment statement consists of a
+ keyword\slash value pair. Several
+ keywords are already defined, and {\em
+ new ones can be added without
+ invalidating existing uses of the
+ language}.
+ \item
+ Keywords are typed, and constant values
+ assigned to them must be of the same
+ type. The supported types are scalar
+ strings, numbers, and dimensions. The
+ latter include all of \TeX{}'s standard
+ dimensional units.
+ \item
+ There is {\em no limit\/} (other than
+ host memory) on the length of a constant
+ string.
+ \item
+ Value string concatenation is supported
+ in the style of ANSI C \cite{ANSI:c89},
+ avoiding the often severe line length
+ limitations of text editors, operating
+ systems, and file systems.
+ \item
+ Provision is made for encoding {\em all}
+ characters in the host character set, so
+ that, e.g.\ binary printer control
+ sequences can be incorporated as {\em
+ printable}, and {\em portable}, text in
+ \TeX{} documents.
+ \item
+ A particular keyword, \verb|language|,
+ is provided to permit the user to
+ specify the output device language, or
+ the \DVI{} driver, to which the
+ \verb|\special| command is directed.
+ \item
+ The language is general enough that it
+ can be used for other purposes. In my
+ 3.0 \DVI{} driver software, the complex
+ issue of paper specification is handled
+ by the same language, and importantly,
+ by the {\em same parser\/} that is used
+ for \verb|\special| strings.
+ \end{itemize}
+%
+In the actual implementation of the parser, I
+chose {\em not\/} to use one of the above-cited
+parser generators. There are two important
+reasons for this.
+
+ \begin{itemize}
+ \item
+ Parser generators convert a grammar file
+ to an output program that is impossible
+ to modify by hand. Portability and
+ extensions of the drivers would be
+ compromised if part of their source code
+ could only be generated on certain
+ systems, or with proprietary software.
+ \item
+ Parser generators encode the language
+ keywords into the parser code, usually
+ in incomprehensible forms; examine the
+ parsing tables in a
+ \verb|yacc|-generated parser
+ \cite{Johnson:yacc} to see why.
+ \end{itemize}
+
+By suitable abstractions, it has proven possible
+to create a recursive-descent parser
+\cite{Aho:red-dragon,Aho:green-dragon} for the
+language in which {\em the keywords and value
+storage locations are provided in a table passed
+to the parser}. The parser code is therefore
+completely portable, and {\em independent\/} of
+the keywords in the language it parses. The same
+code is used for both the \verb|\special| command
+strings, and for paper specification.
+
+\section{A proposed syntax for the
+ {\tt\char92special} command}
+
+The preceding section has described the motivation
+for a new approach to the definition of a
+\verb|\special| language. What does the language
+look like? Some examples will give the general
+flavor before we describe the details of the
+grammar. Here are some fragments of \TeX{} input
+with \verb|\special| commands intended for a
+\DVI{} driver that produces \POSTSCRIPT{}; each of
+these works with \verb|dvialw| in the version 3.0
+development.
+%
+\begin{verbatim}
+% Display a picture with the
+% upper-left corner at the current
+% point
+\special{language "PostScript",
+ include "pict.eps"}
+
+% Display a picture at its original
+% absolute page position
+\special{language "PostScript",
+ overlay "pict.eps"}
+
+% Use literal PostScript to draw a
+% 1in box with lower-left corner at
+% TeX's current point
+\special{language "PostScript",
+ literal
+ "newpath
+ % move origin from upper-left
+ % to lower-left
+ 0 -72 translate
+ 0 0 moveto
+ 0 72 rlineto
+ 72 0 rlineto
+ 0 -72 rlineto
+ -72 0 rlineto
+ closepath
+ 4 setlinewidth
+ stroke
+ showpage"}
+
+% Display a figure at half size
+\special{language "PostScript",
+ literal "0.5 0.5 scale",
+ include "pict.eps"}
+
+% Display the figure in landscape
+% mode by rotating the coordinates
+% about the center of the bounding
+% box
+\special{language "PostScript",
+ literal
+ "BoxWidth 2 div
+ BoxHeight 2 div translate
+ 90 rotate
+ BoxWidth -2 div
+ BoxHeight -2 div translate",
+ include "pict.eps"}
+\end{verbatim}
+
+Naturally, the details of a \verb|\special|
+command invocation should be hidden away in
+suitable macros that are easy to use. Here are
+some examples from a recent document illustrating
+the incorporation by \verb|dvialw| of
+\POSTSCRIPT{} figures from a variety of sources:
+%
+\begin{verbatim}
+\newcommand{\FIGPLOT}[4]{%
+ % Arg 1 = EPS file to plot
+ % Arg 2 = figure caption
+ % Arg 3 = width in inches
+ % Arg 4 = height in inches
+ \begin{figure}[htb]
+ \Figrule\smallskip
+ \begin{center}
+ \setlength{\unitlength}{1.0in}
+ \begin{picture}(#3,#4)(0,0)%
+ \put(0,0){\special{
+ language "PostScript",
+ position "bottom left",
+ literal
+ "/SX {#3 72 mul BoxWidth div} def
+ /SY {#4 72 mul BoxHeight div} def
+ 1 SX sub BoxLLX mul
+ 1 SY sub BoxLLY
+ mul translate
+ SX SY scale",
+ include "#1"}}%
+ \put(0,0){\circle*{0.5}}%
+ \put(0,0){\dashbox{0.1}%
+ (#3,#4)[t]{}}%
+ \end{picture}%
+ \end{center}
+ \caption{\tolerance=6000
+ \emergencystretch=3pt
+ #2
+ File: {\tt #1}.
+ Picture size: #3in wide by
+ #4in high.}
+ \label{#1}
+ \smallskip\Figrule
+ \end{figure}
+}
+
+\newcommand{\Figrule}{\hrule
+ width \linewidth
+ height 2pt
+ depth 2pt \relax}
+
+\FIGPLOT{roseart.ps}{Adobe Illustrator
+ 1.0b2 rose art
+ (scaled 1:2)}
+ {3.4861}{4.625}
+
+\FIGPLOT{golfart.ps}{Test of golfart
+ scaling
+ (scaled $1:2$).}
+ {3.95833}{4.82639}
+
+\FIGPLOT{tiger.ps}{A bitmapped image.}
+ {4.5}{3.0107}
+
+\end{verbatim}
+
+The \verb|literal| string makes use of
+\POSTSCRIPT{} macros output by \verb|dvialw| to
+define the position (\verb|BoxLLX|, \verb|BoxLLY|,
+\verb|BoxURX|, and \verb|BoxURY|) and size
+(\verb|BoxHeight| and \verb|BoxWidth|) of the
+bounding box. The current page position is also
+available as (\verb|CurrentX|, \verb|CurrentY|),
+and the paper size as \verb|PaperHeight| and
+\verb|PaperWidth|. All of these are in standard
+\POSTSCRIPT{} units of big points. These
+quantities are needed to support things like
+figure transformations, landscape mode, change
+bars, and grey shading.
+
+If a \verb|\special| contains both a
+\verb|literal| and an \verb|include| or
+\verb|overlay| statement, then the literal string
+is output {\em before} the inserted file. Should
+the reverse order be required, then the literal
+string must be specified in a separate following
+\verb|\special|.
+
+Finally, here are some examples of the same
+language, now used to parse paper specifications.
+The first is a command-line, or startup-file,
+switch which provides a paper program as the
+switch value:
+%
+\begin{verbatim}
+-paper:{paper="letter";width=8.5in;
+ height=11in;dev_init="...";}
+\end{verbatim}
+%
+In a startup file, such options can be written
+more clearly:
+%
+\begin{verbatim}
+-paper:
+{
+ % standard US paper size
+ paper = "letter";
+ width = 8.5in;
+ height = 11in;
+
+ % printer origin is off by 0.05in
+ x_origin = 1.05in;
+ y_origin = 1in;
+
+ % printer wraps coordinates, so
+ % we need clipping turned on
+ x_clip = 1;
+ y_clip = 1;
+
+ % not all of page is imageable
+ x_left = 0.3in;
+ x_right = 0.3in;
+ y_top = 0.5in;
+ y_bottom = 0.5in;
+
+ % print pages from last to first
+ output_order = -1;
+
+ % adjacent strings are concatenated
+ dev_init = "...."
+ "...."
+ "....";
+ % final formfeed and printer reset
+ dev_term = "\f\033E";
+ page_init = "....";
+ page_term = "....";
+}
+
+-paper=
+{
+ paper = "ALW-note";
+ use = "letter";
+ x_left = 0.41in;
+ x_right = 0.41in;
+ y_top = 0.42in;
+ y_bottom = 0.42in;
+}
+\end{verbatim}
+
+The last example illustrates a feature of the
+paper specification language; the \verb|use|
+keyword references a paper type defined elsewhere
+whose specifications are copied into the internal
+data structures for the new type before the new
+values are installed. This makes it easy to
+prepare modifications of base forms. For example,
+most laser printers use the same size paper, but
+differ in the imageable area and output stacking
+order. The example above defines a paper
+type known to the Apple LaserWriter in terms of a
+standard paper type.
+
+Comments are from percent to end-of-line (like
+\TeX{}), and letter case is {\em not significant}
+in variable names. Whitespace is ignored, so the
+specification can be formatted for readability, or
+for compactness.
+
+Dimensions can be given in any unit known to
+\TeX{} (bp cc cm dd in mm pc pt sp).
+
+The presence of a left brace following the paper
+switch signals that a forms definition follows;
+otherwise, the following token is a paper name.
+To facilitate collection of the complete
+specification at a higher level without having to
+parse it in detail when the switch and its value
+are collected, braces must be balanced; escape
+sequences and comments provide ways to ensure
+this.
+
+\section{The language grammar}
+
+The grammar for the language is based on the C
+programming language grammar given in Appendix B
+of \cite{Harbison:carm-2}, with changes affecting
+hexadecimal escape sequences in strings, and
+concatenation of adjacent strings, as specified in
+the ANSI C standard \cite{ANSI:c89}.
+
+Adjacent string concatenation is a convenient way
+of working around limitations on line length when
+long strings are needed, and adding support for it
+took only four lines of code. Hexadecimal escape
+sequences of arbitrary length permit transparent
+support for character sizes larger than 8 bits.
+Octal escape sequences remain limited to 3 digits
+for backward compatibility; hexadecimal escape
+sequences are new with ANSI C.
+
+In the following grammar, the suffix \verb|-opt|
+means that the item is optional. For brevity,
+numeric constants are not specified in grammatical
+form here. They are parsed by the ANSI C library
+routine, \verb|strtod()|, which expects numbers in
+the form (\verb|[ ]| marks optional fields,
+\verb={|}= marks alternatives):
+%
+\begin{verbatim}
+[whitespace][sign][digits][. digits]
+ [{e|E}[sign]digits]
+\end{verbatim}
+
+Except in quoted strings, tokens may not contain
+embedded blanks. Thus, 210mm is legal input, but
+210\verb*| |mm is not.
+
+Here is the grammar, in standard Backus-Naur form:
+%
+\begin{verbatim}
+program:
+ statement
+
+statement:
+ assignment-statement
+ compound-statement
+ null-statement
+
+assignment-statement:
+ name = constant
+ name : constant
+ name constant
+
+compound-statement:
+ { statement-list-opt }
+
+null-statement:
+ ,
+ ;
+
+statement-list:
+ statement
+ statement ; statement-list
+ statement , statement-list
+
+constant:
+ dimension-constant
+ float-constant
+ string-constant
+ name
+
+dimension-constant:
+ float-constant dimension-unit
+
+dimension-unit: one of
+ bp cc cm dd in mm pc pt sp
+
+string-constant:
+ simple-string-constant
+ string-constant simple-string-constant
+
+simple-string-constant:
+ " character-sequence-opt "
+ ' raw-character-sequence-opt '
+
+character-sequence:
+ character
+ character-sequence character
+
+raw-character-sequence:
+ raw-character
+ raw-character-sequence character
+
+character:
+ printing-character
+ escape-character
+
+raw-character:
+ printing-character
+ \'
+
+printing-character: one of
+ (note that " and \ are omitted,
+ and ' may be specified by \'
+ as well)
+ <space> ! # $ % & ( ) * + , -
+ . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ?
+ @ A B C D E F G H I J K L M
+ N O P Q R S T U V W X Y Z [ ] ^ _
+ ` a b c d e f g h i j k l m
+ n o p q r s t u v w x y z { | } ~
+
+escape-character:
+ \ escape-code
+
+escape-code:
+ character-escape-code
+ octal-escape-code
+ hexadecimal-escape-code
+
+character-escape-code:
+ a b f n r t v \ ' "
+
+octal-escape-code:
+ octal-digit
+ octal-digit octal-digit
+ octal-digit octal-digit octal-digit
+
+hexadecimal-escape-code:
+ x hexadecimal-digit
+ hexadecimal-escape-code hexadecimal-digit
+
+octal-digit: one of
+ 0 1 2 3 4 5 6 7
+
+hexadecimal-digit: one of
+ 0 1 2 3 4 5 6 7 8 9
+ A B C D E F
+ a b c d e f
+
+name:
+ letter
+ letter extended-letter-sequence
+
+extended-letter-sequence:
+ extended-letter
+ extended-letter-sequence extended-letter
+
+letter: one of alphabetic or
+ underscore characters
+ A B C D E F G H I J K L M
+ N O P Q R S T U V W X Y Z
+ a b c d e f g h i j k l m
+ n o p q r s t u v w x y z
+ _
+
+extended-letter:
+ 0 1 2 3 4 5 6 7 8 9
+ A B C D E F G H I J K L M
+ N O P Q R S T U V W X Y Z
+ a b c d e f g h i j k l m
+ n o p q r s t u v w x y z
+ - . _
+\end{verbatim}
+
+For readers unfamiliar with programming language
+grammars, a short explanation is in order. The
+beginning rules
+%
+\begin{verbatim}
+program:
+ statement
+
+statement:
+ assignment-statement
+ compound-statement
+ null-statement
+\end{verbatim}
+%
+say that a \verb|program| is a \verb|statement|,
+and that a \verb|statement| is either an {\tt
+assignment-statement}, or a {\tt
+compound-statement}, or a {\tt null-statement}.
+Further rules in turn define what each of these
+are. The last rule says that an {\tt
+extended-letter} is a digit, letter, hyphen, dot,
+or underscore.
+
+The characters permitted in {\tt extended-letter}
+are chosen
+%
+\begin{itemize}
+ \item
+ to avoid conflict with characters
+ otherwise significant in the grammar, and
+ \item
+ to cover the most common filename syntax,
+ so as to allow unquoted simple filenames
+ to be collected as single constant name
+ tokens for assignments.
+\end{itemize}
+
+This grammar supports two kinds of quoted strings.
+The {\em normal\/} kind is delimited by double
+quotes, and inside it are recognized all the
+escape sequences supported by the C language. The
+{\em raw\/} kind is delimited by single quotes;
+only escape-single-quote pairs are recognized
+inside it. This is more convenient when it is
+necessary to have strings with several
+backslashes, since it then avoids having to double
+all of them. Once normal and raw strings are
+parsed, they are stored identically.
+
+German \TeX{} styles often change the syntax of
+the quotation mark to add an umlaut accent to the
+following character; users of such styles can
+happily use the raw string form to avoid conflict.
+
+Backslashes in literal strings and filenames pose
+a small problem for the user, because \TeX{} will
+ordinarily try to interpret control sequences
+triggered by backslashes in the argument of the
+\verb|\special| command.
+
+For filenames, IBM PC DOS is the only operating
+system that normally would use backslashes, and
+then only as a directory separators. In most
+cases, you should omit directory paths anyway, and
+rely instead on the \CODE{DVIINPUTS} search path
+to let the drivers find the files at run time;
+doing so will enhance document portability. If
+you still wish to use a directory path in the
+\verb|\special| command, you can exploit an
+unadvertised feature of PC DOS; namely, system
+calls accept forward slashes as equivalent to
+backslashes, so you can use forward slashes
+instead. This is normally not possible with
+PC DOS commands that accept filenames on the
+command line, because their simplistic parsing
+confuses such names with option switches.
+
+Literal strings are therefore likely to be the
+only place where backslashes may be unavoidable.
+Although it would have been possible to choose
+another escape character than backslash for such
+strings, this would likely prove confusing to
+those users who are used to C and \UNIX{}, where
+the backslash escape character is firmly
+entrenched.
+
+Fortunately, the solution is not difficult,
+because \TeX{} does not have backslash hardcoded
+as a control sequence prefix; you can change it by
+altering \TeX{}'s catcodes. Thus instead of
+writing something like
+%
+\begin{verbatim}
+\special{literal = "\033[I"}
+\end{verbatim}
+%
+\noindent
+which would raise a \TeX{} {\em Undefined
+control sequence\/} error, you can instead write
+%
+\begin{verbatim}
+{
+ \catcode`\@=0
+ \catcode`\\=12
+ @special{literal = "\033[I"}
+}
+\end{verbatim}
+%
+\noindent
+This changes the \TeX{} control sequence prefix
+from backslash to at-sign, and gives backslash a
+meaning that will not cause problems. The
+surrounding braces ensure that the changes
+disappear when the braced group is exited. The
+catcodes are of course ugly magic numbers, so if
+you do this more than once, you should hide them
+in a macro with a more meaningful name, and use
+that macro in place of the first two lines
+in the group.
+
+The grammar supports statement separators (rather
+than terminators), and they may be either commas
+or semicolons. In a simple language, it is
+convenient to allow both kinds of separators.
+Since there is a null statement, the separator is
+optional after the last statement in a sequence.
+
+Drivers will supply an implicit brace pair
+surrounding the \verb|\special| string retrieved
+from the \DVI{} file, to ensure that
+multi-statement text looks like the compound
+statement required by the grammar.
+
+Finally, note that the assignment statement may
+use either the equals or colon operator, or the
+operator may be omitted altogether. This supports
+the common forms
+%
+\begin{verbatim}
+keyword = value
+keyword : value
+keyword value
+\end{verbatim}
+%
+Because the values have very limited syntactical
+possibilities, there is no ambiguity created by
+this.
+
+\section{The {\tt\char92special} language}
+
+The preceding section defined the grammar for the
+\verb|\special| language. We now need to define
+what keywords will be recognized. As emphasized
+above, the language is {\em extensible}, and the
+parser that I have implemented for it makes it
+very easy to add new keywords {\em without
+touching a single line of the parser code itself}.
+For example, only a short specification like
+%
+\begin{verbatim}
+{
+ {"include", 7},
+ (symbol_value*)&spec.include,
+ T_STRING
+},
+\end{verbatim}
+%
+needs to be added to a table to define a new
+keyword, together with a small amount of code to
+do something with the value returned by the parser
+for that keyword.
+
+The current set of keywords recognized is given in
+the following table:
+%
+\begin{center}
+ \begin{tabular}{llp{1.3in}}
+\hline
+Keyword & Value & Action \\
+\hline
+{\tt boundingbox} & string & Define the
+ coordinates of the
+ lower-left and
+ upper-right corners
+ of the box which
+ bounds the figure
+ input by an
+ \verb|include| or
+ \verb|overlay|
+ command.\\
+
+{\tt graphics} & string & Execute the generic
+ graphics primitives in
+ string (not yet
+ defined).\\
+{\tt include} & filename & Insert file contents
+ with relative page
+ positioning.\\
+{\tt language} & string & Name the output-device
+ language for which
+ this \verb|\special|
+ is intended.\\
+{\tt literal} & string & Insert literal output
+ device code.\\
+{\tt message} & string & Supply an operator
+ message to be sent to
+ the terminal and log
+ file.\\
+{\tt options} & string & Not yet defined.\\
+{\tt overlay} & filename & Insert file contents
+ with absolute page
+ positioning.\\
+{\tt position} & string & Specify the reference
+ point on an inserted
+ figure which is to be
+ mapped to the current
+ page position.\\
+\hline
+ \end{tabular}
+\end{center}
+%
+In a series of assignment statements, the order of
+the keywords is not significant, except that if
+duplicate keywords are specified, the value of the
+last one is used. It is not necessary to supply a
+final newline in the strings or files; one will be
+provided implicitly to ensure correct parsing.
+
+The \verb|graphics| keyword value is intended to
+be used to support a simple generic graphics
+language, yet to be defined. Such a language
+would make it possible to obtain simple line
+graphics on virtually any output device.
+
+The \verb|options| keyword value could be used to
+supply device-dependent information; no particular
+values have yet been defined in my 3.0 \DVI{}
+driver code.
+
+The \verb|message| string provides a means for
+operator communication; for example,
+%
+\begin{verbatim}
+message "Thesis bond paper for this job"
+\end{verbatim}
+%
+The message is sent verbatim to the terminal and
+the log file.
+
+The \CODE{position} keyword specifies a string
+that should contain two blank-separated words.
+The first should be one of \CODE{top},
+\CODE{middle}, or \CODE{bottom}, and the second
+should be one of \CODE{left}, \CODE{center}, or
+\CODE{right}. These words may be abbreviated to a
+single letter if desired. Together, they select
+on the bounding box one of nine points (four
+corners, four edge centers, and the box center)
+which is to be placed at the \TeX{} current point.
+If this keyword is not given, the default is
+%
+\begin{verbatim}
+position = "top left"
+\end{verbatim}
+%
+\noindent
+The point selected by this keyword (or by default)
+will be the {\em reference point\/} for the
+insertion of graphics files.
+
+The following remarks are particular to
+\POSTSCRIPT{} devices, but the possible
+generalizations to others should be evident.
+
+Literal \POSTSCRIPT{} code from a file or a
+literal string is expected to be well-behaved, and
+preferably, should conform to Adobe's Encapsulated
+\POSTSCRIPT{} File format version 2.0 or later
+\cite{Adobe:epsf-spec}, and to Adobe's
+\POSTSCRIPT{} Document Structuring Conventions,
+version 2.0 or later \cite{Adobe:docstruct-spec}.
+It may contain a \verb|showpage|, which is
+disabled temporarily by the \DVI{} driver during
+the execution of the \verb|\special| strings, but
+it should not contain any of these operators:
+%
+\begin{center}
+ \tt
+ \begin{tabular}{lll}
+ \hline
+ banddevice & initgraphics & setdevice \\
+ copypage & initmatrix & setmatrix \\
+ erasepage & note & setpageparams\\
+ exitserver & nulldevice & setsccbatch \\
+ framedevice & quit & setscreen \\
+ grestoreall & renderbands & settransfer \\
+ initclip \\
+ \hline
+ \end{tabular}
+\end{center}
+%
+If it does, erroneous output is virtually certain.
+While these commands could be disabled like
+\verb|showpage| is, Adobe's Encapsulated
+\POSTSCRIPT{} guidelines do not recommend doing
+so.
+
+The imported \POSTSCRIPT{} should write into its
+own dictionary if it needs to define objects.
+Because dictionary sizes must be specified when
+they are created, it is not possible to define a
+standard one in advance in the macros that mark
+the start and end of the imported \POSTSCRIPT{}
+(called \verb|SB| and \verb|SE| in \verb|dvialw|)
+to protect from corruption of the dictionary used
+by the \DVI{} driver.
+
+The \verb|language| keyword should specify
+\verb|"PS"| or \verb|"PostScript"|; letter case
+does not matter. If any other non-empty value is
+found, the \verb|\special| command is ignored by a
+\POSTSCRIPT{} driver, since it presumably applies
+to some other output device. However, if no
+\verb|language| keyword is given, the driver
+assumes it should process the rest of the
+\verb|\special| command.
+
+Files specified by \verb|include| and
+\verb|overlay| keywords are searched for in the
+\verb|DVIINPUTS| path.
+
+In the common {\tt include filename} case, the
+upper-left corner of the \POSTSCRIPT{} bounding
+box will be placed at the current point. The
+\POSTSCRIPT{} file must then contain (usually near
+the start) a comment of the form
+%
+\begin{verbatim}
+%%BoundingBox: llx lly urx ury
+\end{verbatim}
+%
+specifying the bounding box lower-left and
+upper-right coordinates in standard \POSTSCRIPT{}
+units (big points, 1bp = 1/72 inch).
+
+Alternatively, if the comment
+%
+\begin{verbatim}
+%%BoundingBox: (atend)
+\end{verbatim}
+%
+is found in the file, the last 4096 characters of
+the file will be searched to find a bounding box
+comment that specifies the coordinates of the two
+corners. The {\em last\/} such comment found is
+the one used; this requirement permits correct
+handling of inserted files that themselves contain
+nested \POSTSCRIPT{} files.
+
+In the {\tt overlay filename} case, the
+\POSTSCRIPT{} file to be included will be mapped
+onto the page at precisely the coordinates it
+specifies, where the page origin is in the
+lower-left corner, $x$ increasing to the right,
+and $y$ increasing upward. Any
+\verb|%%BoundingBox| specification is ignored,
+since it is not required for positioning. This
+option might be used to print an overlay page.
+For actions that are to be done on every page,
+such as printing a logo, or a string like {\tt
+Draft} or {\tt Company Confidential}, it is more
+efficient to redefine the \POSTSCRIPT{}
+\verb|showpage| command instead.
+
+If the \POSTSCRIPT{} file cannot be opened, or the
+\verb|\special| command string cannot be
+recognized, or for relative positioning, the
+bounding box cannot be determined, a warning
+message is issued and the \verb|\special| command
+is ignored.
+
+Numerous drivers already support \verb|\special|
+command strings of the form {\tt include
+filename}; this parser will recognize them.
+
+A key point here is the \verb|language| keyword.
+If it is {\em not\/} given, the \DVI{} driver must
+assume that the \verb|\special| command is
+intended for it, and attempt to process it. Thus,
+%
+\begin{verbatim}
+\special{include tiger.eps}
+\end{verbatim}
+%
+will be handled as before. However, when the
+\verb|language| keyword is found, then its value
+determines whether the \DVI{} driver will process
+the \verb|\special|, or ignore it.
+
+Every \DVI{} driver must recognize a generic
+language choice relevant to its output device,
+such as {\tt PostScript} or {\tt Epson}. In
+addition, each driver must recognize its own name
+as a language value.
+
+The reason for this requirement is as follows.
+When startup files are supported, their names are
+derived from the driver names. In my 3.0 \DVI{}
+driver code, a driver named \verb|dvialw| will
+search for startup files named \verb|dvialw.ini|
+in a list of standard places. The default
+behavior of a particular driver can be changed
+merely by storing a copy of its executable program
+under a different name, and providing a
+corresponding startup file. Typically, this would
+be done to provide easy-to-use variants of a basic
+driver for different paper types, or different
+page orientations. If the user wishes to
+incorporate driver-specific \verb|\special|
+strings, permitting the \verb|language| value to
+be the driver name provides that flexibility.
+
+Existing mini-languages for graphics, such as
+\verb|eepic|, \verb|epic|, \verb|tpic|, and
+\verb|xpic|, are properly handled using the
+\verb|graphics| and \verb|language| keywords
+together:
+%
+\begin{verbatim}
+\special{language = "tpic",
+ graphics = "..."}
+\end{verbatim}
+
+The \DVI{} Driver Standards Committee has debated
+whether drivers should issue warning messages
+about \verb|\special| commands that they are
+unable to process. In the absence of the
+\verb|language| keyword, I believe that such
+warnings are desirable, although the driver should
+provide an option to suppress such warnings.
+
+However, when a \verb|language| value is found, it
+is important that the driver {\em silently
+ignore\/} ones that it is not prepared to process.
+The presence of that value is sufficient evidence
+to conclude that the user intends it to be ignored
+by some drivers, and certainly does not want
+those drivers to complain about it.
+
+I expect that with more powerful, and
+standardized, \verb|\special| command support of
+the type described in this paper, use of
+\verb|\special|s will increase. Consider, for
+example, a document that makes heavy use of color
+or grey-scale requests via \verb|\special|
+commands; there could be hundreds, or even
+thousands, of them in a document of modest size.
+Were the driver to issue warnings for all of them,
+the terminal output or log file would be flooded
+with mostly useless warning messages that obscure
+much more important information. The
+\verb|language| value provides a standard means to
+prevent this.
+
+\section{Paper specification}
+
+Paper handling and specification is a complex
+issue, and may require future extensions. Thus,
+it is desirable to have a flexible means of
+specifying paper characteristics, and a reasonable
+scheme seems to be to use a small extensible
+language to define it. The assignment-statement
+language whose grammar was presented above is
+suitable for this purpose.
+
+Some examples of the paper specifications
+supported by my 3.0 \DVI{} driver work were given
+earlier. Here, we define the keywords recognized.
+
+ \begin{center}
+ \begin{tabular}{llp{1.1in}}
+ \hline
+Keyword & Type & Description \\
+ \hline
+\CODE{dev_init} & string & initiate device use of paper\\
+\CODE{dev_term} & string & terminate device use of paper\\
+\CODE{height} & dimension & paper height\\
+\CODE{output_order} & number & negative for printing last to first\\
+\CODE{paper} & string & paper form name\\
+\CODE{use} & string & name of copied paper form\\
+\CODE{width} & dimension & paper width\\
+\CODE{x_clip} & number & clip in x direction if non-zero\\
+\CODE{x_left} & dimension & width of left unprintable margin\\
+\CODE{x_right} & dimension & width of right unprintable margin\\
+\CODE{x_origin} & dimension & horizontal offset of \TeX{} (0,0) point\\
+\CODE{y_bottom} & dimension & \sloppy
+ width of bottom unprintable margin\\
+\CODE{y_clip} & number & clip in y direction if non-zero\\
+\CODE{y_origin} & dimension & vertical offset of \TeX{} (0,0) point\\
+\CODE{y_top} & dimension & width of top unprintable margin\\
+ \hline
+ \end{tabular}
+ \end{center}
+%
+The \CODE{paper} keyword defines a name that is
+used to tag the collected parameters. If the form
+name already exists, assignments will replace
+previous values. Otherwise, a new form is
+created.
+
+The \CODE{use} keyword names an existing form
+whose parameters are to be copied to a new one
+named by the \CODE{paper} keyword in the same
+program. This copying happens {\em before\/} any
+of the other keyword assignments are done. The
+order of the statements in the program does not
+matter, because the results of the assignments are
+collected in a temporary form before copying to
+the specified form. Recursive forms references
+are supported; just don't make them circular! The
+\CODE{use} keyword should normally be employed to
+make private modifications of standard forms
+types.
+
+Some printers misbehave if they are presented with
+data that are off the page, or too close to the
+margins; for example, the Hewlett-Packard LaserJet
+wraps such coordinates horizontally. For such
+devices, the \CODE{x_clip} and \CODE{y_clip}
+values should be set non-zero.
+
+Few printers place the (0,0) origin exactly in the
+upper-left page corner; instead, they have it
+slightly offset at some other point, which we call
+(\CODE{x_origin},\CODE{y_origin}). The standard
+\LaTeX{} file, \FN{testpage.\-tex}, can be used to
+determine the correct settings of these values.
+If you print its typeset output, the upper-left
+corner of the inner frame should be exactly one
+inch from the page edges. Suppose you actually
+find that that corner lies 0.75in from the left
+edge, and 1.1in from the top edge. This means the
+printer's (0,0) point is to the left, and just
+below, the upper-left corner. Setting
+\CODE{x_origin = -0.25in} and \CODE{y_origin =
+0.1in} will compensate, so the next time you print
+the test page, the inner frame should be correctly
+positioned.
+
+Most printers are incapable of printing very close
+to the edges of the physical page; the margin
+values \CODE{x_left}, \CODE{x_right},
+\CODE{y_bottom}, and \CODE{y_top} should be set to
+indicate the relevant limits. Sometimes these
+values can be found in the printer documentation.
+However, if the physical paper position relative
+to the printing mechanism is adjustable, as it is
+for most dot-matrix printers, you may have to
+experiment. If you print the \FN{testpage.tex}
+typeset output, the tick marks in the four margins
+will usually not print near the paper edges; use
+them as a guide to setting reasonable values for
+the margin values.
+
+\DVI{} drivers that require a page bitmap will
+allocate memory corresponding to the paper surface
+inside of these margins. Wide margin settings
+can therefore reduce the amount of memory
+required; that in turn can reduce the number of
+bitmap strips that must be processed for
+high-resolution printers, speeding the output.
+
+The standard \TeX{} and \LaTeX{} macro packages
+are parametrized to assume that the \TeX{} (0,0)
+point will be exactly one inch in from the left,
+and one inch down from the top. They also usually
+assume American paper sizes. Text widths and
+heights are then chosen to ensure identical top
+and bottom margins, and except for two-sided
+printing styles, identical left and right margins.
+While the \DVI{} driver \OPTION{x} and \OPTION{y}
+command line options can be used to adjust the
+output position, it is usually better to do so by
+setting paper parameters.
+
+ \begin{sloppypar}
+For example, ISO A4 paper is 210mm (8.2677in)
+wide; \TeX{} macro packages assume 6.5in text
+width with 1in left and right margins. To center
+that text on A4 paper, the 1in margins need to be
+reduced by (8.5 - 8.2677)/2 = 0.1161in, so we
+could put \CODE{x_origin = +0.1161in}. Similarly,
+the A4 height of 297mm (11.6929in) exceeds the
+11in U.~S. paper height, and requires adding
+(11.6929 - 11.0)/2 = 0.3465in to the top and
+bottom margins. That can be accomplished by
+setting \CODE{y_origin = -0.3465in}. Of course,
+if you already have non-zero values of these
+parameters, you will have to adjust them
+accordingly; just {\em add\/} the above offsets to
+the existing values.
+ \end{sloppypar}
+
+If you routinely use non-American paper sizes,
+then you probably should be using a style file
+modification that accounts for the different page
+dimensions, rather than fiddling with paper
+positioning on your output device.
+
+The \CODE{output_order} value should be set
+negative if you want pages printed from last to
+first. This provides an alternate to the
+\OPTION{backwards} command line option, but
+affects only the paper forms types it is defined
+for. If \CODE{output_order} is negative, the
+\DVI{} drivers will simply flip the current
+setting of the backwards-printing switch, which
+may have already been set from the command line.
+
+If the printer needs to receive some magic codes
+to select an alternate paper type (e.g.\ some
+high-speed laser printers support multiple input
+paper trays), it will be necessary for the \DVI{}
+driver to write them into the output file. The
+\CODE{dev_init} and \CODE{dev_term} strings
+provide for this. The \DVI{} drivers output the
+initialization string at the start of the job, and
+the termination string at the end. These are
+output verbatim with nothing added, not even a
+newline.
+
+For example, if you are using the \POSTSCRIPT{}
+driver, \verb|dvialw|, on a system that does not
+have a \POSTSCRIPT{} printer spooler, you might
+want the end of the file to have the \POSTSCRIPT{}
+serial line job terminator character, \CTL{D}.
+You could arrange that by setting
+%
+\begin{verbatim}
+dev_term = "\004";
+\end{verbatim}
+%
+\noindent
+in a paper program.
+
+The DVI drivers already know how to initialize and
+terminate their output devices under normal
+conditions, so you should rarely need to specify
+\CODE{dev_init} and \CODE{dev_term} values.
+
+\bibliography{special}
+
+\makesignature
+
+\end{document}
diff --git a/dviware/driv-standard/papers/special-hosek.tex b/dviware/driv-standard/papers/special-hosek.tex
new file mode 100644
index 0000000000..04b32009d1
--- /dev/null
+++ b/dviware/driv-standard/papers/special-hosek.tex
@@ -0,0 +1,653 @@
+%%%BC Don, I have suggested some editing to your fine epistle.
+%%%BC They are all preceeded by those five letter characters, but not
+%%%BC not always starting in column 1. I would like to distribute
+%%%BC the edited form to our printer standards committee along with
+%%%BC Tom Reid and Glen V.'s work. Do I have your permission to
+%%%BC make those corrections? The opinions are really notes to me.
+%%%BC These notes show a lot of thought.
+%%%BC Thanks, Bart Childs.
+%%%BC
+%%% Format=LaTeX
+%%%
+\documentstyle[twoside]{article}
+ % I'm not wedded to this.
+ % LaTeX was chosen so that the recipient
+ % could format this to match whatever style
+ % they like.
+
+\font\logo=logo10 % Ideally this would be logo10
+\def\AmSTeX{$\cal A\kern-.1667em\lower.5ex\hbox{$\cal M$}\kern-.075em
+ S$-\TeX}
+\def\BibTeX{{\rm B\kern-.05em{\sc i\kern-.025em b}\kern-.08em
+ T\kern-.1667em\lower.7ex\hbox{E}\kern-.125emX}}
+\def\SliTeX{{\rm S\kern-.06em{\sc l\kern-.035emi}\kern-.06em T\kern
+ -.1667em\lower.7ex\hbox{E}\kern-.125emX}}
+\def\TeXMaG{T\kern-.1667em\lower.5ex\hbox{E}\kern-.125emX\-% TeX part
+ M\kern-.1667em\lower.5ex\hbox{A}\kern-.2267emG}
+\def\TeXhax{T\kern-.1667em\lower.5ex\hbox{E}\kern-.125emX\-{\sc hax}}
+\def\MF{\hbox{\logo META}\-\hbox{\logo FONT}}
+\def\PS{{\sc PostScript}}
+\def\Unix{{\sc Unix}}
+
+\chardef\BS=`\\ % This is a better way of doing things than Lamport's
+ % \newcommand
+
+\newcommand{\Special}{{\tt\BS special}}
+\newcommand{\DVI}{{\tt DVI}}
+
+\def\.#1{\ifvmode\leavevmode\fi\hbox{\tt\let\\=\BS
+ \chardef\{=`\{\chardef\}=`\}\chardef\ ='40
+ \chardef\&=`\&#1}}
+
+\begingroup
+\catcode`\_=\active\catcode`\-=\active\catcode`\|=\active
+\gdef\BNFdefs{\def\&##1{\hbox{\bf##1}}
+ \def\dash{\char'174\space} % '174 is an em-dash.
+ \def\e{\hbox to 1em{\hss$\epsilon$\hss}}
+ \catcode`\_=\active\let_=\_
+ \catcode`\-=\active\def->{&\hbox to 1em{\hss$\rightarrow$\hss}}
+ \chardef\-=`\-
+ \catcode`\|=\active\def|{&\hbox to 1em{\hss$\mid$\hss}}
+ \def\|{\hbox to 1em{\hss$\mid$\hss}}
+ \let\\=\cr}
+\endgroup
+
+\def\BNF{\bgroup\BNFdefs\halign\bgroup\hss\it\boldmath##
+ &\it\boldmath##\hfil\cr}
+\def\endBNF{\crcr\egroup\egroup\noindent}
+
+%%%
+%%% Other definitions should be placed here:
+
+
+%%%
+%%% Here are some LaTeX commands for the title
+\title{Proposed \DVI\ \Special\ command standard}
+\author{Don Hosek\\
+ Harvey Mudd College\thanks{BITNET: {\tt DHOSEK@HMCVAX}.
+ Phone: (714)~621-8000.
+ Postal address: Platt Campus Center, Harvey Mudd College,
+ Claremont, CA 91711}\\
+ Claremont, CA}
+%%%BC I like the telephone better. Mine is 409-845-5470
+%%%DH There's little hope of catching me on the phone, but I'll include it
+%%%DH any way.
+\date{August 6, 1987}
+
+\begin{document}
+\maketitle
+
+The information in this report includes some ideas based on responses to
+an article sent to the \TeXhax\ mailing list and printed in the \TeXMaG\
+electronic ``magazine''. Among those people who sent me suggestions were
+Neta Amit, Stephan Bechtolsheim, Peter Breitenlohner, `dorab', John
+Gourlay, Jean-Francois Lamy, Kevin LaRue, William LeFebvre, and Thomas
+J.~Reid. Also, Dean Guenther invited me to send my suggestions for the
+TUG meeting. I apologize if I left anyone out of this list.
+
+\section{Introduction}
+It is becoming clear that some sort of standard on the syntax and
+effect of \Special\ commands is necessary. In my original report to
+\TeXhax\ and \TeXMaG\ \cite{hosek:specials}, I outlined some of the
+issues to be confronted in the development of a \Special\ standard.
+These included device dependency, naming conventions and syntax,
+graphics, and scope (see also \cite{fox:changebars}).
+
+Dean Guenther informs me that he hopes to see some definite standards
+for \Special\ commands set after this year's TUG meeting, and
+Stephan Bechtolsheim (\.{dvi2ps}) is holding off on writing the
+\Special\ handling code for his latest version of the driver until the
+\Special\ command issue is resolved. The suggestions in this paper are
+just that, suggestions; the specifications of this proposed standard are
+open to change. The final standard that comes out of this meeting should
+be specific enough that all implementations of it can generate identical
+results, but also open to extension to reflect changes and innovations
+in printing technology.
+
+\section{Syntax}
+The general syntax for a \Special\ command is: optional environment
+setting commands followed by the special command with multiple special
+commands separated by semicolons. A Backus-Naur Form\footnote{See
+\cite{aho:compilers} for additional information on BNF} syntax for
+\Special\ commands follows:
+\begin{BNF}
+special_command-> spec_cmd \.; special_command \| spec_cmd\\
+spec_cmd-> environment_setting_cmds cmd\\
+ | \e\\
+environment_setting_cmds-> env_cmd environment_setting_cmds\\
+ | \e\\
+\end{BNF}
+Most possible {\it cmd\/} or {\it env\_cmd} values accept options
+that have the syntax described below:
+\begin{BNF}
+options-> required_space opt options \| \e\\
+required_space-> \.\ \ optional_space\\
+optional_space-> required_space \| \e\\
+opt-> angle \| position \| scaling \| tag \| length \| color\\
+ | cap_shape \| file_name\\
+angle-> \." real \| \./ real \., real\\
+position-> \.( dimen \., dimen \.) \| \.+ \.( dimen \., dimen \.)\\
+scaling-> \.< opt_real \., opt_real \.> \| \.[ dimen \., dimen \.]\\
+tag-> chars \.:\\
+length-> req_dimen\\
+color-> \.{black} \| \.{white}\\
+ | \.{red} \| \.{blue} \| \.{yellow}\\
+ | \.{violet} \| \.{green} \| \.{orange}\\
+ | \.{brown}\\
+ | color \.{\&} color\\
+cap_shape-> \.{butt} \| \.{round} \| \.{square} \| \.{bar}\\
+file_name-> opt_area name opt_ext\\
+real-> digit digit_string\\
+ | digit digit_string \.. digit_string\\
+opt_real-> real \| \e\\
+digit-> \.0 \| \.1 \| \.2 \| \.3 \| \.4 \| \.5 \| \.6 \| \.7 \| \.8 \| \.9\\
+digit_string-> digit digit_string \| \e\\
+dimen-> opt_real unit\\
+req_dimen-> real unit\\
+unit-> scaled_unit \| \.{true} scaled_unit \| \e\\
+scaled_unit-> \.{pt} \| \.{pc} \| \.{in} \| \.{bp} \| \.{cm} \| \.{mm}
+ \| \.{dd} \| \.{cc} \| \.{sp}\\
+chars-> chr chars \| \e\\
+chr-> letter \| digit \\
+letter-> \.A \dash \.Z \| \.a \dash \.z\\
+opt_area-> \.< name \.> \| name \.: \| \e\\
+opt_ext-> \.. name \| \e\\
+\end{BNF}
+
+Details of the semantics of the various possiblities for {\it env\_cmd\/}
+or {\it cmd\/} are given in sections~\ref{sec:env} and~\ref{sec:cmds}.
+However, a brief overview of the various {\it env\_cmd\/} and {\it cmd\/}
+values will be given, followed by an explanation of the various
+{\it option\/} values.
+
+\subsection{Overview of {\it env\_cmd}}
+An environment command or commands affect {\it only\/} the first
+{\it cmd\/} following it. Since {\it cmd\/} is never empty, this means
+that an environment setting command can not affect a {\it cmd\/} that is
+in a different \Special\ than the one in which the {\it env\_cmd\/}
+appeared.
+
+The following is a list of possible {\it env\_cmd\/} values with
+option list and a brief description. A detailed explanation will be
+deferred until Section~\ref{sec:env}.
+\begin{description}
+\item[\.{black} {\it color\/}] Set the color to be used as black.
+\item[\.{linecap} {\it cap\_shape\/}] Set the shape of line ends.
+\item[\.{linewidth} {\it length\/}] Set the width of lines.
+\item[\.{offset} {\it position\/}] Change the location of the output
+ from {\it cmd.\/}
+\item[\.{turn} {\it angle\/}] Rotate the command.
+\item[\.{scale} {\it scaling\/}] Scale the command.
+\item[\.{white} {\it color\/}] Set the color to be used as white.
+\end{description}
+
+\subsection{Overview of {\it cmd}}
+\begin{description}
+\item[\.{arc} {\it length\/} {\it angle\/} {\it angle\/}] Draw an arc.
+\item[\.{beginbar} {\it tag\/}] Begin a vertical bar at the current \DVI\
+ $h,v$ coordinates.
+\item[\.{circle} {\it length}] Draw a circle.
+\item[\.{disk} {\it length\/}] Draw a filled-in circle.
+\item[\.{endbar} {\it tag\/}] End a vertical bar at the current \DVI\ $v$
+ coordinate.
+\item[\.{include} {\it tag\/} {\it file\_name\/}] Include the graphics
+ image of the type {\it tag\/} contained in {\it file\_name.}
+\item[\.{landscape}] Orient the page in the landscape position.
+\item[\.{line} {\it length\/} {\it angle\/}] Draw a line.
+\item[\.{message}] Send {\it option\/} to the terminal.
+\item[\.{newsheet}] Force a new sheet.
+\item[\.{pie} {\it length\/} {\it angle\/} {\it angle\/}] Draw a
+ filled-in arc.
+\item[\.{portrait}] Orient the page in the portrait position.
+\item[\.{rotate} {\it angle\/}] Rotate the page about the center of the
+ {\sl real\/} page.
+\item[\.{spline} {\it position\/} {\it position\/} {\it position\/}] Draw
+ a B\'ezier cubic.
+\item[\.{textcolor} {\it color\/}] Set the current text color.
+\end{description}
+
+\subsection{Overview of {\it opt}}
+The order in which the {\it opt\/} values appear in {\it options\/}
+is not important unless more than one {\it opt\/} of a given type
+appears in the paramter list.
+
+\subsubsection{Angles}\label{sec:angle}
+An angle may be specified in two manners. It may be given as~\." followed
+by a real number (let us call it~$n$). The angle~$\theta$ represented,
+is then considered to be (in degrees) $n \bmod 360$ if
+$n \bmod 360\le180$, and $360-(n \bmod 360)$ otherwise. It may also
+be given as \./ followed by two reals separated with a comma (let us
+call them $m$~and~$n$). If $n>0$ and $m\ge0$ then
+$\theta=\arctan\left|m/n\right|$; if $n>0$ and $m<0$ then
+$\theta=180-\arctan\left|m/n\right|$; if $n<0$ and $m\ge0$ then
+$\theta=-180+\arctan\left|m/n\right|$; if $n<0$ and $m<0$ then
+$\theta=-\arctan\left|m/n\right|$; if $n=0$ and $m<0$ then $\theta=180$;
+and if $n=0$ and $m>0$ then $\theta=0$. If $m=0$ and $n=0$ then the
+command should be flushed.
+All angles are considered to be counterclockwise measured from ``up''
+on the current page orientation, unless specified otherwise.
+
+If an angle must be rounded,\footnote{This generally only applies to
+rotation of figures or pages where the array of available rotations
+would tend to be relatively small, such as [-180, -90, 0, 90].} it should
+be rounded as follows:
+\begin{enumerate}
+\item Assuming that the available angles of rotation are in the
+ array~$p$, scan through~$p$ from $1$~to $\it last$ in increasing
+ order. Continue to scan until $p_i\ge\theta$.
+%%%BC I think that $p_i\ge\theta$. is more direct
+%%%DH Good point.
+\item If $p_i-\theta\le\theta-p_{i-1}$ then round $\theta$ to $p_i$,
+ otherwise, round $\theta$ to $p_{i-1}$ ($p_0$ should be set
+ ridiculously low, to make sure that $\theta$ is rounded to $p_1$
+ if $\theta<p_1$).
+\end{enumerate}
+
+\subsubsection{Dimensions}
+Dimensions are specified in essentially the same format as \TeX\ uses
+(see \cite[Chapter~10]{knuth:texbook} for details on the meanings of
+the units used). One extension to this format is that integer values
+shall be assumed to be in terms of \DVI~units (as defined in
+\cite[\S13--20]{ware:dvitype}). In the case of \TeX82, \DVI~units are
+always scaled points ($2^{-16}$~points) so a construction such as
+\verb|\number\mydimen| will yield a valid dimension for a \Special\
+command. This could be used by macros that generate \Special\ commands
+rather than \verb|\the\mydimen| to keep computations by the postprocesor
+down.
+
+Dimensions should be rounded to pixel dimensions using the algorithim
+of {\it rule\_pixels} \cite[\S76]{ware:dvitype}.
+
+\subsubsection{Positions}
+An offset may be described in two manners. An absolute offset is given
+as $\.(x,y\.)$ where $x$~and~$y$ are optional dimensions. If the
+dimension is omitted, the current $h$~or %%%BC inserted a blank here
+ $v$ is substituted for it. The
+standard \DVI\ coordinate system is used (see \cite[\S14]{ware:dvitype}).
+
+A relative offset is specified as $\.+\.(x,y\.)$ where $x$~and %%%BC and here
+ $y$ are
+optional dimensions. If a dimension is omitted, it is treated as zero.
+$x$~is added to the current~$h$, and $y$~is added to the current~$v$
+to get the position for the output of the \Special\ command.
+
+\subsubsection{Scaling}
+Scaling may be described in two manners. Absolute scaling is given as
+$\.[x,y\.]$ where $x$ and $y$ are optional dimensions. If a dimension
+is omitted, the natural width of the \Special's output is substituted
+for it. When given, $x$~or~$y$ cause the width or height of the
+\Special's output to be scaled to match the given dimension.
+
+Relative scaling is specified as $\.< x, y \.>$ where $x$~and~$y$ are
+optional reals. If $x$~or~$y$ are omitted, then they are treated as~1.
+Scaling is performed by multiplying the natural width of the special
+by~$x$ and the natural height by~$y$.
+
+\subsubsection{Tags}
+A tag is used to indicate the nature of external information to be
+included. Their interpretation is given under the description of
+each command that uses them in section~\ref{sec:cmds}. Tags may be of
+any length.
+%%%BC When I first read this I could not figure out what it was.
+%%%BC Then when I did, I became absolutely opposed. Having a TAG
+%%%BC means that it cannot be device independent. This should be
+%%%BC left as it is for input because the thoughts must be considered.
+%%%DH Not necessarily device dependant; the tag only indicates what the
+%%%DH information comes from (they are only used by the graphics inclusion
+%%%DH facility at present) Just because I'm driving a PS printer doesn't
+%%%DH mean that I can't or shouldn't attempt to deal with a Tektronix plot
+%%%DH file or a series of QUIC commands or whatever.
+
+\subsubsection{Lengths}
+A length is given as a dimension. It may not be omitted.
+
+\subsubsection{Colors}
+A color may be one of the names from the definition of {\it color\/} or
+some combination of them. A color not in the list of names may be
+obtained by ``mixing'' colors (e.g. pink may be specified as
+\.{red\&white}). If two graphic objects overlap that are of different
+colors, then the object whose definition occurs later in the page should
+take precedence.
+
+\subsubsection{Line Cap Shapes}
+The shape of the end of a line may be one of three forms:\footnote
+{\cite[p.~217]{adobe:psref} contains illustrations of three of the line
+caps described}
+\begin{description}
+\item[\.{butt}] The line is squared off at its endpoint.
+\item[\.{round}] A semicircle with radius equal to half of the line width
+ is drawn at the end of the line.
+\item[\.{square}] The line is extended one half of the line width past
+ its endpoint and squared off.
+\item[\.{bar}] If the line is vertical at its endpoint, this is treated
+ as a butt cap. Otherwise, a vertical line is drawn through the
+ endpoint, and the edges of the lines are extended or retracted
+ to meet the vertical line drawn.\footnote{This is primarily
+ intended for musical typesetting. See \cite{gourlay:music} and
+ \cite{renner:textyl} for more information on the subject.}
+\end{description}
+
+\subsubsection{File Names}\label{sec:filename}
+File names are specified in the same manner as used by \TeX\ and \MF\
+(see \cite[Part 29]{knuth:texprog} for details and \.{WEB} code).
+The default directory specification is left up to the \DVI\ driver
+designer, although it is suggested that there be some standard
+directory defined for commonly used included images (such as a
+letterhead). Default file extensions are dependent on the context
+of {\it file\_name.\/}
+%%%BC I guess that I end up with the same thoughts that I had back on
+%%%BC the tags. The extension should be furnished by the driver
+%%%BC because that becomes system dependent, not DVI.
+
+
+\section{Environment setting commands}\label{sec:env}
+The commands described here are used to set certain parameters on
+graphics, etc., %%%BC what is this?
+ %%% changed \&c to etc.
+ \Special\ commands. They only affect %%%BC changed effect to affect
+ the {\it cmd\/}
+following them. For example, In the following series of \Special\
+commands, the \.{color} special will only affect the \.{line} command,
+not the
+\.{arc}.
+\begin{verbatim}
+\special{color red line "0 1in; arc "-10 "10 1in}
+
+\special{color red line "0 1in}
+\special{arc "-10 "10 1in}
+\end{verbatim}
+%%%BC The above is questionable! It is enough for the user to
+%%%BC have to understand TeX's difficulties without having
+%%%BC to learn arbitrariness that may be in the driver too.
+%%%BC Leave as is for now!
+
+The %%%BC removed an extra word
+%%%BC commands
+ individual commands are described below, organized by their
+effects. %%%BC added an `s'
+
+\subsection{Color setting commands}
+The \.{black} and \.{white} commands set colors to be used by graphics
+commands.
+\begin{description}
+\item[\.{black} {\it color\/}] Set the color to be used for ``black''.
+ {\it i.e.,\/} the color that lines and curves of graphics
+ primitives are to be drawn in and the color to be used for
+ pixels to be colored in an included graphic image. The default
+ black is \.{black}.
+\item[\.{white} {\it color\/}] Set the color to be used for ``white''.
+ {\it i.e.,\/} the color that will be used for pixels that
+ are set off in an included graphic image. The default white is
+ \.{white}.
+\end{description}
+
+\subsection{Line and curve parameter commands}
+These commands are intended to affect the shapes of lines and curves
+drawn by graphics primitives.
+\begin{description}
+\item[\.{linecap} {\it cap\_shape}] Set the shape of the ends of lines.
+ See the description of {\it cap\_shape\/} above for details
+ on that parameter. The default line cap is \.{butt}.
+\item[\.{linewidth} {\it length}] Set the width of lines and curves to be
+ drawn by graphics primitives. The edges of the line will be
+ half the line width from the zero-width path of the curve or
+ line. The default line width is $0.38889$pt.
+\end{description}
+
+\subsection{Translation and rotation}
+Graphic output is normally placed at the current \DVI\ $h,v$ coordinates.
+These commands alter the placement and sizing of graphic output from a
+\Special\ command.
+\begin{description}
+\item[\.{offset} {\it position\/}] Move the output of the \Special\
+ command by/to {\it position.\/} The default is to print it
+ where it appears.
+\item[\.{turn} {\it angle\/}] Rotate the output of the \Special\
+ command about the position where it appears. The default is
+ to leave it unrotated.
+\item[\.{scale} {\it scaling\/}] Scale the output of the \Special\
+ command by the amount specified by {\it scaling.\/} The default
+ is to print the output at the natural size.
+\end{description}
+
+\section{Proposed commands}\label{sec:cmds}
+%%%BC No {\it cmd\/} may not have an affect on any page than the one upon
+%%%BC suggested new line for above
+No {\it cmd\/} may affect any page other than the one upon
+which it appears. A {\it cmd\/} also may not change the positioning
+of text. The commands proposed are listed below, organized by type.
+%%%BC I am sure that there is reason for the suggestion. However,
+%%%BC I would sure want the next one, DUPLEX, to be global.
+%%%BC What commands did you have in mind?
+%%%DH There is no duplex special; duplex printing should be specified by
+%%%DH a command line option or some such.
+
+\subsection{Duplex printing}
+Duplex printing ({\it i.e.,\/} printing on both sides of a sheet of
+paper, is a feature available with some output devices. Duplex printing
+can only be selected on a global basis (generally through a command-line
+option), but a new sheet may be forced if necessary (for example, for
+a table of contents page that is output at the end of the document).
+This is accomplished with the \.{newsheet} command.
+\begin{description}
+\item[\.{newsheet}] Force a new sheet on output. If \.{newsheet} appears
+ on a page that would normally be printed on the back of a sheet
+ of paper than that page will be printed on a new sheet of paper.
+ If the \Special\ appears on the front of a sheet of paper (this
+ is always the case in simplex printing) then \.{newsheet} has no
+ effect.
+\end{description}
+
+\subsection{Page orientation}
+Most output devices have the ability to print output rotated
+by~$90^\circ$ and sometimes other values. This can be globally specified
+{\sl only\/} by the user interface to the \DVI-driver. Changes on a {\sl
+single page basis\/} may be made through \Special\ commands listed below
+(These commands will generally be issued inside of a command pair
+%%%BC added pair to the above and endinsert below 2 lines
+ such as
+\verb|\pageinsert ... \endinsert|).
+\begin{description}
+\item[\.{rotate} {\it angle\/}] The page that \.{rotate} appears upon
+ will be printed rotated $n^\circ$ counterclockwise from the
+ vertical position on the actual sheet. If necessary, the
+ angle should be rounded as outlined in section~\ref{sec:angle}.
+ If more than one \.{rotate} occurs on a given page, the one
+ occurring later takes precedence.
+\item{\.{landscape}} A specialized case of \.{rotate}. {\it angle\/} is
+ set to $90^\circ$.\footnote{Or $-90^\circ$ if $90^\circ$ is not
+ available and the former is.}
+\item{\.{portrait}} A specialized case of \.{rotate}. {\it angle\/} is
+ set to $0^\circ$. This is likely to only be of use in a document
+ with a global orientation other than $0^\circ$.
+\end{description}
+
+\subsection{Graphics Inclusion}
+To maintain a reasonable degree of compatibility between device drivers
+for graphics inclusion, a graphics inclusion facility must know something
+about
+%%%BC removed -> both
+ the nature of the graphics file. This may be either the
+intended destination of the graphics file (for example, a file may
+be composed of Hewlett-Packard LaserJet Plus control codes) or the
+source of the file (MacPaint, for example can generate \PS\ output;
+however, it contains additional header information which must be stripped
+off of the file before it can be included in a \PS\ file generated by
+some \DVI-to-PS program).
+
+A \DVI\ driver should insure that the current {\em real\/} values of
+$h$~and~$v$ are not changed by any included graphics. If the device
+allows absolute positioning on the page, then the simplest approach
+is to simply reset the position on the page; otherwise the driver
+{\em must\/} keep track of position changes in the included file
+and compensate appropriately afterwards.
+
+\begin{description}
+\item[\.{include} {\it tag\/} {\it file\_name}] Include the graphics
+ file in {\it file\_name\/} of type {\it tag.\/}
+
+ {\it tag\/} indicates the nature of the graphics file.
+ Intelligent drivers should be able to interpret ``foreign''
+ graphics formats. Possible values for {\it tag\/} are: (this is
+ not a full list; other values may be added as necessary to
+ reflect new printers or graphics software)
+ \begin{description}
+ \item[\.{BITMAP:}] The file is a bitmap of an image with the
+ first fullword indicating the width of the bitmap
+ (in pixels), the second fullword indicating the
+ height of the bitmap, and third fullword indicating
+ the intended resolution (in dpi). The data following
+ this is the binary data for the bitmap scanning from
+ left to right horizontally and top to bottom
+ vertically. If rows will not align on fullwords,
+ then they will be padded on the right with 0~bits.
+ \item[\.{EPIC:}] The file is composed of EPIC graphics commands.
+ \item[\.{HALFTONE:}] The file contains a halftone graphics
+ image. Format is similar to that for \.{BITMAP:}
+ except that the first byte contains a value indicating
+ how many bits each pixel requires to store its
+ gray-scale value.
+ \item[\.{IMP:}] The file is composed of \.{IMPRESS} commands.
+ \item[\.{INTER:}] The file is composed of Xerox Interpress
+ commands.
+ \item[\.{MAC:}] The file is a \PS\ file created by a MacIntosh
+ graphics program such as MacPaint.
+ \item[\.{PCL:}] The file is composed of PCL instructions.
+ \item[\.{PS:}] The file is composed of \PS\ commands.
+ \item[\.{QUIC:}] The file is composed of {\sf QUIC} control
+ sequences.
+ \item[\.{TEK:}] The file is composed of Tektronics plot
+ commands.
+ \end{description}
+
+ The file name is as described above in
+ section~\ref{sec:filename}. The default filetype is {\it tag\/}
+ (less the colon).
+\end{description}
+
+\subsection{Graphics primitives}
+The ability to generate simple figures using graphics primitives has
+been used in the program \.{DVIIMP} \cite{ware:dviimp} and a few
+versions of other \DVI-drivers. There is also a \Unix\ utility called
+\.{tpic} which uses \.{pic} commands to generate \Special\ commands for
+\TeX. The philosophy of these graphics primitives could also be
+applied to the \LaTeX\ \.{picture} environment (see \cite{lamport:latex})
+to allow more freedom in the choice of graphic objects.
+
+All graphics primitives ignore \.{white}.
+
+The following graphics primitives are provided:
+\begin{description}
+\item[\.{arc} {\it length\/} {\it angle\/} {\it angle\/}] Draw an arc
+ centered at the current position with radius {\it length\/}
+ from the first {\it angle\/} counterclockwise to the second
+ angle.
+\item[\.{circle} {\it length\/}] Draw a circle with radius {\it length\/}
+ centered at the current position.
+\item[\.{disk} {\it length\/}] Draw a filled circle with radius
+ {\it length\/} centered at the current position.
+\item[\.{line} {\it length\/} {\it angle}] Draw a line of length
+ {\it length\/} at an angle of {\it angle\/} from the current
+ point.
+\item[\.{pie} {\it length\/} {\it angle\/} {\it angle\/}] Draw two lines
+ of length {\it length\/} at the two angles specified, and an
+ arc with the {\it length\/} and angles above, and fill the
+ figure in with the current \.{black} color.
+
+ Line joins are {\sl mitred.\/} The outer edges of the two lines
+ are extended until they meet. If the difference between the two
+ angles is less than $10^\circ$ then the join is drawn as if the
+ two lines each had round line caps and no special joining was
+ done.
+
+ The \.{linecap} setting is ignored.
+\item[\.{spline} {\it position\/} {\it position\/} {\it position\/}] A
+ B\'ezier cubic is drawn from from the current position to
+ the last {\it position\/} in {\it options\/} using the second
+ and third {\it position\/}s as control points.
+\end{description}
+
+\subsection{Miscellaneous \Special\ commands}
+The following miscellaneous commands should also be provided.
+\begin{description}
+\item[\.{beginbar} {\it tag\/}] Begin a vertical line at the current
+ \DVI\ $h,v$ coordinates. The line continues until the $v$
+ coordinate of the matching \.{endbar} on the page. If there is
+ no matching \.{endbar}, then no line is drawn.
+\item[\.{endbar} {\it tag\/}] End a vertical line at the current $v$
+ coordinate (see \.{beginbar}).
+\item[\.{message} {\it option}] Output {\it option\/} to the terminal.
+ If the \DVI-driver does not output page numbers as it processes
+ the file, it should print the \TeX\ page number (from the {\it
+ bop\/} command see~\cite{ware:dvitype}) before printing {\it
+ message\_text.}
+\item[\.{textcolor} {\it color}] All text from the first \DVI\ {\it
+ push\/} to its matching {\it pop\/} are to be typeset in
+ {\it color.\/}
+\end{description}
+
+%\bibliography{texref,misc}
+%\bibliographystyle{plain}
+
+%%% HOSEK1.BBL
+\begin{thebibliography}{10}
+
+\bibitem{aho:compilers}
+Alfred~V. Aho, Ravi Sethi, and Jeffrey~D. Ullman.
+\newblock {\em Compilers: Principles, Techniques, and Tools}.
+\newblock Addison-Wesley, Reading, Massachussetts, 1986.
+
+\bibitem{fox:changebars}
+Jim Fox.
+\newblock Change bars.
+\newblock {\em TUGboat}, 7(3), 1986.
+\newblock Appeared in ``Queries'' section.
+
+\bibitem{gourlay:music}
+John~S. Gourlay, Allen Parrish, Dean~K. Roush, F.~Javier Sola, and Yiling Tien.
+\newblock Computer formatting of music.
+\newblock Technical Report OSU-CISRC-2/87-TR3, Ohio State University, 1986.
+
+\bibitem{hosek:specials}
+Don Hosek.
+\newblock Call for standardization of {\tt dvi} specials.
+\newblock {\em \TeXMaG}, 1(5), 1987.
+
+\bibitem{adobe:psref}
+Adobe~Systems Incorporated.
+\newblock {\em PostScript language reference manual}.
+\newblock Addison-Wesley, Reading, Massachussetts, 1985.
+
+\bibitem{ware:dvitype}
+Donald~E. Knuth.
+\newblock The {\tt dvitype} processor.
+\newblock {\tt WEB} program, Stanford University, August 1984.
+
+\bibitem{knuth:texbook}
+Donald~E. Knuth.
+\newblock {\em The \TeX book}.
+\newblock Addison Wesley, Reading, Massachusetts, 1986.
+
+\bibitem{knuth:texprog}
+Donald~E. Knuth.
+\newblock {\em \TeX: The Program}.
+\newblock Addison Wesley, Reading, Massachusetts, 1986.
+
+\bibitem{lamport:latex}
+Leslie Lamport.
+\newblock {\em \LaTeX: A Document Preparation System}.
+\newblock Addison Wesley, Reading, Massachusetts, 1986.
+
+\bibitem{renner:textyl}
+John~S. Renner.
+\newblock {\TeX}tyl: a line-drawing interface for {\TeX}.
+\newblock Technical Report OSU-CISRC-4/87-TR9, Ohio State University, March
+ 1987.
+
+\bibitem{ware:dviimp}
+Arthur~L. Samuel.
+\newblock The {\tt dviimp} processor.
+\newblock {\tt WEB} program, Stanford University, July 1985.
+
+\end{thebibliography}
+\end{document}