tree 07888082932a7219494496c933f2d419d413080e
parent fef5dd9a72f326c160a7194f558749d24bac7283
author Behdad Esfahbod <behdad@behdad.org> 1458241183 -0700
committer Behdad Esfahbod <behdad@behdad.org> 1458241183 -0700

Synthesize GDEF glyph class for any glyph that does not have one in GDEF

Previously we only synthesized GDEF glyph classes if the glyphClassDef
array in GDEF was null.  This worked well enough, and is indeed what
OpenType requires: "If the font does not include a GlyphClassDef table,
the client must define and maintain this information when using the
GSUB and GPOS tables."  That sentence does not quite make sense since
one needs Unicode properties as well, but is close enough.

However, looks like Arial Unicode as shipped on WinXP, does have GDEF
glyph class array, but defines no classes for Hebrew.  This results
in Hebrew marks not getting their widths zeroed.  So, with this change,
we synthesize glyph class for any glyph that is not specified in the
GDEF glyph class table.  Since, from our point of view, a glyph not
being listed in that table is a font bug, any unwanted consequence of
this change is a font bug :).

Note that we still don't get the same rendering as Uniscribe, since
Uniscribe seems to do fallback positioning as well, even though the
font does have a GPOS table (which does NOT cover Hebrew!).  We are
not going to try to match that though.

Test string for Arial Unicode:

	U+05E9,U+05B8,U+05C1,U+05DC

Before:		[gid1166=3+991|gid1142=0+737|gid5798=0+1434]
After:		[gid1166=3+991|gid1142=0+0|gid5798=0+1434]
Uniscribe:	[gid1166=3+991|gid1142=0@348,0+0|gid5798=0+1434]

Note that our new output matches what we were generating until July
2014, because the Hebrew shaper used to zero mark advances based on
Unicode, NOT GDEF.  That's 9e834e29e0b657f0555df1ab9cea79ff7abcf08d.

Reported by Greg Douglas.