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

["Berthold K.P. Horn" <bkph@ai.mit.edu>]

Hi:

   Thanks to the helpful replies I got to my last query on this list, I find
   myself confused by something else.

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

   It's this tfm and vf business.  I gather that TeX uses .tfm files as its
   source for fount metric information while typesetting, and that .vf files
   are used by the .dvi driver to work out which glyphs in the `real' fount
   should be used.  (this all makes my head hurt because the `real' fount is
   usually an 8r encoded not at all real fount really that needs to be
   re-encoded by the dvi driver, but I can handle that if I don't think about
   it at the same time as thinking about .vfs and TeX and things)

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.

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

   Why are two .tfms being read?  Can anyone explain what's happening here?

Another thing you ask about is why DVIPS reads both TFMs.  Well,
a more interesting question is why it reads the TFM at all, since the
font has all the needed metrics in it.  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.

Regards, Berthold