[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Checksums (was re: 8r fonts)
Here a reaction to some checksum issues:
> (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
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
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 (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
> 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.
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'
Let us make *one* standard checksum algorithm for PS fonts!