[Top][All Lists]

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

[Devel] Mac fonts: getting multiple faces from FOND?

From: Dan Williams
Subject: [Devel] Mac fonts: getting multiple faces from FOND?
Date: Wed, 12 Feb 2003 12:09:36 -0600


Am I just not getting this from my side?  Let me do some rambling:

We have Baskerville.dfont.  Here's the structure:

-- Baskerville (FOND 2424)
----- sfnt 4905
----- sfnt 20647
----- sfnt 5177
----- sfnt 1404
-- Baskerville Semibold (FOND 2425)
----- sfnt 14420
----- sfnt 5669

Now with the current code, when FT_New_Face_From_dfont() is called, it will (aface), but aface in this example would _only_ ever be either sfnt 4905 _or_ to sfnt 14420, depending on what was passed in as face_index (because that's used as res_index).

FT_New_Face_From_dfont( face_index = 2424 )  -----> aface is sfnt 4905
FT_New_Face_From_dfont( face_index = 2425 )  -----> aface is sfnt 14420

How do you get access to all the rest of the 'sfnt' faces? From my reading of the code, you can _never_ get an aface back that contains _any_ of the other faces, like 20647, 5177, 1404, or 5669. parse_fond() contains code to deal with this:

    fond       = (FamRec*)fond_data;
    assoc      = (AsscEntry*)( fond_data + sizeof ( FamRec ) + 2 );
    base_assoc = assoc;
assoc += face_index; /* add on the face_index! */ <----- ALWAYS will be 0 by here

But by this point, FT_New_Face_From_dfont() has already set face_index to 0 before it passed face_index to FT_New_Face_From_FOND()!! So assoc in parse_fond() will _never_ be anything other than the first face.

  (from FT_New_Face_From_dfont())
    /* 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;

If this behavior of face_index always being 0 is intended, then why is this comment here (from Oct 2001)?

     Thanks to Paul Miller (address@hidden) for the fix
     to load a face OTHER than the first one in the FOND!

I'm not sure whether I'm reading the Freetype intentions right. I believe my reading of the code is correct, but if this behavior is by design, please let me know. Our problem with is that we use Freetype for font rendering, but do our own font management. So therefore, we have to get all 'sfnt' resources in a Mac font file, but we can't make Freetype see them at all.


On Wednesday, February 12, 2003, at 11:35  AM, Leonard Rosenthol wrote:

At 11:07 AM -0600 2/12/03, Dan Williams wrote:
Ok, I looked up ftmac.c and had a look. Yes, the API is flawed. It works well for fonts that _do_ contain one FOND per sfnt, but not if you must
access all sfnt's through one FOND.

It's not be a problem to date for folks using the API. What do you see as the problem? Simple performance issues iterating over all FOND/sfnt's??

I don't know how Apple's dfonts are
built (and those are the only ones that matter, as it's bad enough
_they_ make them. No third party in his right mind should ever ship a
dfont), so this may or may not be an issue. However, I assume it _is_,
hence this report ;-)

A .dfont is simply an old style Font Suitcase (DFIL/DMOV) that has had it's resource fork swapped into the data fork. Nothing else.

Apple only has this as a way to no longer have to support resource fork-based fonts without conversion of their existing font library. All new fonts come either as .ttf or .otf.

If you _must_ use FT_New_Face, then yeah, I see no other option than to
use face_index in dual capacity.

I'm still confused about this one, since the code that is in there can figure all this stuff out for you by using the Font Manager calls to locate the correct FOND/sfnt and load it for you from whatever format it happens to be.

 However, since you must have custom
code already that figures out _what_ FOND to use, would it be possible to use the FT_New_Face_From_FOND() API directly? Even better would be to use FT_New_Face_From_SFNT call directly, but that one isn't public (this
could obviously be changed).

Agreed. If you already know which FOND or snft - just use it directly. I have no problem with exposing the SFNT call and would be glad to commit the patch if you needed.

The whole model of suitcase files (*) --
and therefore dfont files -- really doesn't fit well with FT's notion of

        Agreed.   And fortunately they are slowly going away...

I'm quite cross with Apple for adding dfonts: they should have killed
FONDs and suitcases long before OSX came out. They're horrible and

        They had to support existing fonts - both their own and customers...

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

reply via email to

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