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

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

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.  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?  Do you know another
implementation that works this way?

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

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

   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.  And yes, you never want to use that.  So you *do* have to
reencode the font anyway.  Which was my point.  If you have to reencode
it anyway, why bother with an additional shuffling of character codes?

   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, 

or Windows ANSI encoding :-)

   but Unicode encoding will become quite common some time soon.

Well it is there right now in Windows NT with both TrueType and Type 1 fonts
(using ATM 4.0 for NT).  I can see all the popluated parts of Lucida Latin
fonts in `Character Map' e.g. Unfortunately there is very little software that
can take advantage of it yet.

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

   >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 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.  But you are right this
is one of the most confusion parts to most TeX users.

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

Regards, Berthold.