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
Your text looks fubar
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().