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

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

On 09-Jun-98 Stephen J. Turnbull wrote:

[UCS-4]

>  You're missing my point then.  Those wide open spaces mean it needs to
>  be infinitely flexible.  (That's an exaggeration, of course.)
>
>  But for the near future that I see we will need to handle the entire
>  Babel of character sets, including some that don't exist yet.  More
>  flexibility....

Hmm, have you looked at Gaspar's Yudit code? I don't see that what you're
talking about is anything more than it can do already; to add support for
a new codepage, you merely tell it how to map the new characters to a
font, and (if you wish to) how to convert input to those characters. All
external configuration.

New charsets inherently can't be supported until they exist; but when
they exist, it shouldn't be a problem to add support.


[...]

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

Running Wnn *and* Canna sounds unnecessarily memory-hungry, and
symptomatic of design nastiness somewhere. Would it not be better to have
one server with enough flexibility therein to support both methods, and
if really necessary, both protocols?


>  You don't want to talk about Emacs, but have you looked at the huge
>  coding effort that is the LEIM?  LEIM already has this.

Getting now, looking.


[...]

>  Go ahead.  If it's good, I'll jump in.  But I know better than to try
>  to design one from scratch, myself.  I can serve much better
>  elsewhere.  There are plenty of attempts out there to try to improve
>  on.

Hmm. Let's step back a moment; the words "design one from scratch" are
not ones I care to use often. Failure to re-use code where appropriate is
a (virtual) sin, and I'm not denying that there is a lot of relevant code
out there. We seem to be talking about slightly different things, so I
will try to set out a little more clearly what I (think I'm) getting at:

 - Many new programs are continually being developed, especially these
   days for projects like GNOME and KDE.

 - Most of these programs do not support MBCS, and international
   input and display properly.

 - It could be made easy, or at least much easier, for them to do so.
   Exactly how is open to debate, but is also crying out for
   standardisation of some sort.

 - Therefore, even if the current libraries and protocols do do
   everything necessary, there's something missing somewhere, even if
   only glue and public awareness.

What to do about it?

 - Working/improving the necessary support into the widget library
   text-entry and text-display level would help enormously. There's
   no reason this couldn't be done while retaining support for current
   input methods.

 - Making things Unicode internally would additionally allow reliable
   multiple-language-in-one-place support.

 - Make sure the fundamental services are provided separately, and
   other things will also have one way to do every globalised thing
   they need to. If current libraries, backends, protocols and so
   forth really are up to the job already, then we just use them. If
   there's a genuine need for improvement, we can adapt and alter as
   necessary.
   (Speaking of other things, there *is* a Unicode terminal (emulator),
   isn't there? "9term" or something?)


How?

 - Abstracting Unicode text support would, as Gaspar said, be a good
   place to start.

 - Then some widgets, adding other support as and if necessary. If the
   GTK/GNOME/KDE/etc. people find them worthy of integrating, they can.

 - Then, the world! :) (Any remaining corners one at a time)


If you think that's mad, I'll gladly suffer the label. When I can send
mail and write text in any program of my choice, entering text in Japanese
and English, quoting someone else in Greek, and with menus and messages in
Tengwar, without jumping through hoops, I will rest happy...


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