Re: [IME API]Some Insights from Chinese Input Methods

Hi, Thanks for the comments!


On Mon, Dec 16, 2013 at 7:01 PM, SongTao(桌面事业部) <SongTao@sogou-inc.com>wrote:

>   Hello all,
>
>
>
> It's very pleased to see we are making a great progress in IME API.
>
>
>
> I do appreciate the second part of the spec about Chinese Input Composer
> and Converter. It's true that Chinese IMEs are very similar to Japanese
> IMEs. In fact, Chinese IMEs usually use a Phonetic Composer based on
> Pinyin, which require the users to select the correct character from
> a candidate window. Here's what I thought after reading the IME API WD as a
> Chinese input method developer.
>
>
>
> *1) The compatibility of the InputMethodContext:: oncandidatewindowshow.*
>
> Most Chinese input methods use the input and candidate windows which are
> self-rendered, instead of windows embedded to a certain position. That's
> why I don't think the oncandidatewindowshow event can tell us whether a
> window is blocked or not correctly. Why not try Composition Event? How
> about hiding the suggestion when composition starts, and show it when
> composition ends?
>
>
Composition events are sent whenever composition changes, but candidate
window events are sent when
a candidate window appears or changes its appearance.  A composition change
does not always cause
a candidate window visibility change, e.g. while you are using MS-IME on
Windows, typing Japanese hiragana
text, you won't see a candidate window until you actually start conversion
and look for alternate candidates.
Until then, all the composition process is done inline, so it won't
interfere any other UI other than the input field itself.

So candidate window events fire differently than composition events for
those IMEs.
For those IMEs that use always out-of-line composition window like Chinese
IMEs,
you can still rely on oncandidate* events to detect UI interference
possibility,
and you can write one HTML + Javascript to support other languages.


>
>
> *2) Add support for web app to get the candidate list of IMEs.*
>
> For the current suggestion list, we use compositionupdate event to get the
> content of the input from the users, and construct our request only based
> on the search of composition string. Could we further the search request
> with the Candidate String, such as the case of search in Win8? I believe by
> this the input method and search engine would work together and give the
> users a better suggestion.
>
>
FYI, this is (still) being discussed at
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22018
And your suggestion is almost same as the reason Microsoft people proposed
this.

One of the issue blocking this is a privacy issue, which may leak a
personalized dictionary
(user-defined dictionary or history).

  *3) Can we extend ime-mode in CSS and use it to hide or show the input
> method window?*
>
> If [2] can be solved, which means we could get a candidate suggestion
> list, it will make sense to hide the input method window and self-render
> the suggestion list, which will be very helpful for the input method in
> web-games. I think the current ime-mode tag is used to star or end a input
> method, is it possible that we use it to hide or show the input method
> window some day?
>
>
As CSS is for controlling 'view' of HTML, controlling IME using CSS is a
no-no.
Thus ime-mode is listed as 'features at risk' on CSS3 UI spec draft:
http://www.w3.org/TR/css3-ui/
and I'm in a position that not against removing the ime-mode property from
CSS spec.

Your use case isn't necessarily an extension of CSS ime-mode, is it?
This sounds a similar notion of Windows's UI-less mode.
Certainly we have to resolve the [2] first.


>  These suggestions comes to me after reading the IME API as well
> as Composition Event, Composition Interface, Input Method Context
> Interface. Hope it helps.
>
>
> --
> Song Tao
> Desktop Input Method Department
> Sougou Inc.
>
>
-- 
Takayoshi Kochi