Checksums (was re: 8r fonts)

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

Here a reaction to some checksum issues:

> Berthold:
> (1) what happens if WX is non-integer (as it is in all CM, AMS etc fonts
>   --- or at least if it isn't fractional then you do not have good
>   fonts!)?

Non-integers are currently *not* supported. They were not foreseen by Tom
Rokicki. Perhaps Berthold wants to learn us why we need them "uberhaupt?

According to the ``Adobe Font Metrics File Format Specification''
(version 4.0 / 14 feb 1992) WX values can be numbers (pp 26). Numbers
are defined as (pp 6) as

   Numbers can be either a real number or an integer, and signed or unsigned,
   that is, it may or may not contain a decimal point or a leading minus
   sign.

How do we generate checksums for non-integer WX values? Preferable in such
a way that the current values still are valid. And let us keep in mind what
the original idea of the checksum was (TeX the program, pp 217)

   header[0] (part of a TFM file, added Piet) is a 32-bit check sum
   that TeX will copy into the DVI output file. Later on when the DVI
   file is printed, possible on another computer, the actual font that
   gets used is supposed to have a check sum that agrees with the one
   in the TFM file used by TeX. In this way, users will be warned about
   possible incompatibilities.  (However, if the the check sum is zero
   in either the font file or the TFM file, no check is made.) The
   actal relation between this check sum and the rest of the TFM file
   is not important; the check sum is simply an identification number
   with the property that incompatible fonts almost always have
   distinct sums.

> Berthold:
> Using mod 40 representation you can `hide' 6 characters (a-z 0-9 and
> some others).  My idea is not so much to make the checksum unique
> (which is not important if you don't use PK files and don't use
> TFMs in the driver, instead using the font itself to supply metric
> information if it is needed).

I don't see how your implementation of check sums can fullfill the
requirements as explained above.

> *       The idea is to provide some information beyond the single bit:
> *       checksums don't match - which means nothing to most people
> *       (like debugging PS errors without ehandler.ps :=)
> 
> *       With the above encoding-name-hiding scheme, you can recover
> *       the encoding vector and announce some meaningful message like:
>
> ERROR: encoding mismatch, your TFM file was made for `8r'
> encoding, but your printer driver is set up for `tex256' encoding.

Pierre MacKay has proposed a special for PK fonts generated from PS
fonts which can help to debug font incompatibilty problems.
For example:
   27828:  Special: 'ps2pk options: -R600 -O -e8r.enc -E.82 -X72 0 -Y864'
   27880:  Special: 'fontid=Utopia-Regular'
   27903:  Special: 'codingscheme=TeXBase1Encoding'
   27934:  Special: 'fontfacebyte'
   27948:  Num special: 15335424
   27953:  Special: 'pixels_per_inch=600'
   27974:  Special: 'mag=magstep(1.0)'
   27992:  Special: 'aspect ratio=720 / 600'
   28016:  Postamble

Let us make *one* standard checksum algorithm for PS fonts!

--Piet