GNOME Bugzilla – Bug 307469
non-english characters displayed as boxes under wimp theme
Last modified: 2005-08-09 20:07:05 UTC
I have been getting reports from my users that non-English characters display as boxes when using the wimp theme. Well I turned on the wimp theme, and that was in fact the case. Any Japanese that I typed into GTK would display as boxes. I tried this on windows 2003, but most of the users who reported it are on windows xp. (Using GTK 2.6.7)
I guess the problem is that the ms-windows theme engine, if I understand correctly, overrides the font names like "sans" and "serif" that GTK+ uses (and that are mapped in pango.aliases to a list of fonts that cover various scripts) into just the single font names returned by SystemParametersInfo(SPI_GETNONCLIENTMETRICS). Perhaps it should ask for the alias list from Pango (is this possible in the Pango API, I don't know) and append those to the font name from SystemParametersInfo(). On the other hand, maybe one could also say that this is not a bug? If one uses the ms-windows theme engine, that means one wants to use the fonts selected in Display Properties for GTK+, too, and if those fonts then doesn't cover the characters one actually needs, tough. Another point is whether it actually makes sense to use the fonts returned by SPI_GETNONCLIENTMETRICS, which as the parameter name says, are for the *non-client* area of a window, for GTK+ stuff, which most definitely is in the *client* area? Maybe the ms-windows theme engine shouldn't touch fonts and only handle colours and button shapes etc?
Quite probably implementing font fallback or font linking as is mentioned in bug #162681 might help here, too.
I didn't realize the ms-windows theme (it's not called wimp anymore?) used the non-client font. The non-client "text" font on Japanese Windows (I don't know what it is on other systesms) is Tahoma. Tahoma certainly does not contain Japanese, and many other character sets.
I guess it's normal to have Japanese in title bars in Japanese Windows? If this works even if the title bar fonts are set to Tahoma, this means that the magic font fallback or fonr linking mechanism in Windows substitutes other fonts (without user control as to which ones?) for characters not in Tahoma.
Yeah. Even though the title font is Tahoma, Japanese characters are often displayed in the title bar.
I just created a simple MFC application and the controls are using the "System" font... even then I can enter Japanese text just fine. So it does seem to be a matter of substition.
A workaround that we use in the GTK+ runtime that WinGaim distributes is to add a line: tahoma = "tahoma,arial,browallia new,mingliu,simhei,gulimche,ms gothic,latha,mangal" to the pango.aliases file.
Yeah. I already told the maintainer of gimp-win about that a while back (after emailing the glade gtk maintainer) and his GTK packages now include that line by default. I think at this point all gtk windows runtimes now include that line so that this problem should be gone when users upgrade. The problem now is the order of the fonts in that line. For example Japanese text is displayed using the "minglui" font, but the Japanese characters in the minglui font are not that good. (Minglui is a Chinese font). That's outside the context of this bug though.
I believe that this is bug #162681/bug #311651. It just happens that gtk-wimp's choice of fonts triggers these other bugs. *** This bug has been marked as a duplicate of 162681 ***
> I think at this point all gtk windows runtimes now include that line But why stop at tahoma then? Shouldn't one have a corresponding line for all fonts bundled with Windows?
I believe "Tahoma" is the default non-client area font on modern Windows OSes which would mean adding just that one alias fixes most cases of boxes being displayed instead of the appropriate characters. (Of course it does not fix all cases.)
Just want to drop a note. Sometimes ago I emailed Tor that I would patch pangowin32-fontmap to fully utilize the native font-mapping and font-linking mechanisms on Win32 (and a little gain of performance). It's almost finished and I think I need a Saturaday more. It will probably solve the problems metioned above, and bug 310700 as well.