dhosek@euler.claremont.edu (Don Hosek) (05/29/91)
In article <1991May21.001321.28546@athena.mit.edu>, dquah@athena.mit.edu (Danny Quah) writes: > Is there a generally accepted mechanism by which one prints (on > non Postcript printers) dvi files that have been generated from > ..vf's? (The new TeX supports these.) The otherwise-excellent program > dvijep for example dies, looking for the relevant .pk files. > I apologize if this is in TeXfaq, I plowed through several > hundred articles and didn't see an FAQ list. > Please email unless you think there's general interest; I'm > happy to summarize if I get enough further queries. Perhaps the following should be added to the FAQ: it's a pair of excerpts from my paper being presented at the TUG meeting in July (for more information on the meeting, contact Charlotte Laurendeau, cvl@math.ams.com) -So, what are VF files anyway? First off, let's open up the acronym and point out \VF\ stands for: ``Virtual Fonts.'' There are some who would claim that this term is a little misleading in the context of other computer science technology and prefer the term ``Composite Fonts.'' As a non-computer scientist, I prefer to stick with the term ``Virtual Fonts'' myself, mostly because it matches the acronym better. Now that we have that formality out of the way, perhaps it is time to ask what it means for a font to be ``Virtual'' or ``Composite.'' In short, it means that what \TeX\ thinks is a single character is not necessarily a single character to the printer. Some \DVI\ drivers have had a limited version of this capability built into them by necessity: for example, many \DVI-to-HP LaserJet converters will map character codes to different positions (to allow for restrictions on permissible character codes on fonts) and will send larger characters as bitmapped graphics or ``tiled'' pieces of character. However, this capability was rarely within the control of the user.\footnote{Tom Reid's \TeXrox\ drivers came close to implementing some version of \VF\ support in its \ROXDEX\ files which at least allowed manual control over the mapping from \TeX\ character code/font combinations to Xerox character code/font combinations. However, this facility was not terribly robust and an early experiment in creating a Times Caps/Small Caps font revealed that the \TeXrox\ was expecting better behaved \ROXDEX\ files than I was creating: in particular, a given Xerox font could only be referenced from a single \TeX\ font in any \DVI\ file causing problems when the ten point Times Roman was accessed in both the Roman and Caps/Small Caps fonts. Tom Reid later adapted the program to support this sort of tinkering, but I had since left my beloved Xerox~8790.} With the \VF\ format, we have an opportunity to handle many useful features in a way that could be device-independent.\footnote{The current state of matters requires the ``could'' in the preceding sentence; Appendix~\ref{vfsupport} has details on precisely what is supported by the current software.} In fact, with \VF\ files, we find that not only can we handle remapping of fonts rather easily, we can build composite characters, not only by combining characters from the same or different fonts, but by mixing any elements which may appear in a \DVI\ file such as rules or \verb+\special+ commands as well. \section{But don't I need \TeX~3.0 to use \VF\ files?} No. Since \TeX\ generally doesn't know much more about a font than the amount of space that each character takes up, it isn't even aware of whether \VF\ files are used in a \TeX\ run. Support of \VF\ is left entirely up to the \DVI-to-output converter. Incidentally, I think that this is a big design flaw. Had \VF\ support been built into \TeX\ itself, \TeX\ would have become much more versatile. For example, the problem of hyphenating accented characters could have been eliminated once and for all since accented characters would have been able to have been built `on the fly.'' In addition, the ability to have arbitrary remapping of fonts when \TeX\ is run would have solved the notorious ``code page'' problem. However, since Knuth was in a hurry to finish \TeX~3.0, we'll forgive him this oversight. \section{Device drivers supporting \VF\ files} At the time of this writing, the following drivers were the only ones which I was aware of which supported \VF\ features:\footnote{Please be aware that any subjective comments in the list below are exclusively my opinion and are based on direct experience except where noted. I apologize for any inaccuracies.} \begin{itemize} \item ArborText drivers updated since 1990. Some drivers in the ArborText collection undergo infrequent revison (e.g., \dvixer) and so may not yet have this feature. However, since the \VF\ format is based on Arbortext's \XPL\ format for the DVIAPS driver, they have had a head start on implementing the features in their drivers. I have not used versions of these drivers containing \VF\ support. \item DVIPS by Tom Rokicki. This public domain \DVI-to-\PS\ converter is the first public domain driver supporting \VF\ to include source code. Also included with DVIPS is a program, AFM2TFM, written by Donald Knuth~\cite{knuthvf} and modified by Tom Rokicki, which uses \VF\ files in creating remapped versions of \PS\ fonts with support for ligatures and other convenient features. DVIPS runs on Unix, VMS and MS-DOS. \item The em\TeX\ drivers. These drivers, usually bundled with the public domain em\TeX\ for MS-DOS provide excellent functionality for the user, although I have never bothered with the font library support which seems cumbersome to me. \end{itemize} There are also two programs available for converting a \DVI\ file which contains references to \VF\ files into a \DVI\ file with the references expanded into ``clean'' code which could be translated by any \DVI\ processor. These are: \begin{itemize} \item DVIcopy by Peter Breitenlohner. MS-DOS, \unix, VM/CMS. \item DVIvfDVI by Wayne Sullivan. MS-DOS only. -- Don Hosek | To retrieve files from ymir via the mailserver, dhosek@ymir.claremont.edu | send a message to mailserv@ymir.claremont.edu Quixote Digital Typography | with a line saying send [DIRECTORY]FILENAME 714-625-0147 | where DIRECTORY is the FTP directory (sans ---------------------------+ "anonymous") and FILENAME is the filename, e.g. "send [tex]00readme.txt". There is a list of files in each directory under the name 00files.txt. Binary files are not available by this technique.