TD> I read what I could find on EUC, but don't see where it uses codes 0-31 for
TD> printable text.
It doesn't use codes 0-31.
EUC is an application of of ISO 2022 that uses G1, which is one of the
registers of the ISO 2022 virtual machine. For example, in EUC-CN, G1
points at GB-2312.
ESC ) 0 is an ISO 2022 escape sequence. Its purpose is to set G1 to
the DEC special character set.
(Now DEC special happens to be encoded in positions 0-31 of XTerm-
encoded fonts, but that's an implementation detail.)
Now it so turns out that luit implements enough of ISO 2022 to
actually have a G1 register. In order to display EUC correctly, this
register needs to be set to a particular value (GB 2312 in the case of
EUC-CN). When an application sends the enacs sequence, it clobbers
G1, and hence causes luit to garble EUC input.
Please note that luit is doing as requested. The problem is not in
luit, it's not in XTerm, it's not even in termcap; it's in the morass
of complexity that some mindless jerk who'll be first against the wall
when the revolution comes standardised as ISO 2022.
There are two solutions. Don't use ISO 2022 and have people switch to
UTF-8, which is what we've been trying to do for a decade or so. Or
change the XTerm termcap to something that works in EUC locales.
I hope this clarifies things,
Juliusz
