[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Devel] Fw: Freetype Mac font questions

From: Dan Williams
Subject: Re: [Devel] Fw: Freetype Mac font questions
Date: Wed, 12 Feb 2003 11:06:41 -0600


I've copied in an email I sent to Torrey Lyons about freetype explaining my problem... I see two solutions in correcting it:

1)  Use face_index in dual capacity:  its an FT_Long, so use the
upper 16 bits as the res_index, and the lower 16 bits as the
face_index. Pro:  full access to FOND & 'sfnt' resources.  Con:  kind
of breaks the meaning of the API.  ie it now means something totally
different for Mac OS X than other platforms.

2)  Use face_index as an absolute index to all 'sfnt' resources in
the font:  ie it would have nothing to do with res_index, but when
face_index = 12 for FT_New_Face() for example, where FOND 1 had 6
faces, FOND 2 had 5 faces, and FOND 3 had 5, you would have to go
through _all_ FOND resources and count the faces in that FOND, if its
not in that FOND move to the next one, if not there then next, etc.
Pro:  full access to FOND & 'sfnt' resources, keeps compatibility
with the spec in a roundabout way, platform "independent" to a degree
(ie doesn't expose Mac specifics).  Con:  performance degradation
when using large face_indexes.

We get into the issue of Apple's 3-level font hierarchy: File->FONDs->sfnt/NFNT, whereas TrueType collections are only File->Fonts. Its ugly, I know :)

In terms of correcting this issue, I was trying to make it so that the person using Freetype would have to know as little as possible about the structure of a Mac font (ie wouldn't have to access resource fork), but I'm not sure this will work out. I've been whacking at Freetype for the past two days making patches for this but I'm not ready to submit them yet...


Date: Fri, 7 Feb 2003 01:16:14 -0600
Subject: Re: XFree86 (4.3.0 RC 1), freetype
From: Dan Williams <address@hidden>
To: Torrey Lyons <address@hidden>
X-ECS-MailScanner: Found to be clean
Status: RO

Torrey and all,

What version of the Freetype library are you using to get the native fonts? There exists a problem (as I see it) that with the current implementation of .dfont support in freetype, you can only ever retrieve the _first_ face from a 'sfnt' resource due to a bug in FT_New_Face_From_dfont() where face_index gets set to 0 if it is > 0, and res_index gets set to what face_index was.

In ftmac.c:

    /* face_index may be -1, in which case we
       just need to do a sanity check */
    if ( face_index < 0 )
      res_index = 1;
      res_index = (short)( face_index + 1 );
      face_index = 0;
    fond = Get1IndResource( 'FOND', res_index );
    if ( ResError() )
      error = FT_Err_Cannot_Open_Resource;
      goto Error;

    error = FT_New_Face_From_FOND( library, fond, face_index, aface );

So, when you call FT_New_Face_From_dfont() with a face_index of > 0 so you can pull out the 3rd or fourth face from the FOND, res_index gets set to what face_index was, and face_index to 0! Therefore, you can only get the 1st face from any given FOND resource in a dfont file.

The question: is the code in this XFree86 release for freetype this same code? This was based on a checkout of freetype from 3 weeks ago... I've tried in vain to contact the Freetype project about this but I can get no answer (it seems the address@hidden list is > down).


On Wednesday, February 12, 2003, at 08:33  AM, Leonard Rosenthol wrote:

At 11:07 PM +0100 2/7/03, Werner LEMBERG wrote:
I'm a member of the Mac OS X/Darwin team and I need to get in touch with the person who added Mac .dfont support to >> freetype.

        That would be me...

I have a number of questions to ask that person.

        What do you need to know?

-- ----------------------------------------------------------------------- ---- Leonard Rosenthol <mailto:address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]