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

[Anton Litvinov]

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