Re: Proposal: Input Method Editor API

On 2010/09/22 15:25, Hironori Bono (坊野 博典) wrote:
> On Tue, Sep 21, 2010 at 11:07 PM, Masayuki Nakano<masayuki@d-toybox.com>  wrote:

>> 3. Isn't useful text property of CompositionClause?
>>
>> I think that composition string renderers want to get each text of each
>> clause.
>
> Even though I'm happy to add this "text" attribute, I'm wondering if
> we need the "length" attribute as written above.

Yes, if text attribute will be added, the length attribute isn't needed.

>> 4. lineStyle of CompositionClause should have more styles.
>>
>> You defined only "none", "solid", "dotted" and "squiggle". But I think there
>> should be "dashed". Furthermore, there should be a property which suggests
>> whether the line is bold or not.
>>
>> I think that we should be usable all values which will be defined in
>> text-decoration of CSS3 text module.
>
> I'm personally wondering if we really need all values defined in
> text-decoration because it includes some values that may not be useful
> for IME text; such as blink, overline, and line-through. Nevertheless,
> if web developers need them, I'm happy to add them.

I meant that the all values is text-decoration-style in CSS3.
http://www.w3.org/TR/2003/CR-css3-text-20030514/#text-decoration-style
But this is very old document, fantasai might have idea for this.

>> 5. Are Candidate related interfaces and methods needed?
>>
>> We're not accessible the candidate list (and its items) on non-Windows
>> platform, so, I don't think that should be usable for Web application
>> developers.
>
> Right, this interface is only for Windows now. (We may be accessible a
> candidate list if we implement a JavaScript IME, though.)
> Anyway, it is a good idea to remove the Candidate interfaces and
> methods because they are overkill for the initial spec.

Yeah, and a spec which works only on Windows may create inaccessible web 
applications from other platforms if the application is tested only on 
Windows.

>> 6. How do we do when InputMethodManager::setEnable(node, false) is called
>> during composition?
>>
>> I think that the composition should be discarded (or committed), but we
>> *cannot* discard the composition forcibly on Linux. So, when another IME
>> usable editor gets focus, should we start the last composition?
>
> In my honest opinion, I do not have clear answers for this question.
> (Another option is just adding a return value to the function and
> return false on platforms that cannot discard the composition.) I just
> would like to hear opinions of web-application developers to find the
> happiest solution for them.

Perhaps, we should write an informative document for platform vendors 
for indicating what function is needed by HTML UA (e.g., a way for 
turing on/off IME, a way for changing inputting mode directly (Hiragana, 
Katakana), a way for committing composition forcibly).

>> 7. InputMethodManager::setEnable() shouldn't be a method of<canvas>?
>>
>> I think that there is no needs which web application developers can render
>> composition string themselves on non-<canvas>  element.
>>
>> And if this is called for enabling, the element must be changed as
>> focusable.
>
> In my personal opinion, all IME-related interfaces should be in this
> spec. (It is harder for web-application developer to practice learn
> IME interfaces if they are scattered among more specs.)

I agree, but I don't think the node should be non-<canvas> element...

So, if we take the method, it should have boolean result and if UA 
cannot enable IME on the element, it should return false.

>> 10. InputMethodManager::setCaretRecctangle() is...
>>
>> With TSF and Cocoa (Mac), IME can know position of any characters anytime.
>> So, they may want to know non-caret position's character rect.
>>
>> I think that Web application should listen the query by callback function.
>> Then, browser for Win32-IMM and Linux can call the callback function when
>> they need to call ImmSetCandidateWindow() or
>> gtk_im_context_set_cursor_location().
>
> I'm wondering what happens if this callback function (written by
> web-application developers, right?) takes long time. If a user agent
> needs to wait until this callback function returns, it may make some
> user-agents junky.

Yes.

>> Furthermore, IMEs want more information, e.g., selection range, selected
>> text, all text in the focused editor, a character index which is rendered at
>> a point, etc... So, many callback functions are needed...
>
> I realize the current interface is not perfect. On the other hand, I
> also realize adding more callbacks (or interfaces) puts more burden
> onto web-application developers. (I intentionally avoided adding many
> interfaces so web-application developers can use them easily.) Is it
> possible to give me advantages of your idea fro the point of
> web-application developers? I'm happy to add them if they provide more
> advantages than the disadvantages of your idea.

At least, they're needed for supporting reconversion, clickable 
composition string and querying surrounding text of composition string 
for improving the order of candidate list or for inputting complex 
script like Thai language.

See also (written in Japanese):
http://www.d-toybox.com/studio/weblog/show.php?mode=single;id=2009121800
http://www.d-toybox.com/studio/weblog/show.php?mode=single;id=2010032500

If web application developers can reply them by callback function, their 
editors provide good experience like native text editor. Otherwise, 
i.e., they don't support them, the editor provides poorer user 
experience, but it may be good tradeoff in some cases (e.g., vs cost).

>> Finally, web application needs a method which notifies to IME when the
>> layout in editor is changed. E.g., when editor is scrolled, position of
>> candidate window should be updated.
>
> Sorry, I cannot figure out this comment. I assume this rectangle is a
> local coordinate (such as a rectangle in a<canvas>  element) and a
> user-agent is responsible to convert it to the screen coordinate if it
> needs to send it to a system IME. Therefore, when a user agent scrolls
> a web page, it converts the given local rectangle to the screen
> rectangle again and sends it to the system. Is it possible to correct
> me if I'm something wrong?

I meant that when internal contents in <canvas> are scrolled, the web 
application needs to notify the timing to IME.


And I have an additional idea. How about to add method which can change 
IME state? E.g.,:

boolean InputMethodManager::setOpenState(boolean open);
boolean InputMethodManager::setInputMode(integer mode);

setOpenState() method turns on or off current IME. And setInputMode() 
takes a mode constant like hiragana, katakana, hiragana-kotei, etc.

If the platform or IME cannot change to the specified state, they should 
return false, otherwise, true.

Some Japanese web site uses Flash Player for changing IME inputting mode 
forcibly. If we provide same function by the new spec, we can put out 
such hacky Flash Player objects.

-- 
Masayuki Nakano <masayuki@d-toybox.com>
Manager, Internationalization, Mozilla Japan.

Received on Wednesday, 22 September 2010 07:23:02 UTC