[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Checksums (was re: 8r fonts)
> 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.
It does. You code as many characters as possible (namely 6) into the
checksum. Obviously you can't stick in the full encoding vector, because
there is an infinite number possible. So some naming of vector files
has to be agreed upon. The key part is not that it is unique, but that
it is *decodable*.
> * 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.
Nice, but who cares anbout PK fonts :=)
Let us make *one* standard checksum algorithm for PS fonts!
Great idea! But I know what will happen. It will be just like
Tex 'n ANSI encoding => 8r. Because it `wasn't invented here'
it has to be changed - at least enough to make it useless for the
original purpose or at least incompatible :=) Same will happen here.
Fortunately I could care less, since I have used the scheme described
above for years with great success and don't plan to change :=).
Your milage may vary. But getting totally worthless checksum mismatch
error messages is not my idea of fun...
--Piet