Re: Japanese input (was RE: tlug: Japanese)

[ikko-@example.com (Kazuyuki Okamoto)]

Hi,
At 19:44 06/07/98 +0900, Jonathan Byrne wrote:
>-----Original Message-----
>From: Kazuyuki Okamoto <ikko-@example.com>
>
>>The Japanese Input Method is a Server-Client type system.
>
>I don't think there was any question about that, but you
>chart illustrates my point exactly: that the Linux/Unix
>world has too many clients and too many servers.
>
>The chart on some popular proprietary OSes looks like this:
>
>Server                  Client               Application
>------                  ------               -----------
>Apple Japanese server   Apple input method   Hundreds
>
>OS/2 Japanese server    OS/2 input method    Not as many as
>Apple
>
>MS Japanese server      MS input method      Hundreds
>
>Your chart (next) shows very well the much more confused
>picture that we face when using Linux/Unix:
May be so :-)

Server               Client                  Application
------               ------                  -----------
cannnaserver ------- canuum                  Hundreds
                   \ kinput2 (canna suppot)

jserver ------------ uum
                   \ kinput2 (wnn support)
                   \ xwnmo

But jvim has another Input System - onew.
This Input system was execute from Application (jvim).
This case is execution order is
1st - Server (cannaserver or jserver)
2nd - Application (jvim)
3rd - Client (onew)

It is a very complex procedure, or not ? :-)

>This is exactly why I think it's so important for the major
>players in this area to form a group for the purpose of
>coming up with just one standard (and ideally, just one
>server and one front-end processor).  Unfortunately, the
>very fact that this kind of fragmentation exists is a
>powerful argument against the chances of such a group coming
>together.  The cooperative development model has as a whole
>served the Linux community very well, but there are some
>areas where it also has weak points, such as this one.

But, Wnn is derived the cWnn(Chinese Wnn), kWnn(Korean Wnn).
Is it a strong cooperative development ?

>If we had just one standard, then we could count on having
>any Japanese-capable applications working with it, instead
>of the developer having to choose which one(s) to make it
>work with, or going to the trouble of coding in support for
>each of them.

To make standard is difficult.

>But like I said before, I don't really expect the situation
>to change.  It will be the way it is now for a long time,
>maybe permanently.

It will change the situation to support Japanese with glibc2.

# The glibc2 was not enough to support Japanese.
# And X was not support Japanese well ?

# Linux 3.0.34 was released.
--
| Kazuyuki Okamoto <ikko-@example.com>
| http://www.st.rim.or.jp/~ikko-/XF332/DocIndex.html
| http://www.st.rim.or.jp/~ikko-/XF331/DocIndex.html
| XFree86 Docs in Japanese
| PGP Key fingerprint =  56 D2 1E 57 22 12 3B 3C  AB 36 55 37 23 27 F0 61
--------------------------------------------------------------
Next TLUG Meeting: 13 June Sat, Tokyo Station Yaesu gate 12:30
Featuring Stone and Turnbull on .rpm and .deb packages
Next Nomikai: 17 July, 19:30 Tengu TokyoEkiMae 03-3275-3691
After June 13, the next meeting is 8 August at Tokyo Station
--------------------------------------------------------------
Sponsor: PHT, makers of TurboLinux http://www.pht.co.jp