Re: [w3c/editing] EditContext: Do IME see the plaintext in `EditContext`? (#342)

> So for making their communication asynchronous, layout information is cached in the main process before native IME retrieves character rects.

Blink is also caching layout infomation in the main process, but with little difference:

>1) All characters' rects in composition string if in a composition (required for showing candidate list window, some IME may show it at start of composition string, some other IME may show it at start of selected clause in composition string, etc)

same

>2) The first character rect in the editor (if there is no text, stores the caret rect for inserting first character)

Blink only caches rect of current selection, (or rect of the caret if no selection). What is the use of the first char rect for IME if the char is not in active composition? 

>3) Before/after character rects of anchor/focus point of Selection (This is required for allowing IME to show tooltip like UI around selection)

do you mean if the string is "A|BCD|EF" and selection is (1,4), Gecko caches rect for 'A''B' and 'D''E'? in this case Blink caches rect for 'BCD', is that not enough for IME?

>4) All characters' rects at last commit string only immediately after composition ends (this is required for Kakutei-undo feature of Japanese IMEs)

could you elaborate more? we already cache all chars in composition in 1) right? do you mean after comosition ends, we don't reset? and what is Kakutei-undo feature? how do we apply it?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/342#issuecomment-939124797

Received on Friday, 8 October 2021 21:26:25 UTC