diff options
author | Norbert Preining <norbert@preining.info> | 2019-09-02 13:46:59 +0900 |
---|---|---|
committer | Norbert Preining <norbert@preining.info> | 2019-09-02 13:46:59 +0900 |
commit | e0c6872cf40896c7be36b11dcc744620f10adf1d (patch) | |
tree | 60335e10d2f4354b0674ec22d7b53f0f8abee672 /dviware/driv-standard/level-0 |
Initial commit
Diffstat (limited to 'dviware/driv-standard/level-0')
-rw-r--r-- | dviware/driv-standard/level-0/dvi.tex | 570 | ||||
-rw-r--r-- | dviware/driv-standard/level-0/dvistd0.dvi | bin | 0 -> 141268 bytes | |||
-rw-r--r-- | dviware/driv-standard/level-0/dvistd0.pdf | bin | 0 -> 273745 bytes | |||
-rw-r--r-- | dviware/driv-standard/level-0/dvistd0.tex | 886 | ||||
-rw-r--r-- | dviware/driv-standard/level-0/fileform.sty | 579 | ||||
-rw-r--r-- | dviware/driv-standard/level-0/gf.tex | 381 | ||||
-rw-r--r-- | dviware/driv-standard/level-0/pk.tex | 606 | ||||
-rw-r--r-- | dviware/driv-standard/level-0/tfm.tex | 391 |
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 Binary files differnew file mode 100644 index 0000000000..ff870d5e06 --- /dev/null +++ b/dviware/driv-standard/level-0/dvistd0.dvi diff --git a/dviware/driv-standard/level-0/dvistd0.pdf b/dviware/driv-standard/level-0/dvistd0.pdf Binary files differnew file mode 100644 index 0000000000..5bc00d2ca3 --- /dev/null +++ b/dviware/driv-standard/level-0/dvistd0.pdf 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 |