> 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 _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel