RFR: 8285308: Win: Japanese logical fonts are drawn with wrong size [v2]

[Phil Race]

On Mon, 25 Apr 2022 08:15:18 GMT, Toshio Nakamura <tnakamura at 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