[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
dimension based checksums
*** dimension based checksums ***
(was: Re: design size in DVI)
Berthold writes:
> For checking whether TFM files
> are set up for the correct encoding, it is handy to
make
> fontdimen 0 be the checksum so you can interrogate it
> from inside TeX...
This makes sense since fontdimen 0 is NOT A DIMENSION but
rather a pure number that is independant of the "at_size".
(It is officially the tan of the angle of slant of the
font.)
> Non-standard of course.
And dangerous since a macro package could legitimately use
fontdimen 0 as what Knuth states.
Would it not make more sense to use *several* exotic font
dimensions as follows? One is set to 1.0pt (in the TFM) a
second is the checksum "cs" and a third is "CS" the word
reversed checksum. Then TeX will read "at_size",
"at_size" * "cs", and "at_size" * "CS" respectively. Then a
simple calculation determines the checksum "cs" in spite
of over/under flow under multiplication. (This assumes
"at_size" is neither huge nor tiny, and it never is.)
It is not dangerous like the use of fontdimen 0.
This is not as tidy, but the space efficiency is still
better than 1/3 since it is good to have "at_size" handy.
You may consider this inelegant. But the 12 bytes it
costs are just spitle on a hot iron. One can go on and
have as many bytes of checksum as one wants,
and at reasonable cost.
The main limitation of dimension-based data is that it
is not clear how to get it into the DVI --- except as the
rather meager official checksum.
Of his scheme Berthold writes:
> Non-standard of course, but turned off
> by the -K (Knuth) flag that kills all such
extensions...
Non capisco. Whose flag in which application/package?
Cheers
Larry Siebenmann