🚀 go-pugleaf

In article <1991May2.161359.5065@int13.hf.intel.com>, tim@int13.hf.intel.com (Timothy E. Forsyth) writes:

    *  ASCII format files with eexec information in HEX.  This is the
    *  file type that can be downloaded to the printer and is the file
    *  type used on UNIX systems.
This is indeed the desirable format one needs for UNIX systems, given
the UNIX systems I use have nothing resembling a print manager.

    *  Mac format files use some kind of "resource" information to
    *  separate the sections and the eexec section is also in binary
    *  instead of HEX. . . .
    *  . . . and the book refers the reader to
    *  Apple for information about the Mac file format.
Yes -- this is documented in an Adobe document called something like
'Supporting Downloadable Fonts'.  The Adobe document describes the
Mac 'resources', which are fancy names for `data types'.

HOWEVER, THERE'S A CATCH.  On several occasions I have moved Mac font
files to my UNIX system using TOPS.  In such cases there are 16#300
(768) bytes of glop at the beginning of the file, that do not in any
way resemble anything I've read about in any document, anywhere, at
any time.  When I was writing a small program to convert Mac encoded
font files to UNIX all ASCII format, I determined by trial to skip
the first 16#300 bytes, and then all would be groovy.

I then spent roughly a YEAR asking Mac `experts' what the extra
16#300 bytes are, and received only the kinds of looks you get when
you ask a computer store salesperson a difficult question like `how
do you turn on the power?'.  I formed my own theory that these bytes
are used by Mac file manager and when you open a file on Mac, file
manager shufles those extra bytes off somewhere and the application
never sees them.  This is known as `extrapolating from a point'.
Eventually, a Mac knowledgeable person told me my theory was more or
less correct and skipping the extra glop was the Right Thing to do.


	........  Henry