Re: tlug: Linux Office Suite

[Frank Bennett <bennett@example.com>]

"Jonathan Byrne--3Web" <jq@example.com> writes:

> -----Original Message-----
> $B:9=P?M(B : YAMAGATA Hiroo <hiyori13@example.com>
> $B08@example.com(B : tlug@example.com <tlug@example.com>
> 
> >... input method, VJE ...
> 
> 
> What are the benefits of this input method?  Might it not be better to make
> more software that exists with the existing input methods such as Kinput2,
> then to throw yet another new one into the soup?  One of the strengths of
> other operating systems is that developers only have to write for one input
> method for each platform.

Um, my knowledge of this area isn't very broad or very deep, but
I _think_ this is a misunderstanding.  If I remember correctly,
kinput2 is a conversion interface that stands between the
application and the conversion engine.  VJE (which has been
around for quite awhile on other platforms, I believe) is a
conversion engine -- correct me if I'm wrong.

Linux isn't alone in having attracted lots of different
conversion technologies.  There are at least half a dozen
conversion engines available for use with Win95, including Wnn6,
and several reasonably common PD engines (canna, Wnn4, sj3).
These no doubt all take different approaches internally to the
organization of data, the parsing of input and so forth, and
that's all to the good -- no better way to find out what works
than to try out a bunch of different approaches several hundred
thousand times each day.

kinput2 provides an interface to these different engines from
kterm (which I admit I haven't used in a long time -- though
that's 'bout to change).  It's either compiled or configured to
speak with a chosen conversion engine's daemon.  Mule or Emacs 20
uses a conversion interface module called "egg", which relies on
one of a stable of back-end packages of Lisp to talk to the
conversion server.  Handled in this modular fashion, the
existence of multiple conversion engines doesn't seem to be much
of an obstacle to application development, and it gives us the
positive benefits of experimentation.

The only conversion server for Emacs/Mule that I know does _not_
work with the common "egg" interface is SKK, which relies on the
user feeding it information about furigana boundaries that other
conversion servers go to great lengths to figure out without user
intervention.  This is not something you would normally want on a
system to be heavily used for drafting Japanese text, but it
provides a reasonably workable method of input that is easy to
install, quick to learn and doesn't consume a lot of memory.  But
it's the only "black sheep" among the conversion servers that I
know of.

Cheers,
-- 
Frank G Bennett, Jr         @@
Faculty of Law, Nagoya Univ () email: bennett@example.com
Tel: (0171)323-6351         () WWW:   http://rumple.soas.ac.uk/~bennett/
---------------------------------------------------------------
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