On Sat, 3 Feb 2001, Tomohiro KUBOTA wrote:
> >> (1) ISO-2022 is free from 'mojibake', as I wrote.
> > How come?
>
> If ISO-2022 escape sequences were be recognized in every modes,
> xterm -8, -u8, and -lc. If so, even if you invoked xterm with
> wrong mode, ISO-2022 string will be displayed correctly. Thus,
> application softwares can use ISO-2022 for very important messages.
Eek! Is it possible for it to put the encoding back to how it was
afterwards? Does this recurse indefintely?
> I don't know well on them. Where can I study it?
Well, you just do, say
TAG START
TAG SMALL LETTER J
TAG SMALL LETTER A
TAG END
[unicode-code-point-for-ideograph that you want displayed in a style
that is typically used in fonts used for japanese]
Then you could use "zh" too.
> I also heard about 'variant tag'.
Never heard anything of substance on such a thing.
> However, I imagine it would be a vaporware. How difficult
> is it to implement language/variant tag? It introduces
> new 'backspace' problem but we have to solve this in future.
Yeah, it's evil, less so than ISO 2022.
> > That doesn't sound like a very convincing reason, you can just stuff all
> > output through a 2022 -> UTF-8 converter. Don't see any reason for this
> > to be in the terminal itself...
>
> Ok, I stop to be a spokesperson for w3m developers, because I don't
> know the real reason.
I suspect this is going to be a "we can't be bothered to convert character
sets, so lets just tag our output instead, and hey, ISO 2022 can do that"
thing. But that's probably just being too cynical.
--
Robert Brady
[EMAIL PROTECTED]
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/lists/
