After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 121060 - Ligature Second Anchor Point in OpenType GPOS Table
Ligature Second Anchor Point in OpenType GPOS Table
Status: RESOLVED FIXED
Product: pango
Classification: Platform
Component: general
1.2.x
Other Linux
: Normal normal
: 1.4 API freeze
Assigned To: pango-maint
pango-maint
Depends on: 117282
Blocks:
 
 
Reported: 2003-08-30 12:33 UTC by Soheil Hassas Yeganeh
Modified: 2010-06-07 20:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Ligature Second and more Anchor Point (3.28 KB, patch)
2004-01-26 14:02 UTC, Soheil Hassas Yeganeh
none Details | Review
A three component ligature sample (77.20 KB, image/png)
2004-01-26 14:05 UTC, Soheil Hassas Yeganeh
  Details

Description Soheil Hassas Yeganeh 2003-08-30 12:33: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)
Comment 1 Owen Taylor 2003-09-03 15:42:17 UTC
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/
  
Comment 2 Soheil Hassas Yeganeh 2003-12-24 13:02:53 UTC
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 ?

Comment 3 Soheil Hassas Yeganeh 2004-01-26 14:01:01 UTC
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

Comment 4 Soheil Hassas Yeganeh 2004-01-26 14:02:26 UTC
Created attachment 23762 [details] [review]
Ligature Second and more Anchor Point
Comment 5 Soheil Hassas Yeganeh 2004-01-26 14:05:23 UTC
Created attachment 23763 [details]
A three component ligature sample
Comment 6 Owen Taylor 2004-02-29 15:48:53 UTC
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.)
Comment 7 Behdad Esfahbod 2010-06-07 20:07:17 UTC
Soheil, this was fixed looooong time ago.  Please test and open a new bug if something is not working.
Comment 8 Soheil Hassas Yeganeh 2010-06-07 20:47:31 UTC
Sure, I will take a look at it.