Re: more FT2 Mac ponderings

[David Turner]

> 
> While thinking David's suggestion through, about adding an FOND driver, I
> found out that's still not possible without modifications elsewhere in FT2.
> 
> This is because I need to create a special new stream from information that
> can't be reached from the (stdio) stream created by FT_Open_Face(). (The
> reason that I can't get at the information is due to the nature of Mac
> files in general, and the nature of Mac font suitcase files in particular.)
>

Do you mean that you are not able to open a Mac file as a single "flat" file ?
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 ?).

> I see two solutions:
> 1) the *driver* should be responsible for creating the stream -- but this
> seems inefficient for the general case, since most often various drivers
> can check whether they can handle the resource by looking at the default
> stream.
> 2) I supply a Mac-specific FT_New_Stream().
>
Actually, we could probably provide a "standard" driver in something like
"src/fondmac" that sees all files as flat and parses them.

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

> The second solution sounds best to me, but I'm worried about the
> implications. For one, I still need the stdio stream implementation (as in
> config/ansi/ftsystem.c) for non-Mac fonts, and I'd hate to duplicate that
> code just to add one test:
> 
>     if ( is_mac_suitcase(file) )
>          return FT_New_Stream_From_Mac_Suitcase(args);
>     ...continue, create stdio stream...
> 
> Secondly, I really, *really* dislike to duplicate that code. More on that
> in my upcoming reply to Werner's post.
> 
> So, is it negotiable to add a compiler switch to ft_new_input_stream()?
> Something like this:
> 
>     /* do we have an 8-bit pathname? */
>     else if ( args->pathname )
> #ifndef macintosh
>       error = FT_New_Stream( args->pathname, stream );
> #else
>       error = FT_New_Stream_Mac( args->pathname, stream );
> #endif
> 
> FT_New_Stream_Mac() would look roughly like this:
> 
> FT_New_Stream_Mac(path, stream)
> {
>     if ( is_mac_suitcase(path) )
>          return FT_New_Stream_From_Mac_Suitcase(path, stream);
>     else:
>          return FT_New_Stream(path, stream);
> }
> 
> The advantage is that I don't even *need* to write a driver (at least for
> TT), since I can just create a memory stream containing pure sfnt data. For
> T1 I'm not so sure yet (although I can easily create a PFA stream): I still
> need a way to attach the kerning from the FOND to the face object. But
> first things first.
> 

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 guess we don't even need to provide a #ifdef in "ft_new_stream" then
if everything platform-specific is embedded in FT_New_Stream.

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

- David
> Just