Re: [ft-devel] aface->num_faces of FT_New_Face() in ftmac.c

[Werner LEMBERG]

> In the regression test, I've found that FT_New_Face() in ftmac.c
> does not return correct aface->num_faces.  [...]
>
> ...So, now I'm going to fix this, and I want to ask about binary
> compatibility.  At present, via FT_New_Face() in ftmac.c, we can
> access the 2nd sfnt resource as the 2nd face of the font, although
> we don't know how many sfnt resources are included in the font.
> Other resources, like fbit bitmap, NFNT bitmap, are ignored and not
> counted at all.

Where's the problem with binary compatibility?  You are going to
extend the functionality, not to change, aren't you?

> At present, fbit and NFNT bitmap resources are not supported by
> FreeType, but I want to support it in future (I've ever written a
> ruby script to parse it).  In my understanding, the usage of NFNT
> bitmap is similar to the bitmap font in sfnt.

Hmm, is it really just a `strike'?  Or is it more like a full-featured
face, similar to the faces in WINFNT files?  Because of encoding
issues I have changed the bitmap handling for this driver from strikes
to faces.

> So, it is expected to ignore the number of NFNT in
> available-face-counting.  Possibly FreeType user don't want to
> receive the number of embedded bitmap font (numSizes of EBLC table)
> via aface->num_faces.  I wish so.

I fully agree.  Applications can use FT_IS_SCALABLE() to ignore bitmap
fonts.


    Werner