\def\AFMtoTFM{\textsc{afm}to\textsc{tfm}}
\def\DP{\textsc{dvips}}
\def\DPONE{\textsc{dvipsone}}
\def\AF{\textsc{afm2tfm}}

\title{Do you \textbf{really} need virtual fonts?}
\author[Berthold Horn]{Berthold Horn \\Y\&Y \texttt{71172.524@compuserve.com}}
\begin{Article}

\subsection*{Introduction}
Since many people feel very strongly about these issues, 
I'll need to go into some detail to try and sway their opinion.
I'll first discuss why virtual fonts are \emph{not} needed for use of
non-CM fonts --- \emph{or} for reencoding.  Then I'll explain what 
virtual fonts \emph{may} actually be useful for (and why even for 
those purposes there are better ways of going about things).

Part of the confusion may result from lumping together of virtual
font support with support for re-encoding of fonts.  One most
\emph{definitely} needs re-encoding, but it is not part of \VF{}, and in
fact, virtual fonts \emph{per se} are inadequate for this task (see below).

This is a deeply religious issue, so I don't expect to make
too many instant converts.  We all fall in love with the
software tools we use and often assume that the way they
do things in the \emph{only} way they can be done, or perhaps even
that they implement the \emph{best} way.  Unfortunately, to make
my points, I'll be stepping on some toes (lightly I hope).

By the way, many of the points I wish to make cannot be made
without referring to specific programs.  I hope what I say will
not sound \emph{too} much like advertising.

Naturally, there will be many that disagree with what I say here.
I'll be happy (or maybe not!) to read their comments and respond.
From InterNet, send email to \texttt{71172.524@compuserve.com}.

People say to me:
\begin{quote}
 But you know that we (\TeX\ people) need these virtual fonts to cope 
 with non-\TeX\ fonts. 
\end{quote}

\emph{The key point is that this statement is just plain wrong!}
The fact is that \emph{one} particular implementation of a printer
driver (\DP{}) does \emph{force} the user to use virtual fonts to do 
just about anything.  This is a valid approach, but one that
requires the user to deal with more complexity than is really needed.
It is \emph{not} reasonable to generalize from this example to all \DVI{}
processors, based on the limitations of a particular implementation. 

\subsection*{Why does {\protect\rm\protect\DP{}} need virtual fonts?}

The need for \VF{} in \DP{} is mostly a result of the fact that a
companion utility (\AF{}) is unable to make proper TFM files
complete with ligatures and kerning \emph{without} using virtual fonts
(\AF{} also is unable to make TFM files for math fonts).

In fact, you \emph{can} use \DP{} without \VF{} if you use a utility other
than \AF{} to make TFM files.  For example, some people buying Y\&Y
fonts for use with \DP{} use ready-made TFM files supplied with the
fonts that do not require \VF{} (or they run \AFMtoTFM{} on a PC to make
new TFM files for whatever encoding they desire).

A second reason for the forced use of \VF{} in \DP{} is the use of a
somewhat contorted way of dealing with the font encoding issue ---
three mappings instead of just one, see later.  (We won't even
talk about the odd way this was handled in old versions of \DP{}).

\subsection*{CM and non-CM fonts can be used without virtual fonts}

