% $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).