Hi, At 31 Jan 2002 13:28:22 +0000, Juliusz Chroboczek wrote:
> Hi Tomohiro, > > I agree with the general idea. I would like to change a few details. Thank you. I tried implementation last night and it is working almost well. > I would suggest one new resource: > > XTerm*utf8Filter: /usr/X11R6/bin/luit I added it, with name "localeConverter". (I prefer to use "locale" in the keyword, than to use "utf8". Thus, "localeFilter" would be also OK.) > If utf8Filter is set, and XTerm is in UTF-8 mode, XTerm will spawn > > <filter> prog args > > instead of > > prog args Yes, but I am using "locale" now. > In addition, I suggest that the utf8 resource should be changed to a > tri-valued flag: it can be false, true, or auto, the latter meaning > that XTerm should run in UTF-8 mode if the locale is multi-byte, and > in eight-bit mode if it is not. A good idea. In "auto" mode, luit should be used not only in multibyte encodings but also in combining-character encodings such as Thai TIS-620 (ISO-8859-11). An another idea is that luit should be used in all non-ISO-8859-1 locales in "auto" mode, or to prepare two different "auto" modes. It depends on whether people from various countries tend to hope to use luit or to prefer manual font configuration (For example, Russian users have to write resource to use Russian font unless using luit). It is a tradeoff between convenience and performance. > The defaults for these resources should be > > XTerm*utf8Filter: <projectroot>/bin/luit > XTerm*utf8: auto (or perhaps true?) I prefer "true", but I am afraid that many people will complain because it breaks compatibility. Thus, "auto" is a good candidate. > TK> - emulate doublewidth de-facto standard for east Asian encodings > TK> (using http://www.cl.cam.ac.uk/~mgk25/ucs/scw-proposal.html ?) > > With all due respect, I refuse to implement Markus' proposal. I know you don't like to introduce "state". I think we can use a subset of Markus' proporsal without state. Indeed, all what we have to use is "CSI 1 w" sequence. Inserting the sequence before each EastAsianAmbiguous character (and a few more characters written in "Width problems" in http://www.debian.or.jp/~kubota/unicode-symbols.html) is enough. > TK> - whether xterm or luit will support BiDi or not. Usage of fribidi > TK> may have license problem (like Robert Brady's patch). > > My personal opionion is that BIDI belongs above the terminal emulator. Though I don't have enough motivation to discuss on this point because I am not a native speaker of RTL/BIDI languages, all people who speak Arab/Hebrew who I know wanted terminal emulators to support BIDI (though only a few people). If these people really want it, it would be these people's labor to persuade you (and others with same opinion). > And the number 1 item: include your fix for SS in EUC-JP (actually a > slightly improved version). Yes. However, I don't know how to improve my patch. Do you have any idea? --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ _______________________________________________ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
