Japanese input

Japanese input

[rob]

>To port XXXXX Japanese input method to Plan 9 is not a nifty
>idea. Some new and simple method can be designed in Plan 9's way.
>Sorry, not a precise plan for now.

I disagree.  The implementation method may be novel but the
input method itself should be one Japanese users are familiar
and at least comfortable with.  Inventing a new one would be
like requiring Plan 9 terminals for English speakers to have
non-standard placement of the letters on their keyboards.

-rob

Japanese input

[Kenji]

> 
> >>To port XXXXX Japanese input method to Plan 9 is not a nifty
> >>idea. Some new and simple method can be designed in Plan 9's way.
> >>Sorry, not a precise plan for now.
> >
> >I disagree.  The implementation method may be novel but the
> >input method itself should be one Japanese users are familiar
> >and at least comfortable with.  Inventing a new one would be
> >like requiring Plan 9 terminals for English speakers to have
> >non-standard placement of the letters on their keyboards.
> >
> >-rob
> 
> 
> I'd disagree with that analogy. Japanese input using a standard
> keyboard is contortious and kludgy enough that it's worthwhile 
> to look at doing it differently--in a plan9 sort of way.

I'd disagree, because I'm using ASCII keyboard to use Canna server
+ kinput2 now (unfortunately it's not Plan 9).  If Plan 9 is aimed 
for everyday business use in Japanese office, JIS keyboard may be
neccessary.   However, Plan 9 seems not to target such use, at least now
(you can exclude most Japanese by thick English manuals and papers :-).

> Plan9 user interactions are a bit different from the usual X+unix 
> interactions. This has been valuable.

Yeah, this is the problem.  Furthermore, Plan 9 is very new to many of
Japanese including me.  It may take some time to get an real idea what is
Plan 9 to me, and probably to many Japanese.

Recent Japanese input method is a client-server type application.
The server acts to convert kana context to that composed of kanji and
kana/katakana etc, and the client defines user interface, which 
communicates with the server.  The client can request funtions through
defined Canna protocols (attached below).

According to the Canna3.2 manual for protocols to communicate between
Canna server and a client, there are about 40 protocols which cover all
the neccessary operation for kana context-->kanji + kana/katakana conversion.
Therefore, if we can accept the way of Canna server, we only need to write 
its front-end client which defines user interface.
The most important point is that the Japanese special/proper problems are
confined only within this server.

The size of source code of whole the Canna3.2 exceeds several megabytes.
So, I assume it beyonds one's effort, if starting from zero.

Kenji

IMFO:  the protocols for Canna server

Core protocol:  Initialize, Finalize, CreateContext, DuplicateContext,
          CloseContext, GetDictionaryList, GetDirectoryList, MountDictionary,
          UnmountDictionary, RemountDictionary, GetMountDictionaryList,
          QueryDictionary, DefineWord, DeleteWord, BeginConvert, EndConvert,
          GetCandidacyList, GetYomi, SubstYomi, StoreRange, GetLastYomi,
          FlushYomi, RemoveYomi, GetSimpleKanji, ResizePause, GetHinshi,
          GetLex, GetStatus, SetStatus, AutoConvert, QueryExtensions,
          SetApplicationName, NoticeGroupName

Extended protocol:  GetServerInfo, GetAccessControlList, CreateDictionary,
          DeleteDictionary, RenameDictionary, GetWordTextDictionary,
          ListDictionary, Sync, ChmodDictionary, CopyDictionary

Japanese input

[Reed]

>>To port XXXXX Japanese input method to Plan 9 is not a nifty
>>idea. Some new and simple method can be designed in Plan 9's way.
>>Sorry, not a precise plan for now.
>
>I disagree.  The implementation method may be novel but the
>input method itself should be one Japanese users are familiar
>and at least comfortable with.  Inventing a new one would be
>like requiring Plan 9 terminals for English speakers to have
>non-standard placement of the letters on their keyboards.
>
>-rob


I'd disagree with that analogy. Japanese input using a standard
keyboard is contortious and kludgy enough that it's worthwhile 
to look at doing it differently--in a plan9 sort of way.

Plan9 user interactions are a bit different from the usual X+unix 
interactions. This has been valuable.

I expect there may be value in looking at Japanese input in the 
same light and for many of the same reasons. 


-reed

-----
University of Tennessee, Knoxville            Dept of Computer Science
Netlib Development Group         'Dust--is round off error.' says geek
wade@cs.utk.edu -- <URL:http://www.netlib.org/utk/people/ReedWade.html>

Japanese input

[Naoki]

Kenji writes:
>Does this mean you'll port Canna server to Plan 9?

To port XXXXX Japanese input method to Plan 9 is not a nifty
idea. Some new and simple method can be designed in Plan 9's way.
Sorry, not a precise plan for now.

-Nao

Japanese input

[Kenji]

> >Does this mean you'll port Canna server to Plan 9?
> >
> >Kenji
> why don't you?
> 
Because I believe he (Nao) is a member of Canna server.

Kenji

Japanese input

[philw]

>Does this mean you'll port Canna server to Plan 9?
>
>Kenji
why don't you?

Japanese input

[Kenji]

> Dennis writes:
> >Okamoto-san is quite correct to observe that the input
> >method for Japanese provided by ktrans is very naive;
> >it was intended only as a demonstration.
> 
> Neat stuff for demonstration. I think it is not very hard to implement
> a more efficient input method for Japanese. That would be very
> delightful work.

Does this mean you'll port Canna server to Plan 9?

Kenji

Japanese input

[Naoki]

Dennis writes:
>Okamoto-san is quite correct to observe that the input
>method for Japanese provided by ktrans is very naive;
>it was intended only as a demonstration.

Neat stuff for demonstration. I think it is not very hard to implement
a more efficient input method for Japanese. That would be very
delightful work.

-Nao

Japanese input

[dmr]

Okamoto-san is quite correct to observe that the input
method for Japanese provided by ktrans is very naive;
it was intended only as a demonstration.  Certainly it
is less capable than ordinary word-processing software
used in Japan years ago; it just provides for phonetic
romaji input of the kana characters, and a last-"word"
lookup in a hiragana->kanji table.

I found the bug that caused ktrans to get a fault when
trying to look up his name--it's an array overrun.
In /sys/src/cmd/ktrans/translate.c, the v array in
dotrans() is too small.  Full fix is in boddle
format in the plan9/update/cmd/ktrans directory
for WWW and ftp access at plan9.att.com.

	Dennis

Japanese input

[Kenji]

======continued from the former post==========

First of all, please don't get angry to read my posting.   I have good
impression of Plan 9, particulary, by the reason why it tried to carry
an eastern language in itself from the first.

==========================================

I tried ktrans to test its ability to enter Japanese text for these 
several hours.  I've gotten an impression that no native Japanese has 
been connected to this project.....

This Japanese input method is based on a very simple table searching,
so it's very fast because the size of Hiragana-->Kanji conversion 
dictionary is not so huge.  Unfortunately, it means it's not so 
intelligent for my use.  According to my understanding, this kind of 
dictionary reference method seems to be there about a decade ago, 
and has gone.

If we limit our usage of this input method into a very short letter,
it might be usefull, at least, better than nothing.  However, if we
try to write everyday Japanese document, this cannot be my tool, because
it's too much frustrating to correct the wrong conversion....

We have already much powerful many kinds of Kana->Kanji conversion 
engine for unix, such as Wnn and Canna servers which are included 
in the X11 distribution.  Of course, I don't saticefied enough by
those conversion engines, however, those are better.


On the contrary mentioned above, ktrans is much better than nothing.
Therefore, standing as this viewpoint,  I have some proposal to
improve the present conversion engine.

1) introduce a "non-transfer" key

     This is very important to give a chance not to transform 
