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

[Lars Knoll]

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. 

Cheers,
Lars

lookupflag.diff
Description: Text Data