[Q] TFM files headers

[Didier Verna]

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


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

  Exactly.

-- 
Resistance is futile. You will be jazzimilated.

Lisp, Jazz, Aïkido: http://www.didierverna.info