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

[mpsuzuki]

Dear David,

Thank you for information! I'm not pushing the
charmap sorting features to default behaviour, but
knowing the exist of softwares that requires the
consistency between FT2 charmap index versus TTF/OTF
cmap subtable index.

I want to ask another question about your software:

  FT2 charmap index should be exactly same with
  TrueType cmap subtable index?

As described in my previous post, FT2 charmap index
is not exactly same. If TrueType cmap table includes
heavily broken subtables, FT2 does not assign the  
index to them, they are automatically ignored.

It is negligible if we use clean fonts only, but if
FT2 user want to use FT2 as an inspector of TTF/OTF
this skipping behaviour might be confusing.

I think it is possible for FT2 to assign the index
even to broken subtable and make charmap index same
with TTF/OTF cmap subtable index.

Regards,
mpsuzuki

On Mon, 12 Jul 2010 04:12:28 -0400
David Bevan <address@hidden> wrote:

>
>Hi!
>
>Our software uses the FreeType charmap index directly to access the 
>appropriate cmap. (In retrospect, that was perhaps a poor design decision.)
>
>We will need to be able to retain the existing behaviour. However, if the 
>original index is available somehow, we would have no problems with a change 
>in what we need to do to retrieve it.
>
>Thanks.
>
>David %^>
>
>
>
>> -----Original Message-----
>> From: address@hidden
>> [mailto:address@hidden On Behalf Of
>> address@hidden
>> Sent: 7 July 2010 10:47
>> To: address@hidden
>> Subject: [ft-devel] charmap index should be same with cmap subtable index?
>> 
>> 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
>> 
>> _______________________________________________
>> Freetype-devel mailing list
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/freetype-devel
>