[comp.text.tex] printing dvi files with virtual fonts

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.