TK> It defines alternate character set-related capabilities like:
TK> enacs=\E)0
TK> smacs=^N
TK> rmacs=^O
TK> which are indeed using G1 of ISO-2022. This works well for 8bit
TK> encodings which use G0 and G2. However, G1 is used in several
TK> encodings such as EUC-JP and EUC-KR. Thus, using these terminfo
TK> capabilities will overwrite the initial settings of G1 in these
TK> encodings and break proper displaying. This is a real problem in
TK> xterm+luit, though it doesn't matter for legacy xterm because it
TK> doesn't support EUC encodings.
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.
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.
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:
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.
Regards,
Juliusz
_______________________________________________
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
