Re: Problems w/ Mangal?

[Eric Mader <mader jtcsv com>]

At 03:11 PM 1/31/2002, Owen Taylor wrote:

> Eric Mader <mader jtcsv com> writes:
>
> > I've got my indic-xft shaper limping along. It seems to shape well,
> > but when I display Hindi text using an IBM Devanagari font
> > ("Devanagari MT for IBM" - built for IBM's JDK) the text display looks
> > pretty bad. In particular, the placement of the long-I matra looks way
> > off. (And there's no hinting; TrueType Devanagari fonts tend to look
> > pretty bad w/o hinting...)

The problem with the long-I matras was with my shaper. I was setting the 
geomerty of the glyphs *before* calling pango_ot_ruleset_shape, so any 
glyphs that got substituted were displaying with the wrong advance...

> Unfortunately, that is a problem we can't solve within the scope
> of Pango since it's a legal one not a technical one.
> (http://www.freetype.org/patents.html)
>
> Its a reasonably simple matter to recompile FreeType with hinting on.
>
> There have been some improvements in the FreeType autohinter recently
> since the version shipped in Red Hat 7.2, but I suspect they probably
> won't help much here since the autohinter is really tuned for
> roman type.
>
> > In an attempt to see if this was a font problem (though the font
> > *does* display correctly on Windoze ;-) I tried using Mangal
> > instead. With Mangal, I get this error: "Error loading GSUB table
> > 4097" (TTO_Err_Invalid_SubTable)
> >
> > I've narrowed the error down to a bad ClassRangeRecord in
> > Load_ClassDef2 in ftxopen.c. I've tried dumping the GSUB table using
> > the tools on Windows, and I don't see the error that this code is
> > reporting - I suspect that ftxopen is getting lost somehow and isn't
> > really reading what it thinks it is...
> >
> > Has anyone else seem this kind of a problem with Mangal?
>
> Without any shapers that could use Mangal, probably not. :-)
>
> And if there is is any portion of the code I'd expect to have
> bugs when not thoroughly tested, it would be the handling of
> 'GSUB Chaining Context Substitution Format 2: Class-based Chaining
> Context Glyph Substitution', which is just about as complex
> as OpenType gets. (And that's saying a lot...) :-(
>
> Looking into this a little bit, I _think_ what is going on is that
> pango/opentype/ftxgsub.c:Load_ChainContextSubst2() is not handling
> that if lookahead_offset (and presumably the other similar offsets)
> are 0, then the class is empty. I can't find any reference to that in
> the docs for this particular table, but it seems to be a common
> convention in the OpenType format and would make sense with the
> values in mangal.ttf.

I'm on my way out the door at the moment. I'll look at this tomorrow; I can 
compare with the code in my engine, which seems to work OK on Mangal.

> I tried fixing that, but then it died a bit later. It might be
> useful to have the dump of the font when debugging this; otherwise,
> it's probably just a lot of staring at the code. The diff I was
> working with is attached ... most of it is just freeing some problems with
> memory cleanup on error.

I tried to generate a "fresh" dump of the GSUB using MS's old TTODASM tool, 
and it just yelled at me. I pulled down an old one from my work machine and 
looked at that, but I can't guarantee what version of the font it's from. 
I'll look into this some more tomorrow, too.

FWIW: I changed the code that was returning an error to just pin the values 
to something legal instead, and the Mangal seemed to work. I guess I was 
just lucky and it didn't need the part of the table it couldn't parse... :-)

An interesting point here: my engine word-swaps values on the fly, while 
processing the subtables, so it would never trip over any mal-formed pieces 
of subtables that aren't used... Safer, perhaps a bit easier to code, but 
may be slower, depending on just how much of the table acutally gets used.

> Regards,
>                                         Owen

Eric