Remove ClassDef->Defined field. This is the comment accompanying it:
2009-01-29 Behdad Esfahbod <behdad@gnome.org> * pango/opentype/harfbuzz-open.h: * pango/opentype/harfbuzz-gdef.c (Make_ClassRange), (HB_GDEF_Build_ClassDefinition): * pango/opentype/harfbuzz-gpos.c (Load_PosClassRule), (Load_ChainPosClassRule): * pango/opentype/harfbuzz-gsub.c (Load_SubClassRule), (Load_ChainSubClassRule): * pango/opentype/harfbuzz-open.c (Load_ClassDef1), (Load_ClassDef2), (_HB_OPEN_Load_ClassDefinition), (_HB_OPEN_Load_EmptyClassDefinition), (_HB_OPEN_Free_ClassDefinition): Remove ClassDef->Defined field. This is the comment accompanying it: The `Defined' field is not defined in the OpenType specification but apparently needed for processing fonts like trado.ttf: This font refers to a class which contains not a single element. We map such classes to class 0. The comment is correct that trado.ttf (MS Traditional Arabic) uses such classes. However, in my testing I couldn't identify any problems with the font if the special handling is removed. I also processed as many fonts as I could get my hand on and trado.ttf was the only not-totally-broken font hitting the special-case code. DejaVu fonts hit it too, but I'm sure they do not require the special-handling code. Most probably, that code introduces bugs in them. The special-casing was consuming lots of memory. EIGHT MEGABYTES for loading DejaVu Sans! While this could be complete fixed, I decided to remove the special-handling code altogether. I don't think it will make any real difference, and if it does, we'll fix fonts. Such hacks will not be in harfbuzz-ng anyway. Bug originally reported by nsf.
Showing
想要评论请 注册 或 登录