That’s right. The changes look good to me. Thanks, Dmitry
> On 17 Sep 2018, at 17:01, Prasanta Sadhukhan <prasanta.sadhuk...@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.sadhuk...@oracle.com >>> <mailto:prasanta.sadhuk...@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 >> >
