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

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

Hi:

   But it does make a difference, because you need a vector to re-encode from
   T1, from OT1, from LY1, from TS1, etc., and any other encoding you feel the
   need to use.  And all these encoding vectors are system-dependent: they are
   not portable across the entire TeX world.

I think we have been through this: unlike a remapping scheme, which
does have to take into account the target encoding, a reencoding is
*not* system-dependent.  It *overwrites* whatever encoding the system
wants to use, so what the system wants to use becomes irrelevant.
This is an important point and we'll keep on going round and round if
it is not understood.  I am not talking about the particular syntax
some driver uses, but the concept of the encoding vector.

   With the 8r scheme, you *do* need a system-dependent re-encoding file, but
   only *one* per system.

No.  The 8r.enc and 8r.vec files are constant.

   >	Also, the encoding vector is a *constant* --- it does not depend
   >	on the platform.

   The encoding vector might have a constant *effect* if you are using PS
   founts; but it's not necessarily an identical file on all TeX systems.

Well, some systems need to it written out one way, some another. 
But the basic idea is the same: a map from numbers to glyph names.

   >It is *NOT* a mapping from one set of numbers in the range (0-255)to
   >another ser of numbers in the range of (0-255).  (Which is all VF can do).

   Yes, I understand this.  You might like to consider that OzTeX uses
   re-mapping for non-PS printing, because re-encoding is (I'm told) rather
   difficult under those circumstances.

Yes, unfortunately on the Mac people haven't yet figured out how to
reencode fonts other than via the PostScrip route.  So they can only
use what is in Mac standard roman encoding on screen and for non-PS
printing.  But just because remapping is all that can be done there is
not to say that this is either a good thing or in any way a substitute for
true reencoding.

   >Then you are in trouble in any case, since there is no way to reencode
   >a TrueType font on the Mac (other than changing the actual font file).
   >You are stuck with what is in Mac standard roman encoding.  This means
   >you won't have access to 21 of the `standard' 228 glyphs (like eth, thorn).

   To use an argument you used elsewhere: for `simple' use, this doesn't
   matter.  After all, I've never been known to write in Icelandic; and
   virtually all Mac users who *do* write in Icelandic *do* have access to
   these characters.

Hmm, how about ff, ffi, ffl ligatures in the Lucida fonts?  Can't use them
on the Mac.  

   >TeX.

   Hmm...  Accented characters could be faked with fontinst.

Typographically this is not a good thing.  Best to use the ready-made
accented characters the designer created.

   [snip]
   >See above.  The encoding vector is not *different* for different drivers,
   >since it does *not* depend on the underlying encoding of the text font
   >(or whatever the operating system reencodes the text font to).

   But the precise form of each encoding vector file *does* depend on the
   syntax required by the particular dvi driver you are using.  And not all
   TeX dvi drivers can handle re-encoding; some of them must use re-mapping,
   which is entirely system-dependent.

In which case they are sunk anyway as far as this dicsussion goes...

   >For example, many people happily use LY1 (TeX 'n ANSI encoding) - even
   >on Unix.  All you need do is \usepackage[LY1]{fontenc} and no need for
   >`text companion' fonts. These people all use the *same* encoding vector.
   >(Modulo different drivers requiring it in slightly different formats:
   >DVIPS wants an actual PostScript array, OzTeX wants a `charnumber glyphname'
   >format).

   Which is the problem.

   Actually, OzTeX wants a re-mapping vector looking like this:

   \005 $FD     /hungarumlaut
   \006 "L"     /Lslash            approximation
   \007 "l"     /lslash            approximation

   `charnumber charnumber glyphname' - very different to what dvips wants, and
   quite system-dependent.

It's just syntax.  The basic idea is the same `number -> glyph names'
In this case because of the lack of true reencoding on screen and for
non-PS devices we have the extra complexity of needing some approximation
on screen.

Berthold.