Re: Fount encodings, dvi drivers, and stuff

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

Hi:

   If you use fontinst to install a new fount for use with LaTeX, and
   re-encode it to 8r encoding to begin with, what happens at the dvi 
   driver end?

With that scheme, the DVI driver reencodes the font to 8r rather than
to the encoding used in TeX (T1, LY1, or whatever).

   As I understand it, when you install founts using fontinst 1.6 and
   \latinfamily, you get an 8r encoded .tfms to begin with, which are pointed
   at as the `final' founts by the .vf files etc.

This is the `two TFMs plus one VF per font' scheme.  The TFM file that
TeX sees is set up according to the user chosen encoding (T1, LY1, or
whatever).  The other TFM file is set up for 8r.  The VF file maps
character codes in T1 to character codes in 8r.

   I think this means that the dvi driver has to map the glyph numbers
   requested in the dvi file to the appropriate slots in the `real' fount
   file.  

No, it normally doesn't remap the DVI character codes, but instead
changes the encoding in the font.  The font has an encoding vector,
which lists for each character code what glyph to draw.  (There *are*
actually situtations where remapping at the DVI driver level is
required to work around bugs in other software like Adobe Illustrator,
Acrobat Reader etc. but DVIPS doesn't support this).

   So that a request for glyph number 182 (para mark) by the dvi file
   (assuming 8r encoding) means that the dvi driver will actually present
   glyph number 166 (assuming Mac encoding) to the output device?

No.  The DVI file uses character codes in T1 (or LY1). So your example is
poorly chosen since T1 does not include paragraph (and about 38 other
useful glyphs).  Lets instead take `sterling' (\pound).  This is
character code 191 in T1, so 191 is the character code that will
actually appear in the DVI file.  Now in 8r, `sterling' is at 163.  
So the only purpose of the VF file is to remap character code 191 to 163
Note that since VF like TFM deals only with character codes it cannot
really reencode a font (e.g. make unencoded characters accessible).
It can only rearrange the character layout.

Finally, the font has its own encoding, where `sterling' may be elsewhere
(or not even accessible).  It is the DVI drivers job to reencode the font
so that character code 163 is linked to the program that draws the
pound sign.  This is quite easy to do in PostScript, and in the case
of DVIPS is set up in psfonts.map.  

Pretty complicated, and while it has some advantages over the `one TFM
file per font and no VF' scheme, it seems mostly to have disadvantages.

   Rowland.   (whose head is hurting writing this fontinst documentation)

Will it be called the `fountinst' documentation :-)?

Regards, Berthold.