Re: What's the relationship between vfs and tfms?

[Rebecca and Rowland <rebecca@astrid.u-net.com>]

>Hi:
>
>   The famous Sebastian Rahtz tells me that the dvi driver first looks for a
>   vf file with that name, and if it doesn't find one, then assumes its a real
>   fount.   Clearly, one of you has it wrong.  Is it you, or is it him?
>
>The famous Sebastian Rahtz is right, no doubt.

\begin{feeblejoke}
I'd doubt it; anyone with judgement poor enough to engage me in an email
conversation is clearly not to be trusted.  (Thinks: Hmm...  I seem to have
insulted more than Sebastian here.  I always said I was stupid.)
\end{feeblejoke}

>  Since I never use
>DVIPS I don't know much about such details.
>
>   >That VF file gives the name of the `real' font and says how to
>   >rearrange the characters in the `real' font.  It then looks for that
>   >real font.  If it is a `PS' font it will be listed in psfonts.map.
>
>   This makes the not necessarily valid assumption that you're using DVIPS.
>
>Oh?  That *is* what we are talking about isn't it?

I thought I asked a general question about how dvi drivers deal with
virtual founts.

>  Do you know another
>implementation that works this way?

I don't know anything; that's why I asked.

[snip]

>Well, yes, but if you are going to have different names for the same font
>encoded different ways (by `decorating' the base name) then there is no
>need to share the same `real' font.  And hence no need for the VF approach.

It's not essential, but it does strike me as being more easily portable.

>That is, the psfonts.map has two entries to force reencoding of the `raw'
>font to anything you want, no need to add additional reshuffling using VF.

But that does mean you need different encoding vectors for each occurrance
of a different encoding *and* each different dvi driver.  The nice thing
about the vf approach is that you need one 8r encoding vector for each dvi
driver (rather than OT1, T1, and any others that are in use); and the
OT1->8r and T1->8r mapping is handled by a single encoding vector (for each
encoding) that works for all TeX installations.  If everyone used dvips and
the same PostScript founts, then this non-vf approach wouldn't have any
drawbacks.  But what of those of us who use TrueType founts on Macintoshes,
without using dvips?

>   Anyway, the actual encoding the real live Type 1 printer fount file uses
>   can be pretty much anything, and this varies according to computer.  It
>
>Well, for text fonts, the actual font file *always* says Adobe Standard
>Encoding.

Surely not?  I was under the impression that the printer fount files on my
computer say they use Macintosh text encoding.  They certainly behave as if
this were the case.

>  And yes, you never want to use that.  So you *do* have to
>reencode the font anyway.

Until 8r encoding was invented, PS founts were installed `raw', so this
re-encoding step wasn't needed.  As Alan Jeffrey puts it in fontinst.tex:

>Finally, you should tell your {\tt dvi}-to-PostScript driver about the
>fonts.  This will depend on your driver, for example with {\tt dvips}
>you should add the following lines to your {\tt psfonts.map} file:
>\begin{verbatim}
>   ptmr0      Times-Roman
>   ptmri0     Times-Italic
>   ptmb0      Times-Bold
>   ptmbi0     Times-BoldItalic
>\end{verbatim}

In other words, Adobe standard encoding has been used, and re-encoding in
the dvi driver isn't essential.

>  Which was my point.  If you have to reencode
>it anyway, why bother with an additional shuffling of character codes?

Can you think of a way in which TeX documents could be made properly
portable, and dvi drivers could be made easy to set up, given that we'd
need dozens of different output encodings for each different dvi driver?

[snip]

>   The sensible thing to do
>   is to have the dvi driver handle this part of the interface, because the
>   dvi driver set-up is *supposed* to be system-dependent.
>
>Agreed.  But that still doesn't address the question of why yet another layer
>of remapping is needed (VF).

Can anyone who helped make this particular design decision explain it?  As
I see it (in my ignorance), the vf re-mapping is used because it's portable
and works on all TeX systems.  The extra re-mapping to 8r strikes me as
more of a necessary evil, and is only put up with because you only need one
single re-encoding vector file for each dvi driver, so it doesn't add too
much to the mess of system-dependent files we've got anyway.

>   >Well,
>   >a more interesting question is why it reads the TFM at all, since the
>   >font has all the needed metrics in it.
>
>   When you say `the font', what do you mean?  (Thinks: the vf file `is' the
>   fount; each tfm file `is' the fount; the Type 1 printer fount file `is' the
>   fount.)
>
>To me its real simple: the fo(u)nt

I suspect it would me more elegant if you used one spelling or the other;
given that you're in the USA, I won't hold it against you if you use the
deviant spelling.  ;-)

> is the thing that actually contains
>the character programs.  Hence a TFM file is not a font (despite nomenclature
>used in the TeX book, neither is a VF file.

What about pk files?  By your definition, these aren't founts, which puts
TeX users in the interesting postion of being able to produce printed
output with no founts at all (by using tfm, vf, and pk files only).  I
think you could argue that vf files aren't founts, because nothing is
deluded into thinking they are.

>  But you are right this
>is one of the most confusion parts to most TeX users.

Keep your fingers crossed - in a few months, you should be able to point
people at a new bit of documentation at CTAN that'll explain this (assuming
I don't get struck my a meteorite and you don't mind me stealing [1] your
words)

>   >This has to do with DVIPS
>   >wanting to produce resolution-dependent output.  It replaces the
>   >fonts metrics with rounded versions derived from the TFM file.
>
>   I see (I think).  I take it that DVIPS does the rounding?
>
>Yes, in order to achieve (claimed) better spacing at a particular resolution,
>at the cost of worse spacing at all other resolutions...

I see - thanks.

Rowland.

[1]  Lesser artists borrow; greater artists steal.