{\def\contactperson{Robert McGaffey}
\def\Special{{\tt\char"5Cspecial}}
\let\TeXhax\hax
\def\GDF{{\tt GDF}}
\let\DVI\dvi
\def\TeXMaG{\TeX M\kern-.1667em\lower.5ex\hbox{A}\kern-.2267emG}
\newcount\num
\newcount\subnum
\def\section#1{\medskip\global\advance\num by1
\global\subnum0\noindent{\sl\the\num.  #1} \par\noindent\ignorespaces}
\def\subsection#1{\global\advance\subnum by 1\smallskip\leftline{$\bullet$\sl
\enspace\the\num.\the\subnum\enspace#1}\par\noindent\ignorespaces} 
\def\subsubsection#1{\par\leftline{\quad$\circ$\sl
#1}\par\noindent\ignorespaces}

\centerline{\bf The \dvi\ Driver Standards
Committee} 
\medskip 
\noindent
The first few months of 1989 have shown a healthy increase in the
\DVI\ driver standards discussion. For those people
with network access, much has been done to provide for the dissemination
of the information which has come through our hands.
 
The group has a {\tt LISTSERV} discussion group, {\tt DRIV-L}, which
is the primary means of communication between its members. The list
is set up so that anyone who wants to contribute ideas may do so by
sending mail to {\tt DRIV-L@TAMVM1} (Bitnet) or
{\tt DRIV-L@TAMVM1.TAMU.EDU} (Internet). These notes will be
automatically distributed to the membership of the group.
 
Archives of past discussions as well as papers on the topic and
the  current versions of standards documentation, programs, and macros
are stored on the Clarkson archive in the {\tt dvi-standard} group.
Individuals with FTP access may obtain the files from
{\tt sun.soe.clarkson.edu} in the directory {\tt pub/dvi-standard}.
Those without FTP access may still obtain the files via e-mail using
the same mechanism as is used by the \LaTeX\ style collection,
substituting {\tt dvi-standard} for {\tt latex-style} where appropriate.
For example, to obtain the file {\tt driv-l.log8809} and a list of other
files, one might send a message to
{\tt archive-server@sun.soe.clarkson.edu} which looks like:
{\parindent0pt
\begintt
path fschwartz%hmcvax.bitnet@clvm.clarkson.edu
get dvi-standard driv-l.log8809
index dvi-standard
\endtt
}
\noindent
By the TUG meeting in August, we hope to have much of the proposed
standard documented and available from the archive.
 
Bitnet users may also obtain log files from \nl {\tt Listserv@tamvm1}
by sending the command\nl
{\tt get driv-l log}{it yymm}\nl
to {\tt Listserv@tamvm1} where {\it yy\/} is the last two digits of the
year and {\it mm\/} is the month, expressed as a two digit number. For
example, to obtain the log from September, 1988, one would send the
command {\tt get driv-l log8809} to {\tt Listserv}. Listserv commands
should be sent either as the first line of a single-line mail message
or as an interactive message ({\tt TELL} on CMS, {\tt SEND} on VMS).
 
For those without network access, the files may be obtained on
a floppy disk from John Radel for his usual fees.

The remainder of this article outlines some preliminary results of
the committee's work. Persons interested in implementing portions
of this standard should check the Clarkson archive or contact
\contactperson\ to obtain the most recent information on the standard.
 
\section{\b{\ttit special} commands}
The committee has decided that the \Special\ commands defined to date
will be labeled as `experimental' and later classified as
`production' after they've undergone sufficient testing to justify
the reclassification. Experimental \Special\ commands are distinguished
by the prefix |X_|.
 
Further work on the precise syntactical rules for \Special\ are under
development.
 
\subsection{Interface}
One of the early decisions of the committee was that \Special\ will be
treated as a primitive command which the end user should never need
to type. Instead, \Special\ should be accessed through a high level
macro set. This has the additional advantage that users at beta test sites
will usually not be affected by changes to the syntax or names
of \Special\ commands. This is important since when a \Special\ changes
status from `experimental' to `production', its name will change
as noted above.
 
The committee is developing macros for both plain \TeX\ and \LaTeX\
to interface with the developing standard.
At the present time, only preliminary versions of these macros have been
written, but a full macro set for both plain \TeX\ and \LaTeX\
should be be available by the publication
time of this article.
 
\subsection{Scope}
\Special\ commands have been broken down into six classes depending
on what portion of the \DVI\ output they would affect.

\noindent$\bullet${Global:} these \Special\ commands affect the entire
document.
         Examples of this class of \Special\ include commands for
         selecting duplex printing or setting the printing orientation
         (portrait, landscape, etc.).

\noindent$\bullet${Page:} these \Special\ commands affect only the page on
which they
         are printed. Examples of this class include requests for
         feeding of special paper from an auxiliary tray ({\it e.g.,\/}
         for a cover sheet) or a single-page change in orientation.

\noindent$\bullet${Box:} these \Special\ commands affect a block of output that
is
         enclosed in a \TeX\ box (and thus is, by necessity, on a
         single page). For example, a command to rotate a block of
         text would fall under this class.

\noindent$\bullet${Delimited:} these \Special\ commands are those that affect
         a block of output which is not necessarily enclosed by
         a \TeX\ box or contained entirely on a single page. For
         example, a \Special\ command to set color would fall into this
         class.

\noindent$\bullet${Output generating:} these \Special\ commands are those which
         generate self-contained output of some sort. For example,
         the |X_vec| \Special\ of Section%\ref{sc:graphics} falls
         into this class.

\noindent$\bullet${Attribute setting:} these \Special\ commands modify the next
         output generating command which appears on the current page.
         If no output generating command follows an output modifying
         command, the command is ignored and the \DVI\ driver program
         should issue a warning. An example of this class of commands
         would be the |X_linewidth| \Special\ described elesewhere.
\smallskip
\noindent The remainder of this section will consist of additional notes on
those classes of \Special\ commands which need additional
comment.
 
\subsubsection{Global specials}
Global specials, it has been decided, will be required to appear on the
first page of the document. They will either be identified with
a prefix (|X_global:|), delimited by a pair of \Special\ commands
(|X_begin_globals| \dots\ |X_end_globals|) or some similar
scheme.
 
One issue that has not been decided is whether the first page containing
the global \Special\ commands should be the first page of text or a
special page on its own. Having global options specified as part of the
actual first page of text minimizes the impact on existing drivers.
However, it does present some problems with existing macro packages in
regard to ensuring that the options are output at the right place.
This problem stems from the fact that the \Special\ commands used to
convey the options to the drivers are normally placed in the body of
the document. Macro packages which place headline text or entirely
separate title pages prior to writing the first part of the `body' of
the document will cause text to appear in the \DVI\ file before the global
options. Headline text may or may not have any impact upon the global
options, but separate title pages will prevent the global options from
being on the first page of the \DVI\ file. To get around this problem, the
mechanism used for passing global information will need to `cooperate'
with the output routine within the macro package.
 
Requiring an entirely separate page at the start of the \DVI\ file avoids
the need for special interaction with the output routines of various
macro packages. Instead of placing \Special\ commands in the body of the
first page, a separate macro is used which issues a separate
|\shipout| containing the \Special\ commands. This approach makes
things easier for programs which sort or otherwise reorganize a \DVI\
file since no culling of global options from the first text page is
necessary. However, the separate page technique has an undesired effect:
it produces a blank page on existing drivers which do not understand the
options page.
 
\subsubsection{Box specials}
A box \Special\ command, since it will always be entirely
typeset on a single page, will be enclosed in a \TeX\ box (|\hbox|
or |\vbox|). In the \DVI\ output, box structure is reflected by
surrounding {\it push\/} and {\it pop\/} commands. For example,
the \TeX\ commands:
\begintt
normal
\hbox{\special{abc} special}
text
\endtt
generate the following \DVI\ code:
{\obeylines
{\tt "normal"}
{\it push}
{\it right}
{\it xxx} {\tt "abc"}
{\tt "special"}
{\it pop}
{\it right}
{\tt "text"}
}

A \DVI\ driver can exploit this for a command such as |X_rotate|
by maintaining on the \DVI\ stack, values for items such as
{\it rotation\_angle}.
 
\subsubsection{Delimited specials}
The committee has not found an effective way to deal with open
block \Special\ commands yet. They will probably need to be issued in
cooperation with the output routine, to insure that every delimited
command is broken down into matching pairs of \Special\ commands on
each page within its bounds.
 
This approach is necessary for two reasons:

\noindent$\bullet$If pages are reordered for any reason ({\it e.g.,\/} reverse
         ordering for laser printers which stack output face up) the
         driver should not need to have to scan the entire file to
         insure that it does not inadvertently break up a pair
         of \Special\ commands producing a delimited command.

\noindent$\bullet$Without special care being taken, a delimited command which
         spans pages may inadvertently affect page headers and footers
         which are typeset between the beginning and ending blocks.

 
\subsection{Graphics commands}
Three techniques for including graphics have been discussed.
These are:

\noindent$\bullet$Make graphics entirely with \TeX\ primitives.

\noindent$\bullet$Use \MF\ to build a graphic as a font.

\noindent$\bullet$Allow the driver to include a device-specific graphic.

 
\subsubsection{Graphics by \TeX}
Handling graphics entirely with \TeX\ macros and primitives which use
dots or characters from a special graphics font is a technique which has
been in use for some time.
The \LaTeX\ picture environment and \PiCTeX\ work in this way with the
former assembling characters from a graphic font and the latter using
closely spaced dots.
 
David F.~Rogers ({\TUGboat} 10(1) and \TeXhax\ 89(7)) proposed a
series of \TeX\ macros to provide plotting primitives; these macros would
generally be used by \TeX\ input generated by some graphics package.
The macros which were proposed created graphics by closely spacing dots
along each line in the same manner as \PiCTeX.
 
The problem posed by creating graphics in this manner is
that \TeX\ must store all of the graphic elements in memory at once for an
entire page, possibly exceeding \TeX's capacity.
 
To calculate the memory needs, the technique for positioning each dot
was specified as:
\begintt
\kern\DX \raise\Y \hbox{\DOT}%
\endtt
where |\DX| is a dimension register giving the displacement in the
`x' direction from the previous point and |\Y| is a dimension
register giving the displacement in the `y' direction from the reference
point of the graph.
|\DOT| defines the plotting symbol and |\DX| accounts for the
width of this symbol.
 
In memory, \TeX\ saves |\kern\DX| in a {\it kern\/} node, the raised
hbox in an {\it hlist\/} node, and the plotting symbol in a
{\it char\_node.}
These take two words, seven words, and one word of memory, respectively,
for a total of ten words per dot.
A normal-size implementation of \TeX\ with 64\,k-words of memory allows
about 6000 dots to be positioned before it runs out of memory
(assuming that no other macros are loaded and neglecting other text on the
page).
Spacing the dots at 100 per inch, this gives about 60 inches, which is not
sufficient for many graphs.
 
To enhance the capacity of this graphics technique, we decided to use a
|\special| to add a vector drawing capability to \TeX\ and \DVI\ drivers
and use the |\special| instead of closely-spaced dots.
This changes the \TeX\ command sequence to:
\begintt
\kern\DX \raise\Y
\hbox{\special{X_vec \number\XC
               \space \number\YC}}%
\endtt
where |\XC| and |\YC| are dimension registers giving the components
of the vector.
Component values in scaled points are likely to be six-digit numbers with an
additional minus sign for negative numbers.
Thus, an average length for the |\special| string is likely to be
around 18 characters.
In memory, a |\special| is saved in a two-word {\it whatsit\/} node
which points to the |\special| string.
Thus the total memory needs, counting the {\it kern\/} and {\it hlist\/}
nodes, will average 29 words per vector which allows roughly 2000 vectors.
This may be sufficient for many graphs, but falls somewhat short for
complex three-dimensional surface plots.
(One sample 3D surface plot consisted of 13,000 vectors.)
 
Two \Special\ commands have been defined for graphics of this sort (and
specialized commands for more complicated graphic elements will be
defined in the future). The commands defined are:

\noindent$\bullet${\tt X\_linewidth $n$} Specify that the following vector is to
be
         drawn with a line width of $n$ \DVI\ units (scaled points for
         \TeX). Vectors are
         normally 1~point in width. If no vector follows the
         |X_linewidth| \Special\ on this page, the command is
         ignored and the \DVI\ driver program should issue a warning.

\noindent$\bullet${\tt X\_vec $\Delta x$ $\Delta y$} Draw a diagonal line from the
         current point to the point which is offset by $\Delta x$ and
         $\Delta y$ from the current point. $\Delta x$ and $\Delta y$
         are specified in terms of \DVI\ units.
 
\subsubsection{Graphics by \MF}
A different approach to graphics inclusion is to use \MF\ to produce the
graphic as a character of a font and position it using \TeX's normal
character positioning capabilities.
The advantage of this technique is that the graphic is in a format which
many drivers will already accept.
 
METAPLOT by Pat Wilcox (to be described in
 \TUGboat;
see also the Amiga\TeX\ notes of March~12th,
1989 or \TeXMaG\ {3}(3).)
is one example of a package which takes this approach.
 
However, the technique has a number of drawbacks:
Graphic fonts are resolution-dependent; a separate graphic font is
needed for different resolution devices.
\MF\ records changes in pixel values across a scan line when it builds a
character.
Thus, the memory needs depend upon the complexity of the graphic in
addition to the size and resolution of the device.
To circumvent this limitation, it is necessary to break the whole graphic
into smaller pieces.
It is important to ensure that the heights and widths of each piece
are integral numbers of pixels to
allow them to be reassembled without the alignment problems which occur
for letters within words.
 
\subsubsection{Including device-dependent files}
With this approach, the \DVI\ driver processes a special Graphics Description
File (\GDF) which, among other things, indicates the names and formats of
separate graphic files in device-dependent format.
A driver searches this list to find a file in a format appropriate for the
device it supports.
This allows a greatly simplified graphic files to be defined for previewing
purposes while a detailed, higher resolution version is used when the
\DVI\ file is printed.
 
\GDF\ files are processed both by \TeX\ and by the \DVI\ driver.
\TeX\ |\input|s the file and executes code at the start of the
file. This code sets some dimension and box registers giving the size
of the graphic then terminates with an |\endinput| to return
control to the macro which did the |\input|. The portion of the
\GDF\ file following the |\endinput| is processed by the driver.
 
The driver section of the file consists of a series of keywords which
identify lines that apply to a particular graphics format, rotation, etc.
The driver scans these lines searching for a format which it understands.
Depending on the driver and the graphics format, additional lines may
have to be searched for other attributes such as rotation. Eventually,
the name of the graphics file to be included will be found and the
driver will incorporate it into the output file.
 

Bart Childs, Alan Stolleis, and Don
Berryman suggested another scheme for using \Special\ to include
device-dependent graphics files (`A portable graphics inclusion',
\TUGboat\ 10(1)).
 
\section{Additional reference material}
In addition to the works mentioned in the Editor's note at the end
of our last report, the following may also be of interest:

\noindent$\bullet$ Guntermann, Klaus and Joachim Schrod. `High quality \DVI\
         drivers'. Available from the Clarkson archive as the file
         {\tt schrod-guntermann1.tex}.

\noindent$\bullet$ Hosek, Don. `Proposed \DVI\ \Special\ command standard'.
         Available from the Clarkson archive as the file
         {\tt hosek1.tex}.

In addition, anyone interested in implementing any portion of the
developing standard should read the logs available from the Clarkson
archive or {\tt Listserv@tamvm1}.
\smallskip
\rightline{\sl  Tom Reid \& Don Hosek}
%\signature{Tom Reid\\
%       Computing Services Center\\
%       Texas A\&M University\\
%       College Station, TX 77843\\
%       \bigskip
%       \signaturemark Don Hosek\\
%       3916 Elmwood\\
%       Stickney, IL 60402\\
%       \net {\rm Internet:}%u33297@uicvm.uic.edu\\
%       {\rm Bitnet:}%u33297@uicvm\\
%       {\rm Bitnet:}%dhosek@ymir\\
%       {\rm UUNet:}%dhosek@jarthur.claremont.edu\\
%       {\rm JANET:}%u33297\%uicvm.uic.edu@uk.ac.earn-relay}
}