RE: [Freetype] Question on MacOS X

[Wenlin Institute]

At 7:09 PM -0500 11/28/01, Leonard Rosenthol wrote:
>  At 06:25 PM 11/28/2001 -0500, Changyuan Hu wrote:
> >  Does the latest FT2 (specifically the ftmac.c file) support data fork fonts?
>         Yes.  It supports all of the formats supported by Mac OS X - 
> or at least it is supposed to ;).

It doesn't seem to work with .dfont files. ftmac.c makes no 
difference for these -- at least if the file type is 0, which it is 
for the .dfont files that are installed with OS X. FT_New_Face() 
returns FT_Err_Unknown_File_Format for Geneva.dfont, Helvetica.dfont, 
etc.

On the bright side, FT 2.0.5 does work with Mac "suitcase" fonts 
under OS 9 and OS X. For OS X, to use Unix-style pathnames, it's 
necessary to change file_spec_from_path() in ftmac.c to something 
like this:

  FSRef ref;
  if (FSPathMakeRef((UInt8 *) pathname, &ref, 0) != noErr) {
    return -1;
  }
  if (FSGetCatalogInfo(&ref, kFSCatInfoNone, NULL, NULL, spec, NULL) 
!= noErr) {
    return -1;
  }
  return 0;

There are some unused variables in ftmac.c (reported by GCC): 
name_table in parse_fond(), memory in FT_New_Face_From_LWFN(), stream 
in FT_New_Face_From_SFNT(), and error in FT_New_Face_From_FOND().

A compiler warning is given for size_p being possibly uninitialized 
in read_lwfn(). It's not obvious (to me) whether it would always be 
initialized before use even if a file were corrupted. It would be 
safest to initialize size_p = NULL, and check if (size_p != NULL) 
before writing to it.

"#define macintosh" causes a conflict with the precompiled header for 
CoreServices.framework. This can be solved by defining a unique name 
such as FT_MACINTOSH, to replace "macintosh" in ftmac.c and ftobjs.c.

Tom Bishop

--

Wenlin Institute, Inc.        Software for Learning Chinese
E-mail: address@hidden     Web: http://www.wenlin.com
Telephone: 1-877-4-WENLIN (1-877-493-6546)