Re: FT2 Mac support

[Just van Rossum]

Hi David,

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

Ick! Speaking of platform dependencies... This looks like a very brittle
system to me :-(.

>but I suppose that you don't have one on the MacOS.

That's right, I don't.

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

I was wondering why there was so much code overlap in the config/* dirs, I
think I now understand... Sort of.

[ ftmodules.h ]
>Because of the infamous 8.3 DOS naming rule, of course. I'd be happy to use
>"ftmodules.h" in the first place :-)

Ah, sorry, of course.

>> 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 :-()

I understand the function, and I understand how it should work, but I don't
quite understand my compilers' error message:

Error   : object 'tt_default_graphics_state' redefined
ttinterp.c line 732   const TT_GraphicsState  tt_default_graphics_state =

[ Mac stuff, FOND's etc. ]
>It'd be nice to be able to read such files on any platform.

Nice, but out of my league: the Mac resource fork format, is well supported
under MacOS, but needs to be completely reimplemented for any other OS. And
rather unneccesary: the FOND/sfnt combination is equivalent to a plain
.ttf, the FOND/LWFN combination is equivalent to AFM/PFB.

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

Thanks, that was the info I needed... I'll check out the T43 code as an
example.

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

The latter... These FOND's are sucky little creatures, and they're about to
become extinct (rightfully so) but they're still crucial for backward
compatibility.

Btw, yesterday I ported ftview to MacOS (ie. wrote grmac.{c|h} ;-) and that
works nicely!

Just