On Mon, 25 Apr 2022 08:15:18 GMT, Toshio Nakamura <tnakam...@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 > > Toshio Nakamura has updated the pull request incrementally with one > additional commit since the last revision: > > Moved the fix to WFontConfiguration It looks to me as if we specify a latin font as the text component font, some windows fall back behaviour insists on a minimum size for the Japanese fallback font. And the way to avoid that is to specify a locale (Japanese) font instead which is what used to happen. ------- Naoto suggested : -sequence.allfonts.UTF-8.ja=alphabetic,japanese,dingbats,symbol +sequence.allfonts.UTF-8.ja=japanese,alphabetic,dingbats,symbol This did't work for me because it isn't picking up that line anyway So what I see is that MS Mincho isn't even in the list of names it is considering ! Because we are finding this :- sequence.allfonts=alphabetic/default,dingbats,symbol I see Toshio says he saw the UTF-8 entry being used, but I don't see that. So I need to understand why not the UTF-8 entry - note that I have set my system locale to JA now. The consequence of this is that the fallback sequence is what provides Japanese and so it is from the Chinese MingLiu-ExtB font which I do have installed. Toshio is right that what matters here for the native text component is what is picked up in the logic around WFontConfiguration.getTextComponentFontName() The helper method for getTextComponentFontName() is findFontWithCharset() That has a bit of a questionable behaviour in that it returns the *last* font in the list that matches the charset it wants. So *hypothetically* if we had the charset as DEFAULT_CHARSET MS Mincho,DEFAULT_CHARSET Times New Roman,DEFAULT_CHARSET and if we had Times New Roman,DEFAULT_CHARSET MS Mincho,SHIFTJIS_CHARSET then in both cases we'd get Times and still have the problem The latter case seems to actually happen - and so even though the font is there, we ignore it. Clearly what we want is the "locale" font, and we are using encoding to identify any one that matches but this breaks down in UTF8. Toshio pointed out that code in WFontConfiguration initTables() basically says if we found a font tagged as "japanese" then its subsetCharMap entry is SHIFTJIS_CHARSET and this used to work because this also mapped windows-31j to SHIFTJIS_CHARSET. But what do you map UTF-8 to ? The current code maps it to DEFAULT_CHARSET. There needs to be a different way of doing this for UTF-8 locales. So this fix is a "band aid" on the problem that in the UTF 8 locale we don't seem to be picking up the entry we should. If Toshio confirms for SURE he's seeing the UTF-8 one picked up it would be a useful data point. I still need to debug why I am not getting it. Regarding what Toshio pointed out that we can't have both sequence.allfonts.UTF-8.zh.CN=alphabetic,chinese-ms936,dingbats,symbol,chinese-ms936-extb sequence.allfonts.UTF-8.zh.CN=alphabetic,chinese-gb18030,dingbats,symbol,chinese-gb18030-extb I think that's just a fact. Once you choose UTF-8 you have to decide which of these you want. ------------- PR: https://git.openjdk.java.net/jdk/pull/8329