It \emph{is} possible to use non-CM and CM fonts (TrueType,
`PostScript' Type 1, BitStream Speedo etc) \emph{without} resorting to
virtual fonts, provided you have a driver that can do this
(\eg\ \DPONE{} and \DVI{}Windo) and a companion utility (\AFMtoTFM{}) that
can make proper TFM files complete with ligatures and kerning {\em
without} needing \VF{}.

By the way, the encoding issue is a very important and often
misunderstood item.  Since \TeX\ thinks of characters \emph{only} in
terms of numbers, and since the CM fonts have hard-wired encoding,
many \TeX\ users are unaware of what this is all about.  Someone
always working with the same programs and on the same platform 
may not be aware that there is an issue. But that is another story.
Just keep in mind that a file contains \emph{numeric codes} --- \emph{not}
characters.  There must be conventions for what glyph each numeric
code corresponds to -- and there is no single `right' encoding.

\begin{quote}
It is \emph{not} necessary to use virtual fonts to reencode a font.
\end{quote}

Users of Y\&Y software use scalable outline fonts \emph{without} \VF{}.
Y\&Y doesn't sell or support PK bitmapped fonts (except in some
half-baked way).  So it should be obvious that `it works' --- for
otherwise they would have been out of business long ago!

One can use non-CM fonts --- with full support for ligatures, kerning
\emph{and} reencoding -- without resorting to virtual fonts.

A large fraction of sales from Y\&Y are to service bureaus,
publishers, and \TeX\ consultants --- `power users' that need all the
most advanced features.  If \VF{} was needed to do any of the things they
want to do, then you can bet that it would be supported!

\subsection*{The need for font re-encoding and the
  inabillity of {\protect\rm\VF{}} to provide proper re-encoding}

The most commonly claimed reason for need to use \VF{} is that font
encoding must be controlled.  Now the virtual font itself --- like
everything in \TeX\ --- treats characters merely as \emph{numbers} --- 
it has no concept of character other than as a number.  Hence \VF{}
itself can \emph{only} permute the numbers of from 0--255.  That is,
it can move characters around in the space of integers from 0--255.

