From: Shriramana S. <sa...@gm...> - 2012-07-27 10:50:33
|
Hello Martin and others. I've since filed two bugs which are clearly integration issues of Gr2 into LibO and not problems with Gr2 itself, but while double-checking the bug this thread is about, I come to suspect maybe it's a problem with Gr2 after all and not with LibO-Gr2-integration. Please find test material at https://sites.google.com/site/jamadagni/files/temp/krishna-tamil-reordered-attachment-test-3.zip Note the terminal output (which you can check on your system): <quote> $ gr2fonttest -codes font-has-ai-attaching.ttf b95 bc8 bxc8 Text codes b95 bc8 pos gid attach x y ins bw chars Unicode 00 95 1@655,0 7.7 0.0 1 30 1 1 bc8 bc8 01 65 -1@0,0 0.0 0.0 0 30 0 0 b95 b95 Advance width = 19.0 Char Unicode Before After 0 0B95 1 1 1 0BC8 0 0 </quote> Looking at the last two columns, it would appear that the reordering is correctly done, since the input order is B95 BC8 whereas the output order is BC8 B95, but observe the x positions! B95 is at x=0 and BC8 is at 7.7. Surely BC8 should be at 0.0 because it has been reordered to go before B95?! Again a recap: The input sequence is B95 BC8. BC8 VS_AI is reordrant and goes before B95 KA. So entering the positioning table (see gdl-has-ai-attachment.gdl) the glyph order is BC8 B95. Line 200 is intended to attach the preceding BC8 (which is a vowel sign) to the following B95 (which is a consonant) because I want to use their composite metrics in the next pass. Lines 208 and 209 in pass 2 attach a following combining mark above the cluster of KA + VS_AI. They function correctly. The problem is created at line 200 which is however syntactically and logically correct -- it seems to be the processing of this command that is faulty. Perhaps the processing assumes that an attached-to glyph will always precede an attached glyph? -- Shriramana Sharma |