Re: Proposal: Input Method Editor API

Hi, Bono-san.

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

I have some objections:

1. Is "end" better than "length" for CompositionCaret and CompositionClause?

I guess that "length" is more useful and simplizes implementation of Web 
applications.

2. The default values textColor, backgroundColor and lineColor of 
CompositionClause.

I think that the default values of textColor and lineColor should be 
currentColor rather than black and white. If the <canvas> editor uses 
non-system color for the text and background, black and white aren't 
useful.  Similarly, backgroundColor's default value should be transparent.

3. Isn't useful text property of CompositionClause?

I think that composition string renderers want to get each text of each 
clause.

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.

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.

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?

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.

8. InputMethodManager::showCompositionWindow isn't needed.

I need to work very very hard for Gecko if we need to render composition 
string on all elements but I think nobody wants such function.

I think that when InputMethodManager::setEnable(node, true) is called, 
the web application must render the composition string themselves. And 
browsers shouldn't render the composition string. And it's enough.

9. InputMethodManager::showCandidateWindow() isn't needed.

See #5, I don't think this method isn't needed.

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().

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

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.

11. InputMethodManager should be renamed.

InputMethodManager isn't good name because it's a term of IME system of 
Windows. It's usually called IMM ;-)

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

Received on Tuesday, 21 September 2010 14:08:16 UTC