\emph{But}: most fonts have many unencoded characters.  There may be
224 or 500 or even over a thousand characters, yet only 170 may
show up in the `raw' encoding of the font.  To use the font properly
it has to be re-encoded.  There is a `cmap' or `encoding vector'
that maps the integers from 0--255 to characters (usually
specified by some mnemonic name like `space').  To use such a
font properly, the \DVI{} printer driver or \DVI{} previewer has to
be able to reencode the font to a user specified encoding vector.
Note that this has nothing to do with virtual fonts, it is a
capability needed in the \DVI{} processor whether or not virtual
fonts are supported --- and in fact cannot be provided by \VF{} itself.

\begin{quote}
To state this emphatically:  virtual fonts themselves are inadequate
for reencoding, since they cannot make unencoded characters accessible.
And once your \DVI{} processor has its own mechanism for doing
\emph{reencoding}, there is no longer a need for \VF{} to attempt to do this!
\end{quote}
Let me show how easy this encoding business really can be.  Imagine
an ASCII file with a list of numbers and character name pairs.
This file contains up to 256 lines such as the following:
\begin{verbatim}
        32      space
        33      exclam
        34      quotedbl
        35      numbersign
        ...
\end{verbatim}

This is an encoding vector file.  It fully defines the encoding to
be used --- in a totally clear and explicit way.  Now such an encoding
vector file can be used by the \DVI{} processor (the user specifies for
a font that needs reencoding, which of these encoding vectors to
use), as well as by the utility used to create the TFM metric file.

Compare this to \DP{}'s complex mechanism of `input encoding',
`output encoding', plus virtual font remapping (permuting 0--255).
\emph{Three} `mappings', where just \emph{one} is perfectly adequate!

\subsection*{If we don't need {\rm\VF{}} for reencoding, then what are virtual fonts good for? }

\begin{enumerate}
\item Making a fake smallcaps font;
\item Add new composite/accented characters;
\item Making new fonts that contain characters from two existing fonts;
\item Changing the side-bearings and advance widths of chacacters in a font;
\item Achieving weird and wonderful effects by packaging \TeX\ \DVI{} commands
for drawing rules and \verb|\special|s as `characters'
\end{enumerate}

\subsection*{What are the drawbacks of using virtual fonts for these purposes?}
\begin{enumerate}
\item The font designer will be in pain when he sees his creation mutated
using virtual fonts to create fake smallcaps!  A smallcaps font
should have properly designed `small caps letters', \emph{not} scaled
replicas of the uppercase letters.  Making a smallcaps font this
way is not quite as evil as making a bold font by smearing a regular
face, but it comes close\ldots  Admittedly, many fonts do not
have companion `expert fonts' or smallcaps versions, so one is 
tempted to make up a fake smallcaps font, but its not a good idea.

\item Most text fonts contain 58 `standard' accented/composite characters
that cover ISO Latin 1 and some more.  These can be easily used
directly \emph{if} your \DVI{} driver provides for reencoding.  Curiously
\DP{}/\AF{} instead uses the virtual font mechanism to compose the
accented character from base and accent.  This is not a good idea
since the designer of a quality font often makes a composite that is
not \emph{exactly} achievable by superimposing base and accent.  Aring,
Ccedilla, and ccedilla are particular cases of glyphs usually \emph{not}
made by superimposing base and accent, but by designing an outline.
Also, the rendering at some resolutions will not be as good, since the
hinting for the composite can take into account interactions between
the base and accent.  This is \emph{not} possible if the two parts are drawn
separately. (By the way, \AFMtoTFM{} can be used to insert convenient
pseudo ligatures for the accented characters in the TFM file).
\item   Combining parts of two fonts seems like a legitimate use for virtual
fonts.  It comes in handy, for example, when an `expert font'
contains the small caps letters, but not the upper case letters.
But see below.
\end{enumerate}
So what are the drawbacks of using virtual fonts for these purposes
(And how can one achieve the same results some other way)?

\begin{quote}
The main problem is: Only \emph{\TeX} knows anything about virtual
fonts.
\end{quote}

Now if \TeX\ is all you ever use, \emph{and} if you don't use text in
your illustrations, then that may be just fine with you.
But in a lot of professional work, \TeX\ does not live in isolation.
Illustrations are created using graphics applications of all sorts.
These can be inserted into the text in EPSF or TIFF or other form.
(Where we come to meet the nightmare of non-standardization of
\verb|\special| -- but that is another diatribe\ldots)

Now if the illustration has any text in it, it is usually desirable
to have the font used in the nomenclature match the text font.
So the graphic application has to be able to use the same fonts
as \TeX.  Hence PK bitmapped fonts are not useful, one needs to use
fonts in some established industry standard form such as Type 1
or TrueType (note that virtually all fonts commonly used with \TeX\
are now available in T1 format, including CM, AMS, \LaTeX, \SLiTeX
etc). And this won't work if the font is a `virtual font'. What to do? 

\subsection*{Font manipulation tools}

Well, in the \TeX\ world we tend to be somewhat myopic.
We try to do everything in \TeX, or using tools that come with \TeX.
Sometimes we go through amazing contortions to do this, even when it
can be done quite easily some other way (for example making graphs 
by drawing millions of dots in \TeX\ rather than using PostScript).

There \emph{are} tools available for manipulation fonts in Adobe Type 1
format.  These create \emph{real} fonts that can be used not just with \TeX.
Such tools can:
\begin{enumerate}
\item combine characters from different fonts into one font;
\item create new composite/accented characters (add ISO Latin 2 glyphs say);
\item make obliqued versions of a font (although the designer may not agree);
\item adjust the side-bearings and advance widths of characters;
\item and about a dozen other things\ldots
\end{enumerate}
It should be clear from the above that I have pretty strong feelings on
this issue!  But that is only to counter the pretty strong feelings many
users --- particularly in the Unix / University world --- have on this issue!

\subsection{Easy, totally general reencoding}

In \DVI{}Windo and \DPONE{} you can use \emph{any} encoding (for printing
\emph{and} for on screen display), and using arbitrary encoding is as
simple as adding a line like
\begin{verbatim}
   tir  Times-Roman     *remap* isolati1
\end{verbatim}
to a `font substitution' file --- or, running a batch file called
encode (this should all be one one line):
\begin{verbatim}
   encode isolati1 c:\afm c:\tfm c:\psfonts 
   c:\windows W tir tii tib tibi
\end{verbatim}
(the latter takes care of all four styles of Times-Roman).  What could be
simpler?  This is not to say that it is easy to implement this!  In fact, the
operating systems, PostScript printer drivers, Adobe Type Manager, and clone
printers conspire to actually make it very hard.  But the user need not suffer!

\subsection*{MathTime version 1.1}

Lets talk about the MathTime fonts for a second. It certainly saved some work
to not have to make up the glyphs for the letters in the math italic font
MTMI, but instead to `borrow' them from Times-Italic (with major changed in
side-bearings and advance widths).  And virtual fonts make it possible to
splice together RMTMI and Times-Italic to make a MTMI font.
\begin{quote}
        However, this has been the source of very many headaches!  
        Virtual font fanatics please pay close attention!
\end{quote}

First of all, there are eight (8) versions of true Adobe Times-Italic
alone.  And different printers have built in different versions.  
For example, many TI printers use the old 001.002 version, while most QMS
printers use the (almost) latest version 001.007.  So what you say?  Well,
while the advance widths of the characters have not changed since 001.002
(thank god), the glyph shapes \emph{and} side-bearings have.  Just for example,
the lower case `z' in 001.002 has a short flat bottom right on the
baseline, while the `z' in 001.007 has a distinctive `swash' bottom
which descends way below the baseline and comes much further over
to the right where it ends in a bulb.  Subscript position designed
to work with 001.002 will cause collision when used with 001.007!
Conversely, a subscript on `z' will look too far away when used with
version 001.002, because the fonts were actually tuned for 001.007.

We won't even talk about `clones' of Times, such as the one by BitStream,
which are used in some low-cost laser printers.  These have entirely
different `color' for a start and different side-bearings and shapes.

And what about that Linotronic to which you have entrusted generation
of the final copy of your book (at \$3--\$8 per page)?  What version
of Times-Italic is it using?  Are you willing to risk it?

So what is the solution?  Don't use virtual fonts!  

The IBM PC version of MathTime version 1.1 from Y\&Y comes with true
Adobe Times 001.007 and an installation procedure that creates a {\em
real} MTMI that (i) can be used with any application, not just \TeX,
and (ii) has `wired in' the version of Times-Italic for which RMTMI
was designed.  No `surprises' are possible!

By the way, service bureaus are in the habit of asking for the fonts
separately from the PostScript file (this is a hang over from a bygone
era, but that is another story).  And they want a \emph{real} font -- their
image setter doesn't know anything about \emph{virtual} fonts.

Unfortunately the tools for combining RMTMI and Times-Italic,
adjusting side-bearings and advance widths etc are quite sophisticated
and not available on other platforms (particularly if you care about
hinting, since most tools for manipulating fonts destroy the hinting).
So many users find themselves in the unfortunate position of having to
buy the IBM PC version \emph{and} utilities for converting from PC to
Mac or Unix format.

\subsection*{Some remaining minor issues}

There are some other, less important issues.  Implementation of \VF{}
in the \DVI{} processor creates a significant performance hit.  The 
seriousness of this depends on the cleverness of the implementor, 
and for printer drivers its probably not a big concern (since 300
milli-seconds per page is not noticably slower than 150 milli-seconds
per page).  The performance hit in \DVI{} previewers is more serious.
Try Textures with a file that calls for \VF{} fonts versus the same basic 
text with non-VF fonts (which gives up some of the advantages of the
assembly language coding in Textures 1.6).

%\TeX\ loves to use lots of fonts.  Using virtual fonts only increases
%the number of fonts called for in the resulting PostScript file.
%Unfortunately, all but one \DVI{} printer driver download complete Type 1 fonts.  
%This is very slow and easily overloads `virtual memory' in many older
%printers and type setters.  Again, this will only get worse with \VF{}.
%\DPONE{} uses partial font downloading of Type 1 fonts, so it doesn't have
%this problem and hence could easily \emph{afford} the added overhead.

\end{Article}


\endinput