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

