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

[Dan Williams]

Leonard,

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

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

Baskerville.dfont
-- 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;
    else
    {
      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 OpenOffice.org 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.

Thanks,
Dan

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
> > > collections.
>
>         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
> > > useless...
>
>         They had to support existing fonts - both their own and customers...
>
>
> LDR
> --  
> ----------------------------------------------------------------------- 
> ----
> Leonard Rosenthol                             
> <mailto:address@hidden>
>                                              <http://www.lazerware.com>