Re: Proposal: Input Method Editor API

Hello, everyone!

2010/9/20 Hironori Bono (坊野 博典) <hbono@google.com>:
> Greetings,
>
> I'm Hironori Bono, a software engineer of Google. I would like to
> propose adding a new API, IME (Input Method Editor) API to HTML5 APIs,
> so we can control an IME associated with the hosting user-agent and
> retrieve its detailed information.

(1) I have a question:  What if the IME is itself written in Javascript?

I ask this because your proposal appears to assume that the IME is an
operating-system-based IME.  Often that is the case, of course.
However, one should also consider the possibility of a
Javascript-based IME in which the controlling IME code and data both
originate from a network URL resource (I have been working on exactly
such a Javascript-based IME system).

In any case, it makes a lot of sense to me to be able to control an
IME as your document suggests.

(2)  Secondly, a comment:  The "informational" part of your document
suggests that IMEs are just for Chinese, Japanese, and Korean.  While
IMEs are of course critical for those scripts, there are additional
use cases where an "IME" of one sort or another is quite useful, so
you might consider mentioning some non-CJK use cases.

One example: I have written an IME where typing the partial or
complete name of a Unicode symbol results in a pick list of Unicode
characters.  For example, if you type "integral" you will get a pick
list of all the mathematical "integral" symbols.  Likewise, if you
type "star", you will get a pick list of all of the "star" characters
in Unicode.

Another example: I have also written an "IME" that allows one to type
pinyin phonetics using numbers for the tones in Mandarin Chinese and
the IME automatically translates the input into the proper phonetics
with tone marks above the vowels. For example, typing "Zhong1guo2"
automatically is converted to "Zhōngguó".  While this is clearly
related to Chinese, it is a specialized kind of IME to make it easier
to type a Latin-based phonetic system.  Also it does not employ pick
lists but is still a type of IME since algorithmic processing is
required to translate input strings into the desired output strings.
I am not sure how the API that you propose
would handle specialized IMEs which do not produce pick lists, such as
the one I describe here.

Best Wishes -- Ed Trager

>
> I assume this new API is useful for the following use-cases.
>
> * Use Case 1: retrieving the detailed information when receiving a
> composition event.
>
> Even though composition events provides basic information of IMEs,
> some web applications may need its details (such as clauses, caret
> position, etc.) Even though it is an overkill to add these information
> to DOM events, it is useful to provide interfaces to retrieve such
> detailed information.
>
> * Use Case 2: using IMEs on a web application which uses <canvas> elements.
>
> When a web application which use <canvas> elements implements editing
> capabilities, it has difficulties when they manipulate IMEs. For
> example, it cannot control the place where it shows IME windows. It is
> useful to provide APIs that controls IMEs so developers can implement
> more web applications that uses HTML5 capabilities.
>
> I would like to publish a document that describes the details of my
> proposal to the URL below:
>  https://docs.google.com/fileview?id=0B8eVDHQ9_22-YWEyMGNmZjUtMWYxNy00YjI3LTlhYmQtNzA1YjlmYzViMzI0&hl=en&authkey=CNXmwLAM
>
> Would it be possible to give me your thoughts?
>
> Thank you for your interest in advance.
>
> Best regards,
>
> Hironori Bono
> E-mail: hbono@google.com
>
>

Received on Tuesday, 21 September 2010 04:03:33 UTC