[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#254316: CJK font fails after running slang/ncurses program

On Sat, Jun 26, 2004 at 12:56:26AM +0200, Juliusz Chroboczek wrote:
> 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.)

yes (and xterm's users think they're encoded in 96-126; "real" 0-31 are
control characters).
> 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.

...and since it has to be set to a particular value (and because there's
no good method to determine what it was - or isn't there?) you suggest
that the application not use G1 for anything else.  (Your initial report
only stated that it would break the 2022 state, btw).

But (now that I'm thinking along those lines), luit knows what the particular
value is, and in principle could have massaged the ^O into a string that
would select BG 2312 back into G1.

(Ignoring the issue of being a bit late to modify luit, I'm curious if
there was some reason why that couldn't work).
> 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.

( google suggests 2022 has many fans ;-)

> 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

Thomas E. Dickey

Attachment: pgpGzWvFJH1rA.pgp
Description: PGP signature

Reply to: