On Thu, Jul 08, 2004 at 05:13:53PM -0500, Branden Robinson wrote: > On Sat, Jun 26, 2004 at 08:04:27AM -0400, Thomas Dickey wrote: > > On Sat, Jun 26, 2004 at 07:10:07AM +0200, Roman S Dubtsov wrote: > > > Package: xterm > > > Version: 4.3.0.dfsg.1-5 > > > Severity: normal > > > Tags: l10n > > > > > > This is true at least in ru_RU.KOI8-R locale. I tried launching xterm > > > with "utf8: 1" and "locale: false" and then invoking luit. Before luit > > > was started, line-drawing characters were ok (but russian characters > > > were drawn as boxes). But when luit was running, all line-drawing > > > characters were replaces with letters (though I had my cyrillic letters > > > back). > > > > Regarding luit - this may be a duplicate of 254316 > > > > For the utf8 - that wouldn't work. > > > > I posted a script adapting uxterm to ru_RU.KOI8-R locale a while back, > > using the resource setting > > > > *VT100*allowC1Printable: true > > > > with terminus fonts. > > Is this a bug in XTerm, then? What should I do about this report? There are a couple of issues here: The one I was commenting on was the one relating to the allowC1Printable resource. It's not a bug in xterm. Xterm is designed to treat codes in the range 128-159 as control characters (that applies to any terminal that follows ISO-6429). I added the allowC1Printable resource to bypass that - mainly for the Russian & similar users who have a character set that doesn't follow that standard. (On the other hand, rxvt doesn't follow that standard either, and some people think that's good - in this case for instance ;-) I'm not sure whether it's better to make an FAQ for this issue, or just distribute a koi8-term script to show how to set it up (but then see the problems in supporting uxterm). Line-drawing does work in the example I sent a few months ago - I used that for some testing of dialog. Trying to use utf8 with a ru_RU.KOI8-R locale looks like user error to me. The other issue is luit versus line-drawing characters (#254316). That's fixable by changing the terminfo - but may impact users of screen (screen uses the termcap interface and gets confused when it sees termcap's equivalent to sgr0 when that string turns off line-drawing - a rather ugly effect). I'd made a fix for that a while back, but didn't test it with multi-byte strings such as \E(B. I have a fix for that (to ncurses), but it's not in Debian yet. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Attachment:
pgplO4d5gy4IM.pgp
Description: PGP signature