% -*-LaTeX-*- %/u/sy/beebe/tex/ndvi/doc/dvistatus.ltx, Tue May 30 16:18:20 1989 %Edit by Nelson H.F. Beebe % Second edition % DVISTATUS.LTX.52, 12-Oct-88 22:24:57, Edit by BEEBE % First edition %------------------------------------------------------------------------ % EVERYTHING TO THE RIGHT OF A % IS A REMARK TO YOU AND IS IGNORED BY % LaTeX. % % WARNING! DO NOT TYPE ANY OF THE FOLLOWING 10 CHARACTERS AS NORMAL TEXT % CHARACTERS: % & $ # % _ { } ^ ~ \ % % The following seven are printed by typing a backslash in front of them: % \$ \& \# \% \_ \{ and \}. %------------------------------------------------------------------------ \documentstyle[dvidriver]{article} \makeunderscoreletter % used in file names; don't need subscripts \newcommand{\INDEX}[2]{} % no indexing here \newcommand{\HOST}[1]{{\sf #1}} \newcommand{\PGM}[1]{{\sf #1}} \hbadness = 10000 % don't complain about underfull boxes \title{\protect\TeX{} DVI Driver Family Status} \author{Nelson H.F. Beebe\\ Center for Scientific Computing\\ Department of Mathematics\\ 220 South Physics Building\\ University of Utah\\ Salt Lake City, UT 84112\\ USA\\ \medskip Tel: (801) 581-5254\\ \medskip EMAIL: Beebe@Science.Utah.Edu (Internet) } \date{Second Edition, 01 July 1989} \begin{document} \maketitle \section{Introduction} This document summarizes the status of the \TeX{} DVI driver family distribution. It describes \begin{itemize} \item the current versions of documentation and software; \item what operating systems, compilers, and output devices are supported; \item how to obtain the distribution from Utah and several other sources; \item the DVI electronic newsletter, and \item work in progress. \end{itemize} Since the informal announcement of this software at the 1986 \TeX{} Users Group meeting at Tufts University and the formal announcement in the April 1987 TUGboat, demand has exploded; the author estimates that over 1000 sites in 28 countries are now running this software. Our initial attempts at providing the software for free, or in return for a donation, proved economically infeasible (we ran seriously in the red), and consequently, a fixed distribution charge was instituted in the spring of 1988. The burden of exact cost accounting for each order would be too great to manage; a fixed fee results in some being subsidized at the expense of others, but not excessively so. The distribution tapes contain not only the driver family, but also an extensive collection of Computer Modern fonts (itself requiring over 100 hr of DEC-20/60 time to generate), additional \TeX{}-related support software, and for \VAX{} \VMS{}, the latest GNU Emacs release, so it remains a bargain. Since the driver family is in the public domain, those who obtain distributions may freely re-distribute what they get. Local user groups are encouraged to share the software; we are doing this on a national scale in Poland. In the interests of the end users, however, it must be recognized that this is an active software development project, and periodically returning to the source at Utah, or one of the official redistribution channels, should be rewarding. \section{Documentation} Documentation for the \TeX{} DVI driver family was last updated 15 April 1987 for Revision 2.07; it is now slightly out-of-date, and will be updated for release 3.0. It consists of \begin{itemize} \item a large manual entitled {\em A \TeX{} DVI Driver Family\/} contained in source files \FN{dvidriver.*} intended for people who are installing the family on a new operating system, or adding support for a new device; it need not be read by people who just use the drivers; \item a \UNIX{} manual page file, \FN{dvi.1l}; \item a \VAX{} \VMS{} help file, \FN{dvi.vms}; \item a GNU and \TOPS{} Emacs info file, \FN{dviman2}; \item a GNU Emacs \TeX{}info file, \FN{dviman2.texinfo}, used to produce the previous info file; and \item a \LaTeX{} document, \FN{dviman.ltx}, that prints in a similar style to a \UNIX{} manual page. \end{itemize} \noindent% The last five contain essentially the same information, but in different formats. They are intended to provide end-user documentation, with details of what drivers are available, how to run them, and what command-line options are available. \section{DVI Driver Versions} The version history of the family is given in Table~\ref{version}. Starting with 2.10.12, an edit number will be appended to the major and minor version numbers; edit number 12 reflects 12 edits applied since 2.10(.00) was released. Major versions will appear at long intervals. Minor versions will appear every few months, and will generally add new drivers or new operating system support. Edits fix small bugs, or make small cosmetic changes that improve the user interface. \begin{table}[thb] \caption{Version history (reverse chronological order).}\label{version} \begin{center} \begin{tabular}{|ll|} \hline 3.00 & [??-???-89] \\ 2.10.12 & [01-Sep-88] \\ 2.10 & [01-Nov-87] \\ 2.09 & [23-Sep-87] \\ 2.08 & [15-Aug-87] \\ 2.07 & [15-Apr-87] \\ 2.06 & [1986-1987] \\ \hline \end{tabular} \end{center} \end{table} \begin{quotation} \bf \noindent Note: Version 2.10 incorporated a major rewrite of \PGM{dvialw} and \PGM{dvijep}, the two most popular drivers, to make much better use of the limited memory on the laser printers, and to permit arbitrary numbers and sizes of fonts. Users running older versions are urged to update to 2.10 or later. \end{quotation} \section{Host Operating Systems and Compilers} The operating systems supported are given in Table~\ref{os}. The drivers will port to almost any other \UNIX{} system not listed in the table with relatively little effort. \begin{table}[thb] \caption{Operating systems supported.}\label{os} \begin{center} \begin{tabular}{|ll|} \hline Operating System & Compiler(s) \\ \hline Gould \UNIX{} & \PGM{cc} \\ Sun \UNIX{} & \PGM{cc}, \PGM{gcc} \\ Hewlett-Packard \UNIX{} & \PGM{cc}\\ \PCDOS{} & Microsoft C 3, 4, 5 \PGM{cl}\\ \TOPS{} & \PGM{kcc-20}, \PGM{pcc-20}\\ \VAX{} \UNIX{} & \PGM{cc}, \PGM{gcc}\\ \VAX{} \VMS{} & \PGM{cc}, \PGM{gcc}\\ \hline \end{tabular} \end{center} \end{table} On \PCDOS{}, only the Microsoft C compilers have so far been found usable. Microsoft C 5.1 has been tried and found unusable because it permanently predefines the ANSI C macro \CN{__STDC__} to be 0 instead of 1. Borland Turbo C 1.5 is definitely {\em not\/} usable for the DVI drivers because of completely erroneous floating-point code generation. Turbo C 2.0 resolves the floating-point problems, and in November, 1988, I developed work-arounds for several new bugs in the compiler and the library. For programs that have no floating-point code, I have found Turbo C 1.5 quite usable; it compiles about 5--7 times faster than the Microsoft C 5.0 compiler. Version 2.0 remains as fast, but examination of the assembly code generated for the string primitives shows that, when optimization is selected in both compilers, the Microsoft C compiler produces substantially better object code. In the large memory model required for the DVI drivers, the inner loops for \CF{strchr} and \CF{strrchr} have 11 instructions each with Turbo C 2.0 when the \CN{-O} option is chosen, and 5 and 7 respectively with Microsoft C 5.0 with \CN{-Oailt}. \PGM{gcc} is the GNU Project C compiler, which generates code for at least these architectures: \begin{itemize} \item Alliant FX/8, \item Altos 3068, \item Convex C1 and C2, \item Intel 386 (Compaq 386, Sequent 386, Sun 386i), \item MIPS (MIPS and DECstation 3100), \item Motorola 68xxx (Sun 2 and 3, HP 9000/300 and 320, AT\&T 3B1, Integrated Solutions, Sony NEWS, NeXT), \item Motorola 88000 (in progress), \item National Semiconductor 32xxx (Sequent, Encore, NS Genix), \item Sun SPARC (Sun 4 and Solbourne), and \item \VAX{} (\UNIX{} and \VMS{}). \end{itemize} \noindent% That is a remarkable record surpassed only by \PGM{pcc}, but that was never available for diverse systems from one set of master sources. \PGM{gcc} is also {\em free\/}. On the Sun 3, it produces code about 10\% more compact, and 10\% faster than the native Sun \PGM{cc} compiler at Sun OS 3.x; Sun \PGM{cc} produces better floating-point code than \PGM{gcc} at Sun OS 4.0. \PGM{gcc} is the standard C compiler on the NeXT workstation. Due to code generation errors, neither Sun \PGM{cc} nor \PGM{gcc} % compile the drivers correctly on the Sun 386i under \UNIX{}; under 386i DOS, the Microsoft and Borland compilers produce working drivers. Version 3.0 is expected to add support for the operating systems in Table~\ref{new-os}. These are not in the 2.10 distribution, but once 3.0 development has stabilized, pre-releases from the development directories may be made available by special arrangement on tape or for ANONYMOUS FTP; IBM PC floppy distributions will not be offered. Contact the author for details and current status. \begin{table}[thb] \caption{New operating systems supported.}\label{new-os} \begin{center} \begin{tabular}{|ll|} \hline Vendor & Operating System \\ \hline Acorn & Archimedes \\ IBM & VM/CMS \\ Intel & RMX \\ Prime & Primos \\ \hline \end{tabular} \end{center} \end{table} \section{Output Devices Supported} Devices supported by the \TeX{} DVI driver family at version 2.10 are given in Table~\ref{devices}. The \PGM{dvitype} program is not strictly part of the distribution; it should be a standard part of every \TeX{} distribution. Similarly, there are programs \PGM{dvitty} and \PGM{dvidoc} which attempt to display DVI files on ASCII printers and terminals; they are included in the tape and ANONYMOUS FTP distributions, but are not members of the family. \begin{table}[thb] \caption{Supported output devices.}\label{devices} \begin{center} \begin{tabular}{|lp{3in}|} \hline Program & Output Device \\ \hline \PGM{dvialw} & \POSTSCRIPT{} (Apple LaserWriter) \\ \PGM{dvibit} & Version 3.10 BBN BitGraph terminal \\ \PGM{dvica2} & Canon LBP-8 A2 laser printer (fast experimental version) \\ \PGM{dvican} & Canon LBP-8 A2 laser printer \\ \PGM{dvidla} & DEC LA50 144 $\times$ 72dpi and LA75 144 dpi printers \\ \PGM{dvieps} & Epson 9-pin family 60/72 and 240/216 dpi matrix printer\\ \PGM{dviimp} & Imagen imPRESS-language laser printer family \\ \PGM{dvijep} & Hewlett-Packard LaserJet Plus \\ \PGM{dvijet} & Hewlett-Packard LaserJet \\ \PGM{dvil3p} & DEC LN03 Plus laser printer \\ \PGM{dvimac} & Apple Imagewriter 72 and 144 dpi printer \\ \PGM{dvimpi} & MPI Sprinter 72 dpi printer \\ \PGM{dvioki} & OKIDATA Pacemark 2410 72 and 144 dpi printer \\ \PGM{dviprx} & Printronix 60h $\times$ 72v dpi printer \\ \PGM{dvitos} & Toshiba P-1351 180 dpi printer \\ \PGM{dvityp} or \PGM{dvitype} & DVI Translator for human-readable output \\ \hline \end{tabular} \end{center} \end{table} New devices for which support should be available in 3.0 are given in Table~\ref{new-devices}. \begin{table}[thb] \caption{New device drivers scheduled for future release. Names are subject to change before final release.}\label{new-devices} \begin{center} \begin{tabular}{|lp{3in}|} \hline Program & Output Device \\ \hline \PGM{dviadx} & Anadex Silent Scribe 72 and 144 dpi dot matrix printer\\ \PGM{dviapo} & Apollo screen display previewer\\ \PGM{dvicon} & IBM RT 6150 and 6155 console previewer\\ \PGM{dvidsk} & Hewlett-Packard DeskJet 300 dpi ink jet printer\\ \PGM{dvielq} & Epson LQ 24-pin family 180 dpi dot matrix printer\\ \PGM{dviep2} & Epson 9-pin family 120/216 dpi dot matrix printer\\ \PGM{dvifuj} & Fujitsu DL2400 24-pin 180 dpi dot matrix printer\\ \PGM{dvigp} & Phillips GP 72 dpi and 144 dpi dot matrix printer\\ \PGM{dvihl8} & Brother HL-8 with brain-damaged Hewlett-Packard LaserJet emulation\\ \PGM{dviibm} & IBM 4202 120 dpi dot matrix printer\\ \PGM{dvilzr} & Data Products laser printers (1230 and 1260) with brain-damaged Hewlett-Packard LaserJet emulation\\ \PGM{dvio92} & OKIDATA 192 72 and 144 dpi dot matrix printer\\ \PGM{dvisun} & Sun Windows screen display previewer\\ \PGM{dviupc} & AT\&T \UNIX{} PC screen display previewer\\ \PGM{dvivga} & IBM PC VGA display previewer\\ \hline \end{tabular} \end{center} \end{table} In addition, the \TOPS{} \POSTSCRIPT{} spooler program, \FN{lw78.c}, has now been ported to \UNIX{}. \section{DVI Driver Distribution} Distributions of the DVI driver family are available from a number of sources; they are described in this section. The master files reside on the author's main host machine, \HOST{science.\-utah.\-edu}, a DEC-20/60 TOPS-20 system. ANONYMOUS FTP (any password) to that machine can retrieve the file \FN{00readme.\-txt} which tells how to find the DVI distribution, and much else, on local machines. Distribution formats of individual files, compressed \UNIX{} \PGM{tar} files, and \IBMPC{} \FN{.arc} files are available on \HOST{science.\-utah.\-edu}. It is important to read the \FN{00readme.\-txt} file carefully and follow its instructions about what files to retrieve, and how; otherwise you risk getting corrupted, or incomplete, data. \VAX{} \VMS{} \PGM{backup} save sets of the DVI family, Computer Modern fonts, a \POSTSCRIPT{} printer spooler, and several \TeX{}-related programs are available on \HOST{ctrsci.\-utah.\-edu}, a \VAX{} 8600 running \VMS{} 4.4, where again a \FN{00readme.\-txt} file gives retrieval details. The ANONYMOUS FTP password is {\em GUEST\/}; no other string will be accepted. Distribution from Utah must be requested in writing, by postal mail to \begin{verse} \TeX{} DVI Driver Distribution\\ Center for Scientific Computing\\ Department of Mathematics\\ 220 South Physics Building\\ University of Utah\\ Salt Lake City, UT 84112\\ USA \end{verse} or by electronic mail to \HOST{dvi-request@\-science.\-utah.\-edu} or the author, or by FAX to the telephone number (801) 581-4801. A telephone number and street address should be provided to facilitate resolution of questions, and delivery by express freight companies (who cannot deliver to postal boxes). Telephone orders will be accepted only in unusual circumstances. Nine-track tape (1600 bpi, and for \VMS{} only, 6250 bpi), Sun $1/4in$ cartridge tape, and IBM PC floppy distributions are available from Utah for a fixed US\$100 charge, which includes documentation, media, and shipping. Shipping is by UPS ground service within the lower 48 states, or airmail to Alaska, Hawaii, and international destinations. Do {\em not\/} send tapes or floppies with your request. Prepayment in checks drawn on a US bank, or international postal money orders, is preferred because it reduces paperwork. Purchase orders will be accepted when prepayment is not possible; an invoice will accompany the shipment. Faster shipment by UPS, DHL, Federal Express or Airborne Express is possible by special arrangement, {\em provided our local staff has the time to handle the order}. It carries a surcharge equal to the approximate freight charges; prepaid or collect shipments should be used. We try to fill orders within one to two weeks of receipt, but it sometimes takes longer because of our local responsibilities, or because an order is missing information, like tape format and density, that we need before it can be completed. Distributions are available from the following other channels; allow up to 2 months after release of new versions for these to be available. All of these are volunteers, and have full-time commitments elsewhere. They are updated by net distribution where possible, but it still takes them some effort for them to incorporate the changes in their local distribution mechanism. \begin{quote} Peter Abbott\\ Aston University\\ Computing Services\\ Aston Triangle\\ Birmingham B47 ET\\ England\\ Email: {\small \HOST{AbbottP\%uk.ac.aston.mail\%uk.ac.rl.gb@nss.cs.ucl.ac.uk}}\\ or\\ Email: {\small \HOST{PAbbott@nss.cs.ucl.ac.uk}}\\ {}[only net retrieval]\\ \medskip Massimo Calvani\\ Department of Astronomy\\ University of Padova\\ Vicolo dell'Osservatorio\\ 35122 Padova\\ Italy\\ Email: {\small \HOST{Calvani\%vaxfpd.infnet\%iboinfn.bitnet@cunyvm.cuny.edu}}\\ {}[only net retrieval]\\ \medskip Lance Carnes\\ Personal \TeX, Inc.\\ 12 Madrona Ave\\ Mill Valley, CA 94941\\ Email: {\small \HOST{"well!pti"@lll-lcc.arpa}}\\ {}[only \IBMPC{} floppies]\\ \medskip Edgar M. Cooke\\ Software Research Assoc. Inc.\\ 1-1-1 Hirakawa-cho\\ Chiyoda-ku\\ Tokyo 102\\ Japan\\ Email: {\small \HOST{kddlab!srava.sra.junet!cooke@uunet.uu.net}}\\ {}[only net retrieval]\\ \medskip Richard J. Kinch\\ Kinch Computer Co.\\ 501 S Meadow St\\ Ithaca, NY 14850\\ Email: {\small \HOST{-unknown-}}\\ {}[only \IBMPC{} floppies]\\ \medskip Mark Kosten\\ LaTrobe University\\ Bundoora, Victoria\\ Australia\\ Email: {\small \HOST{"munnari!latvax8.lat.oz.au!ccmk"@uunet.uu.net}}\\ {}[net retrieval and tape distribution]\\ \medskip Joachim Lammarsch\\ Universit\"{a}t Heidelberg\\ Rechenzentrum - Im Neuenheimer Feld 293\\ Heidelberg 6900\\ West Germany\\ Email: {\small \HOST{\$rz92\%dhdurz1.bitnet@cunyvm.cuny.edu}}\\ {}[only net retrieval]\\ \medskip Jon Radel\\ P. O. Box 2276\\ Reston, VA 22090\\ U.S.A.\\ Email: {\small \HOST{jonradel\%icecream.princeton.edu@princeton.edu}}\\ {}[only \IBMPC{} floppies]\\ \end{quote} We would prefer that \IBMPC{} floppy distributions be handled through Personal \TeX{} or Jon Radel; their prices are also lower. Preparation of floppies takes substantial personal time for the author which would be better spent on other activities. \section{Electronic Newsletter} A network mailing list is maintained for the issuance of newsletters; there were 285 subscribers on 29 May 1989. Requests for addition or deletion should be sent to the author at the address on the first page of this document. Users on any network reachable from the Internet can be included; that includes at least Arpanet, CSnet, MILnet, NSFnet, and SPAN (mainly US), Bitnet (US, Canada, and Europe), NetNorth (Canada), EARNnet (Europe), JUNET (Japan), Janet (Britain), Usenet (worldwide), and national university nets in Australia and New Zealand. A total of 19 newsletter issues have so far appeared. Back issues are included in all DVI distributions as the files \FN{00mail.*}. Regrettably, local staffing and funding do not permit postal mailings of the newsletter; if there is a demand for it, and subscribers are willing to pay for it, it could be arranged in the future. There is a smaller related electronic list for beta testing of a powerful \LaTeX{} editing mode in GNU Emacs; this will probably become part of the standard GNU Emacs distribution in 1989. It contains many useful functions, and recognizes {\em every\/} macro in the {\em \LaTeX{} User's Guide and Reference Manual}. Send requests for addition to the list to the author at the same address as for the newsletter. The code is also included in the \VAX{} \VMS{} distribution tapes in the file \FN{[.emacs-18-52\-.lisp]latex-mode\-.el}. \section{Future Directions} {\bf NB: Anything discussed in this section is subject to possibly substantial changes.} Source release of the 3.0 development is still many months off in the future; changes are still frequent, and a premature release would open a horrendous bag of worms that would make management of the development beyond my limited resources. Every time I have attempted to predict when a piece of software would be complete, I have been wrong, so I shall not attempt to set any date for the version 3.0 release. Here is a summary of new features in the 3.0 development: \begin{itemize} \item For devices which require page bitmaps, the bitmaps are constructed in strips with multiple passes through the commands for the current page in the DVI file. The amount of memory to be used for a bitmap strip is set to a default value, but the value may be changed by a command-line option. This removes the need to limit the printable page size that existed in earlier versions on small machines, particularly the \IBMPC{}. \item File search paths are supported for all supported operating systems. A separate search path, \CN{DVIINPUTS}, is provided for startup files, \POSTSCRIPT{} header files, and files required by \verb|\special{}| commands. It defaults to the same value as \CN{TEXINPUTS}, so normally, it need not be specified. \item Font file names are constructed from a format that may be set at run-time in the \CN{FONTFMT} environment variable, and that variable can specify several name formats. This generalizes, and replaces, the \CN{FONTLIST} variable used in earlier versions. \item A new font file encoding, Group 4 FAX, implemented by Michael Ferguson and colleagues at INRS Telecommunications in Montr\'{e}al, has been added. This is even more compact than \CN{PK} format, and will be referred to as \CN{FX4} format. A utility for converting from \CN{GF} or \CN{PK} formats to \CN{FX4} format is provided. \item \verb|\special{}| strings of arbitrary length are supported. Although the \TeX{} input buffer size typically limits input strings to about 500 characters, macro-generated strings can be larger. \item NUL characters in \verb|\special{}| strings are supported. In C, such characters terminate strings by default, so extra processing is necessary to avoid such truncations. \item Support for Wizard C on \PCDOS{} has been replaced by support for its descendant, Borland Turbo C 2.0 or later. \item On most systems, the operating system and compiler can now be determined automatically, eliminating the need to edit \FN{machdefs.h}. This is supported by a new header file, \FN{os.h}. \item ANSI C is the standard programming language. Header files \FN{stdlib.h}, \FN{stddef.h}, and \FN{unixlib.h}, and several string utilities \FN{str*.c}, support the illusion of an ANSI environment on pre-ANSI C systems. \item \begin{sloppy} Dependency lists in makefiles are now generated automatically by a \UNIX{} script, \PGM{FIX\-MAKE\-FILES}, which uses a script, \PGM{fixmf}, plus \PGM{nawk} (using files \FN{include*.\-awk}), and \PGM{sed}. This greatly facilitates makefile updating when the source files are often changing, and ensures that dependencies are always correct. \end{sloppy} \item \begin{sloppy} Handling of font magnifications has been revised by elimination of the floating-point \CN{mag_table[]} array from \FN{gblvars.h}, and its replacement by an integer table, \CN{stdmag[]}, in \FN{stdmag.h}. That file is automatically generated by \FN{genmag.c}. The contents of \CN{stdmag[]} can be replaced at compile-time, or at run-time, by definitions of the environment variable \CN{FONTMAGS}. Revised code in \FN{openfont.h} will now find the closest matching magnification when font substitution is called for; previously, the \CN{mag_table[]} mechanism required an exact match, making it awkward to support magnification families that were not already represented in the \CN{mag_table[]} array. \end{sloppy} \item Environment variable handling and naming has been standardized across all operating systems, and the names are now set in the preprocessor macros, \CN{ENV_xxx}, in \FN{machdefs.h}. \item \CN{FASTZERO} and \CF{zerom} have been eliminated in favor of an implementation of the ANSI library routine, \CF{memset}, where required. \item Paper dimensions no longer are fixed in the \FN{dvixxx.c} files. Instead, a general, programmable, and easily-extendable, mechanism for specification of paper characteristics has been implemented in \FN{paper.c}. A list of all the standard paper sizes I could find is present in \FN{paper.dat}, and the more popular ones have been extracted and stored as initializing values for \CN{stdform[]} in \FN{gblvars.h}. \FN{gensiz.c} can be used to generate much of \FN{paper.dat}. \item A startup file, \FN{dvi.ini}, is read in \FN{initglob.h} and options found there are parsed by \CF{fileargs} in \FN{filarg.c} and then set by calls to \CF{option}. After processing that file, driver \PGM{dvixxx} then does the same thing with \FN{dvixxx.ini}. Both files are looked for in the \CN{DVIINPUTS} search path; neither file need exist. This makes it simple to have private values of options that are used regularly, without having to specify them on the command line. It also makes it possible to get around operating system limitations on command line arguments, and environment variable syntax. The reason for having two initialization files is that some things, like paper types, can be defined for all drivers in one file, \FN{dvi.ini}. The \FN{dvixxx.ini} file can then provide modifications specific to one output device. \item Private and library functions that are \CN{void} are no longer typecast as \CN{(void)} when called; some compilers (e.g. Lattice C on IBM PC and VM/CMS, and Prime compilers) erroneously flag this as an error. \item \begin{sloppy} \CF{exit} is called with the ANSI standard arguments \CN{EXIT_SUCCESS} and \CN{EXIT_FAILURE}, instead of 0 and 1. \VAX{} \VMS{} unnecessarily changed the interpretation of \CF{exit}'s arguments, and the ANSI committee had to support it. The private version, \CF{EXIT}, is no longer used in the DVI drivers. \end{sloppy} \item All \CF{main} functions are declared of type \CN{int}, and return \CN{EXIT_SUCCESS} or \CN{EXIT_FAILURE}. \item \FN{texidx.c} has been fixed to correctly handle out-of-core sorting. \item \CF{qsort} and \FN{qsort.c} (used in \PGM{texidx}) has been renamed \CF{shsort} and \FN{shsort.c}, avoiding conflicts with library functions of the same name, and more properly describing the underlying algorithm (shellsort, instead of quicksort). Shellsort is stable, whereas quicksort is not, and a stable sort is required for correct ordering of index subfields. \item \begin{sloppy} Memory allocation and freeing is now handled in the DVI driver code by \FN{xalloc.c}, which contains functions \CF{xmalloc}, \CF{xcalloc}, \CF{xmemused}, \CF{xrealloc}, and \CF{xfree}. These provide work-arounds for some deficiencies in existing \CF{malloc}/\CF{free} implementations, additionally keep a record of memory utilitization, and provide for debug tracing of memory usage. The \CF{x*alloc} functions do not return when memory is exhausted, removing the necessity for checking function return values in their callers; in the rare event that recovery is possible in such a case, \CF{malloc} can still be called. \end{sloppy} \item A new preprocessor symbol, \CN{DVI}, is defined at compile time; it is used in a few routines that are separately compiled, and need to know whether they are being used in the DVI drivers, or in other code. \item A new preprocessor symbol, \CN{TEST}, is used in some files to bracket built-in test code with a \CF{main} function. This avoids having to carry around a second file that serves as a test program. \FN{filarg.c}, \FN{paper.c}, and \FN{xalloc.c} currently use this facility. \item When a font substitution is made, a Boolean flag, \CN{substitute}, is now set in the \CN{font_entry} structure. In \FN{prtpage.h}, when that flag is set, \CF{setchar} is called instead of \CF{setstr}, so that single characters are set at a time, rather than strings of characters. This will improve the positioning of substituted characters. \item Ten new device drivers have been added: \PGM{dviadx}, \PGM{dvidsk}, \PGM{dvielq}, \PGM{dviep2}, \PGM{dvigp}, \PGM{dvihl8}, \PGM{dviibm}, \PGM{dvilzr}, \PGM{dvisun}, and \PGM{dviupc}. One driver, \PGM{dvigd}, has been deleted. The drivers \PGM{dvi*72} have been dropped; they can be produced by compiling the corresponding high-resolution versions with \CN{HIRES} undefined. This change reduces the amount of code to be maintained; in most cases, users will prefer the higher resolution version anyway, so that is the default. \item \begin{sloppy} Documentation files have been updated, and a new file, \FN{doc/\-dvistatus.\-ltx} (whose output you are now reading), will be kept up-to-date as a record of the current status of the DVI family. \end{sloppy} \item The definition of \CF{PIXROUND} in \FN{gendef.h} has been corrected; it was wrong for negative arguments, and would result in one-dot positioning errors. \item Support for the IBM VM/CMS operating system has been added, using the Waterloo C compiler. Since the character set is EBCDIC, rather than ASCII, this entailed a redesign of how character string output is handled. The output files created always contain ASCII text, so this means that all text characters, but not binary data, must go through EBCDIC to ASCII translation. This has been done in such a way as to avoid any extra overhead on a native ASCII host. The non-ASCII support also serves on Prime Primos, which uses an ASCII character set biased by 128. \item \begin{sloppy} References to the preprocessor symbols \CN{FIRSTPXLCHAR} and \CN{LASTPXLCHAR} everywhere except in \FN{charpxl.h}, \FN{gendefs.h}, and \FN{readpxl.h} have been replaced by \CN{FIRSTFONTCHAR} and \CN{LASTFONTCHAR}, which correctly reflect the range 0\ldots{}255; \FN{PXL} format fonts remain restricted by their design to 0\ldots{}127. \end{sloppy} \item All uses of C type \CN{float} have been replaced by type \CN{double}. For \PGM{dvialw} in particular, this tends to ensure that identical coordinates are generated on different machines, at least to the precision they are output in. \item The \POSTSCRIPT{} header file, \FN{dvialw.ps}, has been extensively rewritten to remove device resolution dependence, and operators that conflict with the Adobe Encapsulated \POSTSCRIPT{} File (EPSF) guidelines. Uses of the \verb|bind| operator have also been removed in order to make it possible for \verb|\special{}| code to redefine operators at print time. \end{itemize} I have made substantial progress in enhancing the support for \verb|\special{}|. This work is currently being done with \PGM{dvialw}, but in such a way that it will be easy to generalize it to all other drivers. The first step needed in this direction is to define a grammar for what the \verb|\special{}| string looks like. Previously, most DVI drivers have defined this syntax completely {\em ad hoc}, with no thought to rigorous parsing, or to future extensions. Most of the following description is extracted from the comments in \PGM{dvialw}. The contents of the \TeX{} \verb|\special{}| command is expected to conform to a minilanguage in the same grammar as for paper specifications. The argument string should contain a series of assignment statements for one or more of the keywords given in Table~\ref{special-keywords}. \begin{table}[thb] \caption{{\tt \bs special\{\}} keywords.}\label{special-keywords} \begin{center} \begin{tabular}{|llp{2.3in}|} \hline Keyword & Value & Action\\ \hline graphics & string & execute the generic graphics primitives in string (not yet defined)\\ include & filename & insert file contents with relative page positioning\\ literal & string & insert literal \POSTSCRIPT{}\\ options & string & not yet defined\\ overlay & filename & insert file contents with absolute page positioning\\ \hline \end{tabular} \end{center} \end{table} \noindent% The order of these is not significant, except that if duplicate keywords are specified, the value of the last one is used. It is not necessary to supply a final newline in the strings or files; one will be provided automatically to ensure correct output. Literal \POSTSCRIPT{} code from a file or a literal string is expected to be well-behaved, and preferably, should conform to Adobe's EPSF format version 1.2 or later, and to Adobe's \POSTSCRIPT{} Document Structuring Conventions, version 2.0 or later. It may contain a \verb|showpage| (which is disabled temporarily here), but it should not contain any of the operators given in Table~\ref{bad-operators}. \begin{table}[thb] \caption{Deprecated \protect\POSTSCRIPT{} operators.}\label{bad-operators} \begin{center} \begin{tt} \begin{tabular}{|llll|} \hline banddevice & grestoreall & nulldevice & setpageparams\\ copypage & initclip & quit & setsccbatch\\ erasepage & initgraphics & renderbands & setscreen\\ exitserver & initmatrix & setdevice & settransfer\\ framedevice & note & setmatrix & {}\\ \hline \end{tabular} \end{tt} \end{center} \end{table} \noindent% If it does, erroneous output is virtually certain. While these commands could be disabled like \verb|showpage| is, Adobe's EPSF guidelines do not recommend doing so. The imported \POSTSCRIPT{} should write into its own dictionary if it needs to define objects. Because dictionary sizes must be specified when they are created, it is not possible to define a standard one in advance in the \verb|SB| (\verb|\special{}| begin) and \verb|SE| (\verb|\special{}| end) macros to protect from corruption of the dictionary, \verb|TeXdict|, used by \PGM{dvialw}. The language keyword should specify \verb|"PS"| or \verb|"PostScript"|; letter case does not matter. If any other non-empty value is found, the \verb|\special{}| command is ignored, since it presumably applies to some other output device, and control returns immediately. However, if no language keyword is given, we assume \POSTSCRIPT{}, and continue. Files specified by \verb|include| and \verb|overlay| keywords are searched for in the \CN{DVIINPUTS} path. In the common case of \verb|include "filename"|, the {\em upper-left\/} corner of the bounding box will be placed at the current point. The \POSTSCRIPT{} file must then contain (usually near the start) a comment of the form \begin{verbatim} %%BoundingBox: llx lly urx ury \end{verbatim} \noindent% specifying the bounding box lower-left and upper-right coordinates in standard \POSTSCRIPT{} units of big points (1/72 inch). Alternatively, if the comment \begin{verbatim} %%BoundingBox: (atend) \end{verbatim} \noindent% is found in the file, the last 4096 characters of the file will be searched to find a comment of the form: \begin{verbatim} %%BoundingBox: llx lly urx ury \end{verbatim} \noindent% In the case of \verb|overlay "filename"|, the \POSTSCRIPT{} file to be included will be mapped onto the page at precisely the coordinates it specifies, where the page origin is in the lower-left corner, $y$ increasing upward, $x$ increasing to the right. Any \verb|%%BoundingBox| specification is ignored, since it is not required for positioning. This option might be used to print an overlay page. For actions that are to be done on every page, such as printing a logo, or a string like {\em Draft\/} or {\em Company Confidential\/}, it is more efficient to redefine \verb|showpage| instead. If the \POSTSCRIPT{} file cannot be opened, or the \verb|\special{}| command string cannot be recognized, or for relative positioning, the bounding box cannot be determined, a warning message is issued and the \verb|\special{}| command is ignored. Any literal string, and the section of the \POSTSCRIPT{} file between the comment lines \begin{verbatim} %begin(plot) %end(plot) \end{verbatim} \noindent% or the entire file, if the \verb|%begin(plot)| comment cannot be found, is copied to the output file as \begin{verbatim} SB % filename (xcp-llx) (ycp-ury) translate % if relative positioning ...literal string... ...PostScript file contents... SE % filename \end{verbatim} \noindent% The \verb|SB| and \verb|SE| macros revert to standard \POSTSCRIPT{} units of big points, and bracket the inserted \POSTSCRIPT{} text with \verb|save| and \verb|restore| commands. The \verb|translate| command positions the (0,0) origin of the inserted \POSTSCRIPT{} such that the {\em upper-left\/} corner of the bounding box is at \TeX{}'s current point. For literal inserted \POSTSCRIPT{} without an \verb|include| or \verb|overlay| command, the origin is moved to \TeX{}'s current point. The \verb|save| and \verb|restore| in \verb|SB| and \verb|SE| ensure that the inserted \POSTSCRIPT{} code cannot change the environment existing before the \verb|\special{}|. Should it be necessary to do so (e.g. to remember things from one \verb|\special{}| to the next, or to redefine an operator, like \verb|showpage|), you should just output \verb|SE| followed by your \POSTSCRIPT{}, followed by another \verb|SB|. The intervening \POSTSCRIPT{} will then apply to \PGM{dvialw}'s private dictionary, \verb|TeXdict|. In order to support things like landscape mode, change bars, and grey shading, it is necessary to have paper dimensions, the bounding box size, and the current point available to inserted \POSTSCRIPT{} code. These are stored in the \POSTSCRIPT{} macros \verb|PaperHeight|, \verb|PaperWidth|, \verb|BoxHeight|, \verb|BoxWidth|, \verb|CurrentX|, and \verb|CurrentY| in the outer level dictionary, \verb|TeXdict|. \verb|PaperHeight| and \verb|PaperWidth| are set only once, at the beginning of the job. The other four are redefined before each \verb|SB| is output. Their values are all in standard \POSTSCRIPT{} units of big points, {\em not\/} pixels. For an \verb|overlay| command, the size of the bounding box will be the page size. The origin can be moved to the lower-left page corner by the \POSTSCRIPT{} sequence \begin{verbatim} CurrentX neg CurrentY neg translate \end{verbatim} \noindent% This is useful in order to obtain absolute page positioning, such as for a page logo overlay. The size of the bounding box in big points is saved in \POSTSCRIPT{} macros \verb|BoxWidth| and \verb|BoxHeight|. They can be used to perform geometric transformations on the included \POSTSCRIPT{}. For \verb|overlay "filename"|, they are set to the page size. Here are some examples: \begin{small} \hfuzz=10in %be quiet about overfull boxes here \begin{verbatim} % Display a picture with the upper-left corner at the current point \special{language "PostScript", include "pict.eps"} % Display a picture at its original absolute page position \special{language "PostScript", overlay "pict.eps"} % Use literal PostScript to draw a 1in box with lower-left corner at % TeX's current point \special{language "PostScript", literal " newpath 0 -72 translate % move origin from upper-left to lower-left 0 0 moveto 0 72 rlineto 72 0 rlineto 0 -72 rlineto -72 0 rlineto closepath 4 setlinewidth stroke showpage"} % Display a figure at half size \special{language "PostScript", literal "0.5 0.5 scale", include "pict.eps"} % Display the figure in landscape mode by rotating the coordinates % about the center of the bounding box \special{language "PostScript", literal "BoxWidth 2 div BoxHeight 2 div translate 90 rotate BoxWidth -2 div BoxHeight -2 div translate", include "pict.eps"} \end{verbatim} \end{small} Landscape mode for a complete document is properly handled by a paper type, and that is now working for \PGM{dvialw}. Landscape mode for a single page is tricky, because there is the question of which way to rotate the page, and how to support portrait mode page headers with a landscape mode table. The latter cannot be accomplished on most devices because of restrictions they impose. However, it is possible with \POSTSCRIPT{}, and I have a demonstration file that shows how to do it. \PGM{dvialw} has been revised to make it possible to output \POSTSCRIPT{} conforming to Adobe's EPSF specifications. To do this, each page must be independent of every other page, and for a job with downloaded fonts, this poses a very large overhead. Normally, fonts are not reloaded every page, but apart from this, the output \POSTSCRIPT{} follows the EPSF guidelines. In particular, none of the deprecated operators are used, and I have demonstrations that show that it is possible to incorporate \PGM{dvialw} output as input pictures that can be arbitrarily transformed. This can even be iterated to produce a figure showing a \TeX{} page inside a \TeX{} page inside a \TeX{} page inside a \ldots{}. \PGM{dvialw} has also been changed to remove almost all dependence on output device resolution. Now, only a single parameter sets the resolution in dots/inch. This should make it easy to extend to support \POSTSCRIPT{} printers of other resolutions, including the NeXT 400-dpi laser printer, and phototypesetters. With the assistance of in-line \POSTSCRIPT{} code, change bars proved to be easy to implement; I thought about how to do it one evening, wrote the code the next morning, and had it working almost immediately. The essential idea is to redefine the \POSTSCRIPT{} \verb|showpage| operator to handle completion of an open change bar at end-of-page, and provide for its continuation on the following page. From the user's point of view, change bars merely involve bracketing the changed text with \verb|\BeginChangeBar| and \verb|\EndChangeBar| macros; no restrictions whatever are placed on the intervening text. Grey shading proved harder to do, but the problem has now been solved. Because \POSTSCRIPT{} has an opaque painting model, it is impossible to draw the shading after text has been set, since the shading would replace the text. Drawing the shading first would be more convenient, since it could permit shading to be handled like change bars, and flow automatically across page boundaries. Instead, it is necessary in the \TeX{} code to place the text to be shaded in a box, then to calculate the box dimensions, output \POSTSCRIPT{} code to draw a grey box slightly larger than that, then output the box itself. The tricky part is to get both boxes correctly aligned. I have written \POSTSCRIPT{} macros that make it easy to take an input \POSTSCRIPT{} file and arbitrarily scale it to fit a rectangle of specified size. Here is an example that scales a figure to fit a half-size page: \begin{verbatim} \special{language = "PS", literal = "PageWidth 2 div PageHeight 2 div RESIZE", include = "spec8a.eps"} \end{verbatim} \noindent% The use of the predefined \verb|PageWidth| and \verb|PageHeight| values ensures that this will work correctly for any paper size. \FN{dvialw.ps} also contains a macro \verb|sx sy SCALE| to scale an input figure by factors \verb|sx| and \verb|sy| from its natural size. At INRS Telecommunications in Montr\'{e}al, Michael Ferguson has implemented \TeX{} macros that actually read the \POSTSCRIPT{} file to find the dimensions from the \verb|%%BoundingBox| comment, and then automatically compute the space needed for the figure, freeing the user of having to insert explicit \TeX{} spacing requests around a \verb|\special{}|. Those macros should be easily adaptable to this new \verb|\special{}| support code in \PGM{dvialw}. In order to deal with the fact that \verb|\special{}| code is not standardized, and each driver implementer has done it differently, it may be desirable to provide a run-time regular expression editing capability for \verb|\special{}| strings. This would add the not-insignificant code for regular expression parsing, which may require excessive memory. It would, however, make it fairly straightforward to provide built-in (and user-definable) support for syntaxes provided by other DVI drivers. No code to do this has yet been implemented, and it would probably be better instead to write a separate DVI-to-DVI filter to do the job. While such changes can obviously also be done in the original \TeX{} manuscript, DVI files have become a medium of documentation exchange on the Internet, and will often be processed on a system other than the one they were generated on. Most of the preceding remarks seem to be dependent upon \POSTSCRIPT{}, and indeed, features like change bar support seem to need the programmability of \POSTSCRIPT{}. What about ordinary graphics files? In the TUG DVI committee, we have been wrestling with this problem for many months. In May, 1989, I gave a talk in Paris on the topic of \TeX{} and graphics, where I discussed various possibilities. It is published in {\em Cahiers GUTenberg\/}, No. 2, Mai 1989, pp. 13--53. While simple pictures can be done (usually laboriously) with \TeX{} macros, \TeX{} memory limits put a very severe restriction on the complexity of pictures that can be handled, and \TeX{} is almost completely lacking in graphics primitives. Thus, handling of complex pictures seems destined to be relegated to requests in a \verb|\special{}| string. The problem is then to decide on a format that can be generated by graphics packages, produced by translation from popular graphics file formats (e.g.\ Tektronix and HPGL), and written by hand for simple cases. After long thought, my inclination is not to invent something new here, but instead to adopt a subset of \POSTSCRIPT{}. A subset is required to simplify the parser. \POSTSCRIPT{} is a stack-based extensible language, and parsing cannot be done correctly until {\em every\/} operator can be interpreted; some operators take variable numbers of arguments, and the stacks cannot be managed without knowing how many arguments an operator must consume. I have therefore modified my \PLOT{} graphics system to produce such a subset, and have produced a working parser for that subset in about 220 lines of code and 130 lines of comments. With planned extensions to the subset, it seems likely that an adequate parser may be around 1000 lines of code, which represents about 10\% of the current size of a typical DVI driver. Although \POSTSCRIPT{} has a large vocabulary, a subset of 20 operators is sufficient for most line graphing applications, and it should be possible to write the parser in such a way that a vector of pointers to functions can be provided by the caller, so that the same parsing code can be used by all the DVI drivers, with separate implementations of the primitives for different drivers. However, all of the bitmap device drivers could use essentially identical code, since in each case, the primitives merely have to be expanded into dots in a bitmap of known resolution. \end{document}