Hi,
At Thu, 08 Feb 2001 16:03:06 +0000,
Markus Kuhn <[EMAIL PROTECTED]> wrote:
Very good. Using language tag (or ESC sequence?) and guarantee
ISO-2022 -> UCS -> ISO-2022 round-trip compatibility is interesting.
(I think complete round-trip compatibility cannot be achieved because
a language may have multiple ESC sequences or coded character sets
which share common codepoint in Unicode, just like JIS X 0212 and
JIS X 0213. However, I don't know this causes some practical problems.)
A few comments:
- I think G and T cannot be unified. There are two points of
(1) unification of glyph and (2) guarantee of round-trip compatibility.
- Some on-demand-font-loading mechanism would be needed. Otherwise,
many fonts (almost of them might not be used) must be loaded on
the invocation. (This would also help people who don't need
doublewidth font while XTerm automatically load doublewidth font
if available and consume additional machine resources.)
- in "locale-encoding" mode, it is obvious that the language which
is specified by the locale is the only language. Thus, in "locale-
encoding" mode, "default language" should not be "" but the language
specified by the locale. Well, as Roozbeh said, locale language
can be the default not only in "locale-encoding" mode but also
in UTF-8 mode.
- (very optional) Since UTF-8 with language tag can guarantee
ISO-2022 round-trip compatibility, someone can develop a wrapper
for UTF-8 XTerm that receive input as ISO-2022, convert it into
UTF-8, and give it to XTerm. Such a wrapper may be easily
implemented with very small amount of source code. Then, why not
integrate the wrapper to XTerm? (Ok, the wrapper is default OFF,
so that accidental ESC sequence cannot break the state of XTerm.)
- Specifying "typeface", i.e., Roman or Italic, is not a feature
of plain text but a feature of rich text. No, I don't oppose
this idea. I just want to point out that implementation of this
should have lower priority than language tag and so on.
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://surfchem0.riken.go.jp/~kubota/
"Introduction to I18N"
http://www.debian.org/doc/manuals/intro-i18n/
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/lists/
