Hi, At 20 Mar 2002 16:25:55 +0000, Juliusz Chroboczek wrote:
> This is a known issue. Note that it is not peculiar to luit: the same > is true of kterm, which is why the kterm terminfo does not include ACS > capabilities. kterm supports ACS, just as I wrote (will write) below. > TK> The root of this problem is the definition of terminfo capabilites > TK> of enacs, smacs, and rmacs which conflicts with EUC encodings. > TK> How can we change the definition? > > Very simple. We need to change the definition of xterm to use VT 220-style > ACS. Namely > > :smacs=\E(0:rmacs=\E(B: > > (enacs is not needed). This will work for all locales that put ASCII > in G0 and point GL at G0 -- which includes all locales used on modern > Unices. I think this way is much better and works perfectly without confligting with all major encodings. Indeed, I found that "TERM=kterm" uses it! Thus kterm supports ACS. > Additionally, we need a new definition for ``xterm with no ACS'' for > encodings that do not satisfy the above condition (e.g. ISO-2022-JP). > This is quite simple to add: > > xterm-nacs|xterm without alternate characters:\ > smacs@:rmacs@:enacs@:tc=xterm: Sure. Strictly speaking, it is needed. However, very little people will need this, I think. (If it were needed by a certain amount of people or by some major encodings, we would need not only "xterm-nacs" but also "xterm-color-nacs", "xterm-r6-nacs", "xterm-xf86-v*-nacs", and so on so on. However, I think it is not realistic idea. We are happy because kterm-type enacs/smacs/rmacs can work well with all major encodings.) > I have been arguing for these changes to be made to ncurses for months > (since the first releases of luit), but Thomas is afraid of what they > might do to backwards compatibility. I would suggest that you take it > up with him. I checked term-type enacs/smacs/rmacs works well for many terminal emulators. $ xterm (or other terminal emulator) $ cat some-8bit-file (confirm that both of GL and GR characters are displayed properly) $ TERM=kterm dialog --msgbox foobar 8 20 (this uses enacs/smacs/rmacs to display line-drawing characters. Checks the line-drawing characters are displayed well.) $ cat some-8bit-file (confirm that usage of enacs/smacs/rmacs does not break GL or GR) I checked xterm, kterm, hanterm, rxvt, eterm, aterm and all of them works well (it can display line-drawings, and, more importantly, GL and GR are not destroyed by enacs/smacs/rmacs). gnome-terminal could not display line-drawing characters. Howevre, it is not as a severe bug as garbage characters for GL or GR. Anyway, I think gnome-terminal is responsible to fix this bug. I think ncurses should not hesitate to adopt kterm-type enacs/smacs/rmacs. On the other hand, mlterm http://mlterm.sourceforge.net implements proper ISO-2022 parser and this causes garbage characters. Thus, it is a present problem, not a future problem with future xterm+luit. Thus, I hope this situation will be fixed as soon as possible. And more, I think that leaving enacs/smacs/rmacs definition will mislead terminal-emulator-developers. Thomas, could you please change enacs/smacs/rmacs definition for "xterm" just as Juliusz has reported? --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ _______________________________________________ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
