Re: more FT2 Mac ponderings

[Just van Rossum]

At 6:28 PM +0100 01-03-2000, David Turner wrote:
>Do you mean that you are not able to open a Mac file as a single "flat" file ?

Well, erm, yes and no. Mac files have *two* independent forks: a data fork
and a resource fork. For Mac font suitcases I need the resource fork, and
for your average cross-platform font (.ttf, .otf, .pfa, .pfb) I still need
the data fork. The main problem is that the stream object is created
*before* I can check which of the forks I need, so that's why I need to
customize FT_Stream_New().

>If this was possible, it would much probably ease a lot of things as I suspect
>that browsing the resource storage scheme shouldn't be very difficult
>(I believe it all starts with a 128 bytes header, isn't it ?).

The resource fork format is documented, but I'd like to avoid that level:
it's very low... The "normal" way to approach resources on the Mac is
through the Resource Manager, which offers (roughly) a dictionary-like
interface. The thing is, I just need to peek at the FOND resource, and then
do either this (for TT):
- Create a memory stream pointing an sfnt resource, residing in the same
file. Then let the sfnt driver do it's work.
...or this (for T1):
- Open a *different* file which contains the T1 data. Synthesize a PFA
stream. Let the t1 driver do it's work.

[ ... ]
>Actually, we could probably provide a "standard" driver in something like
>"src/fondmac" that sees all files as flat and parses them.

I don't quite follow you...

>Then, then some the files of this module could have a Mac-specific version
>located in "config/macos", they would replace the standard one when building
>on a Macintosh system..
>
>The problem is to find a common API for both implementation, and one that
>wouldn't
>create too many changes to the rest of the FT2 code..

Ah, I see.

Supporting Mac suitcases on non-Mac platform seems a bad idea:
- it's a lot more work to implement and to get right
- it's an entirely new can of worms, since Mac files can exist on other
platforms in several forms:
   - binhex (.hqx)
   - macbinary (.bin)
   - as two separate files, one for the data fork, one for the resource fork.
   - ... and probably more...
- this is an effort *I* am not interested in doing.

There is software out there that converts Mac-style TT fonts to flat .ttf
files, and similarly for Type 1 fonts. This is completely lossless, and as
I see it, *much* preferable over trying to support Mac files directly in a
non-Mac environment.

[ snip ]
>FT_New_Stream is located in "ftsystem.c", which can be replaced by a
>system-specific version. For example, the file "config/unix/ftsystem.c"
>supercedes "src/base/ftsystem.c" because it uses memory-mapped files to
>access the font data (which results in a serious i/o performance boost)

I know, but let me explain again why I don't want to do that:
- I need the src/base/ftsystem.c implementation *as is* to support flat files
- I don't want to duplicate that code just to add one little switch which,
IMHO, can be *much* more comfortably be implemented as a compiler switch in
ft_stream_new().

>Note however that I'd very much like to be able to parse Mac font files
>directly on other platforms too, even if it is not a top priority..

See above... Main issue: it would increase the complexity of my
contribution by a factor of 10, while achieving dubious extra functionality.

Just