% 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}