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

[mpsuzuki]

Hi,

Sorry for long lated working for FreeType classic MacOS port.
I've almost finished to modularize framework-dependent parts of
ftmac.c (as initial revision), and now I proceed to regression
test.

# BTW, the commandline interface of MPW (classic MacOS developer
# environment) is very difficult to use for UNIX junkies, like me.
# I wrote a MPW program which scans specified folder and tries
# to open all files as font.

The current status is available from GNU arch archives at

URL
        http://www.gyve.org/~mpsuzuki/arch-2005.09.03

Archive Name
        address@hidden

Project Name
        freetype2--mps-macos--0.2
        ft2demos--mps-macos--0.2


In the regression test, I've found that FT_New_Face() in ftmac.c
does not return correct aface->num_faces.

>From the document in freetype.h, original FT_New_Face() is designed
to return available number of faces: if 2 TTF faces are embedded
in single TTC file, aface->num_faces must be 2. But, aface->num_faces
is not touch in ftmac.c (you can know easily by grep ftmac.).
Therefore, FT_New_Face() in ftmac.c cannot count the faces of special
font format supported by ftmac.c: old PS font for MacOS (LWFN:
LaserWriter FoNt), and Suitcase.

About LWFN, it is noted that FT_New_Face() cannot count the faces
in it, in ftmac.c. However, I never seen LWFN font including
multiple resources, and I suppose it's not widely used.

On the other hand, Suitcase font format is designed to include
multiple sfnt scalable font resources into single font file.
It is still used in classic MacOS (you can find Courier of MacOS
9.2 includes 2 sfnt resources). I think it is expected to count
the faces in Suitcase correctly.

...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.

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. 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.
By excluding NFNT resource from available-face-counting, we can
use Suitcase font aslike TTC. In fact, think about the situation:
the first face is outline only, the second face is bitmap only,
the third face is outline only... everyone will be confused. 

But, if we exclude NFNT bitmap resources from available-face-counting,
we cannot access them anymore, because they are separated from
sfnt resource. To solve this problem, some ugly hook in sfnt
resource handler will be required. From the viewpoint of FreeType
developer, I don't want to do so - counting NFNT resource as
separated resource is better to code modularization.

Yet I don't have ready-to-commit NFNT driver, so this issue can
be suspended. "This font has 4 faces, but 2 faces are in
unsupported formats" is not good reply, my first fix must be
counting without NFNT. Any comments are welcome.

Regards,
mpsuzuki