Re: FT2 Mac support

[David Turner]

Hi Just,

> 
> FT2 now compiles and builds nicely with CodeWarrior under MacOS. I'm using
> the config files in config/ansi, and that works, except I had to add the
> line
> 
> FT_DRIVER(psnames_driver_interface)
> 
> to ansi/ftmodule.h.
> 
I see. This file is normally regenerated by invoking "make modules" on the
command line, but I suppose that you don't have one on the MacOS.

The files "ftmodule.h", "ftoption.h" and "ftsystem.h" are not all necessarily
up-to-date in the various "config/<system>" directories for now..

> (Doesn't it make more sense to call the driver setup file ftmodules.h? It
> lists multiple driver modules after all.)
> 
Because of the infamous 8.3 DOS naming rule, of course. I'd be happy to use
"ftmodules.h" in the first place :-)

> I've only tried ftlint.c so far, and finishes successfully with both .ttf
> and .pfb files. Excellent!
> 
Good, thanks for the report..

> Building was also relatively painless, except I my compiler complained
> about truetype.c, but I'm not sure if that's a bug in FT, my mistake or
> even a compiler bug... Using the individual source files worked great. Oh,
> truetype.c *does* compile if I remove the line
> 
> #define FT_MAKE_OPTION_SINGLE_OBJECT
>
What was the complaint ? With the command-line build system, "truetype.c" is
simply a wrapper that includes all other TrueType C files. This has the 
advantage
of generating a single object file. Moreover, it eliminates many inter-module
"externs", which is a good thing if you want to compile the driver as a DLL
(on Unix, there is no "def" file to specify the DLL entries, all "extern"
functions are simply exported publicly, bwaaaa :-()

Otherwise, it's not really needed..

> I'm now looking into adding some Mac support, which for now should just
> consist of support for so called "suitcase" files. These are Mac resource
> files which roughly work like this:
>
> - A Mac suitcase file contains one or more FOND resources, one for each
> font in the suitcase (this seems a nice analogy to .ttc files, so I think
> the face_index argument of FT_New_Face() can be used for this!)
>
> - This FOND resource (among many other things) indicates one of two 
> situations:
> 
> 1) there is an sfnt resource in the same file. This is a chunk of data
> which is 100% equivalent to a .ttf file, so I think this needs to be
> wrapped in a stream object and we're all set.
> 
> 2) there is an accompanying Type 1 font file. The PS name of the font can
> be found in the FOND, and a filename for the T1 font can be derived from
> that. A Mac T1 font is also a resource file, and contains the T1 data in a
> sequence of resources, similar to the chunks inside a .pfb file. So I think
> this also just needs to be wrapped in a stream object, and we're all set.
> 
> (Actually, there's a third situation: there's no outline font available,
> but one or more bitmap sizes. Although I *love* bitmap fonts, I'm not very
> much interested in supporting them, though, since it seems quite an
> effort...)
>
> I'm not familiar enough with the driver and platform configuration
> architecture to know where would be the correct place to implement these
> things, so I'd like your advice on that. I guess it could go like this: I
> put all supporting code in config/mac, and modify the tt and t1 drivers to
> use that code if compiled for MacOS. Hm, I think I also need to patch
> FT_New_Face(), since I need to do some checking *before* the stream is
> created. Alternatively I could create a new function FT_New_Face_Mac(), but
> I'd like to avoid that.
>
It'd be nice to be able to read such files on any platform. I believe it
wouldn't need a change in FT_Face, rather we could do as follows:

  - create an optional module used to parse Mac font files (basically by
    looking for a FOND resource directory).

  - the "sfnt" module could look in "load_format_tag" for the Mac module
    to test wether we're using a Mac font file or not (if the module isn't
    found, or if it's not a Mac file, it would default to its current behaviour)

  - the "type1" driver would also look for the module to test a Mac Type 1
    font, and default to its current behaviour otherwise.

Note that it would mean really minor changes in "sfnt", a bit more in "type1".
Each SFNT table is accessed through the face->goto_table(tag,stream). This is
done in order to embed TrueType streams in other files (basically, it was
designed to deal with Type 43), so it would not change anything in the TrueType
loader, of the CFF/Type2 one when it comes..

> Another issue is kerning for T1. The FOND resource also contains kerning
> information, and since AFM files are not used by any Mac app (except font
> editors ;-) they are ususally not installed on the system. However, the
> kerning info is available in the FOND resource, so I think it makes most
> sense to try and fetch it from there by default, as if it's a 'kern' table
> of a TT font. Does this make sense?
> 
Yes, it does, definitely. But us the AFM file under the normal AFM format,
or does it use another system-dependent "binary" version like pfm/ofm ?

> And now for an actual bug report ;-)
> 
> I think line 124 in src/type1/t1afm.c should read
> 
>     if ( ACCESS_Frame(stream->size) )
> instead of
>     if ( !ACCESS_Frame(stream->size) )
>
Agreed !!
 
> Even after that fix I ws unable to attach an afm file: the stream->read
> method was NULL so I got an FT_Err_Invalid_Stream_Operation error within
> FT_Access_Frame().
>
> No idea how to fix that...
>
Well, it was a bug, I put parameters T1_Read_AFM( stream, face ) instead
if T1_Read_AFM( face, stream ) in t1afm.c

I have fixed that in my sources, but it seems I can't commit the changes
to the CVS server (????). If anyone knows what the error message :

  cvs server: [11:12:08] waiting for uid1006's lock in 
/cvsroot/freetype2/src/type1

means really, he's welcomed to comment on it..
 
Thanks,

- David