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