[Devel] Re: [Kannada] Re: Problem with freetype rendering of an Indic opentype font

[Owen Taylor]

On Mon, 2003-09-08 at 09:48, Lars Knoll wrote:
> On Monday 08 September 2003 01:39, Owen Taylor wrote:
> > On Sun, 2003-09-07 at 17:51, Lars Knoll wrote:
> > > On Sunday 07 September 2003 23:37, Arun Sharma wrote:
> > > > On Thu, Sep 04, 2003 at 10:24:10PM +0200, Werner LEMBERG wrote:
> > > > > > I see a problem with the freetype rendering of this unicode string:
> > > > > >
> > > > > > "0xcb7 0xccd"
> > > > > >
> > > > > > Using Microsoft tunga.ttf (A kannada font that ships with Windows
> > > > > > XP).  In fact, the problem manifests itself with all other
> > > > > > consonants too, including 0xcb7.
> > > > >
> > > > > I don't have time to investigate but it seems to me that some
> > > > > contextual shaping is happening.  If this is true it is not a problem
> > > > > of FreeType 2 (which doesn't support OpenType directly for the
> > > > > moment) but rather a problem one level higher where Indic scripts are
> > > > > handled, probably within the Pango library.  Owen?
> > >
> > > I did some investigations and the problem seems to lie within the
> > > freetype 1 open type code used by Qt and pango. The font uses chain
> > > substitutions to achieve correct rendering of this combination and these
> > > seem to work incorrectly. Up do now I didn't find time to dig into this
> > > in more detail.
> >
> > I just recently applied a patch to Pango for Chain Context substitutions
> > that apparently was needed for Kannada -
> >
> > http://people.redhat.com/otaylor/opentype-patches/pango-26-chain-format3
> >
> > (from Kailash C. Chowksey.) Could that fix the problem here? (That patch
> > is in Pango-1.2.5)
> 
> No, the problem was actually unrelated to the chaining substitutions.
> 
> > http://bugzilla.gnome.org/show_bug.cgi?id=118592 also comes up for
> > tunga.ttf, though we haven't come up with a final patch for that.
> 
> I have debugged the problem today, and found that the problem lies somewhere 
> else than I first guessed. tunga.ttf has a ligature for the character 
> combination quoted above. The lookup table for the ligature has a LookupFlag 
> of 0x0100, so it should skip marks that do not have a MarkAttachmentClass of 
> 0x01. The 0xccd character however is a mark according to the gdef table, but 
> has no MarkAttachmentClass defined.
> 
> Thus TT_GDEF_Get_Glyph_Property() return 0x8 for the glyph, and the 
> Check_Property() call fails Lookup_LigatureSubst. Seems like we have to 
> ignore the high byte of the LookupFlag if the glyph has no 
> MarkAttachmentClass (the specs are not really clear about this IMO).
> 
> I've attached a patch that fixes the problem and gives correct shaping of the 
> above glyph combination. 

I think you accidentally sent the wrong patch, since 99% of it had
nothing to do with this, but searching for 'opentype' in the patch,
I find:

===
@@ -1169,10 +1169,9 @@
        * the attachment type specified."
        */
       desired_attachment_class = flags & IGNORE_SPECIAL_MARKS;
-      if ( desired_attachment_class )
+      if ( desired_attachment_class && (*property &
IGNORE_SPECIAL_MARKS) )
       {
-       if ( basic_glyph_class == TTO_MARK &&
-            *property != desired_attachment_class )
+       if ( *property != desired_attachment_class )
          return TTO_Err_Not_Covered;
       }
     } else {
===

Hmm, I *guess* you could interpret the opentype spec that way - 
the text is:

  If not zero, skips over all marks of attachment type 
  different from specified.

Perhaps that means:

  If not zero, skips over all marks that have specified
  attachment type that is different from the type specified
  here. (Marks not in the MarkAttachClassDef table are
  not skipped.)

I think it would be very much worth suggesting that the spec be
fixed here, since the current text is unclear. Last time I had
a fix for the spec, I sent it to address@hidden, which
eventually got to the right place.

Regards,
                                        Owen