GNOME Bugzilla – Bug 121488
Thai modules display garbage
Last modified: 2004-12-22 21:47:04 UTC
Symptom: Thai-xft and thai-ft2 modules display all Thai characters using "unknown glyphs" (boxed hexadecimal of their 8-bit TIS-620 codes) instead of correct Thai glyphs. My analysis: thai-x, thai-xft, and thai-ft2 share the same object file thai-shaper.lo, but the header file thai-shaper.h is preprocessed differently by the HAVE_X macro. As a result, the struct _ThaiFontInfo defined in the header varies its structure across the compilation units. The thai-shaper.lo is generated by the first build, which appears to be thai-x in the Makefile. Thus, the struct appears fine for it, but the rest ones access different struct. And the assignments of pointers to functions are shifted, which appears to assign the make_unknown_glyph() function to the offset of make_glyph() function pointer member as seen by thai-shaper.lo.
A remedy: Make it more object-oriented. The extra element of the X backend should be made in a somewhat "derived class". However, considering the trivialness of the single extra member, a simple workaround might help, by moving the extra element to the end of struct, as in the attached patch.
Created attachment 19742 [details] [review] A workaround patch
Note that the code is entirely different in CVS HEAD, so complicated fixes to gtk-2-2 probably don't make sense. I think the simplest thing woudl be simply to include "config.h" in thai-shaper.h.
I think the problem is the content of thai-shaper.lo itself. There should be only one version of it. So, I think removing any preprocessing from it should be done. And I've prepared another patch that does that. (Yes, I realize the difference with CVS HEAD. Hoping the fix is not too complicated.)
Created attachment 19760 [details] [review] Removing preprocessing from thai-shaper
Is it really worth rewriting stuff in the 1.2.x branch, which will shortly be dead. All that is needed, to fix the problem, is, I think: --- pango-1.2.5/modules/thai/thai-shaper.h.thai 2003-09-08 12:04:55.000000000 -0400 +++ pango-1.2.5/modules/thai/thai-shaper.h 2003-09-08 12:05:01.000000000 -0400 @@ -1,6 +1,8 @@ #ifndef __THAI_SHAPER_H__ #define __THAI_SHAPER_H__ +#include "config.h" + #ifdef HAVE_X #include "pangox.h" #endif
OK. It does work. (Sorry that I didn't get the point in the first place how it works.) So, provided that only the type, not any function, from pangox is referenced in thai-shaper, this should be fine. (Otherwise, the linking error would come back again.)
Please proceed to close this bug. Its seriousness for Thai users is comparable to security fixes. (In fact, it's serious enough to be a measurement for which distro is the quickest in fixing it. And we have got a winner. :-P)
If you want to commit a fix to the pango-1-2 branch, that's fine with me. Otherwise I'll get to it next time I do a stable release. [ For Red Hat, the patch is in our CVS repository since 8 September, and the RHEL 3 beta 2 Pango RPMS. But it really doesn't matter much since we don't ship any scaleable Thai fonts...]
Well, I don't have a commit account. So, I need your hands for this.
[BTW, in case you want to include some Thai scalable fonts in Red Hat, you may get some from ftp://linux.thai.net/pub/thailinux/software/thaifonts-scalable/ or for cvs snapshot: cvs -d :pserver:anonymous@linux.thai.net:/home/cvs co software/thaifonts-scalable version 0.4.0 is just gonna been released soon. Any suggestion is appreciated.]
I've applied the fix in CVS now, though I don't think I'll be doing another Pango-1.2.x release.