summaryrefslogtreecommitdiff
path: root/dviware/driv-standard/papers/draft-8907-tub.tex
blob: 38a424d7e6cce0c2d6b3b90511fac18492050c33 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
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}