Re: [Devel] Re: FreeType 2.1.2's cmap detection broken?
> With that, it appears that a real bug may have crept in between
> 2.0.9 and 2.1.0+. With opens___.ttf font, ftdump from FreeType
> pre-1.4 reports:
>
> encoding 0: Apple Unicode
> encoding 1: Apple Roman
> encoding 2: Windows Unicode
>
> ftdump from FreeType 2.0.9 reports:
>
> charmaps
> 0: platform: 0, encoding: 0
> 1: platform: 1, encoding: 0
> 2: platform: 3, encoding: 1
>
> fonttools reports:
>
> <cmap_format_4 platformID="0" platEncID="0" version="0">
> <cmap_format_6 platformID="1" platEncID="0" version="0">
> <cmap_format_4 platformID="3" platEncID="1" version="0">
>
> ftdump from FreeType 2.1.2 (with CVS as of 2002-08-06) reports:
>
> charmaps
> 0: platform: 1, encoding: 0 <--- Only one left!?!
Two of the three cmaps of opens___.ttf are indeed buggy, and the
current validation tests in FT 2.1.2 reject them. fonttools silently
fixes the problematic cmaps -- Just, it would be great if fonttools
could report if fixes are necessary.
I imported the font into pfaedit and exported it back to a TTF. Now
FT2 reports that it has three cmaps. Again, the two buggy cmaps have
been silently fixed by pfaedit -- George, I ask you the same: perhaps
a small window could be opened, showing the results of the conversion
from TTF to SFD.
In the particular case of opens___.ttf. the test in line 688 of
ttcmap0.c (in routine tt_cmap4_validate) is not satisfied for last
segment in the (0,0) cmap: This segment should map character code
0xFFFF to the missing glyph, i.e., the offset should be 0. Instead,
the offset is 0xFFFF also, which is wrong, producing a value outside
of the glyph ID table -- since you can't assume in general that
character code 0xFFFF is always invalid for a format 4 cmap, the cmap
is incorrect. Without having it debugged further, I assume the same
problem happens within the (3,1) cmap.
David, I think it would be a good idea to relax the validation tests
even more, probably throwing away all cmap segments which are invalid
(like the above). Or we could check for (0,0) and (3,1) cmaps which
must be Unicode; then the 0xFFFF segment could be always ignored.
Werner
Reply to: