Masao Uebayashi wrote:
> 
> > > Another implementation exists for NetBSD 1.4.
> > >
> > >         http://www.asahi-net.or.jp/~pf5y-inue/world21-beta.html (in Japanese)
> > >
> > > But it dosen't catch up to 1.5 nor current.
> >
> > I wish I could read Japanese...
> 
> We should realize that no matter how well documents are written, they
> will never be read if they're written only in Japanese...

We need an universal translator badly! :)

> > > > languages other than English. It uses UTF-8 encoding, and once it's
> > > > completed you'll be able to see English, Japanese, Korean, etc. on "one"
> > > > screen. The first test release will be available shortly (within this
> > > > week or next).
> > > Hmmmmm.  But many imput methods for Japanese dosen't support UTF-8 but
> > > ISO-2022-JP, EUC-JP or Shift_JIS.  :-(
> >
> > They should be provided separately, anyway. IMHO, ISO-2022-JP/KR, EUC-JP/KR,
> > and etc. are not for _universal_ operating system.
> 
> How should it be separated, do you think? It seems not realistic to me
> that kernel (wscons) supports all the i18n functions like Citrus has.

I'm still thinking about it. The kernel doesn't need to have all the 
functionality Citrus has, of course. 

> 
> I personally think if wscons provides bitmap display support, user
> programs (e.g. kon) can do the all jobs, that is CJK input/output.

It's not a good idea to have a userland program access hardware directly,
nor it can do everything. Imagine these: fancy bootup logo, kernel messages 
in various languages, and framebuffer based non-X window system, and etc. 
How would they possible without infrastructure built in the kernel? So I 
think I should first deal with dev/ic/vga.c before making such things 
real. 

Jun-Young

--
Bang Jun-Young <bjy@mogua.org>