[ft-devel] charmap index should be same with cmap subtable index?

[mpsuzuki]

Hi all,

When I was working with Savannah bug #30059,
        http://savannah.nongnu.org/bugs/?30059
I had a question about the relation between
the index for FT_Face->charmap[] and
the index for cmap subtable in TTF/OTF.

When FT2 handles clean TTF/OTF, they are exactly same.

# In Microsoft TrueType spec, having 2 subtables
# with same platformID/encodingID was prohibited.
# But now ISO/IEC 14496-22 permits such as far
# as languageID are different.

OpenType spec recommends to sort cmap subtables by
platformID/encodingID/languageID. Looking at the
encodingID naming convention for (Apple's) Unicode,
ISO and Microsoft platforms, the search from the last
to the first is best to find the widest cmap subtable
for Unicode.

However, the sorting is recommended but not required.
In Apple's TrueType specification, I could not find 
any request to sort cmap subtables. Thus, there is
a possibility that the last cmap subtable is the
widest Unicode cmap.

In the case of Savannah bug #30059, the sample font
including so many cmap subtables (ca. 400, about 100
subtables can be parsed, 300 tables are heavily broken)
was used to make FT2 cache system crashed. This is
extreme case, but it is true that FT2 cannot handle
a TTF/OTF including cmap subtables > 15.

In addition, if cmap includes some seriously broken
subtables, FT2 ignores them, give no index for them.

Considering this behaviour, I want to try a re-sort
of cmap subtables in FT2 during the parsing of cmap
table (as an experiment). It will completely disconnect
the index in FT_Face->charmaps[] and the index for
TTF/OTF cmap subtables. Does the disconnection cause
serious problem in FT2 clients?

Regards,
mpsuzuki