Re: 8r fonts

[Piet Tutelaers <P.T.H.Tutelaers@urc.tue.nl>]

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

The world for TeX-users and TeX-maintainers would have been a lot
better when Knuth (or somebody else) had written a WEB-module (is that
possible?) or C-module that contains all functions a decent DVI-driver
needs. What we now have are a lot of programs all using there own
methods for reading TFM and VF files. By providing this module it could
have been the standard for everybody.

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

Checksums for CMR fonts always have been working properly. A mismatch
is an indication that your METAFONT source differs from the one used
for generating the TFM file. 

For PS fonts Tom Rokicki has designed a similar algorithm which was in
use till the `thirth' PS fonts generation.  Unfortunately this
algorithm used a left shift so that PS fonts derived from different AFM
files could get the same checksum.  That was the reason I have proposed
a new algorithm based upon a cyclic shift.  This algorithm is accepted
by Karl in web2c derived software (afm2tfm) and fontinst. The last
package via the CS utility (source available) I wrote for this purpose.

I don't know what PCTeX uses. I have heard that they don't have implemented
virtual fonts so perhaps they don't need checksums at all.

Your question makes one thing very clear. There is no way the TeX
community can garantee that a new standard gets implemented by all PD
software and vendors. In the beginning we had something like TRIP and
TRAP tests. But we don't have anything similar for DVI drivers and
fonts.  Perhaps we should make the above checksum algorithm part of the
DVI driver standard? 

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

The current CS algorithm for TFM fonts derived from PS fonts is:

   unsigned long s1 = 0, s2 = 0;                /* unsigned long! */
   for (i=0; i<256; i++) {
      if (ev[i] == NULL) continue;
      s1 = ((s1<<1) ^ (s1>>31)) ^ width[i];     /* cyclic left shift */
      for (p=ev[i]; *p; p++)
         s2 = s2 * 3 + *p ;
   }
   return (s1<<1) ^ s2 ;

Here ev[i] contains a pointer to the character name of the current
encoding and width[i] its corresponding WX value in the AFM file.

So its is clear that a checksum depends upon (1) the encoding vector (2)
the WX values from the AFM file for the characters selected through this
encoding vector. People who use a different AFM file than the one used to
generate the TFM file on CTAN can get `checksum mismatch' warnings. They
have either to use the AFM files from CTAN or regenerate the TFM files with
their AFM 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.
> 

I don't understand what you mean by `hiding the encoding vector'.  In
the current implementation in TFM/VF fonts the checksum is a 32-bit
number. So there is not much to hide.

--Piet