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

["Matthew J. Francis" <asbel@example.com>]

On 07-Jun-98 Jonathan Byrne wrote:

[...]

>  Japanese input works this way in all proprietary OSes too,
>  and I confess that they spoil you.  The main reason that I
>  spend as much time under Windows as I do is simply because
>  Japanese input works so well, and even works in a lot of
>  English applications.

I wasn't aware of this, but then again also JWP is the only Japanese
application I ever use(d) in Windows. And, as it is primarily aimed at
people without a whole Japanese setup, it is its own FEP.
Although now occasionally I use Yudit and Canna/Kinput2 (I once tried
to set up Wnn4 - and failed abysmally), I admit that mostly I end up
running real JWP under Wine. Works quite well, all things considered,
but it does tend to crash annoyingly from time to time.


>  Here's a "think big" suggestion/idea:  one of the problems
>  that I see in the general world of Unix Japanese input is
>  that there are too many different ways of doing it: Kinput2,
>  Canna, Wnn, SKK, Egg, etc., 

[input unification]


What you're suggesting could also be done to a great extent, I think,
even without the complete alliance of all the parties.
What it would take is:

 - One library and/or daemon that knows how to speak to *all* the
   available back-end servers;

 - A set of widgets that know how to use the services from the
   first

 - A compelling reason for people to start using the second.

I think that exactly that compelling reason is the olive-branch of
Unicode support, that Yudit extends into the sea of a thousand one-locale
charsets. Hardly anything supports Unicode at the moment, and there's no
real reason they can't use Yudit's support; the core widgets have already
been ported to two major toolkits (Qt and Motif), so I don't think adding
the other major ones (e.g. GTK+) would be a major problem.

If we can package them separately, and say, "Here, look, just compile in
this here widget instead of (toolkit X)'s default entry/text edit control,
and you can have free Unicode support", I really think people will use
them. Quite probably even the toolkit writers would be interested in such
a thing. (If done right, other, non-Unicode text forms could also be
catered for - a drop-in replacement/upgrade for Kinput2?)

As the saying goes, "If we build it, they will come". Much of the reason
for the general fragmentation is, I think, that no one solution is
*clearly* better than the others...


Anyway, realising that the above description glosses over many
implementational details, I ask (as those here probably know much more
about the mechanics than I): How could it best be done, and what are the
potential problems?


Cheers,
-Matt.

"The results of this intrusion into your life will be used 'responsibly'
in ways you cannot even begin to imagine. Of course, the innocent have
nothing to fear from the rapidly expanding data industry."
 - Radiohead, Airbag/How Am I Driving?

--------------------------------------------------------------
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