GNOME Bugzilla – Bug 161027
inadequate fallback mechanism of the win32 backend of pango
Last modified: 2011-03-02 21:35:35 UTC
As the attachment shows, the Chinese text "你好"(means "hello" in English) in the cell"A1" is garbage, while in the edit line is OK. if the cell is selected to modify, then the Chinese text is shown fine. Also, If a proper font is chosen for the cell, it would be shown fine. But it would be very boring that you must choose a font for each cell manually.
Created attachment 34731 [details] A snapshot showing the garbage text.
Could you create a sample workbook for us that shows the problem, please? (Adding it as attachment here would be perfect.)
Created attachment 34793 [details] the file shown in the last screenshot the sheet only contains one cell "A1" which is a Chinese word. So to display it, there must be Chinese fonts on your box. When I select the cell, the edit entry is shown fine, but the cell itself can't be displayed until you choose a Chinese font for it. However, if you double clicked on the cell to modify it, it would be displayed fine. It sounds a werid problem.
I get little boxes with hex codes in them for both cases. That is probably a sign of not having the right font.
i get little boxes without hex codes in them for both cases. this is probably a case where i don't have the right font.
At home (Gnumeric 1.3.92, SuSE 9.1) I get the right characters both in the edit line and in the cell.
I reported the bug for Gnumeric on windows, not on Linux. :)
Our default font is 'Sans' and we're not being terribly careful to ensure that it contains the necessary glyphs. owen : Is GtkEntry being smart enough to notice that the selected font does not have the glyphs or is it just using a better default font ?
With Pango/Xft you will never get hex boxes if any font on your system has the glyphs. Not really familiar with the details on Win32, Cc'ing Tor to comment there. The reason that the entry is working and the sheet not might be that the system default font is being picked up for the user interface and that is a Chinese default font. Ideally 'Sans' would combine together fonts to handle all languages, but I'm not sure if it will in practice.
gtk-wimp is smart enough to set the GtkEntry's font to your MS Windows font, which would have the necessary glyphs. that would explain the difference.
> gtk-wimp is smart enough to set the GtkEntry's font to your MS Windows font, > which would have the necessary glyphs. that would explain the difference. No, with the default "pango.aliases" from Tor, gtk-wimp doesn't display CJK as it uses the font Tahoma (which doesn't contain CJK characters): http://www.ivanwong.info/gnumeric/gnm_wimp.png On the contrary, as the default "pango.aliases" have these aliases: sans = "arial,browallia new,mingliu,simhei,gulimche,ms gothic,latha,mangal" serif = "times new roman,angsana new,mingliu,simsun,gulimche,ms gothic,latha,mangal" monospace = "courier new,courier monothai,mingliu,simsun,gulimche,ms gothic,latha,mangal" The "Default" theme is happy to display CJK (mingliu and simhei are Chinese fonts). I added one the following statement in pango.aliases of gnumeric-1.x.x- rcx.exe to make sure that gtk-wimp is ok with CJK too: Tahoma = "Tahoma,browallia new,mingliu,simhei,gulimche,ms gothic,latha,mangal" The problem described by Shixin can be explained by these two screenshots: http://www.ivanwong.info/gnumeric/gnm_def01.png http://www.ivanwong.info/gnumeric/gnm_def02.png I guess non-editing cells of Gnumeric are not rendered with pango.
> I guess non-editing cells of Gnumeric are not rendered with pango. I think I was wrong. e.g with these aliases: Tahoma = "Tahoma,browallia new,mingliu,simhei,gulimche,ms gothic,latha,mangal" Impact = "Impact,browallia new,mingliu,simhei,gulimche,ms gothic,latha,mangal" Selecting the fonts Tahoma or Impact in Gnumeric solves the problem (and of course, it doesn't work without those aliases) However, it's very interesting that with the default aliases of sans/serif/monospace, selecting sans/serif/monospace doesn't display those characters correctly.
This might also be yet another case of bug #152997, in case your Pango is 1.6.0? Did you get Pango binaries bundled with Gnumeric? Have you tried replacing them with the 1.4.1 binaries from www.gimp.org/win32/downloads.html?
Yes I use pango 1.6.0 in the Gnumeric package. However, since I am well aware of 152997 (I reported it), I did remove the implementation of the covers method before building. It has no problem displaying CJK in any official Gtk+ widgets.
Partially fixed: 2005-07-26 Ivan, Wong Yat Cheung <email@ivanwong.info> * src/style.c (style_font_new_simple): use pango_font_description_copy() so that we store the exact font description we pass to pango. Partially Fix #161027. However, it only guarantees that gnumeric uses the exact aliases on Win32. Users will still not be able to see Asian characters if he choose a Latin font due to the inadequate fallback mechanism of the win32 backend of pango.
#15 s/Latin font/Latin font which doesn't have a appropriate alias/
ivan, do you still face this issue (if so, which version are you running) or can this be closed as obsolete?
Yes, the problem Ivan mentioned in comment #15 still exists in Gnumeric 1.7.1 downloaded from http://www.gnome.org/~mortenw/gnumeric/gnumeric-1.7.1-win32-1.exe
(In reply to comment #17) > ivan, do you still face this issue (if so, which version are you running) or > can this be closed as obsolete? Yes, due to the same reason.
This bug should be retargeted at Product:pango and the Summary: shoud be made more correct. (Non-"Englishness" is not the issue here (after all, most of the common Latin script fonts in Windows contain lots of caracters that aren't used in English). Font coverage and fallback mechanisms is.) And actually, this bug probably then will in fact clearly be a duplicate of some already filed bug.
Tor : Good idea.
Tor: Like, dupe of bug 162681?
*** Bug 637166 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 162681 ***