Menu
▾
▴
#39 Advancewidth can Vanish in Graphite2
The referenced files are held within the attached gzipped tar file.
The same font causes text to render quite differently for some fonts between LibreOffice 3.3.2 on Linux, which I believe contains the original Graphite
rendering engine, and LibreOffice 3.4.4, which I believe contains Graphite2. In the new rendering, certain characters end up with zero or negligible advance width.
The example text consists of two lines. The first and third are blank and the second is a row of U+0E01, a Thai consonant. I attach the file as collapse.odt.
The example Graphite definition is in ex.gdl, and is reproduced here:
table(glyph)
g1 = pseudo(codepoint("b"), U+0E01);
gc = codepoint("c");
gd = codepoint("d");
endtable
table(substitution)
gc > gd;
endtable
To reproduce, create the Graphite font by taking any non-Graphite true type font not containing a glyph for the character U+0E01 (I took Phetsarath OT),
and generate the Graphite font by the command:
1. grcompiler -d ex.gdl /usr/share/fonts/truetype/ttf-lao/Phetsarath_OT.ttf ex.ttf AAspeck
(Obviously, use the appropriate input font file name.)
2. Induce your system to make the font available to you.
3. Open the file in LibreOffice 3.3.2. You *see* one rows of *b*'s between two blank lines, as recorded in ex1.pdf. This is the expected behaviour.
4. Open the file in LibreOffice 3.4.4. You see one very thick 'b', as recorded in ex2.pdf. This is not the expected behaviour.
The debug files are also included. The problem also appears with LibreOffice 3.5.0 Beta 2. The files provided were generated using Version 4.0 of the Graphite compiler, but the same behaviour was also seen with Versions 2.4 and 4.1.
Operating system: Ubuntu 10.04, i686, kernel version 2.6.32-37-generic. Libreoffice 3.3.2 is fully installed.
Gzipped tar file holding related files, other than font file itself.
This is a libreoffice integration bug. gr2 engine itself seems to handle this situation perfectly happily.
The attached file, awbugfix.zip, contains a simpler example, ex3.gdl, that will demonstrate the bug with any true type font supporting 'b' and having glyphs for 'c' and 'd'. It should cause 'd' to display as 'b', but the bug results in the glyphs having zero advance width. This example avoids testing complications caused by changes of script within a run.
The bug corrections are included in the files Slot.cpp and gr_slot.cpp, my corrections of the corresponding Graphite2 Version 1.0.3 (bis) files. In both files, the problem is that the (post-hinting?) advance width may be looked up by pseudoglyph ID rather than the corresponding real glyph ID. The bug in gr_slot.cpp has a very small effect, while the bug in Slot.cpp has the readily visible effect.
Unfortunately, I don't have a smaller test bed than LibreOffice 3.4.4, for which I have demonstrated that they fix the problem (at least, if built without Java). The changes correct the problem in both my new test case and in the font in which I originally encountered the problem.
Solution + GDL file for a simpler example