Red Hat Bugzilla – Bug 61538
gedit does not like unicode fonts
Last modified: 2014-03-16 22:26:12 EDT
Steps to Reproduce: 1. run gedit 2. set default font to something unicode (iso10646-1) 3. type in some text Actual Results: Your text looks fubar Expected Results: Your text should not look fubar.
Owen may correct me, but I believe this is expected with GTK 1.2.
Huh? Why whould switching the font charset from iso8859-1 to iso10646-1 change text that is *only* in iso8859-1 characters to boxes?
Well, that's the way it is.... you have to have a font that matches the encoding of the locale. Some things can just truncate an iso-10646-1 font and get a iso-8859-1 font by luck, GTK+ doesn't support that. (Without looking at the gedit source code, I don't know the full details, but it appears that it is using gdk_font_load() rather than gdk_fontset_load(), since otherwise it would be replacing the iso10646-1 with iso8859-1 and probably get a useable font.)
This bug was in all of 7.x, gnome-terminal has the same issue, I don't think it's something we want to fool with for hampton. Switching to fontset might break other stuff.
I'm still bafffled. gnome-terminal works *perfectly* with iso10646 fonts.
It works if you have "enable multibyte support" but not if you don't. which is essentially gdk_font_load() vs. gdk_fontset_load()
Oops, it's the other way around, it works if you _don't_ enable multibyte support. But we enable it by default. But that's inconsistent with what Owen said since multibyte support means fontsets.
Owen says the unknown chars are caused by gdk_font_load() in combination with gdk_draw_string() which expects the string to be in a 16-bit encoding. gnome-terminal uses gdk_draw_char() or XDrawString() or something so doesn't have this issue with gdk_font_load().