summaryrefslogtreecommitdiff
path: root/dviware/driv-standard/papers/draft-8907-tub.tex
diff options
context:
space:
mode:
authorNorbert Preining <norbert@preining.info>2019-09-02 13:46:59 +0900
committerNorbert Preining <norbert@preining.info>2019-09-02 13:46:59 +0900
commite0c6872cf40896c7be36b11dcc744620f10adf1d (patch)
tree60335e10d2f4354b0674ec22d7b53f0f8abee672 /dviware/driv-standard/papers/draft-8907-tub.tex
Initial commit
Diffstat (limited to 'dviware/driv-standard/papers/draft-8907-tub.tex')
-rw-r--r--dviware/driv-standard/papers/draft-8907-tub.tex434
1 files changed, 434 insertions, 0 deletions
diff --git a/dviware/driv-standard/papers/draft-8907-tub.tex b/dviware/driv-standard/papers/draft-8907-tub.tex
new file mode 100644
index 0000000000..38a424d7e6
--- /dev/null
+++ b/dviware/driv-standard/papers/draft-8907-tub.tex
@@ -0,0 +1,434 @@
+% 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 <xitijsch@ddathd21.bitnet> 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}