Mailing List ArchiveSupport open source code!
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]RE: tlug: Kinput2
- To: tlug@example.com
- Subject: RE: tlug: Kinput2
- From: TBaetzle@example.com
- Date: Thu, 26 Mar 1998 22:38:30 +0100
- Content-Type: text/plain
- Reply-To: tlug@example.com
- Sender: owner-tlug@example.com
Disclaimer: I don't know what I'm talking about ;-) > Jonathan Byrne wrote: > Is Kinput2 a global FEP, or does it only work on things that are run > from > the same Kterm window in which Kinput2 was started? > It's global to the local display, and it works even if you don't start it in a KTerm. Just make sure you start it _before_ you start any KTerms that you wish to use it - AFAIK KTerm does not query dynamically wether a Kinput has become available if it didn't find it during startup. > Next, a "how does it work" question: on MacOS, Windows 95/NT, and > presumably > OS/2 (haven't tried OS/2 J), switching to Japanese input mode will > attempt > to put Japanese text into any application, whether it's double-byte > enabled > or not. > I don't know about Macs, but on Win and OS/2 (and of course AmigaOS) all applications are event-driven. The keyboard and mouse drivers create events when you hit a key or move the mouse. These events are then passed down a hierarchy of so-called event handlers which add, modify or remove events. The mapping from keyboard scan code to a character value accoring to the currently enabled character set would be done by a handler. What the FEPs do on these systems is add another event handler at a high priority that does the conversion. The applications, which get the "input events" much later in the chain of event handlers basically can't tell what has been going on. The application really has to know that when it gets a code sequence like 0x82, 0xA9, 0x82, 0xC8 that it should display "kana" in Hiragana and not some weird combinations of other characters. > If the app with the focus isn't written to accept inline Japanese > input, you get the little input box that pops up on your screen and > you can > type Japanese and choose kanji. When you hit enter it goes into your > document at cursor position, and sometimes you are lucky and it will > work if > you chose a Japanese font, under times it just won't and you get > garbage. > But the OS will always try and force it in there. > And weird things do happen - you see n characters in the display, but the cursor is really positioned at n + m characters :-( > What is the difference between that approach and the Kinput2 + Canna > or Wnn > approach, where it won't even try to force Japanese into an app that > isn't > written for it, such as Netscape Mail? Can a force-it-in everywhere > approach be done on Linux/UNIX, or does the way things work under UNIX > make > this not possible? > The "Kinput" approach is that the application queries Kinput for the input when it's available. You could probably create a "transparent" FEP in a Unix/X environment since this also uses an event mechanism. However, I don' think that many applications would be able to cope with it... Thomas --------------------------------------------------------------- Next TLUG Meeting: 11 April Sat, Tokyo Station Yaesu gate 12:30 Featuring Tague Griffith of Netscape i18n talking on source code --------------------------------------------------------------- a word from the sponsor: TWICS - Japan's First Public-Access Internet System www.twics.com info@example.com Tel:03-3351-5977 Fax:03-3353-6096
- Follow-Ups:
- RE: tlug: Kinput2
- From: Scott Stone <sstone@example.com>
Home | Main Index | Thread Index
- Prev by Date: LANG & kinput2 (was RE: tlug: Cathedral and Bazar)
- Next by Date: Re: tlug: Mounting my W95 partition
- Prev by thread: Re: tlug: Kinput2
- Next by thread: RE: tlug: Kinput2
- Index(es):
Home Page Mailing List Linux and Japan TLUG Members Links