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

[Gaspar Sinai <gsinai@example.com>]

Hi Guys,
The last time I saw such a long thread was rec.humor when a guy
asked not to reply to his post :)

>     Matt> Hmm, have you looked at Gaspar's Yudit code? I don't see
> 
> No.  One of these days....

I have just bought a laptop and installed redhat 5.0 on it. I 
compiled an rpm package for Intel and Sparc (RH 4.2):

      http://www2.gol.com/users/gsinai/yudit-1.0-2.i386.rpm
      http://www2.gol.com/users/gsinai/yudit-1.0-2.sparc.rpm

To print you probably want to have /usr/share/yudit/data/cyberbit.ttf

      http://www.bitstream.com/


>     Matt> that what you're talking about is anything more than it can
>     Matt> do already; to add support for a new codepage, you merely
>     Matt> tell it how to map the new characters to a font, and (if you
>     Matt> wish to) how to convert input to those characters. All
>     Matt> external configuration.
> 
> Brother, you are in for some unpleasant surprises :-)  Check out
> locale (5), o-negai-shimasu.  No silver bullet here.

I wasted too much time with setlocale and unfortunatelly I had to abandon
the idea. First it seemed I can save a lot of work. Then it turned out,
that, practically it can not be used in a multi-language environment. I
could elaborate, but not on this mailing list. Part of the problem was
lack of locale support, problems in rendering.  Unfortunatelly I'll be
still in Hungary on 13th...

> 
>     Gaspar> o Languages to be added dynamically to the input
>     Gaspar> conversion server.
> 
>     >> Why?  Why not run multiple backends, as today where many
>     >> systems run Wnn and Canna concurrently?  Or are you talking
>     >> about the input manager (like kinput2)?
> 
>     Matt> Running Wnn *and* Canna sounds unnecessarily memory-hungry,
>     Matt> and symptomatic of design nastiness somewhere. Would it not
> 
> Nope.  Symptomatic of the fundamental fact that "tastes differ."  In
> any case, that was an example to demonstrate feasibility.  I think it
> would be insane to try to overload a Japanese server with algorithms
> for Devanagari or Arabic.  Multiple servers.

Fortunatelly Japanese is the only expeptionally difficult input method.
All other inputs (Arabic, Devangari, Hangul) can share a few basic
algorithm. Algorithms don't take much memory. 

Yudit uses roman transliteration for all, but it could be extended to 
handle local keyboards as well.

> 
>     Matt> be better to have one server with enough flexibility therein
>     Matt> to support both methods, and if really necessary, both
>     Matt> protocols?
> 
> Such a server would be just as big as the two put together.
> Memory-hungry?  For dictionaries, yes.  Incompatible, though, they
> can't be combined.  No silver bullet here.

You don't need to read the whole dictionary into memory. MMAP is a
beautiful example how you can read Megabytes of static databases
fast without physical memory consumption. The pages that are 
referenced are automatically swapped in and out by the OS.

> Please to reuse protocols.

My problem is that there are many of them (I am talking  about the ones
between the input server and the front end).
I think, that new apps could use a new standard protocol and old apps are
supposed to use XIM anyway, so we could modify front-ends. I understand
that this is the hard way and Wnn will never be available for us...
Consider this as my long-term solution. 

Lets get practial:
-----------------
I also sympathize with Matthew, the highest priority now is to 
provide it in a widget set so that programmers would make multi-lingual
apps without knowing it. What if we make an abstraction layer first that
can use the old methods and the new ones? Old methods could be phased
out. If old methods are not used any more we could just remove the code.

Fortunately this thread is only about input methods... or it it? 

Some URLs:
GGI   http://synergy.foo.net/~ggi
BERLIN: http://www.berlin-consortium.org/


The wheather is very nice in Hungary,
Have a nice day.

gaspar

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