Mailing List ArchiveSupport open source code!
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]Re: Japanese input (was RE: tlug: Japanese)
- To: tlug@example.com
- Subject: Re: Japanese input (was RE: tlug: Japanese)
- From: Gaspar Sinai <gsinai@example.com>
- Date: Wed, 10 Jun 1998 18:50:31 +0900 (JST)
- Content-Type: TEXT/PLAIN; charset=US-ASCII
- In-Reply-To: <13694.1758.375190.293256@example.com>
- Reply-To: tlug@example.com
- Sender: owner-tlug@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
- Follow-Ups:
- tlug: Re: Japanese input
- From: Karl-Max Wagner <karlmax@example.com>
- References:
- Re: Japanese input (was RE: tlug: Japanese)
- From: "Stephen J. Turnbull" <turnbull@example.com>
Home | Main Index | Thread Index
- Prev by Date: Re: tlug: Sun disk label fdisk/SCSI question
- Next by Date: Re: Japanese input (was RE: tlug: Japanese)
- Prev by thread: Re: Japanese input (was RE: tlug: Japanese)
- Next by thread: tlug: Re: Japanese input
- Index(es):
Home Page Mailing List Linux and Japan TLUG Members Links