From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Thu,  5 Oct 1995 00:28:34 -0400
From: Kenji Okamoto okamoto@earth.cias.osakafu-u.ac.jp
Subject: Japanese input
Topicbox-Message-UUID: 2ae77660-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <19951005042834.BzWW4JJwiLr03_aA6BiDAkVzMYPPsnak53hYhJ8Vmhs@z>

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