Re: [OpenJDK 2D-Dev] RFR: 8240518: Incorrect JNU_ReleaseStringPlatformChars in Windows Print
Hi Sergey, Prasanta, Pankaj, Thank you for the review. May I ask a sponsor of the fix as well? I'm not a committer. Best Regards, Toshio Nakamura Pankaj Bansal wrote on 2020/03/05 18:22:43: > From: Pankaj Bansal > To: Toshio 5 Nakamura , awt- > d...@openjdk.java.net, 2d-dev <2d-dev@openjdk.java.net> > Date: 2020/03/05 18:22 > Subject: [EXTERNAL] RE: RFR: 8240518: Incorrect > JNU_ReleaseStringPlatformChars in Windows Print > > Looks good to me > > -Pankaj > > -Original Message- > From: Sergey Bylokhov > Sent: Thursday, March 5, 2020 2:35 PM > To: Toshio 5 Nakamura ; awt- > d...@openjdk.java.net; 2d-dev <2d-dev@openjdk.java.net> > Subject: Re: RFR: 8240518: Incorrect > JNU_ReleaseStringPlatformChars in Windows Print > > (CC) 2d-dev, > > Looks fine. > > On 3/4/20 4:48 am, Toshio 5 Nakamura wrote: > > Hi, > > > > I'd like to ask review and sponsor of this fix. > > > > Issue: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8240518=DwIFAg=jf_iaSHvJObTbx-siA1ZOg=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw=Ugr81mDyW3UBisxHYIBGJRn59YtU54N94eZ3qym_AxI=aiMA0Y77aGl1__RhHjtvahZ0wWG8fG0G4BgFOcpvrPY= > > Fix: https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Etnakamura_8240518_webrev.00=DwIFAg=jf_iaSHvJObTbx-siA1ZOg=EVbFABcgo-X99_TGI2-qsMtyulHUruf8lAzMlVpVRqw=Ugr81mDyW3UBisxHYIBGJRn59YtU54N94eZ3qym_AxI=YaighmfLyolNRz8ORpStjqHH1p4KX8d4g_AwsY0GPHk= > > > > Eclipse OpenJ9 VM detects two errors about > JNU_ReleaseStringPlatformChars in WPrinterJob.cpp. > > Then, I checked similar situation in the folder, and found one > lacking of the release method in awt_PrintControl.cpp. > > > > Best regards, > > > > Toshio Nakamura > > > > > -- > Best regards, Sergey. >
Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFont
Thank you, phill. I really appreciate your kind support. Toshio Nakamura - Original message -From: Philip Race To: Toshio 5 Nakamura Cc: 2d-dev@openjdk.java.netSubject: [EXTERNAL] Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFontDate: Mon, Jun 3, 2019 9:02 AM Approved and pushed.-philOn 5/20/19, 5:20 AM, Toshio 5 Nakamura wrote: Hi phil, Do you have chance to check this proposal again? To relieve your worry, I tested all locales additionally withUbuntu16.04, 18.04, RHEL7, 8, and CentOS7. There weremany improvements. But, acutually, this testcase in the proposal detected two other issues. I believe the root causes are different, and they can be treated separately. Details are in the bug DB. By the way, Noto CJK fonts v2.001 [1] seems to changetheir fullname to the same one as familyname. So, this problem doesn't exist with the new version. Anyway, since many distributions still use Noto CJK fonts v1.001,I believe this proposal is still useful. [1] https://github.com/googlefonts/noto-cjkJBS: https://bugs.openjdk.java.net/browse/JDK-8219901Webrev.02: http://cr.openjdk.java.net/~tnakamura/8219901/webrev.02/ Thanks,Toshio Nakamura - Original message -From: "Toshio 5 Nakamura" Sent by: "2d-dev" <2d-dev-boun...@openjdk.java.net>To: philip.r...@oracle.comCc: 2d-dev@openjdk.java.netSubject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFontDate: Tue, Apr 30, 2019 7:58 PM Hi Phil, Thank you so much for the review and pointing out. I updated the webrev to cover non-English results by testcase side. Additionally, I need another fix in FcFontConfiguration.java.From internationalization view point, we need to tell zh_CN and zh_TW,and fcinfo's file name requires not only language but also country. I tested this with major locales under Ubuntu 16.04, 18.04, CentOS 7,RHEL7 and 8beta. Could you kindly review this again?http://cr.openjdk.java.net/~tnakamura/8219901/webrev.02/ Thanks,Toshio Nakamura - Original message -From: Phil Race To: Toshio 5 Nakamura , jayathirth@oracle.comCc: 2d-dev@openjdk.java.netSubject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFontDate: Fri, Apr 26, 2019 7:26 AM The test fails for me when I set the Japanese locale. I am using Ubuntu 16.04.Have you done any locale testing ?env|grep LANGLANG=ja_JP.UTF-8GDM_LANG=ja_JPLANGUAGE=ja_JP.UTF-8 $ ~/jdk-client/build/linux-x86_64-server-release/jdk/bin/java FCCompositeTestPF=Noto Sans Mono CJK JP RegularFC=Noto Sans Mono CJK JP RegularPF=TakaoPGothicFC=Takao Pjava.lang.RuntimeException: FullName mismatch: TakaoPGothic,Takao P at FCCompositeTest.test(FCCompositeTest.java:92) at FCCompositeTest.main(FCCompositeTest.java:52)Exception in thread "main" java.lang.RuntimeException: Method invocation exception at FCCompositeTest.test(FCCompositeTest.java:97) at FCCompositeTest.main(FCCompositeTest.java:52)-phil. On 4/23/19 3:14 AM, Toshio 5 Nakamura wrote: I apologize if my poor description caused confusion. Hi Jay,Thank you so much for your review. Hi phil,I'm looking forward to hearing your results.Noto font is expected to be used more widely, and I'm eager to fix this problem.I welcome any suggestions or comments. Thanks,Toshio Nakamura - Original message -----From: Jayathirth Rao To: Toshio 5 Nakamura Cc: Philip Race , 2d-dev@openjdk.java.netSubject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFontDate: Tue, Apr 9, 2019 3:26 PM Hi, (Ignore the previous mail received with less info) Observations: I went through different FontConfiguration & FontManager implementations and I see that in case of fontConfig(linux) only we are encoding/decoding CompositeFonts in a unique way(In case of font config we override get2DCompositeFontInfo()). For other platforms we use parent get2DCompositeFontInfo() where we are populating face names using getFaceNameFromComponentFontName(). Also getDefaultPlatformFont() returns predetermined face names in case of Windows and Mac. For Linux changes made in FontConfiguration and FontManager looks fine. Thanks, Jay On 04-Apr-2019, at 6:14 PM, Toshio 5 Nakamura <toshi...@jp.ibm.com> wrote: Hi phil, Jay, Thank you for taking your time to review this patch. Thanks, Toshio Nakamura - Original message -From: Jayathirth Rao <jayathirth@oracle.com>To: toshi...@jp.ibm.comCc: 2d-dev <2d-dev@openjdk.java.net>Subject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFontDate: Thu, Apr 4, 2019 8:43 PM Hi, I am also taking a look at this. I will update my observations soon. Thanks, Jay On 04-Apr-2019, at 8:23 AM, Philip Race <philip.r...@oracle.com> wrote: I w
Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFont
Hi phil, Do you have chance to check this proposal again? To relieve your worry, I tested all locales additionally withUbuntu16.04, 18.04, RHEL7, 8, and CentOS7. There weremany improvements. But, acutually, this testcase in the proposal detected two other issues. I believe the root causes are different, and they can be treated separately. Details are in the bug DB. By the way, Noto CJK fonts v2.001 [1] seems to changetheir fullname to the same one as familyname. So, this problem doesn't exist with the new version. Anyway, since many distributions still use Noto CJK fonts v1.001,I believe this proposal is still useful. [1] https://github.com/googlefonts/noto-cjkJBS: https://bugs.openjdk.java.net/browse/JDK-8219901Webrev.02: http://cr.openjdk.java.net/~tnakamura/8219901/webrev.02/ Thanks,Toshio Nakamura - Original message -From: "Toshio 5 Nakamura" Sent by: "2d-dev" <2d-dev-boun...@openjdk.java.net>To: philip.r...@oracle.comCc: 2d-dev@openjdk.java.netSubject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFontDate: Tue, Apr 30, 2019 7:58 PM Hi Phil, Thank you so much for the review and pointing out. I updated the webrev to cover non-English results by testcase side. Additionally, I need another fix in FcFontConfiguration.java.From internationalization view point, we need to tell zh_CN and zh_TW,and fcinfo's file name requires not only language but also country. I tested this with major locales under Ubuntu 16.04, 18.04, CentOS 7,RHEL7 and 8beta. Could you kindly review this again?http://cr.openjdk.java.net/~tnakamura/8219901/webrev.02/ Thanks,Toshio Nakamura - Original message -From: Phil Race To: Toshio 5 Nakamura , jayathirth@oracle.comCc: 2d-dev@openjdk.java.netSubject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFontDate: Fri, Apr 26, 2019 7:26 AM The test fails for me when I set the Japanese locale. I am using Ubuntu 16.04.Have you done any locale testing ?env|grep LANGLANG=ja_JP.UTF-8GDM_LANG=ja_JPLANGUAGE=ja_JP.UTF-8 $ ~/jdk-client/build/linux-x86_64-server-release/jdk/bin/java FCCompositeTestPF=Noto Sans Mono CJK JP RegularFC=Noto Sans Mono CJK JP RegularPF=TakaoPGothicFC=Takao Pjava.lang.RuntimeException: FullName mismatch: TakaoPGothic,Takao P at FCCompositeTest.test(FCCompositeTest.java:92) at FCCompositeTest.main(FCCompositeTest.java:52)Exception in thread "main" java.lang.RuntimeException: Method invocation exception at FCCompositeTest.test(FCCompositeTest.java:97) at FCCompositeTest.main(FCCompositeTest.java:52)-phil. On 4/23/19 3:14 AM, Toshio 5 Nakamura wrote: I apologize if my poor description caused confusion. Hi Jay,Thank you so much for your review. Hi phil,I'm looking forward to hearing your results.Noto font is expected to be used more widely, and I'm eager to fix this problem.I welcome any suggestions or comments. Thanks,Toshio Nakamura - Original message -----From: Jayathirth Rao To: Toshio 5 Nakamura Cc: Philip Race , 2d-dev@openjdk.java.netSubject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFontDate: Tue, Apr 9, 2019 3:26 PM Hi, (Ignore the previous mail received with less info) Observations: I went through different FontConfiguration & FontManager implementations and I see that in case of fontConfig(linux) only we are encoding/decoding CompositeFonts in a unique way(In case of font config we override get2DCompositeFontInfo()). For other platforms we use parent get2DCompositeFontInfo() where we are populating face names using getFaceNameFromComponentFontName(). Also getDefaultPlatformFont() returns predetermined face names in case of Windows and Mac. For Linux changes made in FontConfiguration and FontManager looks fine. Thanks, Jay On 04-Apr-2019, at 6:14 PM, Toshio 5 Nakamura <toshi...@jp.ibm.com> wrote: Hi phil, Jay, Thank you for taking your time to review this patch. Thanks, Toshio Nakamura - Original message -From: Jayathirth Rao <jayathirth@oracle.com>To: toshi...@jp.ibm.comCc: 2d-dev <2d-dev@openjdk.java.net>Subject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFontDate: Thu, Apr 4, 2019 8:43 PM Hi, I am also taking a look at this. I will update my observations soon. Thanks, Jay On 04-Apr-2019, at 8:23 AM, Philip Race <philip.r...@oracle.com> wrote: I will get back to this soon but you will still need a 2nd reviewer.-phil.On 3/25/19, 12:29 AM, Toshio 5 Nakamura wrote: Hi Phil, Just a gentle reminder, I appreciate it if you have a time to look at this. Thanks, Toshio Nakamura - Original message -From: "Toshio 5 Nakamura" Sent by: "2d-dev" <2d-dev-boun...@openjdk.java.net>To: Philip Race Cc: 2d-dev <2d-d
Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFont
Hi Phil, Thank you so much for the review and pointing out. I updated the webrev to cover non-English results by testcase side. Additionally, I need another fix in FcFontConfiguration.java.From internationalization view point, we need to tell zh_CN and zh_TW,and fcinfo's file name requires not only language but also country. I tested this with major locales under Ubuntu 16.04, 18.04, CentOS 7,RHEL7 and 8beta. Could you kindly review this again?http://cr.openjdk.java.net/~tnakamura/8219901/webrev.02/ Thanks,Toshio Nakamura - Original message -From: Phil Race To: Toshio 5 Nakamura , jayathirth@oracle.comCc: 2d-dev@openjdk.java.netSubject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFontDate: Fri, Apr 26, 2019 7:26 AM The test fails for me when I set the Japanese locale. I am using Ubuntu 16.04.Have you done any locale testing ?env|grep LANGLANG=ja_JP.UTF-8GDM_LANG=ja_JPLANGUAGE=ja_JP.UTF-8 $ ~/jdk-client/build/linux-x86_64-server-release/jdk/bin/java FCCompositeTestPF=Noto Sans Mono CJK JP RegularFC=Noto Sans Mono CJK JP RegularPF=TakaoPGothicFC=Takao Pjava.lang.RuntimeException: FullName mismatch: TakaoPGothic,Takao P at FCCompositeTest.test(FCCompositeTest.java:92) at FCCompositeTest.main(FCCompositeTest.java:52)Exception in thread "main" java.lang.RuntimeException: Method invocation exception at FCCompositeTest.test(FCCompositeTest.java:97) at FCCompositeTest.main(FCCompositeTest.java:52)-phil. On 4/23/19 3:14 AM, Toshio 5 Nakamura wrote: I apologize if my poor description caused confusion. Hi Jay,Thank you so much for your review. Hi phil,I'm looking forward to hearing your results.Noto font is expected to be used more widely, and I'm eager to fix this problem.I welcome any suggestions or comments. Thanks,Toshio Nakamura - Original message -From: Jayathirth Rao To: Toshio 5 Nakamura Cc: Philip Race , 2d-dev@openjdk.java.netSubject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFontDate: Tue, Apr 9, 2019 3:26 PM Hi, (Ignore the previous mail received with less info) Observations: I went through different FontConfiguration & FontManager implementations and I see that in case of fontConfig(linux) only we are encoding/decoding CompositeFonts in a unique way(In case of font config we override get2DCompositeFontInfo()). For other platforms we use parent get2DCompositeFontInfo() where we are populating face names using getFaceNameFromComponentFontName(). Also getDefaultPlatformFont() returns predetermined face names in case of Windows and Mac. For Linux changes made in FontConfiguration and FontManager looks fine. Thanks, Jay On 04-Apr-2019, at 6:14 PM, Toshio 5 Nakamura <toshi...@jp.ibm.com> wrote: Hi phil, Jay, Thank you for taking your time to review this patch. Thanks, Toshio Nakamura - Original message -From: Jayathirth Rao <jayathirth@oracle.com>To: toshi...@jp.ibm.comCc: 2d-dev <2d-dev@openjdk.java.net>Subject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFontDate: Thu, Apr 4, 2019 8:43 PM Hi, I am also taking a look at this. I will update my observations soon. Thanks, Jay On 04-Apr-2019, at 8:23 AM, Philip Race <philip.r...@oracle.com> wrote: I will get back to this soon but you will still need a 2nd reviewer.-phil.On 3/25/19, 12:29 AM, Toshio 5 Nakamura wrote: Hi Phil, Just a gentle reminder, I appreciate it if you have a time to look at this. Thanks, Toshio Nakamura ----- Original message -From: "Toshio 5 Nakamura" Sent by: "2d-dev" <2d-dev-boun...@openjdk.java.net>To: Philip Race Cc: 2d-dev <2d-dev@openjdk.java.net>Subject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFontDate: Mon, Mar 11, 2019 9:58 PM Hi Phil,Thank you so much for your reviewing.Yes, "family" part can be removed with a few changes in"src/java.desktop/unix/classes/sun/awt/FcFontManager.java".The updated webrev is:http://cr.openjdk.java.net/~tnakamura/8219901/webrev.01/> So you don't need to clean everything - just your develop -internal> and -ea folders.Yes, thank you for the clarification.Thanks,Toshio NakamuraPhilip Race wrote on 2019/03/10 18:05:18:> From: Philip Race > To: Toshio 5 Nakamura > Cc: 2d-dev <2d-dev@openjdk.java.net>> Date: 2019/03/10 18:05> Subject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East> Asian countries cannot belong to CompositeFont>> I can sponsor this but first :>> You seem to have made "family" redundant but aren't removing it.> There's no point in writing it out if nothing uses it on reading.> So we should remove it unless you can explain why you think it should be kept.>&g
Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFont
I apologize if my poor description caused confusion. Hi Jay,Thank you so much for your review. Hi phil,I'm looking forward to hearing your results.Noto font is expected to be used more widely, and I'm eager to fix this problem.I welcome any suggestions or comments. Thanks,Toshio Nakamura - Original message -From: Jayathirth Rao To: Toshio 5 Nakamura Cc: Philip Race , 2d-dev@openjdk.java.netSubject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFontDate: Tue, Apr 9, 2019 3:26 PM Hi, (Ignore the previous mail received with less info) Observations: I went through different FontConfiguration & FontManager implementations and I see that in case of fontConfig(linux) only we are encoding/decoding CompositeFonts in a unique way(In case of font config we override get2DCompositeFontInfo()). For other platforms we use parent get2DCompositeFontInfo() where we are populating face names using getFaceNameFromComponentFontName(). Also getDefaultPlatformFont() returns predetermined face names in case of Windows and Mac. For Linux changes made in FontConfiguration and FontManager looks fine. Thanks, Jay On 04-Apr-2019, at 6:14 PM, Toshio 5 Nakamura <toshi...@jp.ibm.com> wrote: Hi phil, Jay, Thank you for taking your time to review this patch. Thanks, Toshio Nakamura - Original message -From: Jayathirth Rao <jayathirth@oracle.com>To: toshi...@jp.ibm.comCc: 2d-dev <2d-dev@openjdk.java.net>Subject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFontDate: Thu, Apr 4, 2019 8:43 PM Hi, I am also taking a look at this. I will update my observations soon. Thanks, Jay On 04-Apr-2019, at 8:23 AM, Philip Race <philip.r...@oracle.com> wrote: I will get back to this soon but you will still need a 2nd reviewer.-phil.On 3/25/19, 12:29 AM, Toshio 5 Nakamura wrote: Hi Phil, Just a gentle reminder, I appreciate it if you have a time to look at this. Thanks, Toshio Nakamura - Original message -From: "Toshio 5 Nakamura" Sent by: "2d-dev" <2d-dev-boun...@openjdk.java.net>To: Philip Race Cc: 2d-dev <2d-dev@openjdk.java.net>Subject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFontDate: Mon, Mar 11, 2019 9:58 PM Hi Phil,Thank you so much for your reviewing.Yes, "family" part can be removed with a few changes in"src/java.desktop/unix/classes/sun/awt/FcFontManager.java".The updated webrev is:http://cr.openjdk.java.net/~tnakamura/8219901/webrev.01/> So you don't need to clean everything - just your develop -internal> and -ea folders.Yes, thank you for the clarification.Thanks,Toshio NakamuraPhilip Race wrote on 2019/03/10 18:05:18:> From: Philip Race > To: Toshio 5 Nakamura > Cc: 2d-dev <2d-dev@openjdk.java.net>> Date: 2019/03/10 18:05> Subject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East> Asian countries cannot belong to CompositeFont>> I can sponsor this but first :>> You seem to have made "family" redundant but aren't removing it.> There's no point in writing it out if nothing uses it on reading.> So we should remove it unless you can explain why you think it should be kept.>> I don't think this (removing it) is a problem for backports or> compatibility of the> format since release name is part of the file name where we write> the information,> and such a file name will necessarily be a consequence of a feature> or update release> containing this fix.>> Where it might be an issue is testing on 13-ea builds since they all report> that as the version string so for testing you may need to clean out your> ~/.java/fonts/13-ea folder. The same is for your 13-internal private builds.>> I think this is your point when you wrote :->>> The cached font list is stored under ~/.java/fonts directory.>> We should delete it before applying the fix.>> So you don't need to clean everything - just your develop -internal> and -ea folders.>> Meanwhile I tested it .. and it seemed OK but I am still trying to join> up all the dots to make sure it is all correct code-wise.>> -phil>> On 2/28/19, 3:21 PM, Toshio 5 Nakamura wrote: > Hi,>> Could you review the fix and may I have a sponsor for it?>> Bug: https://bugs.openjdk.java.net/browse/JDK-8219901> Webrev: http://cr.openjdk.java.net/~tnakamura/8219901/webrev.00/>> Issue:> Even if Google Noto fonts[1] were installed and listed by fontconfig library> on Linux, CompositeFont couldn't contain it.>> Fix description:> "src/java.desktop/share/classes/sun/font/CompositeFont.java" (l. 296)> validates the target font by comparing names. But, the current code> compared FamilyName with FullName (Font.ge
Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFont
Hi Phil, Just a gentle reminder, I appreciate it if you have a time to look at this. Thanks, Toshio Nakamura - Original message -From: "Toshio 5 Nakamura" Sent by: "2d-dev" <2d-dev-boun...@openjdk.java.net>To: Philip Race Cc: 2d-dev <2d-dev@openjdk.java.net>Subject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFontDate: Mon, Mar 11, 2019 9:58 PM Hi Phil,Thank you so much for your reviewing.Yes, "family" part can be removed with a few changes in"src/java.desktop/unix/classes/sun/awt/FcFontManager.java".The updated webrev is:http://cr.openjdk.java.net/~tnakamura/8219901/webrev.01/> So you don't need to clean everything - just your develop -internal> and -ea folders.Yes, thank you for the clarification.Thanks,Toshio NakamuraPhilip Race wrote on 2019/03/10 18:05:18:> From: Philip Race > To: Toshio 5 Nakamura > Cc: 2d-dev <2d-dev@openjdk.java.net>> Date: 2019/03/10 18:05> Subject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East> Asian countries cannot belong to CompositeFont>> I can sponsor this but first :>> You seem to have made "family" redundant but aren't removing it.> There's no point in writing it out if nothing uses it on reading.> So we should remove it unless you can explain why you think it should be kept.>> I don't think this (removing it) is a problem for backports or> compatibility of the> format since release name is part of the file name where we write> the information,> and such a file name will necessarily be a consequence of a feature> or update release> containing this fix.>> Where it might be an issue is testing on 13-ea builds since they all report> that as the version string so for testing you may need to clean out your> ~/.java/fonts/13-ea folder. The same is for your 13-internal private builds.>> I think this is your point when you wrote :->>> The cached font list is stored under ~/.java/fonts directory.>> We should delete it before applying the fix.>> So you don't need to clean everything - just your develop -internal> and -ea folders.>> Meanwhile I tested it .. and it seemed OK but I am still trying to join> up all the dots to make sure it is all correct code-wise.>> -phil>> On 2/28/19, 3:21 PM, Toshio 5 Nakamura wrote: > Hi,>> Could you review the fix and may I have a sponsor for it?>> Bug: https://bugs.openjdk.java.net/browse/JDK-8219901> Webrev: http://cr.openjdk.java.net/~tnakamura/8219901/webrev.00/>> Issue:> Even if Google Noto fonts[1] were installed and listed by fontconfig library> on Linux, CompositeFont couldn't contain it.>> Fix description:> "src/java.desktop/share/classes/sun/font/CompositeFont.java" (l. 296)> validates the target font by comparing names. But, the current code> compared FamilyName with FullName (Font.getFontName()).> Then, Noto font was treated as invalid.> "src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java"> should provide FullName.>> The cached font list is stored under ~/.java/fonts directory.> We should delete it before applying the fix.>> This fix is possible to change the default font, if CompositeFont> is used (especially under Ubuntu18.04 and East Asian settings).> But, I believe the fixed behavior is correct.>> [1] https://www.google.com/get/noto/>> Thanks,> Toshio Nakamura
Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFont
Hi Phil, Thank you so much for your reviewing. Yes, "family" part can be removed with a few changes in "src/java.desktop/unix/classes/sun/awt/FcFontManager.java". The updated webrev is: http://cr.openjdk.java.net/~tnakamura/8219901/webrev.01/ > So you don't need to clean everything - just your develop -internal > and -ea folders. Yes, thank you for the clarification. Thanks, Toshio Nakamura Philip Race wrote on 2019/03/10 18:05:18: > From: Philip Race > To: Toshio 5 Nakamura > Cc: 2d-dev <2d-dev@openjdk.java.net> > Date: 2019/03/10 18:05 > Subject: Re: [OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East > Asian countries cannot belong to CompositeFont > > I can sponsor this but first : > > You seem to have made "family" redundant but aren't removing it. > There's no point in writing it out if nothing uses it on reading. > So we should remove it unless you can explain why you think it should be kept. > > I don't think this (removing it) is a problem for backports or > compatibility of the > format since release name is part of the file name where we write > the information, > and such a file name will necessarily be a consequence of a feature > or update release > containing this fix. > > Where it might be an issue is testing on 13-ea builds since they all report > that as the version string so for testing you may need to clean out your > ~/.java/fonts/13-ea folder. The same is for your 13-internal private builds. > > I think this is your point when you wrote :- > >> The cached font list is stored under ~/.java/fonts directory. >> We should delete it before applying the fix. > > So you don't need to clean everything - just your develop -internal > and -ea folders. > > Meanwhile I tested it .. and it seemed OK but I am still trying to join > up all the dots to make sure it is all correct code-wise. > > -phil > > On 2/28/19, 3:21 PM, Toshio 5 Nakamura wrote: > Hi, > > Could you review the fix and may I have a sponsor for it? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8219901 > Webrev: http://cr.openjdk.java.net/~tnakamura/8219901/webrev.00/ > > Issue: > Even if Google Noto fonts[1] were installed and listed by fontconfig library > on Linux, CompositeFont couldn't contain it. > > Fix description: > "src/java.desktop/share/classes/sun/font/CompositeFont.java" (l. 296) > validates the target font by comparing names. But, the current code > compared FamilyName with FullName (Font.getFontName()). > Then, Noto font was treated as invalid. > "src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java" > should provide FullName. > > The cached font list is stored under ~/.java/fonts directory. > We should delete it before applying the fix. > > This fix is possible to change the default font, if CompositeFont > is used (especially under Ubuntu18.04 and East Asian settings). > But, I believe the fixed behavior is correct. > > [1] https://www.google.com/get/noto/ > > Thanks, > Toshio Nakamura
[OpenJDK 2D-Dev] [13] JDK-8219901: Noto fonts for East Asian countries cannot belong to CompositeFont
Hi, Could you review the fix and may I have a sponsor for it? Bug: https://bugs.openjdk.java.net/browse/JDK-8219901 Webrev: http://cr.openjdk.java.net/~tnakamura/8219901/webrev.00/ Issue: Even if Google Noto fonts[1] were installed and listed by fontconfig library on Linux, CompositeFont couldn't contain it. Fix description: "src/java.desktop/share/classes/sun/font/CompositeFont.java" (l. 296) validates the target font by comparing names. But, the current code compared FamilyName with FullName (Font.getFontName()). Then, Noto font was treated as invalid. "src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java" should provide FullName. The cached font list is stored under ~/.java/fonts directory. We should delete it before applying the fix. This fix is possible to change the default font, if CompositeFont is used (especially under Ubuntu18.04 and East Asian settings). But, I believe the fixed behavior is correct. [1] https://www.google.com/get/noto/ Thanks, Toshio Nakamura
[OpenJDK 2D-Dev] JDK-8210707: Some line shaped characters are not displayed without Anti Aliasing
Hello, I reported JDK-8210707: Some line shaped characters are not displayed without Anti Aliasing [1]. With some specific conditions (For example, OpenSans light font, 22points, U+007C VERTICAL LINE), the character is not displayed on AWT. I understood it's not JDK issue, and reported it to FreeType [2]. But, they stated > We lack motivation to track it down because the monochrome rasterizer is not very popular these days. I've explained my situation to them, but I'm worried about stagnating this problem. I appreciate any advice or support. (I'm considering Phil's suggestion to work with Redhat since the environment is Redhat Enterprise Linux. This problem occurs with FreeType libraries of the latest, RHEL bundled, and OpenJDK bundled.) [1] https://bugs.openjdk.java.net/browse/JDK-8210707 [2] https://savannah.nongnu.org/bugs/index.php?54589 Best regards, Toshio Nakamura
[OpenJDK 2D-Dev] Fw: RFR: JDK-8187100: support VariationSelectors(Resend)
Hi Phil,
In other words, I just misunderstood your suggestion below.
Recent discussions led me correct understanding, and I took this way.
sorry for your confusion.
> For example we could explore having isComplexCharCode return true for
these and
> directing all uses down the layout path ? Then we can maybe remove all
this logic from
> case used by the fast path code.
Toshio Nakamura
- Forwarded by Toshio 5 Nakamura/Japan/IBM on 2018/06/26 02:09 -
From: "Toshio 5 Nakamura"
To: Phil Race
Cc: 2d-dev <2d-dev@openjdk.java.net>, "Steven R. Loomis"
Date: 2018/06/23 09:08
Subject:Re: [OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation
Selectors(Resend)
Sent by:"2d-dev" <2d-dev-boun...@openjdk.java.net>
Hi Phil, Steven,
Thank you so much for your support, and sorry for taking your time.
As Akira-san suggested, Harfbuzz has VS capability.
It seems difficult to use its glyph picking up mechanism in this case,
but its layout mechanism we can use. And, I tried to use it.
Regarding default UVS table, if composite fonts keep font slot,
we just need to check whether Base+VS is defined in Non-default UVS table
or not.
When Non-default UVS doesn't have the entry, we always use its default
glyph.
Best regards,
Toshio Nakamura
Inactive hide details for Phil Race ---2018/06/23 07:34:06---Oh .. so this
is doing what I suggested a couple of emails back. IPhil Race ---2018/06/23
07:34:06---Oh .. so this is doing what I suggested a couple of emails back.
If we see a VS we always delegate t
From: Phil Race
To: "Steven R. Loomis"
Cc: Toshio 5 Nakamura , 2d-dev
<2d-dev@openjdk.java.net>
Date: 2018/06/23 07:34
Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation Selectors
(Resend)
Oh .. so this is doing what I suggested a couple of emails back.
If we see a VS we always delegate to TextLayout ?
Yes, it does simplify the patch a lot and I am perfectly OK with
this approach but I am surprised as, but Toshio was very keen on
having it there without TextLayout being needed .. why the change of
heart ?
But I don't get the removal (skipping) of the Default UVS table ?
-phil.
On 06/22/2018 03:26 PM, Steven R. Loomis wrote:
Phil, does this help:
https://gist.github.com/srl295/a81ec3a8495d53b85f368a7872138e86#file-webrev-02-vs-03-diff
it is a diff between the 02 and 03 versions.
On Fri, Jun 22, 2018 at 2:59 PM Phil Race <
philip.r...@oracle.com> wrote:
Please save me time and tell me where I will find the
changes from the .02 version ?
In particular I mean where are the changes associated
with
"Use TextLayout (Harfbuzz) if VS appears." ?
-phil.
On 06/22/2018 12:59 PM, Steven R. Loomis wrote:
Updated webrev:
http://cr.openjdk.java.net/~srl/8187100/webrev.03
- Use TextLayout (Harfbuzz) if VS appears.
- Composite font's behavior was changed to
not change the font by VS.
These changes made the patch so simplified.
- add comment about suggested DejaVu version
On Thu, May 31, 2018 at 3:19 PM Steven R.
Loomis wrote:
Updated webrev:
http://cr.openjdk.java.net/~srl/8187100/webrev.01/
On Fri, May 18, 2018 at 9:16 AM, Toshio 5
Nakamura wrote:
Thank you for your review, Phil.
I'm working to handle your points.
Toshio Nakamura
Philip Race
wrote on 2018/05/18 13:39:35:
> From: Philip Race <
philip.r...@oracle.com>
> To: Toshio 5 Nakamura <
toshi...@jp.ibm.com>
> Cc: 2d-dev <2d-dev@openjdk.java.net>
> Date: 2018/05/18 13:39
> Subject: Re: [OpenJDK 2D-Dev] RFR:
JDK-8187100: support Variation
> Selectors(Resend)
>
> There's a lot to think about here but
I have some requests to first
Re: [OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation Selectors(Resend)
Hi Phil, Steven,
Thank you so much for your support, and sorry for taking your time.
As Akira-san suggested, Harfbuzz has VS capability.
It seems difficult to use its glyph picking up mechanism in this case,
but its layout mechanism we can use. And, I tried to use it.
Regarding default UVS table, if composite fonts keep font slot,
we just need to check whether Base+VS is defined in Non-default UVS table
or not.
When Non-default UVS doesn't have the entry, we always use its default
glyph.
Best regards,
Toshio Nakamura
From: Phil Race
To: "Steven R. Loomis"
Cc: Toshio 5 Nakamura , 2d-dev
<2d-dev@openjdk.java.net>
Date: 2018/06/23 07:34
Subject:Re: [OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation
Selectors(Resend)
Oh .. so this is doing what I suggested a couple of emails back.
If we see a VS we always delegate to TextLayout ?
Yes, it does simplify the patch a lot and I am perfectly OK with
this approach but I am surprised as, but Toshio was very keen on
having it there without TextLayout being needed .. why the change of
heart ?
But I don't get the removal (skipping) of the Default UVS table ?
-phil.
On 06/22/2018 03:26 PM, Steven R. Loomis wrote:
Phil, does this help:
https://gist.github.com/srl295/a81ec3a8495d53b85f368a7872138e86#file-webrev-02-vs-03-diff
it is a diff between the 02 and 03 versions.
On Fri, Jun 22, 2018 at 2:59 PM Phil Race
wrote:
Please save me time and tell me where I will find the changes from
the .02 version ?
In particular I mean where are the changes associated with
"Use TextLayout (Harfbuzz) if VS appears." ?
-phil.
On 06/22/2018 12:59 PM, Steven R. Loomis wrote:
Updated webrev:
http://cr.openjdk.java.net/~srl/8187100/webrev.03
- Use TextLayout (Harfbuzz) if VS appears.
- Composite font's behavior was changed to not change the
font by VS.
These changes made the patch so simplified.
- add comment about suggested DejaVu version
On Thu, May 31, 2018 at 3:19 PM Steven R. Loomis <
s...@icu-project.org> wrote:
Updated webrev:
http://cr.openjdk.java.net/~srl/8187100/webrev.01/
On Fri, May 18, 2018 at 9:16 AM, Toshio 5 Nakamura <
toshi...@jp.ibm.com> wrote:
Thank you for your review, Phil.
I'm working to handle your points.
Toshio Nakamura
Philip Race wrote on 2018/05/18
13:39:35:
> From: Philip Race
> To: Toshio 5 Nakamura
> Cc: 2d-dev <2d-dev@openjdk.java.net>
> Date: 2018/05/18 13:39
> Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8187100: support
Variation
> Selectors(Resend)
>
> There's a lot to think about here but I have some
requests to first
> clean up the proposed code to conform to coding
standards.
>
> I see lots of lines > 80 chars. Please fix
>
> I see if(foo){ and else{ which should be "if (foo) {"
and "else {"
>
> Basically always have a space before { and after ) and
around "=" and "=="
>
> One line that WAS
> 51 hb_codepoint_t u = (variation_selector==0) ?
unicode :
> variation_selector;
>
> has no spaces around "==" almost certainly to avoid
going over 80 chars.
> Now you've broken the line you can fix that.
>
> Eliminate all wild card imports and import exactly what
is needed.
> Maybe this is only about the test.
>
> remove what looks like SCCS style comments on the @test
line.
> Make the test simply print a warning if the person
didn't install
> fonts where you expected.
> Why? Because @ignore defaults to .. not being ignored.
>
> For the JNI methods calls read the spec and see if
calling them may
> throw an exception
>
> I'm looking at sequences like
> env->SetIntArrayRegion(unicodes, 0, 2, tmp);
> 71 env->CallV
Re: [OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation Selectors(Resend)
Hi Phil,
Thank you for your comments.
That situation (mixing fonts by characters) sometimes
occurs in Japanese environment, and I naturally thought
displaying specified glyph has priority.
For example, a composite font has
FontA (contains Japanese Kanji Level 1/2 (basic)) and
FontB (contains Kanji Level 1/2/3/4 (basic+extension)).
Then, if using a Kanji Level 3 character among Kanji
Level 1/2 characters, FontB appears among FontA.
The behavior of composite font with VS is not described
in Unicode Standard. I'm not sure which behavior should
be chosen.
Best regards,
Toshio Nakamura
From: Phil Race
To: Toshio 5 Nakamura , "Steven R. Loomis"
Cc: 2d-dev <2d-dev@openjdk.java.net>, srl...@gmail.com
Date: 2018/06/20 05:38
Subject:Re: [OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation
Selectors(Resend)
On 06/18/2018 10:28 AM, Toshio 5 Nakamura wrote:
Hi Phil,
Thank you very much for your great comments.
I tried to handle your comment as much as I could. Could you kindly
rereview it?
(So far, it contains only our contribution.)
> Updated webrev 02
http://cr.openjdk.java.net/~srl/8187100/webrev.02/
The following points were not directly applicable. I'd like to
explain them.
- Performance concern of fast path
We'd like to handle direct drawing such as Graphics2D.drawString, and
layout is not used in this case.
I tired to separate the original methods and VS capable ones to
minimize a impact.
Only if VS character appears, VS capable method will be called.
right and I was saying in my email of 11th June, that your way of detecting
if a VS char is there could be more efficient
It is somewhat improved in this update ..
(except FontRunIterator.java:next, which uses a member variable and
couldn't use that way.)
- Complex code of CMap
Composite fonts need to search a glyph by two steps.
1 - Search VS specific glyph in each composed font.
2 - If it's not available in all fonts, search a glyph without VS.
I changed getGlyph method with allowFallback parameter,
hope it clears our purpose.
I believe that if you are looking for a glyph for (say) U+ then it
should always come
from the same slot of a composite font whether a variation selector is
specified or not.
Otherwise you may get glyphs with variations from a different font than the
glyphs from
the same script without variations and that may look very wrong.
So I am not sure about that and maybe we'll change it in the future.
I am running some general font tests to make sure this does not break
anything,
If that passes OK then we should be OK.
-phil.
- isVariationSelector for two blocks
VS characters are U+FE00-U+FE0F and U+E0100-U+E01FF.
The latter is represented by Surrogate pair in a char array.
My previous code named the same for them, and it may cause a
confusion.
I updated the names to isVariationSelectorBMP and
isVariationSelectorExt.
Steven,
Thank you for your kind support.
Best regards,
Toshio Nakamura, IBM Japan
Inactive
hide details for "Steven R. Loomis" ---2018/06/19
02:02:35---Updated webrev 02
https://urldefense.proofpoint.com/v2/ur"Steven R. Loomis"
---2018/06/19 02:02:35---Updated webrev 02 INVALID URI REMOVED
From: "Steven R. Loomis"
To: Toshio 5 Nakamura
Cc: Philip Race , 2d-dev
<2d-dev@openjdk.java.net>
Date: 2018/06/19 02:02
Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation
Selectors(Resend)
Sent by: srl...@gmail.com
Updated webrev 02 http://cr.openjdk.java.net/~srl/8187100/webrev.02/
On Thu, May 31, 2018 at 3:19 PM, Steven R. Loomis <
s...@icu-project.org> wrote:
Updated webrev:
http://cr.openjdk.java.net/~srl/8187100/webrev.01/
On Fri, May 18, 2018 at 9:16 AM, Toshio 5 Nakamura <
toshi...@jp.ibm.com> wrote:
Thank you for your review, Phil.
I'm working to handle your points.
Toshio Nakamura
Philip Race wrote on 2018/05/18
13:39:35:
> From: Philip Race
> To: Toshio 5 Nakamura
> Cc: 2d-dev <2d-dev@openjdk.java.net>
> Date: 2018/05/18 13:39
> Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8187100: support
Variation
> Selectors(Resend)
>
> There's a lot to think about here but I have some requests to
first
> clean up the proposed code to conform to coding standards.
>
> I see lots of lines > 80 chars. Please fix
>
> I see if(foo){ and else{ whi
Re: [OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation Selectors(Resend)
Hi Phil,
Thank you very much for your great comments.
I tried to handle your comment as much as I could. Could you kindly
rereview it?
(So far, it contains only our contribution.)
> Updated webrev 02 http://cr.openjdk.java.net/~srl/8187100/webrev.02/
The following points were not directly applicable. I'd like to explain
them.
- Performance concern of fast path
We'd like to handle direct drawing such as Graphics2D.drawString, and
layout is not used in this case.
I tired to separate the original methods and VS capable ones to minimize a
impact.
Only if VS character appears, VS capable method will be called.
(except FontRunIterator.java:next, which uses a member variable and
couldn't use that way.)
- Complex code of CMap
Composite fonts need to search a glyph by two steps.
1 - Search VS specific glyph in each composed font.
2 - If it's not available in all fonts, search a glyph without VS.
I changed getGlyph method with allowFallback parameter,
hope it clears our purpose.
- isVariationSelector for two blocks
VS characters are U+FE00-U+FE0F and U+E0100-U+E01FF.
The latter is represented by Surrogate pair in a char array.
My previous code named the same for them, and it may cause a confusion.
I updated the names to isVariationSelectorBMP and isVariationSelectorExt.
Steven,
Thank you for your kind support.
Best regards,
Toshio Nakamura, IBM Japan
From: "Steven R. Loomis"
To: Toshio 5 Nakamura
Cc: Philip Race , 2d-dev
<2d-dev@openjdk.java.net>
Date: 2018/06/19 02:02
Subject:Re: [OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation
Selectors(Resend)
Sent by:srl...@gmail.com
Updated webrev 02 http://cr.openjdk.java.net/~srl/8187100/webrev.02/
On Thu, May 31, 2018 at 3:19 PM, Steven R. Loomis
wrote:
Updated webrev:
http://cr.openjdk.java.net/~srl/8187100/webrev.01/
On Fri, May 18, 2018 at 9:16 AM, Toshio 5 Nakamura
wrote:
Thank you for your review, Phil.
I'm working to handle your points.
Toshio Nakamura
Philip Race wrote on 2018/05/18 13:39:35:
> From: Philip Race
> To: Toshio 5 Nakamura
> Cc: 2d-dev <2d-dev@openjdk.java.net>
> Date: 2018/05/18 13:39
> Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation
> Selectors(Resend)
>
> There's a lot to think about here but I have some requests to first
> clean up the proposed code to conform to coding standards.
>
> I see lots of lines > 80 chars. Please fix
>
> I see if(foo){ and else{ which should be "if (foo) {" and "else {"
>
> Basically always have a space before { and after ) and around "=" and
"=="
>
> One line that WAS
> 51 hb_codepoint_t u = (variation_selector==0) ? unicode :
> variation_selector;
>
> has no spaces around "==" almost certainly to avoid going over 80
chars.
> Now you've broken the line you can fix that.
>
> Eliminate all wild card imports and import exactly what is needed.
> Maybe this is only about the test.
>
> remove what looks like SCCS style comments on the @test line.
> Make the test simply print a warning if the person didn't install
> fonts where you expected.
> Why? Because @ignore defaults to .. not being ignored.
>
> For the JNI methods calls read the spec and see if calling them may
> throw an exception
>
> I'm looking at sequences like
> env->SetIntArrayRegion(unicodes, 0, 2, tmp);
> 71 env->CallVoidMethod(font2D,
> sunFontIDs.f2dCharsToGlyphsMID, 2, unicodes, results);
> 72 env->GetIntArrayRegion(results, 0, 2, tmp);
> 73 *glyph = tmp[0];
> 74 cleanup:
> 75 if (unicodes != NULL) env->DeleteLocalRef(unicodes);
> 76 if (results != NULL) env->DeleteLocalRef(results);
>
> If call GetIntArrayRegion may leave a pending exception it needs to
> be checked and cleared
> before you make another call.
>
> Look at the performance implications of things like the extra
> work done now in FontUtilities.isSimpleChar() and see how to minimise
> it since it could affect all text rendering in a way that is
measurable
> in at least some way.
>
> I idly wonder if
>
>
> public static boolean isBaseChar(int charCode){ ...
>
> might be more cleanly or efficiently implemented with a switch ?
>
> Not sure.
>
> -phil.
>
> On 5/14/18, 1:28 AM, Toshio 5 Nakamura wrote:
> Could someone review our proposal to support Unicode Variation
Selectors?
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8187100
> > Webrev: http://cr.openjdk.java.net/~srl/8187100/webrev.00/
>
Re: [OpenJDK 2D-Dev] JDK-8187100 [PATCH][SWING] To make display Variation Selector(IVS/SVS/FVS)
Hi
That's very encourage us that the similar requirement exist.
As the starting point of discussion, I'd like to share the results of
analysis.
(This is also Steven's request.)
1) Heap usage
Akira-san's code had smaller foot print.
(Mesured by Font2Demo, IPAmj font, and RHEL7)
Akira-san's
(w/o VS) 7454464 bytes, (w/ VS) 7773472 bytes
Ours
(w/o VS) 7593096 bytes, (w/ VS) 7631088 bytes
2) Mongolian support
This works for not only FVS, but also other Mongolian glyphs.
This is separated by our patch.
3) Swing key operations
I agreed that this is another layer's issue, and dropped from my patch,
too.
4) Our code's advantages
- Composite (logical) fonts support
- Obeyed Unicode standard more strictly
- Base character definition
- Behavior when no VS glyph is available
I sent my latest update to Steven, which was revised based on Phil's greate
comments.
Best regards,
Toshio Nakamura, IBM Japan
From: Nakajima Akira
To: Phil Race , <2d-dev@openjdk.java.net>,
Toshio 5 Nakamura , "Steven R. Loomis"
Date: 2018/06/14 08:41
Subject:Re: [OpenJDK 2D-Dev] JDK-8187100 [PATCH][SWING] To make display
Variation Selector(IVS/SVS/FVS)
Hello Phil.
Thanks for your reply and suggestion.
>
http://www.oracle.com/technetwork/community/oca-486395.html
Signed OCA is listed as
NTT Comware Corporation - OpenJDK
--
Company: NTT Comware Corporation
Name: Akira Nakajima
E-Mail: nakajima.ak...@nttcom.co.jp
--
On 2018/06/14 3:14, Phil Race wrote:
> Hi Akira,
>
> It seems that maybe we should be looking at what you propose and
> comparing it
> to see if one or the other approach is better and if one missed
> something the other spotted.
> I'd like to ask Steven and Toshio to take the lead on that.
>
> However for any of your patch to be included it is imperative that you
> FIRST
> have a signed OCA accepted. Please see
>
http://www.oracle.com/technetwork/community/oca-486395.html
> where your name is not present ...
>
> -phil.
>
> On 06/13/2018 12:53 AM, Nakajima Akira wrote:
>> I happened to create similar patch(for SWING and JavaFX) without
>> knowing the report below.
>>
https://bugs.openjdk.java.net/browse/JDK-8187100
>>
>> I do not know much about circumstances, because this is my first post
>> about Java forum.
>> Please discard this if unnecessary.
>>
>>
>> ==
>> Difference with following patch.
>>
http://cr.openjdk.java.net/~srl/8187100/webrev.00/
>>
>> 1. For Acceleration and Memory saving, load only partial format14
>> glyphs table.
>> java.desktop/share/classes/sun/font/CMap.java
>>
>> +if (numMappings[i] > 0 && (uniStart[i] == null ||
>> glyphID[i] == null)) {
>> +try {
>> +initNonDef(i);
>>
>>
>>
>> 2. Support Mongolian and FVS (I checked on Linux and Windows)
>> java.desktop/share/classes/sun/font/FontUtilities.java
>>
>> +else if (code <= 0x18af) { // 1800 - 18AF Mongolian
>> (including FVS)
>> +return true;
>> +}
>>
>>
>> 3. Not implementing following
>>
>> >> 3) Swing text component's DEL and BS key operations change
>>
>>
>>
>>
>> ==
>> This SWING patch fixes following 2 bugs.
>>
>> 1. To make display IVS/SVS (JDK-8187100)
>> Sample is kami.java and kami2.java.
>>
>> java.desktop/share/classes/sun/font/CMap.java
>> java.desktop/share/classes/sun/font/CharToGlyphMapper.java
>> java.desktop/share/classes/sun/font/Font2D.java
>> java.desktop/share/classes/sun/font/TrueTypeGlyphMapper.java
>> java.desktop/share/native/libfontmanager/sunFont.c
>> java.desktop/share/native/libfontmanager/hb-jdk-font.cc
>>
>>
>> 2. To make dislpay Mongolian and FVS
>> Sample is mongol.java.
>>
>> java.desktop/share/classes/sun/font/FontUtilities.java
>>
>>
>>
>> ==
>> I checked this patch on CentOS 7.5 and Windows7 x64.
>>
>>
>> I created same patch for JavaFX
>> and posted to openjfx-...@openjdk.java.net.
>>
>>
>>
>> PATCH
>>
>> diff -r e1b3def12624 src/java.desktop/share/classes/sun/font/CMap.java
>> --- a/src/java.desktop/share/classes/sun/font/CMap.javaWed Jun 13
>> 06:35:04 2018 +0200
>> +++ b/src/java.desktop/share/classes/sun/font/CMap.javaWed Jun 13
&
Re: [OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation Selectors(Resend)
Thank you for your review, Phil.
I'm working to handle your points.
Toshio Nakamura
Philip Race <philip.r...@oracle.com> wrote on 2018/05/18 13:39:35:
> From: Philip Race <philip.r...@oracle.com>
> To: Toshio 5 Nakamura <toshi...@jp.ibm.com>
> Cc: 2d-dev <2d-dev@openjdk.java.net>
> Date: 2018/05/18 13:39
> Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation
> Selectors(Resend)
>
> There's a lot to think about here but I have some requests to first
> clean up the proposed code to conform to coding standards.
>
> I see lots of lines > 80 chars. Please fix
>
> I see if(foo){ and else{ which should be "if (foo) {" and "else {"
>
> Basically always have a space before { and after ) and around "=" and
"=="
>
> One line that WAS
> 51 hb_codepoint_t u = (variation_selector==0) ? unicode :
> variation_selector;
>
> has no spaces around "==" almost certainly to avoid going over 80 chars.
> Now you've broken the line you can fix that.
>
> Eliminate all wild card imports and import exactly what is needed.
> Maybe this is only about the test.
>
> remove what looks like SCCS style comments on the @test line.
> Make the test simply print a warning if the person didn't install
> fonts where you expected.
> Why? Because @ignore defaults to .. not being ignored.
>
> For the JNI methods calls read the spec and see if calling them may
> throw an exception
>
> I'm looking at sequences like
> env->SetIntArrayRegion(unicodes, 0, 2, tmp);
> 71 env->CallVoidMethod(font2D,
> sunFontIDs.f2dCharsToGlyphsMID, 2, unicodes, results);
> 72 env->GetIntArrayRegion(results, 0, 2, tmp);
> 73 *glyph = tmp[0];
> 74 cleanup:
> 75 if (unicodes != NULL) env->DeleteLocalRef(unicodes);
> 76 if (results != NULL) env->DeleteLocalRef(results);
>
> If call GetIntArrayRegion may leave a pending exception it needs to
> be checked and cleared
> before you make another call.
>
> Look at the performance implications of things like the extra
> work done now in FontUtilities.isSimpleChar() and see how to minimise
> it since it could affect all text rendering in a way that is measurable
> in at least some way.
>
> I idly wonder if
>
>
>public static boolean isBaseChar(int charCode){ ...
>
> might be more cleanly or efficiently implemented with a switch ?
>
> Not sure.
>
> -phil.
>
> On 5/14/18, 1:28 AM, Toshio 5 Nakamura wrote:
> Could someone review our proposal to support Unicode Variation Selectors?
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8187100
> > Webrev: http://cr.openjdk.java.net/~srl/8187100/webrev.00/
>
> Toshio Nakamura
>
> > From: "Steven R. Loomis" <srl...@gmail.com>
> > To: 2d-dev <2d-dev@openjdk.java.net>
> > Date: 2018/05/03 03:27
> > Subject: Re: [OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation
> > Selectors (Resend)
> > Sent by: "2d-dev" <2d-dev-boun...@openjdk.java.net>
> >
> > I added a screenshot to
https://bugs.openjdk.java.net/browse/JDK-8187100
> > if anyone wants to see what the impact of this fix is
> >
> > On Wed, Apr 25, 2018 at 8:39 AM, Steven R. Loomis <srl...@gmail.com>
wrote:
> > (Retrying as actual text)
> >
> > Support Unicode Variation Selectors.
> >
> > Code by my colleague Toshio Nakamura, I added a simple test, and
> > include a test that was part of JDK 8187100. (Both tests are run
manually.)
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8187100
> > Webrev: http://cr.openjdk.java.net/~srl/8187100/webrev.00/
> >
> > On 04/08/2018 11:46 PM, Toshio 5 Nakamura wrote:
> > >
> > > Hello
> > >
> > > IBM would like to propose Unicode Variation Selector[1] capability to
AWT
> > > and Swing components.
> > > (This proposal was posted to i18n-dev first, and I got a suggestion
to
> > > discuss
> > > in 2d-dev.)
> > >
> > > This proposal changed the following files:
> > > src/java.desktop/share/classes/sun/font/CMap.java
> > > src/java.desktop/share/classes/sun/font/CharToGlyphMapper.java
> > > src/java.desktop/share/classes/sun/font/CompositeGlyphMapper.java
> > > src/java.desktop/share/classes/sun/font/Font2D.java
> > > src/java.desktop/share/classes/sun/font/FontRunIterator.java
> > > src/java.desktop/share/classes/sun/font/FontUtilities.java
> > > src/java.desktop/share/classes/sun/font/TrueTypeGlyphMapper.java
> > > src/java.desktop/share/native/common/font/sunfontids.h
>
Re: [OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation Selectors(Resend)
Hi Steven, Thank you for becoming the sponsor of my proposal and creating an official Webrev and tests. Of course, they are fine for me. Toshio Nakamura From: "Steven R. Loomis" <srl...@gmail.com> To: 2d-dev <2d-dev@openjdk.java.net> Date: 2018/04/26 00:41 Subject:[OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation Selectors (Resend) Sent by:"2d-dev" <2d-dev-boun...@openjdk.java.net> (Retrying as actual text) Support Unicode Variation Selectors. Code by my colleague Toshio Nakamura, I added a simple test, and include a test that was part of JDK 8187100. (Both tests are run manually.) Bug: https://bugs.openjdk.java.net/browse/JDK-8187100 Webrev: http://cr.openjdk.java.net/~srl/8187100/webrev.00/ On 04/08/2018 11:46 PM, Toshio 5 Nakamura wrote: > > Hello > > IBM would like to propose Unicode Variation Selector[1] capability to AWT > and Swing components. > (This proposal was posted to i18n-dev first, and I got a suggestion to > discuss > in 2d-dev.) > > This proposal changed the following files: > src/java.desktop/share/classes/sun/font/CMap.java > src/java.desktop/share/classes/sun/font/CharToGlyphMapper.java > src/java.desktop/share/classes/sun/font/CompositeGlyphMapper.java > src/java.desktop/share/classes/sun/font/Font2D.java > src/java.desktop/share/classes/sun/font/FontRunIterator.java > src/java.desktop/share/classes/sun/font/FontUtilities.java > src/java.desktop/share/classes/sun/font/TrueTypeGlyphMapper.java > src/java.desktop/share/native/common/font/sunfontids.h > src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc > src/java.desktop/share/native/libfontmanager/sunFont.c > src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java > 542 lines will be changed. > > There are three parts. > 1) Adding CMap format 14 support > 2) Adding CharsToGlyphs functions support Variation Selector Sequences > 3) Swing text component's DEL and BS key operations change > > > How would I go about obtaining a sponsor? > > [1] _http://www.unicode.org/versions/Unicode10.0.0/ch23.pdf_ > Chapter 23.4 Variation Selectors > > Best regards, > > Toshio Nakamura > IBM Japan
[OpenJDK 2D-Dev] Proposal: Unicode Variation Selector
Hello IBM would like to propose Unicode Variation Selector[1] capability to AWT and Swing components. (This proposal was posted to i18n-dev first, and I got a suggestion to discuss in 2d-dev.) This proposal changed the following files: src/java.desktop/share/classes/sun/font/CMap.java src/java.desktop/share/classes/sun/font/CharToGlyphMapper.java src/java.desktop/share/classes/sun/font/CompositeGlyphMapper.java src/java.desktop/share/classes/sun/font/Font2D.java src/java.desktop/share/classes/sun/font/FontRunIterator.java src/java.desktop/share/classes/sun/font/FontUtilities.java src/java.desktop/share/classes/sun/font/TrueTypeGlyphMapper.java src/java.desktop/share/native/common/font/sunfontids.h src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc src/java.desktop/share/native/libfontmanager/sunFont.c src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java 542 lines will be changed. There are three parts. 1) Adding CMap format 14 support 2) Adding CharsToGlyphs functions support Variation Selector Sequences 3) Swing text component's DEL and BS key operations change How would I go about obtaining a sponsor? [1] http://www.unicode.org/versions/Unicode10.0.0/ch23.pdf Chapter 23.4 Variation Selectors Best regards, Toshio Nakamura IBM Japan
