Re: [ft] Carbon-free fonts support for Mac OS X 10.5 (Leopard) compatibility

[mpsuzuki]

Hi,

On 10 Dec 2007 12:32:25 -0800
George Williams <address@hidden> wrote:
>On Mon, 2007-12-10 at 07:17, address@hidden wrote:
>> This issue may NOT be regression, it is NEW problem
>> occurs since new fonts bundled to Mac OS X 10.3.
>> 
>> TimesLTMM and HelvLTMM have "POST" resource to store
>> Adobe Type1 PS font in resource fork, but the resources
>> are fragmented.
>I don't think that is new... As I recall the pfb file is divided into
>several segments (initial ASCII, middle binary, final ASCII) each of
>which is chopped up into 0x800 byte chunks which are each stored in its
>own POST resource.

I see. I was confused it's not reasonable for Apple to
establish NEW format for resource-fork fonts, your
explanation answers it. Such fragmented fonts have existed
for a long time, but I (and possibly Yamato-san too) was
not aware of it. Anyway, I think this is not regression
because it was never supported without ftmac.c.

I've checked Adobe TechNote #5040 "Supporting Downloadable
PostScript Language Fonts", and found the related description
in section 3.2 "Macintosh `POST' resource".
I was astonished that the chopping is not so simple: the pure
the ASCII text fragment should be declared as ASCII (type1),
the binary fragment should be declared as HEXADECIMAL (type2),
and it is possible to store the data in data-fork.

In my understanding, the declaration of HEXADECIMAL type
is for font downloading system to transfer the data after
hexadecimal reencoding of binary data (it does not mean
that the data in the fragment is coded as hexadecimal).
I'm not sure if a resource-fork fonts can include pre-
hexedecimally-coded binary data and declare it as ASCII.
George (or anybody else), if you've ever seen such font,
please let me know.
If we can excluse such possibility, the copying the
fragment to allocated memory is the easiest implementation 
to obtain normal Adobe Type1 PS font.

Checking resource ID of the fragments of "POST" resource
carefully, I found that the smaller ID means the earlier
fragment of the Adobe Type1 PS font.

>I assumed this was because 128K macs didn't have much memory, and these
>fragments had to be small enough to be dealt with easily. Now-a-days
>it's a pain in the neck, of course.

I see, I think it's reasonable explanation.