Re: [Devel] Freetype Mac .dfont issues?

[Dan Williams]

Hi,

I have here a preliminary patch that allows more than the first face to 
be used from Freetype for mac fonts, both suitcases and dfonts.  This 
patch is _NOT_ submission quality, I'm simply posting it to get a 
review if this is the right thing to do.

Caveats with the patch:
1)  Whacked up to support gcc building with -DTARGET_API_MAC_CARBON, 
not using CodeWarrior (ignore #include changes)
2)  Hack to make both suitcases and dfonts use 
FT_New_Face_From_dfont().  This function would get renamed.
3)  Doesn't work with some fonts like LastResort.dfont, Keyboard.dfont, 
Taipei.dfont, Beijing.dfont, perhaps because they do not have the 
correct TrueType version identifier in their 'sfnt' headers.  Crashes 
on FT_FREE(stream) in open_face_from_buffer().
4)  Whitespace changes

With these in mind, please review the patch and see if the method seems 
acceptable.

Thanks,
Dan

On Wednesday, February 12, 2003, at 12:43  PM, Leonard Rosenthol wrote:

> At 12:55 AM -0600 1/24/03, Dan Williams wrote:
> > I'm working on native Mac font support for OpenOffice.org.
>
>         Great!
>
>
> > Presumably, this gets passed down the line to FT_New_Face_dfont(). 
> > The following snippet I don't quite understand the logic of.
> >
> >     /* face_index may be -1, in which case we
> >        just need to do a sanity check */
> >     if ( face_index < 0 )
> >       res_index = 1;
> >     else
> >     {
> >       res_index = (short)( face_index + 1 );
> >       face_index = 0;
> >     }
>
>         I would agree that this code is wrong, and needs to be fixed.
>
> 	The rest of the pipeline is fine, and handles loading any res_index 
> and face_index correctly as noted by the comments in the sources.
>
>
> Leonard

ftmac.c.MANYFACES.patch
Description: Binary data