On Tue, 26 Apr 2022 16:50:24 GMT, Phil Race <[email protected]> wrote:
>> Toshio Nakamura has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Moved the fix to WFontConfiguration
>
> Hmm. I'm not sure I'm seeing what you see in the native app.
> There the Latin font is larger than the JDK case, and the Japanese font is
> smaller than the JDK case,
> and they end up about the same size as each other.
> Also you have to remember if you select "8 pt" in a windows native app, that
> (at 100% scale) is at 96dpi, not 72dpi.
> So that's 96/72 times the size of the Java 8 pt font. 8 * 96 / 72 will round
> up to 11 pixels in native, not the 8 pixels in Java.
>
> Also JDK - in theory - controls the exact fonts that are used even in a
> TextField.
>
> I'd like to see this resolved but I'm still not feeling like I have a
> sufficient understanding.
@prrace
Sorry for your confusion. Please allow me to explain with 30-point case. That's
too small Japanese characters than alphabets.
(With 8-point case, the native application clipped upper side, but I couldn't
find the reason.)
Java code:
`t.setFont(new Font(Font.SERIF, Font.PLAIN, 30));`
Native code:
`CreateFont(-30, 0, 0, 0, 0, 0, 0, 0, ANSI_CHARSET, 0, 0, 0, 0, _TEXT("Times
New Roman"));`
These codes displayed the exact same glyphs. Screen shot was attached in JBS.
> Also JDK - in theory - controls the exact fonts that are used even in a
> TextField.
Well, I think TextField sets only one font (HFONT) via
`AwtTextComponent::SetFont(AwtFont* font)`.
`spyxx` command recorded only that WM_SETFONT event.
So, we need to pick up a proper font from fontconfig file.
Now, unexpected encoding was set and unexpected font was picked up.
Expected native call:
`CreateFont(-30, 0, 0, 0, 0, 0, 0, 0, SHIFTJIS_CHARSET, 0, 0, 0, 0, _TEXT("MS
Mincho"));`
-------------
PR: https://git.openjdk.java.net/jdk/pull/8329
