<AWT Dev> [12] RFR JDK-8191178:[macos] Problem with input of yen symbol

[Dmitry Markov]

That’s right. The changes look good to me.

Thanks,
Dmitry

> On 17 Sep 2018, at 17:01, Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com> wrote:
> 
> Hi Dmitry,
> I guess fullwidth currency symbols are 
> U+FF04 <https://www.fileformat.info/info/unicode/char/ff04/index.htm> FULLWIDTH DOLLAR SIGN
> U+FFE1 <https://www.fileformat.info/info/unicode/char/ffe1/index.htm> FULLWIDTH POUND SIGN
> U+FFE5 <https://www.fileformat.info/info/unicode/char/ffe5/index.htm> FULLWIDTH YEN SIGN
> etc which are already part of this check 
> (codePoint >= 0xFF00) && (codePoint <= 0xFFEF)
> right?
> 
> Regards
> Prasanta
> On 17-Sep-18 9:22 PM, Dmitry Markov wrote:
>> Hi Prasanta,
>> 
>> I think it would be wise to generate InputMethodEvent for ‘Fullwidth currency symbols’, as well.
>> 
>> Thanks,
>> Dmitry 
>> 
>>> On 17 Sep 2018, at 10:02, Prasanta Sadhukhan <prasanta.sadhukhan at oracle.com <mailto:prasanta.sadhukhan at oracle.com>> wrote:
>>> 
>>> Hi All,
>>> 
>>> Please review a fix for an issue where
>>> when "yen" symbol is entered from a keyboard using Romaji keyboard layout using "backslash" character, it was showing a "backslash" character 
>>> rather than "yen" symbol.
>>> 
>>> This is a regression of JDK-8068283 <https://bugs.openjdk.java.net/browse/JDK-8068283> where the check to control JNI invocation of "sun.lwawt.macosx.CInputMethod.insertText(String)" is changed from 
>>> "if ([self hasMarkedText] || !fProcessingKeystroke || (utf8Length > 1))
>>> to 
>>> if ([self hasMarkedText] || !fProcessingKeystroke || (utf16Length > 2))
>>> 
>>> Now, in this case for "yen" symbol, the utf16Length is 2 so InputMethodEvent is not generated, rather a KeyEvent is generated for "\" character.
>>> This check was again modified for JDK-8132503 <https://bugs.openjdk.java.net/browse/JDK-8132503> where the check for unichar belongs to certain unicode block is introduced
>>> 
>>> (utf8Length > 1) && [self isCodePointInUnicodeBlockNeedingIMEvent:[useString characterAtIndex:0]]
>>> 
>>> Now, there although utf8Length is 2 the check for codepoint is complex or not does not take into account "unicode" currency symbols. 
>>> It only takes into account CJK symbols and punctuations and "Halfwidth and Fullwidth Forms' Unicode block.
>>> 
>>> Proposed fix also add "currency" symbol unicode [[https://www.fileformat.info/info/unicode/category/Sc/list.htm <https://www.fileformat.info/info/unicode/category/Sc/list.htm>]
>>> in the mix so that we can have InputmethodEvent generated for currency symbols.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191178 <https://bugs.openjdk.java.net/browse/JDK-8191178>
>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8191178/webrev.0/ <http://cr.openjdk.java.net/%7Epsadhukhan/8191178/webrev.0/>
>>> 
>>> Regards
>>> Prasanta
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20180918/42146c07/attachment-0001.html>