GNOME Bugzilla – Bug 114737
ransom note typography for greek with Bitstream Vera
Last modified: 2004-12-22 21:47:04 UTC
Hello, GTK+ applications on my system, when displaying greek text on their menus, labels, etc., present an ugly "pi" character, which is noticably different compared to the rest of the letters. As far as I can tell, this problem seems to be caused by pango choosing this particular letter from Bitstream Vera. I'm fairly confident in saying this because: - The problem goes away when Vera is removed from the system. - Vera only contains the small "pi" and capital "omega" letters from the greek ranges, and its "pi" looks exactly like the one I see in my GTK+ programs. The same is probably happening with "omega", but it's not noticable, probably because the glyph doesn't stand out. Obviously, even though it lacks support for greek, Vera contains these two characters so that they can be used as mathematical symbols. This is probably the case with quite a few fonts in circulation. But in such cases, pango should find the first font that has *full* coverage of the language (as specified by fontconfig's lang=el tag), and use that instead. Thanks, Vasilis
Created attachment 17331 [details] Image illustrating the problem. Look at the label next to the third spinbutton.
Created attachment 17332 [details] Once I remove the ttf-bitstream-vera package, the problem goes away.
Either A) You fontconfig configuration is broken (could you attach your fonts.conf?) or: B) Fontconfig doesn't think your chosen Greek font supports Greek. (What does $ fc-list <FontName> family lang give?) I'd expect things to work properly if you explicitely choose your font in the GNOME control center, but we should figure out why it isn't working right be default.
Created attachment 17336 [details] Should be the stock Debian file (haven't touched it).
Looks fine. One final possibility is that you've actally picked 'Vera Sans' as your UI font (in the gnome-control-center, say) - if that's the case, then fontconfig will use glyphs from Vera whenever it can.
Hello, First of all, as far as the font configuration is concerned, I wouldn't think that it's what causes the problem. I haven't touched the fonts.conf file that comes with my distribution, and that in turn should be the original one, apart from some Debian-related directories. I see nothing suspicious in it, but I've attached it nonetheless so you can see for yourself. Other than that, how can I find the "chosen Greek font"? My setup is a standalone GTK+ one, i.e. I don't have GNOME installed. In addition, the only .gtk* file in my home directory is .gtkrc, which obviously is the 1.2.x configuration file. My guess on this is that there is no configuration for the font GTK+ uses, so it goes for its defaults. FWIW, I also tried running the program with my root user, whose home directory is *really* clean (runs X with twm etc.). Same effect. Thanks, Vasilis
Then could you run the fc-list command as I asked above? [ Note that this bug actally has exactly 0 to do with Pango ... you should get the same results with any program using fontconfig/Xft ]
Hello, Well, I can't really run the command you told me to, because I don't know which font to specify for it. That's what I was explaining in the previous comment. Nevertheless, here's something else which should help: $ fc-list :lang=el family | sort Andale Mono Arial Arial Black Comic Sans MS Courier New FreeMono FreeSans FreeSerif Georgia Impact Thryomanes Times New Roman Trebuchet MS Verdana That is, the only fonts that fontconfig recognises as suitable for greek are the MSFT ones, the FreeFont ones and Thryomanes. And rightfully so. Anyway, the cause of the problem is pretty obvious to me by now. GTK+/pango applications probably ask for Vera Sans by default, so they get the "pi" glyph anyway - you said that yourself. Politics aside, wouldn't sans-serif be a more reasonable default? Oh, and this doesn't happen with all Xft programs as you suggested. mozilla-xft, most notable, doesn't exhibit the problem. Thanks, Vasilis
The default GTK+ font is "Sans" (same as "sans-serif") and that is defined as is whatever you have configured in your fonts.conf. Perhaps Debian has a font setting in /etc/gtk/gtkrc-2.0? Further debugging of the problem on your system could be done by setting FC_DEBUG=1 (font matching debug log) or FC_DEBUG=2 (verbose font matching debug og).
Debian doesn't seem to have such a configuration file; /etc/gtk/ contains only gtkrc.* files (all of which belong to the libgtk1.2-common package), while an /etc/gtk-2.0/ directory contains other, seemingly irrelevant files (gdk-pixbuf.loaders and gtk.immodules). Following your FC_DEBUG suggestion, I've created a minimal gtkmm programs that illustrates the problem, which is the following: #include <gtkmm/main.h> #include <gtkmm/window.h> #include <gtkmm/label.h> int main(int argc, char *argv[]) { Gtk::Main kit(argc, argv); Gtk::Window window; window.set_border_width(8); Gtk::Label label("Πιπί"); window.add(label); label.show(); Gtk::Main::run(window); return 0; } I'll be attaching its output with FC_DEBUG=1 (about 10k uncompressed) as well as the compressed output with FC_DEBUG=2 (about 10k gzipped, 300k+ uncompressed).
Created attachment 17350 [details] Sample program output with FC_DEBUG=1
Created attachment 17352 [details] Sample program output with FC_DEBUG=2, gzip compressed
This is looking to familar to me: lang: 200 "el-gr"(s), aa|af|ast|ava|[...]|el|[...](s) The problem is that your language sets are showing up as string (s) instead of a langset so fontconfig is checking for equality between "el-gr" and that big long string, and it fails, even though "el" is in that string. We've seen this problem before, though I no longer remember the details. What version of fontconfig do you have? If it's recent, you might want to try running 'fc-cache -f' in case you have some old stale caches around. (If your windows fonts are on a windows partition make sure there isn't anything funny going on with writabiity there)
I have fontconfig 2.2.0, the latest package to have appeared in unstable. I tried running fc-cache -f, and then tried removing all instances of fonts.cache-1 and ran it again, but nothing changed. Also, all font and cache files are on reiserfs. The good news is that, thanks to your hints, I've managed to find a way to make the problem go away. I've created an entry of "el" in /etc/locale.alias (/usr/lib/X11/locale/locale.alias already has such an entry) and run the sample program with LC_ALL=el. This results to the "pi" letter being selected from the same font as all the other ones.
There was (another) bug in language matching in fontconfig which caused 'el-gr' to not match 'el'.
The fontconfig-2.2.1 package that Keith put out early today contains the necessary fix. Thanks for the report ... it's good that we got this resolved.
Reclosing with a more appropriate resolution. Sorry for the noise.