[HarfBuzz] Valid range of deltaGlyphID is too small
Jonathan Kew
jonathan at jfkew.plus.com
Tue Sep 27 03:27:41 PDT 2011
On 27 Sep 2011, at 11:04, Dohyun Kim wrote:
> Hi,
>
> While testing harfbuzz-ng with a huge font which has more than 64,000
> glyphs, I encountered a strange result of hb-shape:
>
> <uniAC00=0+970|gid-1389=0|uniB098=6+970|gid-1388=6>
>
> As shown, minus GID numbers are printed on the screen; this of course
> is not valid.
>
> The problem seems to occur because of the valid range of deltaGlyphID
> in hb-ot-layout-gsub-table.hh.
> After having changed 67th line of hb-ot-layout-gsub-table.hh from
>
> SHORT deltaGlyphID; /* Add to original GlyphID to get
>
> to
>
> USHORT deltaGlyphID; /* Add to original GlyphID to get
>
> the problem disappeared and correct glyph names were printed instead
> of minus GIDs.
>
> I have no idea about whether USHORT typecast is good for this case.
> Anyway, changing to USHORT has solved an issue which has nagged me for months.
The OT spec shows deltaGlyphID as a (signed) 16-bit value, so SHORT (and not USHORT) is the correct type. I'd guess the real issue is that GlyphID arithmetic is implicitly supposed to happen in 16-bit unsigned space, with silent wraparound of over- or under-flow, but HBNG ends up doing the arithmetic with 32-bit values and doesn't implement the modulo-64K truncation appropriately everywhere. (Note that hb_codepoint_t, often used for glyph indexes, is a 32-bit type.)
Behdad can no doubt identify the proper place to fix this, either immediately in SingleSubstFormat1::apply where the deltaGlyphID addition is done, or somewhere more general under replace_glyph(). (Not sure offhand if there may be other potential sources of glyph-ID-arithmetic overflow?)
JK
More information about the HarfBuzz
mailing list