Comment 1 by nishimotz on 2013-02-23 07:45
Japanese IME works better if NVDAObjects/inputComposition.py is modified as follows:

def calculateInsertedChars(oldComp,newComp):

(omitted)

    #return newComp[newComp[diffStart:](diffStart:diffEnd]
    return)

Regarding Japanese IME, diffEnd is not necessary as far as I know.

Comment 2 by mdcurran on 2015-01-08 06:15
I assume this is still an issue?
If so, is the reason you don't want to use diffEnd because it is invalid (less or equal to diffStart), or because its more pleasing in Japanese to always read to the end, even if only the middle changed? Could you provide an example?

Comment 3 by nishimotz on 2015-01-08 09:18
At the time of previous writing, I didn't explain the consecutive clause conversion of Japanese input method.

Technically, we should obtain information regarding TF_DA_ATTR_INFO (for TSF) or GCS_COMPATTR (for IMM32) from Japanese input method editor.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms629063%28v=vs.85%29.aspx

http://msdn.microsoft.com/en-us/library/cc195099.aspx

Just after pressing space key and first candidate appears, the results may differ depending on the configurations or previous usage of the system.

If all the characters are 'target_converted' characters (we also say that characters are converted as single clause), the user want to hear the explanations for all of the characters as the feedback of conversion.

If some characters are 'target_converted' and other characters are just 'converted' (we say that characters are converted as multiple clauses), the user should know what portion is 'target' (or 'selected'), because we must use left/right arrow keys to choose the 'target' portion and press space key to select alternatives for the target portion.

In Japan, implementations regarding this differs among screen readers:

• type A: For the first time of pressing space key, all (including both target and non-target) characters are explained. For second time and later (i.e. choosing alternatives for the target portion), only the target characters are explained.
• type B: Always only the target characters are explained.

Anyway, it is not just the matter of string comparisons.
If the last portion of characters are omitted just because they are same as input characters, the user may misunderstand as the result is separated into multiple clauses and only the first portion is marked as 'target clause'.

NVDA-JP has been worked around GCS_COMPATTR and we added TF_DA_ATTR_INFO support since 2014.3jp, so we should contribute regarding this.

@michaelDCurran Since you were assessing the reported issue earlier, could you please share any thoughts/inputs you may have in response to @nishimotz's #2730 (comment)?

Let me continue the discussion of #8621 regarding Japanese IME here.

The first candidate issue is still open for Japanese as well, however, it is different from Chinese.
Candidates window of Japanese IME is not shown during the type of Latin characters.
Windows 10 can show the prediction window during the type, but usually it is not expected to be announced.

When the space key is pressed, first candidate is shown, without candidate window.
At the second press of space key, candidate window pops up and the second candidate is focused.
As the result, first candidate is not announced as character description.

Auto focus means announce the prediction window under Windows 10. Am I right?
@nishimotz

As far as I have seen, the first candidate in Japanese IME shown after pressing space is treated as a reading string. That is why the first candidate is not announced as character description.