[Q] TFM files headers
didier at didierverna.net
Fri Sep 13 20:16:44 CEST 2019
Doug McKenna <doug at mathemaesthetics.com> wrote:
> A BCPL string starts with a length byte for the remaining bytes in the
> string. Everything after that number of bytes in each field should be
> ignored, and therefore can be garbage or nulls. There is no
> requirement that it be null padding that I recall
David Fuchs'paper in TUGBoat Vol.2 n.1 says otherwise. That's why I
implemented the check in my parser. But maybe this paper is too old.
In fact, going back to my initial example (pagd8y.tfm), I know realize
that if you just ignore the garbage instead of checking that it's a
bunch of zeros, then the header becomes PARC-compliant.
Indeed, the character encoding scheme string, which is advertised as
of length 31, contains:
- "TeX typewriter and Windows ANSI" which indeed is 31 characters long,
- "Y&Y Inc" which is 7 characters long.
In total, we do reach 40... So it looks like someone had fun hiding
the Y&Y stuff at the end of the string.
> Regardless, a null in the legal part of the string will cause problems
> for any parser that might try to record it as a C string.
That's why I don't use C ;-)
> But all of that is only a problem if one is assuming the extra data
> past what TFM cares about is in that Xerox-added format. There's no
> way I can discern to tell different private extended formats apart. I
> don't know about any other documented formats in this extra space, but
> that doesn't mean there aren't any.
Resistance is futile. You will be jazzimilated.
Lisp, Jazz, Aïkido: http://www.didierverna.info
More information about the texhax