Your message dated Sat, 28 Feb 2009 15:56:03 +0000 with message-id <[email protected]> has caused the report #517535, regarding pterm: Double-encodes utf8 input when run in an utf8 locale to be marked as having been forwarded to the upstream software author(s) [email protected]
(NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 517535: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517535 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---On Sat, Feb 28, 2009 at 01:56:25PM +0100, Tollef Fog Heen wrote: > Package: pterm > Version: 0.60+2009-02-22-1 > > The recent new upload of putty broke input of UTF-8 characters when run > in an UTF-8 locale where I now get double-encoded UTF-8. If I run it in > the C locale, I can input UTF-8 just fine, but when run in the > nb_NO.UTF-8 locale, I get the broken behaviour. > > I've verified the double-encoded input by cat-ing to a file as well as > using locale-aware applications such as emacs and irssi. Ah, is *that* what this is? I'd noticed some similar problems but not got round to tracking it down. -DKEY_DEBUGGING says: keypress: keyval = 00f6, state = 00000000; string = c3 b6 generating sequence: c3 b6 ... but that's interpreted as ISO-8859-1: if (!use_ucsoutput) { /* * The stuff we've just generated is assumed to be * ISO-8859-1! This sounds insane, but `man * XLookupString' agrees: strings of this type * returned from the X server are hardcoded to * 8859-1. Strictly speaking we should be doing * this using some sort of GtkIMContext, which (if * we're lucky) would give us our data directly in * Unicode; but that's not supported in GTK 1.2 as * far as I can tell, and it's poorly documented * even in 2.0, so it'll have to wait. */ if (inst->ldisc) lpage_send(inst->ldisc, CS_ISO8859_1, output+start, end-start, 1); } else { /* * We generated our own Unicode key data from the * keysym, so use that instead. */ if (inst->ldisc) luni_send(inst->ldisc, ucsoutput+start, end-start, 1); } It appears, though, that in GTK+ 2.0 event->string is in the current locale (http://library.gnome.org/devel/gdk/stable/gdk-Event-Structures.html#GdkEventKey confirms this). How about this patch? Index: unix/gtkwin.c =================================================================== --- unix/gtkwin.c (revision 8469) +++ unix/gtkwin.c (working copy) @@ -1049,6 +1049,10 @@ ldisc_send(inst->ldisc, output+start, -2, 1); } else if (!inst->direct_to_font) { if (!use_ucsoutput) { + int charset; +#if GTK_CHECK_VERSION(2,0,0) + charset = inst->ucsdata.line_codepage; +#else /* * The stuff we've just generated is assumed to be * ISO-8859-1! This sounds insane, but `man @@ -1061,8 +1065,10 @@ * far as I can tell, and it's poorly documented * even in 2.0, so it'll have to wait. */ + charset = CS_ISO8859_1; +#endif if (inst->ldisc) - lpage_send(inst->ldisc, CS_ISO8859_1, output+start, + lpage_send(inst->ldisc, charset, output+start, end-start, 1); } else { /* -- Colin Watson [[email protected]]
--- End Message ---
