% draft-8907-tub.tex 21 Jun 91 %------------------------------------------------------------ % % Second DVI driver standards committee report. % % Published in TUGboat Vol. 10, No. 2, July 1989, pages 188-191. % % [LaTeX, plus tugboat macros, plus alltt] %% js: changed by Joachim Schrod on 21 Jun 91. %% js: It now uses ltugboat instead of ltugbot %% js: (I used ltugboat version 1.04 / tugboat.com version 1.05). \documentstyle[ltugboat,alltt]{article} \title{Report from the \DVI\ Driver Standards Committee} \author{Tom Reid \\ Don Hosek} % This SHOULD be \and but it don't % work with ltugbot.sty \newcommand{\DVI}{{\tt DVI}} \newcommand{\contactperson}{Robert McGaffey, address on page~\addresspage,} \newcommand{\Special}{{\tt\char"5Cspecial}} \newcommand{\addresspage}{999} %% js: \newcommand{\TeXhax}{\TeX{\sc hax}} \newcommand{\GDF}{{\tt GDF}} %% js: \newcommand{\TeXMaG}{T\kern-.1667em\lower.5ex\hbox{E}\kern-.125emX% %% js: M\kern-.1667em\lower.5ex\hbox{A}\kern-.2267emG} \hbadness=9999 % Don't bother me with details \begin{document} \maketitle The first few months of 1989 have shown a healthy increase in the discussion in the \DVI\ driver standards discussion. For those people with network access, much has been done to provide for the dissemination of the information which has come through our hands. The group has a {\tt LISTSERV} discussion group, {\tt DRIV-L}, which is the primary means of communication between its members. The list is set up so that anyone who wants to contribute ideas may do so by sending mail to {\tt DRIV-L@TAMVM1} (Bitnet) or {\tt DRIV-L@TAMVM1.TAMU.EDU} (Internet). These notes will be automatically be distributed to the membership of the group. Archives of past discussions as well as papers on the topic and the current versions of standards documentation, programs, and macros are stored on the Clarkson archive in the {\tt dvi-standard} group. Individuals with FTP access may obtain the files from {\tt sun.soe.clarkson.edu} in the directory {\tt pub/dvi-standard}. Those without FTP access may still obtain the files via e-mail using the same mechanism as is used by the \LaTeX\ style collection, substituting {\tt dvi-standard} for {\tt latex-style} where appropriate. For example, to obtain the file {\tt driv-l.log8809} and a list of other files, one might send a message to {\tt archive-server@sun.soe.clarkson.edu} which looks like: \begin{small} \begin{verbatim} path fschwartz%hmcvax.bitnet@clvm.clarkson.edu get dvi-standard driv-l.log8809 index dvi-standard \end{verbatim} \end{small} By the TUG meeting in August, we hope to have much of the proposed standard documented and available from the archive. Bitnet users may also obtain log files from {\tt Listserv@tamvm1} by sending the command \begin{small} \begin{alltt} get driv-l log{\it yymm} \end{alltt} \end{small} to {\tt Listserv@tamvm1} where {\it yy\/} is the last two digits of the year and {\it mm\/} is the month, expressed as a two digit number. For example, to obtain the log from September, 1988, one would send the command {\tt get driv-l log8809} to {\tt Listserv}. Listserv commands should be sent either as the first line of a single-line mail message or as an interactive message ({\tt TELL} on CMS, {\tt SEND} on VMS). For those without network access, the files may be obtained on a floppy disk from John Radel for his usual fees (see the article, ``Contents of the Archive Server'' in this issue for information on obtaining these files). % Editor: Could you insert % a page number for this article into this sentence? The remainder of this article outlines some preliminary results of the committee's work. Persons interested in implementing portions of this standard should contact check the Clarkson archive or contact \contactperson\ to obtain the most recent information on the standard. \section{\Special\ commands} The committee has decided that the \Special\ commands defined to date will be labeled as ``experimental'' and later classified as ``production'' after they've undergone sufficient testing to justify the reclassification. Experimental \Special\ commands are distinguished by the prefix \verb+X_+. Further work on the precise syntactical rules for \Special\ are under development. \subsection{Interface} One of the early decisions of the committee was that \Special\ will be treated as a primitive command which the end user should never need to type. Instead, \Special\ should be accessed through a high level macro set. This has the additional advantage that users at beta test sites will usually not be affected by changes to the syntax or names of \Special\ commands. This is important since when a \Special\ changes status from ``experimental'' to ``production,'' its name will change as noted above. The committee is developing macros for both plain \TeX\ and \LaTeX\ to interface with the developing standard. At the present time, only preliminary versions of these macros have been written, but a full macro set for both plain \TeX\ and \LaTeX\ should be be available by the publication time of this article. \subsection{Scope} \Special\ commands have been broken down into six classes depending on what portion of the \DVI\ output they would affect. \begin{description} \item[Global] These \Special\ commands affect the entire document. Examples of this class of \Special\ include commands for selecting duplex printing or setting the printing orientation (portrait, landscape, etc.). \item[Page] These \Special\ commands affect only the page on which they are printed. Examples of this class include requests for feeding of special paper from an auxiliary tray ({\it e.g.,\/} for a cover sheet) or a single-page change in orientation. \item[Box] These \Special\ commands affect a block of output that is enclosed in a \TeX\ box (and thus is, by necessity on a single page). For example, a command to rotate a block of text would fall under this class. \item[Delimited] These \Special\ commands are those that affect a block of output which is not necessarily enclosed by a \TeX\ box or contained entirely on a single page. For example, a \Special\ command to set color would fall into this class. \item[Output generating] These \Special\ commands are those which generate self-contained output of some sort. For example, the \verb+X_vec+ \Special\ of Section~\ref{sc:graphics} falls into this class. \item[Attribute setting] These \Special\ commands modify the next output generating command which appears on the current page. If no output generating command follows an output modifying command, the command is ignored and the \DVI\ driver program should issue a warning. An example of this class of commands would be the \verb+X_linewidth+ \Special\ described in Section~\ref{sc:graphics}. \end{description} The remainder of this section will consist of additional notes on those classes of \Special\ commands which need additional comment. \subsubsection*{Global specials} Global specials, it has been decided, will be required to appear on the first page of the document. They will either be identified with a prefix (\verb-X_global:-), delimited by a pair of \Special\ commands (\verb-X_begin_globals- \ldots \verb-X_end_globals-) or some similar scheme. One issue that has not been decided is whether the first page containing the global \Special\ commands should be the first page of text or a special page on its own. Having global options specified as part of the actual first page of text minimizes the impact on existing drivers. However, it does present some problems with existing macro packages in regard to ensuring that the options are output at the right place. This problem stems from the fact that the \Special\ commands used to convey the options to the drivers are normally placed in the body of the document. Macro packages which place headline text or entirely separate title pages prior to writing the first part of the ``body'' of the document will cause text to appear in the \DVI\ file before the global options. Headline text may or may not have any impact upon the global options, but separate title pages will prevent the global options from being on the first page of the \DVI\ file. To get around this problem, the mechanism used for passing global information will need to ``cooperate'' with the output routine within the macro package. Requiring an entirely separate page at the start of the \DVI\ file avoids the need for special interaction with the output routines of various macro packages. Instead of placing \Special\ commands in the body of the first page, a separate macro is used which issues a separate \verb|\shipout| containing the \Special\ commands. This approach makes things easier for programs which sort or otherwise reorganize a \DVI\ file since no culling of global options from the first text page is necessary. However, the separate page technique has an undesired effect: it produces a blank page on existing drivers which do not understand the options page. \subsubsection*{Box specials} A box \Special\ command, since it will always be entirely typeset on a single page, will be enclosed in a \TeX\ box (\verb+\hbox+ or \verb+\vbox+). In the \DVI\ output, box structure is reflected by surrounding {\it push\/} and {\it pop\/} commands. For example, the \TeX\ commands: \begin{verbatim} normal \hbox{\special{abc} special} text \end{verbatim} generate the following \DVI\ code: \begin{verse} {\tt "normal"}\\ {\it push}\\ {\it right}\\ {\it xxx} {\tt "abc"}\\ {\tt "special"}\\ {\it pop}\\ {\it right}\\ {\tt "text"} \end{verse} A \DVI\ driver can exploit this for a command such as \verb+X_rotate+ by maintaining on the \DVI\ stack, values for items such as {\it rotation\_angle}. \subsubsection*{Delimited specials} The committee has not found an effective way to deal with open block \Special\ commands yet. They will probably need to be issued in cooperation with the output routine, to insure that every delimited command is broken down into matching pairs of \Special\ commands on each page within its bounds. This approach is necessary for two reasons: \begin{itemize} \item If pages are reordered for any reason ({\it e.g.,\/} reverse ordering for laser printers which stack output face up) the driver should not need to have to scan the entire file to insure that it does not inadvertently break up a pair of \Special\ commands producing a delimited command. \item Without special care being taken, an delimited command which spans pages may inadvertently affect page headers and footers which are typeset between the beginning and ending blocks. \end{itemize} \subsection{Graphics commands} \label{sc:graphics} Three techniques for including graphics have been discussed. These are: \begin{enumerate} \item Make graphics entirely with \TeX\ primitives. \item Use \MF\ to build a graphic as a font. \item Allow the driver to include a device-specific graphic. \end{enumerate} \subsubsection*{Graphics by \TeX} Handling graphics entirely with \TeX\ macros and primitives which use dots or characters from a special graphics font is a technique which has been in use for some time. The \LaTeX\ picture environment and \PiCTeX\ work in this way with the former assembling characters from a graphic font and the latter using closely spaced dots. In {\it TUGboat\/}~{\bf10}(1),\footnote{This article also appeared in \TeXhax~{\bf89}(7).} David F.~Rogers proposed a series of \TeX\ macros to provide plotting primitives; these macros would generally be used by \TeX\ input generated by some graphics package. The macros which were proposed created graphics by closely spacing dots along each line in the same manner as \PiCTeX. The problem posed by creating graphics in this manner is that \TeX\ must store all of the graphic elements in memory at once for an entire page quickly exceeding \TeX's capacity. To calculate the memory needs, the technique for positioning each dot was defined. This is: \begin{verbatim} \kern\DX \raise\Y \hbox{\DOT}% \end{verbatim} where \verb|\DX| is a dimension register giving the displacement in the ``x'' direction from the previous point and \verb|\Y| is a dimension register giving the displacement in the ``y'' direction from the reference point of the graph. \verb|\DOT| defines the plotting symbol and \verb|\DX| accounts for the width of this symbol. In memory, \TeX\ saves \verb|\kern\DX| in a {\it kern\/} node, the raised hbox in an {\it hlist\/} node, and the plotting symbol in a {\it char\_node.} These take two words, seven words, and one word of memory, respectively, for a total of ten words per dot. A normal-size implementation of \TeX\ with 64\,k-words of memory allows about 6000 dots to be positioned before it runs out of memory (assuming that no other macros are loaded and neglecting other text on the page). Spacing the dots at 100 per inch, this gives about 60 inches which is not sufficient for many graphs. To enhance the capacity of this graphics technique, we decided to use a \verb|\special| to add a vector drawing capability to \TeX\ and DVI drivers and use the \verb|\special| instead of closely-spaced dots. This changes the \TeX\ command sequence to: \begin{verbatim} \kern\DX \raise\Y \hbox{% \special{X_vec \number\XC \space \number\YC}% \end{verbatim} where \verb|\XC| and \verb|\YC| are dimension registers giving the components of the vector. Component values in scaled points are likely to be six-digit numbers with an additional minus sign for negative numbers. Thus, an average length for the \verb|\special| string is likely to be around 18 characters. In memory, a \verb|\special| is saved in a two-word {\it whatsit\/} node which points to the \verb|\special| string. Thus the total memory needs, counting the {\it kern\/} and {\it hlist\/} nodes, will average 29 words per vector which allows roughly 2000 vectors. This may be sufficient for many graphs, but falls somewhat short for complex three-dimensional surface plots. (One sample 3D surface plot consisted of 13,000 vectors.) Two \Special\ commands have been defined for graphics of this sort (and specialized commands for more complicated graphic elements will be defined in the future). The commands defined are: \begin{description} \item[\tt X\_linewidth $n$] Specify that the following vector is to be drawn with a line width of $n$ \DVI\ units (scaled points for \TeX). Vectors are normally 1~point in width. If no vector follows the \verb+X_linewidth+ \Special\ on this page, the command is ignored and the \DVI\ driver program should issue a warning. \item[\tt X\_vec $\Delta x$ $\Delta y$] Draw a diagonal line from the current point to the point which is offset by $\Delta x$ and $\Delta y$ from the current point. $\Delta x$ and $\Delta y$ are specified in terms of \DVI\ units. \end{description} \subsubsection*{Graphics by \MF} A different approach to graphics inclusion is to use \MF\ to produce the graphic as a character of a font and position it using \TeX's normal character positioning capabilities. The advantage of this technique is that the graphic is in a format which many drivers will already accept. METAPLOT by Pat Wilcox\footnote{See the Amiga\TeX\ notes of March~12, 1989 or \TeXMaG~{\bf3}(3) for information about this package.} is one example of a package which takes this approach. However, the technique has a number of drawbacks: Graphic fonts are resolution-dependent; a separate graphic font is needed for different resolution devices. \MF\ records changes in pixel values across a scan line when it builds a character. Thus, the memory needs depend upon the complexity of the graphic in addition to the size and resolution of the device. To circumvent this limitation, it is necessary to break the whole graphic into smaller pieces. It is important to ensure that the heights and widths of each piece are integral numbers of pixels to allow them to be reassembled without the alignment problems which occur for letters within words. \subsubsection*{Including device-dependent files} With this approach, the \DVI\ driver processes a special Graphics Description File (\GDF) which, among other things, indicates the names and formats of separate graphic files in device-dependent format. A driver searches this list to find a file in a format appropriate for the device it supports. This allows a greatly simplified graphic files to be defined for previewing purposes while a detailed, higher resolution version is used when the \DVI\ file is printed. \GDF\ files are processed both by \TeX\ and by the \DVI\ driver. \TeX\ \verb+\input+s the file and executes code at the start of the file. This code sets some dimension and box registers giving the size of the graphic then terminates with an \verb+\endinput+ to return control to the macro which did the \verb+\input+. The portion of the \GDF\ file following the \verb+\endinput+ is processed by the driver. The driver section of the file consists of a series of keywords which identify lines that apply to a particular graphics format, rotation, etc. The driver scans these lines searching for a format which it understands. Depending on the driver and the graphics format, additional lines may have to be searched for other attributes such as rotation. Eventually, the name of the graphics file to be included will be found and the driver will incorporate it into the output file. In {\it TUGboat\/}~{\bf10}(1), Bart Childs, Alan Stolleis, and Don Berryman suggested another scheme for using \Special\ for inclusion of device-dependent graphics files in ``A portable graphics inclusion.'' % Section removed at Tom Reid's suggestion since most of it has yet % to be discussed in depth on driv-l. %\subsection{Miscellaneous commands} %In addition to the commands listed above, the following miscellaneous %\Special\ commands have been proposed: %\begin{description} %\item[\tt X\_duplex] Specifies that printing is to be on both sides % of the sheet. This can be either a global or a page command. % If it is a page command, it causes the following page to be % printed on the back of the current page. %\item[\tt X\_landscape] Specifies that printing is to be done in % landscape (as opposed to portrait) style. This can be either % a global or a page command. %\item[\tt X\_portrait] Specifies that printing is to be done in portrait % style. This can be either a global or a page command. %\item[\tt X\_rotate $n$] Rotate the current box by $65536n^\circ$. % Conversion of traditional units such as degrees and radians % is easily accomplished through \TeX\ macros. This is a closed % block command. %\item[\tt X\_simplex] Specifies that printing is to be on one side of % the sheet. This can be either a global or a page command. % If it is a page command and the \Special\ occurs on a page % that would be printed on the % front side of the sheet then the current page is printed % simplex; if the \Special\ occurs on a page that would occur on % the back side of a sheet, a blank page is printed on the back % side of that sheet and the current page is then printed % simplex.\footnote{This seemingly complex scheme prevents % drivers from needing to scan more than a page at a time.} %\end{description} %Additional macros will be defined as more discussion on the topic %transpires. % \section{Additional reference material} In addition to the works mentioned in the Editor's note at the end of our last report, the following may also be of interest: \begin{itemize} \item Guntermann, Klaus and Joachim Schrod. ``High quality \DVI\ drivers'' Available from the Clarkson archive as the file {\tt schrod-}\discretionary{}{}{} {\tt guntermann1.tex} \item Hosek, Don. ``Proposed \DVI\ \Special\ command standard'' Available from the Clarkson archive as the file {\tt hosek1.tex}. \end{itemize} In addition, anyone interested in implementing any portion of the developing standard should read the logs available from the Clarkson archive or {\tt Listserv@tamvm1}. \end{document}