Hi, From: Jungshik Shin <[EMAIL PROTECTED]> Subject: Re: supporting XIM Date: Mon, 31 Mar 2003 11:08:53 +0900
> > - a word processor whose menus and messages are in English but can > > input/display/print text in your native language > >Which is better? The first one is completely unusable and the second > >one is unconveinent but usable. > > > > > I agree with you on this point. That's why I compared the status of KDE > in 1999-2000 > with that in 2003. Back in 1999-2000, KDE/Qt people thought that > translating messsages > is I18N, but they don't do any more and KDE/Qt supports 'genuine I18N' > much better now. I am glad there are people who understand this point. Several years ago, even when I said this tens of times I was ignored. > > - Xmms cannot display non-8bit languages (music titles and so on). > > > > Are you sure? It CAN display Chinese/Japanese/ Korean id3 v1 tag > as long as > the codeset of the current locale is the codeset used in ID3 v1 tag. I'll test this further. However, please note I won't be satisfied by "i18n" which require specific configuration other than setting LANG variable (and installing required softwares and resources). > > - Xft/Xft2-based softwares cannot display Japanese and Korean at the > > same time while Xft and Xft2 are UTF-8-based, because there are no > > fonts which contain both of Japanese and Korean. This should not > > be regarded as a font-side problem, because (1) font-style principle > > is different among scripts (there are no "courier" font for Japanese) > > > > You can use 'alias' in fontconfig if some programs use 'Courier' > or 'Arial' instead > of generic fonts names like 'monospace', 'serif', 'sansserif', and so > forth. I want such "alias" to be automated. If I have one Korean font installed, it is obvious that renderer must use the font for all Korean texts. It is not a good idea that the renderer fail to display Korean when the user doesn't configure the "alias". Since typography is different among scripts (Latin, Cyrillic, Greek, Han, Hangul, Hiragana, Katakana, Arab, Hebrew, Thai,...), we cannot expect there will be various fonts which include various scripts in the world (except for a few basic fonts like 'misc' or 'sansserif'). I cannot imagine "courier" Hiragana fonts nor "mincho" Arab fonts. This is why "alias" mechanism is not a makeshift but a naturally needed mechanism. > > - There are no lightweight web browser like dillo which is i18n-ed. > > I think that w3m-m17n is an excellent lightweight browser that > supports I18N well. Well, I meant a lightweight GUI browser. Though I haven't checked, I imagine dillo and so on use 8bit font mechanism. There is another i18n extension of w3m: "w3mmee". I don't know which is better. > > - FreeType mode of XFree86 Xterm doesn't support doublewidth characters. > > > Well, it sort of does. Anyway, I submitted a patch to Thomas and I expect > he'll apply it sooner or later. After that, I'll add '-faw' option > (similar to '-fw' option). Fantastic! May I want more? Xterm can automatically search a good (corresponding) doublewidth font in non-FreeType mode. How about your patch? > I already mentioned this issue. Programs like 'fmt' has to be > modified, but there's already > an alternative to 'fmt' that supports Unicod linebreaking algorithm. When I wrote this sentence, I thought about Text::Wrap() in Perl. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
