Re: Problems w/ Mangal?

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.

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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]