Bugzilla Bug 11785

The Write activity in OLPC XO sometimes shows strange characters instead of
Arabic characters. Forcing a re-render (like selecting the text and changing
the font) seems to get the correct rendering back.

This is not reproducible always - sometimes it works fine, and sometimes it
does not.

I have seen the exact same symptoms with other scripts as well (eg: Amharic).

Created an attachment (id=4685) [details]
Screenshot of garbled rendering

Could you please repeat this test with the DejaVu sans font? In my tests DejaVu
Serif does not contain glyphs for Arabic. The bug appears to be caused by
incorrect font substitution.


In any case please let me know if you can trigger the bug with the DejAVu Sans
font.

Thanks!

Martin

I finally got a chance to look into this deeply. Here's what I think is
happening. (All the methods I refer to are in
src/af/gr/xp/gr_CairoGraphics.cpp, as in Abiword trunk)

The font substitution is happening properly (eg: if the user selected font is
Deja Vu Sans, but the glyph is present in Mothanna, Mothanna does get selected
by GR_CairoGraphics::shape)

However, in GR_CairoGraphics::renderChars the rendering (on-screen drawing) is
done with the user selected font instead (to be exact, the previously selected
font). Since GR_CairoGraphics::renderChars handles GlyphIds instead of
characters, and since GlyphIds will differ from font to font (especially for
complex script fonts), the resultant output is garbage.

Some more investigation makes me believe that
GR_CairoGraphics::_adjustedPangoFont is to blame here. I simply comment out

        if (pFont == m_pAdjustedPangoFontSource &&
                m_iAdjustedPangoFontZoom == getZoomPercentage())
        {
                return m_pAdjustedPangoFont;
        }

and it seems to work fine both for trunk as well as the version of Abiword we
ship with the stable XO builds (the filename was different for the older
abiword).
I'm not at all familiar with the Abiword code and coding standards - so could
you possibly look into this ?

This affects all CTL languages and not just Arabic - I did most of the testing
with Bengali, which is my native language.

Some of us needs to review this. Would be awesome to have it working in 2.8.3.

I'll take this.

Created an attachment (id=5241) [details]
Sample document

For future reference on how to reproduce this:

1. Load the attached document (it came from bug 6987)
2. At the very beginning of this document, insert the character "1"
3. Save the document, close it, and reopen it.

=> The document will look all garbled, similiar to the screenshot attached to
this report.

Fixed in trunk, and will be backported to 2.8.4 soonish. Please test it.

The problem was indeed in GR_CairoGraphics::_adjustedPangoFont() and
_adjustedLayoutPangoFont(), but in a slightly different way than mentioned in
comment #3.

What was really going on is the following:

1. _adjustedPangoFont (GR_PangoFont * pFont, PangoFont * pf) is supposed to
return the correct PangoFont given A) the font of the textrun (pFont) that is
selected in the document, and B) the font (pf) that Pango substituted in its
place. Given that a substituted font pf is always returned by pango as a 12pt
font, we have to scale it to the proper size depending on the zoom. This
function will do that, and cache the result.

2. It is in this caching that lies the problem. If we create the sample
document as described in comment 6, trap the calls to _adjustedPangoFont(), and
print the name of the pFont and pf, we get for the first line of text:

Requesting adjusted font for "Loma", pango selected font is "DejaVu Sans 72"
Requesting adjusted font for "Loma", pango selected font is "Waree 72"
Requesting adjusted font for "Loma", pango selected font is "Waree 72"
Requesting adjusted font for "Loma", pango selected font is "Waree 72"

3. What we see here is that the first line of output is for the "1" character
in the document. The other 3 lines are for the 3 Thai textruns in the document.
Because of the first output line, the old font caching mechanism now cached for
font "Loma" at size X and zoom Y, the font "DejaVu Sans 72" at size X and zoom
Y. As soon as it needed to render the Thai textruns, the wrong cached font was
returned (the DejaVu one).

4. As an additional test, remove the "1" from the document, save it, and reopen
it. You can see that the output is correct now. Only "Waree 72" fonts are
substituted in the document now, which hides the caching bug.

=> The proper way of caching is the font is obviously NOT caching the pango
font belonging to "source" font at size X and zoom Y, but caching the pango
font belonging to the *replaced pango font* at size X and zoom Y.