GNOME Bugzilla – Bug 121060
Ligature Second Anchor Point in OpenType GPOS Table
Last modified: 2010-06-07 20:47:31 UTC
In OpenType GPOS table, in lookup type 5 ( Mark2Liga ), It defines an anchor point for each of the components of the ligature. But pango doesn't support this , it just mentions the first anchor point in Mark2Liga lookup. I test this by VOLT arabic font (arabic.volt.ttf) that comes by msvolt package. ( It is not distributable , so I won't attach it)
Hmm. - Since Arabic GPOS is only done with the patches in bug 117282, I assume you are referring to that. - The OpenType code in Pango does have support for MarkLigatureAttach records see - Lookup_MarkLigPos(), but currently there is no way of getting ligIDs/ components information from GSUB to GPOS, so we probably need some changes to the pango_ot_ruleset_position()/pango_ot_ruleset_shape() interfaces to handle that. - There may also be some problems with the ligIDs/ components code in the opentype/ directory. See the qt-ligature-components entry in: http://people.redhat.com/otaylor/opentype-patches/
I see this code in Lookup_LigatureSubst function of pango/opentype/ftxgsub.c : ... if ( i == j ) { /* We don't use a new ligature ID if there are no skipped glyphs and the ligature already has an ID. */ if ( in->ligIDs[in->pos] ) { if ( ADD_String( in, i, out, 1, &lig->LigGlyph, 0xFFFF, 0xFFFF ) ) return error; } else { if ( ADD_String( in, i, out, 1, &lig->LigGlyph, 0xFFFF, in->max_ligID ) ) ^--- ???? return error; (in->max_ligID)++; } } else { if ( ADD_String( in, 1, out, 1, &lig->LigGlyph, 0xFFFF, in->max_ligID ) ) ^---- ???? return error; ... Why didn't you pass the lig->LigGlyph as ligID to ADD_String instead of in->max_ligID ?
I think We have to make some changes to solve this bug: 1. To save the component number of each glyphs in GlyphString, we have to add an attribute to PangoGlyph structure (I named it "component"). 2. After applying ligature substitution, we have to trace the glyphs after the last component to make their component number valid. 3. After gsub rules applied, before giving glyph string back up to engines, in "pango_ot_ruleset_substitute" function, we have to copy the component number of each glyph in the TT_GSUB_String to the GlyphString's glyph component number. 4. In entry of "pango_ot_ruleset_position" function, we have to copy back the GlyphString's glyph component number back to the input TT_GSUB_String. I've attached a patch, but because my Pango is just a local cvs copy, maybe the patch cannot be applied so the changes can be applied by hand. I've also attached a screenshot of an 3-component Arabic ligature ( LamLamShaddaHeh) with many marks entered to show this. Best Regards
Created attachment 23762 [details] [review] Ligature Second and more Anchor Point
Created attachment 23763 [details] A three component ligature sample
Changing PangoGlyph like this actually doesn't work, since that's an ABI change. (The glyphs->glyphs array is public, if you change the size of PangoGlyph, old code that indexes the array will get garbage) What I decided to do to handle this case is have a PangoOTBuffer object that holds the information across substitution and positioning, and only write the glyphs into the PangoGlyphString at the very end. I had this implemented a few months ago, then lost the patch when my laptop harddrive died, and just redid it again from scratch. I'd very much appreciate if you want to test the code I just checked into CVS. (It will be in the Pango-1.3.5 I do tomorrow as well.)
Soheil, this was fixed looooong time ago. Please test and open a new bug if something is not working.
Sure, I will take a look at it.