Re: 8r fonts

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

   >                (FONTCHECKSUM O ooooooooo)  <=== missing
   > vptovf doesn't put this in?

   The VPL and PL psfonts are generated with fontinst. The checksums were
   generated with addchecksum (a PERL script) in combination with the cs
   utility. I remember that one has to be very carefull with generating
   virtual fonts. Especially the order in which fonts are generated is
   very important. And one has to be very carefull with cleaning fonts because
   they may be referenced elsewhere.

   Virtual fonts are complex by there nature.  

No kidding.  Two TFMs + one VF per font.  And in one of the TFMs
kerning and ligatures can be junk because they are not used etc.

   A lot of the complexity in
   generating them is caused by the fact that fontinst can not generate
   proper checksums. PERL would be a much better tool to handle all the PS
   font stuff. And it is not too late to rewrite fontinst into PERL.

Checksums seem to be a mess.  People are getting checksum errors
all the time and typically do not know what it means.
And so they are ignored and people ask about ways of turning off the warnings.
Plus over the years the algorithms used have drifted.
Plus it is driver specific.
What *is* the algorithm for checksums used by fontinst?
What *is* the algorithm for checksums used by AFM2TFM?
What does PCTeX use?

I personally think that checksums can serve a much better purpose than
they do now: hide the encoding information there. This is critically
important since TFMs are encoding sensitive and if you have the wrong
TFM you are hosed and you can't tell from looking at this binary mess
what it is.  This is even more important with drivers who (because they
do not produce resolution independent output) refer to TFM files.

Which is why AFMtoTFM hides the name of the encoding vector used to
generate the TFM in the checksum.  Not only can you later decode this
to find out what the encoding vector was, but since this is passed
into the DVI file by TeX, it can be checked at the driver/previewer
level to see whether it matches what encoding *it* is set up for.
Solves many nightmarish debugging problems!  Just as important as
having TeX announce on screen that there are `missing characters'.

   With the help of VERIFYCS (and cs) it should now be possible to trace
   all incorrect and/or missing checksums.

   --Piet

Berthold.