<AWT Dev> [9] Review request for 8132503: [macosx] Chinese full stop symbol cannot be entered with Pinyin IM on OS X
Anton Litvinov
anton.litvinov at oracle.com
Thu Oct 29 12:09:44 UTC 2015
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
>
More information about the awt-dev
mailing list