GNOME Bugzilla – Bug 50834
gdk_text_width_wc is broken for chars with 8bit set
Last modified: 2011-02-04 16:09:10 UTC
URL of the message in gtk-devel-list: http://mail.gnome.org/archives/gtk-devel-list/2000-August/msg00164.html With current code, for fonts that are not fontsets and 8bit chars with high bit set, width of strings is measured incorrectly. Owen agreed to apply this patch.
(I didn't agree to apply the patch. I agreed to decide whether to apply or reject patch or not before 1.2.9)
Created attachment 320 [details] [review] Patch changing handling of GDK_FONT_FONT and _wc() functions
The patch in the mail doesn't cover nearly all the cases where the code does simple assignment to handle the case of converting from wide characters to indices into a GDK_FONT_FONT. The new attachment tries to go about this more comprehensively. My reservations about this patch are: - It's big - It makes the common operation of gdk_char_width_wc() on ascii much, much, slower. Testing of it to make sure that it really fixes the complaint of this bug would be appreciated, in any case.
attempt to add any comment..
Hello Owen, I'm testing it right now. After applying it to vanilla 1.2.8, panel chashes (SIGSEGV) when I press the button with 'foot' on it (each time I press it, each time it crashes). If I don't apply your patch, panel works fine. You patch of course fixes the problem of of truncating labels, thank you very much. Here is a backtrace of panel when it crashes:
+ Trace 3935
Here is a patch to fix that bug. Everything seems fine now. As for slowing down operations on ascii - a special branch could be written.. (or gdk_use_mb set to 0). --- gdkim.c~ Thu Feb 22 00:00:45 2001 +++ gdkim.c Thu Feb 22 00:00:33 2001 @@ -1520,7 +1520,7 @@ src_wc = g_new (wchar_t, length + 1); - for (i = 0; i <= length; i++) + for (i = 0; i < length; i++) src_wc[i] = src[i]; src_wc[i] = 0;
OK, thanks for the fix. Yes, it's pretty easy to optimize the 8bit case - assuming functional locale support (something that most of us have the luxury of assuming now.) However, GTK+-1.2's gdk_wcstombs, etc, were written assuming the kind of completely busted, barely functional locale support that was common 2-3 years ago on Linux, and I think it's rather later in the GTK+-1.2 cycle to change that now. As for changing the gtkrc.* fonts. I have mixed feelings. Yes, it's bad that gnomecc doesn't work, but that could be fixed by making it write fontset not font for some locales. I'll send some mail to Pablo Saratxaga who maintains those files and ask for his opinion. I have no idea what the AA patch is doing for internationalization (or which AA patch you are referring to.) I actually don't think Xft has support for non-unicode encodings currently, so whether you use fonts or fontsets, it certainly will require extra code to get internationalization working. see how changing this would matter.
As for optimizing for ascii - I think just setting gdk_use_mb to 0 for locales with iso-8859-1 should do the trick (and it will be ideologically-correct solution IMO). No functional locale support required at all from the system for it to work, I think. As for fixing gnome themer applet to make it fontset-aware - I think it will be impossible to do it right (without hardcoding mapping between locale and must-have items of fontset - which is ugly). So I really think that removing fontset definitions from gtkrc.* is the only clean solution. As for AA patch - I looked at Ximian's patch - yes, it doesn't have support for wide fonts at all, and it seems that it does not to support fontsets at all too. But it's full of conversion form wchars to chars via plain assignment (this is easily fixable, of course). And it won't be surprising if Xft doesn't support fontsets at all. So, sticking to fonts for 8bit locales is a very nice idea.
I've applied the patch to CVS, along with an additional change to add a --with-native-locale option to configure, which, on non-broken systems, speeds up mb<=>wc conversion operations a lot. I'm not going to change the gtkrc.* files now, because I don't think it's possible to get sufficient testing to know the effect of that change at this point. I do consider this something that someone packaging GTK+ might want to change if they know what fonts will be present on the destination, and of course, people using GTK+ can always edit their own /etc/gtk/gtkrc.* files to suit.
Owen, I'm sorry for so late bug report - it appears gtkentry is totally broken after your patch (not that it broke gtkentry - gtkentry was broken before too) - it draws characters incorrectly after applying your patch. It's because gtkentry uses {text,width}_wc unconditionally (independant of the entry->use_wchar). My original hackish patch didn't reveal the bug since it only touched char_width_wc (used by gtklabel). The only quick way to fix gtkentry is the following patch: --- gtkentry.c~ Thu Jan 27 18:39:54 2000 +++ gtkentry.c Tue Feb 27 16:51:57 2001 @@ -363,7 +363,7 @@ entry->char_offset = NULL; entry->text_mb = NULL; entry->text_mb_dirty = TRUE; - entry->use_wchar = FALSE; + entry->use_wchar = TRUE; gtk_entry_grow_text (entry); } I'm sorry for so late report.