summaryrefslogtreecommitdiff
path: root/dviware/driv-standard/level-0
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/level-0
Initial commit
Diffstat (limited to 'dviware/driv-standard/level-0')
-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
8 files changed, 3413 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