[Indic-computing-devel] Re: [Kannada] Re: Problem with freetype rendering of an Indic opentype font

[Dr. U.B. P. <pav...@vi...>]

> 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).

What is meant by MarkAttachmentClass? When we design the 
Opentype font, normally we use Microsoft VOLT and define the 
glyphs there. As you correctly pointed out, 0xccd is defined as 
Mark. This will define the glyph as Mark in the GDEF table. How 
to add the MarkAttachmentClass? Which tool are you using to dump 
the embedded tables of the OTF? Is it TTX? 

BTW, I did not develop Tunga.ttf :-)
 
> I've attached a patch that fixes the problem and gives correct shaping of the 
> above glyph combination. 
> 
> Cheers,
> Lars


Rgds,
Pavanaja-----------------------------------------------------
Dr. U.B. Pavanaja
Editor, Vishva Kannada
World's first Internet magazine in Kannada
http://www.vishvakannada.com/

Note: I don't worry about pselling mixtakes