Date: Thu, 11 Jun 1998 11:50:08 +0900 From: Jun-ichiro itojun Itoh <itojun@iijlab.net> To: Gary Kline <kline@tao.thought.org> Cc: tlambert@primenet.com, hackers@FreeBSD.ORG Subject: Re: internationalization Message-ID: <7849.897533408@coconut.itojun.org> In-Reply-To: kline's message of Wed, 10 Jun 1998 19:31:42 MST. <199806110231.TAA09494@tao.thought.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>> I've been working on iso-2022 encoding support for runelocale (xpg4) >> library. At this moment I'm working on some specific packages >> (for example, nvi or scheduler software called "sch") but will be >> able to merge the modification into xpg4 library part. > Wonderful! With the broadly international reach of > FreeBSD I was hoping that someone in China|Japan|Taiwan > would be into this. There may be a broader need for > wide character support--say Sanskrit and Thai. ... No problem under my framework, if proper multilingual renderer such as modified xterm (sanskritterm, or thaiter?) is there. I'm only working on internal string representation of multibyte, and multilingual string. For X11 modification for total multilingualization, people at Waseda Univ (japan). is doing a big project. I have never seen their code (I dunno if it is redistributed or not) but the screenshot is simply STUNNING. http://www.mling.waseda.ac.jp/ (text is in Japanese but you can view the screenshot) >> > This was my first leaning, but I'm increasingly >> > going toward the ISO families. >> Yes, iso-2022 families are quite important for supporting >> asian languages. Unicode is, for us Japanese, quite incomplete and >> unexpandable. > Is there a way of explaining (briefly :) how the > iso-2022 character set is displayed? This point > came up the other day and I guessed that it was > done by a ((large)) table-lookup under X. I don't see what you exactly mean, could you please explain? If you are talking about font bitmap, bitmap font for asian characters are, of course, very large. This is because we have multiple (3 for Japanese, almost 10 for mainland chinese) 96x96 character sets. (/usr/X11/lib/X11/fonts/misc may have some asian bitmap font, if you have installed those) There are several outline (vector) font there, but it needs CPU power to be rendered. If you are talking about visibility control in CUI (curses), scrwidth() should pass you the necessary screen width to render a wchar_t letter. I don't know which standard defines scrwidth(), but it is implemented in runelocale code found in BSDI. >> > :-( ! >> > How does the ISO2022 model work here? Isn't it the >> > same for Japanese and Chinese? >> Yes, for Japanese, Chinese and Korean iso-2022 based model (euc-xx >> falls into the category) is really important. However, I personally >> believe that filenames must be kept in C locale for simplicity... > I'll check out iso-2022 further; if you know of any > english-language docs on this, please sent me a > pointer. "Understanding Japanese Information Processing" by Ken Lunde, from O'reilly should be a best starting point. If you would like to start it cheaper, there are various webpages. itojun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7849.897533408>