<AWT Dev> [9] Review request for 8132503: [macosx] Chinese full stop symbol cannot be entered with Pinyin IM on OS X

[Alexander Zuev]

Anton,

   this version looks fine to me.

/Alex

On 29/10/15 19:08, Anton Litvinov wrote:
> Hello Alexander,
>
> The second version of the fix, which addresses your suggestion 
> concerning introduction of a separate method checking, if the 
> "unichar" belongs to certain Unicode blocks, was created. For this 
> purpose the method "-(BOOL) isCodePointInUnicodeBlockNeedingIMEvent: 
> (unichar) codePoint;" was introduced. Could you please review the 
> second version of the fix.
>
> Webrev: http://cr.openjdk.java.net/~alitvinov/8132503/jdk9/webrev.01
>
> Thank you,
> Anton
>
> On 10/29/2015 3:09 PM, Anton Litvinov wrote:
>> Hello Alexander,
>>
>> Thank you for review of this fix. Responses to your questions are 
>> following.
>>
>> 1) I also was not able to find any methods available in 
>> "java.lang.Character", "java.lang.Character.UnicodeBlock", 
>> "java.lang.Character.Subset" classes or API in Cocoa which would 
>> allow to get minimal and maximal code point for the given Unicode 
>> block. I do not think that resuming work on RFE JDK-7057645 created 
>> in 2011 will help to resolve this particular bug, because it will not 
>> be possible to introduce a new API in JDK 8, for which this bug was 
>> originally filed.
>>
>> 2) Yes, I think that "aString" can have more than 1 Unicode 
>> character, since it is described as "The text to insert" in the 
>> documentation of the method "(void)insertText:(id)aString 
>> replacementRange:(NSRange)" 
>> (https://developer.apple.com/library/mac/documentation/Cocoa/Reference/NSTextInputClient_Protocol/#//apple_ref/occ/intfm/NSTextInputClient/insertText:replacementRange:)
>>
>> And, if "aString" contains more than 1 Unicode character, this case 
>> was already taken into account by "(utf16Length > 2)" check.
>>
>> "AWTView.m" without this fix:
>> 893     if ([self hasMarkedText] || !fProcessingKeystroke || 
>> (utf16Length > 2)) {
>>
>> "AWTView.m" with this fix:
>> 894     if (utf16Length > 2) {
>> 895         aStringIsComplex = YES;
>>
>> 3) Concerning creation of a separate function for checking, if 
>> "unichar" belongs to certain Unicode blocks. Did you mean addition of 
>> the possible function which would just check, if "unichar" is in any 
>> of the Unicode blocks hard coded in the function? Or did you mean the 
>> function which would just check, if "unichar" belongs to 1 Unicode 
>> block, whose identifier is transferred to the function, for example, 
>> as some "enum" value?
>>
>> Thank you,
>> Anton
>>
>> On 10/28/2015 5:21 PM, Alexander Scherbatiy wrote:
>>> On 10/27/2015 1:18 PM, Anton Litvinov wrote:
>>>> Hello,
>>>>
>>>> Could you please review the following fix for the bug.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8132503
>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8132503/jdk9/webrev.00
>>>>
>>>> The bug consists in the fact that after the fix for JDK-8068283, 
>>>> when IDEOGRAPHIC FULL STOP character "。" is entered from a 
>>>> keyboard using Pinyin IM, "java.awt.event.InputMethodEvent" is not 
>>>> generated and FULL STOP character "." is entered in 
>>>> "javax.swing.JTextArea" component.
>>>>
>>>> The solution adds the additional check to "if" condition, which was 
>>>> edited by the fix for JDK-8068283,
>>>>
>>>> "if ([self hasMarkedText] || !fProcessingKeystroke || (utf16Length 
>>>> > 2)) {"
>>>>
>>>> in the method "- (void) insertText:(id) replacementRange:(NSRange)" 
>>>> from the file 
>>>> "jdk/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m". 
>>>> This additional check defines, whether the analyzed code point 
>>>> belongs to Unicode code points range "U+3000 – U+303F" ("CJK 
>>>> Symbols and Punctuation"), which contains "。" character and, if it 
>>>> is so, generates "InputMethodEvent".
>>>>
>>>    It was interested for me does Cocoa or Java allow to get a 
>>> minimal and maximal character for the given Unicode Block.
>>>    I was not able to find how to do it in Cocoa.
>>>    Java has an open RFE JDK-7057645 Add methods to 
>>> Character.UnicodeBlock (returning first & last codepoints, the list 
>>> of blocks).
>>>    May be the current issue can be one more valid use case for the RFE.
>>>
>>>    I have just few comments:
>>>     - aString is treated as NSString. Can it have more than one 
>>> Unicode character?
>>>     - It could be better to move the check that a unichar belongs to 
>>> a separate function that can be easily extended later for new 
>>> Unicode Blocks.
>>>
>>>   Thanks,
>>>   Alexandr.
>>>
>>>> It was verified in a local environment that the regression test 
>>>> from the fix for JDK-8068283 does not fail with this fix also.
>>>>
>>>> Thank you,
>>>> Anton
>>>
>>
>