[Q] TFM files headers

[Doug McKenna]

Didier wrote:

>| 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.

Agreed, it does say so, and that article was from 1980--81 or so.  So the answer as to whether the remaining space is required to be nulls should be in the source code of pltotf.  And indeed, that's what it does, although the notes in the source code say the nullification of the remaining garbage bytes wasn't added until two years later, in April 1983 (Version 1.3).  Search the WEB source code for "tidy up the remaining bytes", which is commenting on the routine creating a BCPL string.

>| 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:
>| - 31,
>| - "TeX typewriter and Windows ANSI" which indeed is 31 characters long,
>| - 0,
>| - "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.

Don't ascribe to cleverness that which can be explained by other simpler means.  It could just as easily be garbage (in readable form) that got copied in with a blockmove for 40 bytes, or some similar brute force code, using a C string as the address of the source bytes (hence that first null byte).

But interestingly, a web (the other web) search for "Y&Y Inc" matches this TeX-related page:

<https://www.tug.org/yandy/dviwindo.htm>

So perhaps this TFM file has something to do with them.


Doug McKenna