On Fri, 22 Apr 2022 03:24:09 GMT, Phil Race <p...@openjdk.org> wrote:
>> Japanese logical fonts are drawn with wrong size since Java 18. >> It's triggered by JEP 400, UTF-8 by Default. `sun.awt.FontConfiguration` >> (and `sun.awt.windows.WFontConfiguration`) seems to expect the native >> encoding instead of the default encoding. This patch changes to use native >> encoding. >> >> Tested: jdk_desktop on Windows, Linux, and macOS > > Hmm. I am surprised that the glyphs are actually bigger. Did you come to > understand the exact mechanism (steps) > by which this triggers the wrong size ? Without that explanation it isn't > apparent to me we've understood the problem > even if this fixes it. > > And whilst you tested linux & mac it is a shared code change so it is another > reason to understand .. > > And are you sure you can't write a test ? Even something that uses heuristics > around the metrics ? Thank you for the comments, @prrace @naotoj The bigger fonts are caused by the behavior of RichEdit component. I was able to recreate the similar behavior with a native application. I attached the code and the screen shot to JBS. RichEdit seems to use fallback font if English font (Arial, for example) was set for Japanese text. It could show Japanese, but its size was not perfect. So, we need to set a proper font. NG case (Java18): "Arial 9pt" with ANSI_CHARSET was used. OK case (Java17): "MS Gothic 9pt" with SHIFTJIS_CHARSET was used. > And whilst you tested linux & mac it is a shared code change so it is another > reason to understand .. OK, I moved the fix to Windows part. I need to change setEncoding method to protected, because "encoding" value was used in the constructor. > And are you sure you can't write a test ? Even something that uses heuristics > around the metrics ? Sorry, I tried some ways, but I couldn't. It tightly binds with OS settings. A pre-submit test was failed once, but passed after rerun. ------------- PR: https://git.openjdk.java.net/jdk/pull/8329
