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

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

(I was going to reply only to Berthold, but I changed my mind)

>Ghee, and everyone always tells me that this `two TFM plus one VF per font'
>scheme is so trivial that I am a fool to complain about its complexity :-)

:-)  Actuallly, I understand *roughly* what's going on; it's just the
details that I haven't yet got the hang of.  I think part of the problem is
that everyone wants to make it seem `oh so simple', so all the explanations
skip the important details.

[snip]
>Here is the simple version of the story: In this scheme, TeX sees only
>one TFM file, which is for a virtual font.  It puts the name of that
>file in the DVI file.  DVIPS sees that name, discovers there isn't a
>real font with that name, and looks for a VF file with that name.

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?

>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.

>Typically the entry in psfonts.map will also specify how the `raw'
>font is to be reencoded to be this `real' font.
>
>I put `real' in quotation marks because it is the reencoded font, not
>the `raw' unadulterated font.  Why the need for reencoding?
>Because the virtual font mechanism can only shuffle around numbers,
>that is, map character code numbers to other numbers.  It cannot
>make unencoded characters accessible (Typically `raw' `PS' fonts
>are set up for Adobe StandardEncoding which leaves over 60 of
>the `standard' 228 glyphs in text fonts unencoded).  Now if you
>have to reencode the font already why do you also need the shuffling
>of character codes by the VF?  Hey, don't ask me :-)

A puzzle, isn't it?  I think it's because TeX uses T1 and OT1 encoding and
that's that (aside from when it doesn't, but you know what I mean).
Forward and backward compatibility are Good Things, so you don't want to
fiddle about with encodings too much (ever wondered why most people use OT1
by default?)

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
doesn't make any sense at all to have *this* part of the encoding dealt
with by TeX itself, because the encoding used by the Type 1 fount is likely
to change with time and computer system - after all, most of us use either
Adobe Standard or Mac encoded encoded founts at the moment, but Unicode
encoding will become quite common some time soon.  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.

This way, you can have a system independent TeX set-up, which means you get
better compatibility across time and space (if you'll pardon the pretension)

Does this reasoning make any sense, and does it have any relationship to
reality?

>   Why are two .tfms being read?  Can anyone explain what's happening here?
>
>Another thing you ask about is why DVIPS reads both TFMs.

Not DVIPS; vftovpl.

>  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.)

>  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?

Thanks again,
Rowland.