intentionally.  There are many cases where we need to input Hiragana
not Kanji.   In the present situation, I have to hit ctl+E, then ctl+G
again.   Hmmm.... It can do!   ....   OK!  please forget this.


The other stuffs we need, if we use it for heavy use of Japanese input.

2) introduce a chance to add a word into the dictionary

3) introduce a learning mechanism for individual's different habit of
   kanji usage.


Anyway, it's very interesting to see the functionality of this kind
from the first in an operatiog system.

Kenji

Japanese input

[Kenji]

=====Continued from the former post======

I'm now enjoying to try Japanese input on my Plan 9 on PC 486/33MHz.
Searching speed of Kanji candidate is very fast, which makes me much
confortable.  However, this seems to have no functionality to learn
my habit of Kanji usage. 

One more thing which I'd like to propose.   This engine uses Jikan16
character which makes me some problem.   The top line of the kanji/
Hiragana character is hidden.  To avoid this, I recommend you to use
k14 as a default character set.   Am I doing something wrong?

kenji

Japanese input

[Kenji]

Wait a minute!!!

I was much surprised to find a manual page describing JAPANESE INPUT method.
Oh, Oh, Oh, just a wait.  I'll try it.... ^_^

So, I ,at first, tried to input my name, Oka-Moto and Ken-Ji.   
Ctl+G and input oka....    What an Amasing tool!  Yes, ktrans can display
Hiragana in my 8-1/2...  Then, hit Ctl + T.  OK! well done!!  My name 
appeared on the display in kanji.  Good enough!

Next, I inputted Ken-ji.   It's ok, too.  I can see my first name in Hiragana.
Then, tried ctl_T........ Alas!  The ktrans has been broken with the error
messages of as below:

ktrans 79: suicide : sys: trap: fault read addr=0x9ca4e6f6 pc=0x0001842.

So, I tried to see the source codes of ktrans, however, it's large enough.

Can someone be able to enlighten me what's going on?

Anyway,  I was really surprised when I saw this function of ktrans!!

Kenji