[Bug 47872] New: gdiplus:font fails in Japanese locale on Windows 10

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=47872

Bug ID: 47872
           Summary: gdiplus:font fails in Japanese locale on Windows 10
           Product: Wine
           Version: 4.17
          Hardware: x86
                OS: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdiplus
          Assignee: [e-mail]
          Reporter: [e-mail]

gdiplus:font fails in Japanese locale on Windows 10:

font.c:834: Test failed: wrong face name MS UI Gothic
font.c:842: Test failed: wrong face name MS UI Gothic
font.c:853: Test failed: wrong face name MS UI Gothic

https://test.winehq.org/data/tests/gdiplus:font.html

These failures happen on the new w1064v1809-ja TestBot VM but interestingly not
on the win7u64-1spie9-ja VM.
Maybe this means Windows 10 replaced "MS Shell Dlg" with "MS UI Gothic" for the
Japanese locale?

[Bug 47872] gdiplus:font fails in Japanese locale on Windows 10

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=47872

François Gouget  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |source, testcase

[Bug 47872] gdiplus:font fails in Japanese locale on Windows 10

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=47872

Vincent Povirk  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #1 from Vincent Povirk  ---
"MS Shell Dlg" isn't a real font:
https://docs.microsoft.com/en-us/windows/win32/intl/using-ms-shell-dlg-and-m...

It seems that "MS UI Gothic" was always used on a Japanese locale, but gdi32
reported it as the virtual "MS Shell Dlg" font that maps to it. I guess it now
reports the actual font, but only on some locales (Chinese uses "SimSun"
according to current test results).

This also suggests gdiplus doesn't actually know how to do this mapping, or it
would've reported MS UI Gothic on previous Windows versions.

[Bug 47872] gdiplus:font fails in Japanese locale on Windows 10

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=47872

Sagawa  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sagawa.aki+winebugs@gmail.c
                   |                            |om

--- Comment #2 from Sagawa  ---
Created attachment 66083
  --> https://bugs.winehq.org/attachment.cgi?id=66083
gdiplus:font result (Windows 7, ja-jp)

I think SystemPreferredUILanguages cause this issue.

Because, on my Japanese Windows 7, gdiplus:font shows same errors as seen on
Windows 10 (see the attachment for details).

font.c:829: Test failed: wrong face name MS UI Gothic
font.c:837: Test failed: wrong face name MS UI Gothic
font.c:848: Test failed: wrong face name MS UI Gothic

The difference between my environment and win7u64-1spie9-ja VM is
SystemPreferredUILanguages.
On my PC, it's 0411 (Japanese) while on win7u64-1spie9-ja VM[1] it's 0409
(English US). Moreover, on Windows 10 PC[2], it's 0411,0409.

[1]
https://test.winehq.org/data/f870aa4988fa8e980919c144682da72865364ff0/win7_f...
[2]
https://test.winehq.org/data/f870aa4988fa8e980919c144682da72865364ff0/win10_...

What do you think about this point?

[Bug 47872] gdiplus:font fails in Japanese locale on Windows 10

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=47872

--- Comment #3 from François Gouget  ---
It does look like SystemPreferredUILanguages is what causes the difference.
That could mean that this should be checked to either skip the ok() check or
change the expected result.

[Bug 47872] gdiplus:font fails in Japanese locale on Windows 10

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=47872

--- Comment #4 from Vincent Povirk  ---
Part of this is really testing gdi32 behavior. Sometimes DEFAULT_GUI_FONT is a
different face than MS Shell Dlg. That doesn't really belong in the gdiplus
tests. It looks to me like test_stock_fonts in gdi32:font covers this.

The rest may just be a side-effect of not passing MS Shell Dlg into gdiplus
functions.

[Bug 47872] gdiplus:font fails in Japanese locale on Windows 10

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=47872

--- Comment #5 from Vincent Povirk  ---
Can someone with a failing setup test this patch?
https://testbot.winehq.org/JobDetails.pl?Key=62692

(The patch or test .exe can be downloaded from links in the "File name"
column.)

[Bug 47872] gdiplus:font fails in Japanese locale on Windows 10

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=47872

--- Comment #6 from François Gouget  ---
(In reply to Vincent Povirk from comment #5)
> Can someone with a failing setup test this patch?
> https://testbot.winehq.org/JobDetails.pl?Key=62692

That job is gone. Do you still have that patch?

[Bug 47872] gdiplus:font fails in Japanese locale on Windows 10

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=47872

--- Comment #7 from Vincent Povirk  ---
I don't, and I don't have access to a setup to try to recreate it at the
moment.

The change was to hard-code the value of ms_shell_dlg and copy it into the
LOGFONT structure, instead of testing the font face of DEFAULT_GUI_FONT and
copying it out.

[Bug 47872] gdiplus:font fails in Japanese locale on Windows 10

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=47872

--- Comment #8 from Vincent Povirk  ---
Created attachment 66667
  --> https://bugs.winehq.org/attachment.cgi?id=66667
possible fix

My mistake, here it is.

[Bug 47872] gdiplus:font fails in Japanese locale on Windows 10

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=47872

--- Comment #9 from François Gouget  ---
SystemPreferredUILanguages=0409 vs 0411
---------------------------------------

I ran tests where I took control of the VMs and manually tweaked the localed.
The result is that an unpatched gdiplus:font succeeds when
SystemPreferredUILanguages is 0409 and fails if it is set or starts with 0411.

Here's a diff between two unpatched gdiplus:font runs on w1064:

@@ -32,7 +32,7 @@
     SystemDefaultLCID=0409
     UserDefaultLCID=0411
     ThreadLocale=0411
-    SystemPreferredUILanguages=0409
+    SystemPreferredUILanguages=0411,0409
     UserDefaultUILanguage=0411
     ThreadUILanguage=0411
 Dll info:
@@ -41,6 +41,9 @@
 gdiplus:brush skipped dlls/gdiplus/tests/brush.c -
 gdiplus:customlinecap skipped dlls/gdiplus/tests/customlinecap.c -
 gdiplus:font start dlls/gdiplus/tests/font.c -
+font.c:832: Test failed: wrong face name MS UI Gothic
+font.c:840: Test failed: wrong face name MS UI Gothic
+font.c:851: Test failed: wrong face name MS UI Gothic
 font.c:866: fallback font Arial
 font.c:697: gdiplus:
 font.c:698: L"Tahoma",-13: EmHeight 2048, LineSpacing 2472, CellAscent 2049,
CellDescent 423, FontHeight 15.691406, FontSize 13.000000

The 2020-03-16 patch
--------------------

What it does is remove the lfFaceName check against "MS Shell Dlg" so of course
it fixes the first failure.

But a few lines down there are two other checks of lfFaceName against
"Microsoft Sans Serif" || "Tahoma" and those still fail in the Japanese locale.

https://testbot.winehq.org/JobDetails.pl?Key=67263&f217=exe32.report#k21...

Note that without the patch we get the same failures with different font names
in the Chinese VM (test.winehq.org does not have those results because WineTest
times out but you can fish them out on the TestBot). But with the patch all
failures disappear in the Chinese locale!

Maybe the test should check the SystemPreferredUILanguages value and only
perform these tests in a couple of well-known locales (English and French for
instance), since the other locales can apparently get different fonts.

Why different SystemPreferredUILanguages values?
------------------------------------------------

By default my Windows 7 Ultimate VM is in the en-US locale.

1. If I start the Control panel, go to "Clock Language, and Region" -> "Change
display language" -> "Choose a display language", "Japanese" and then reboot,
this is what I get:

SystemPreferredUILanguages=0409
    UserDefaultUILanguage=0411
    ThreadUILanguage=0411

Incidentally this is how I configured win7u64-1spie9-ja, except I also changed
"Administrative" -> "Change system locale..." (and rebooted of course), the
formats and country. I see nothing wrong with this approach to setting the
locale. I suspect this is how most users with a multi-language Windows version
would do it.

I get the same result on Windows 10 when I go through the Settings GUI to
change the locale.

2. If instead I use the TestBot's script and run "SetWinLocale --mui ja-JP" to
recfigure that VM I get:

SystemPreferredUILanguages=0411
    UserDefaultUILanguage=0411
    ThreadUILanguage=0411

SetWinLocale changes the local by running intl.cpl on an XML file. This seems
to be how an administrator would create a 'CD' that installs Windows in a
specific locale. Unfortunately that part is really not very well documented.

Running this method against a Windows 10 VM I get exactly the same results
which makes sense since this is how I normally configure the TestBot's Windows
VM nowadays because it can mostly be automated.

3. There may be a third case which is when a user an already localized version
of Windows on a PC or CD. In the past those Windows versions did not support
multiple languages (Windows 10 changed that). I suspect this third case would
have looked more like the second case but I cannot verify that.

So I don't know why the two methods I use give different results. I also don't
know how to get the same results as method 2 using only the GUI. But I see no
reason why one configuration should be considered broken. So I think the tests
should work in both cases.

[Bug 47872] gdiplus:font fails in Japanese locale on Windows 10

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=47872

[e-mail] changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 47872] gdiplus:font fails in Japanese locale on Windows 10

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=47872

--- Comment #10 from Vincent Povirk  ---
I was hoping that hard-coding "MS Shell Dlg", instead of using the unexpected
value we get out of DEFAULT_GUI_FONT, would fix the remaining failures. I still
think this change is a step in the right direction - we shouldn't be testing
parts of gdi32 that are already tested elsewhere.

We're still sort of testing gdi32 behavior here, as it substitutes another font
for "MS Shell Dlg". But it's also testing that gdiplus succeeds in this case
with the real font (detected using GetTextFaceW) and not MS Shell Dlg.

But now I'm confused, because test_nonexistent_font in gdi32:font also seems to
test for substitution of "MS Shell Dlg" but it expects the face name to be
unchanged.

Perhaps what we really want to test is that we get the same result from gdiplus
that we would through gdi32 with the LOGFONT structure, but that basically
means duplicating code from gdiplus into the tests.

[Bug 47872] gdiplus:font fails in Japanese locale on Windows 10

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=47872

--- Comment #11 from Esme  ---
It turns out font substitution is not detected by GetFaceName. It's determined
later in GdipCreateFontFamilyFromName, using EnumFontFamilies.

I see this is in the gdi32 tests under test_EnumFonts_subst, but it only tests
that the resulting font isn't "MS Shell Dlg".

Is there any value in testing the actual fonts, or is it good enough to test
that gdiplus successfully returns with a different font name?

[Bug 47872] gdiplus:font fails in Japanese locale on Windows 10

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=47872

--- Comment #12 from Esme  ---
FWIW, I think Wine uses this list to decide on the substitution:
https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/gdi32/freetype.c#l372...

Possible values in Wine are: Tahoma, Microsoft Sans Serif [Arabic], MS UI
Gothic [Japanese], SimSun [Chinese Simplified], Gulim [Korean], and PMingLiU
[Chinese Traditional]

https://docs.microsoft.com/en-us/windows/win32/intl/using-ms-shell-dlg-and-m...
describes a similar mapping.

I don't think this is worth testing in gdiplus tests. We should just check that
we get a different font from MS Shell Dlg.

[Bug 47872] gdiplus:font fails in Japanese locale on Windows 10

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=47872

--- Comment #13 from Esme  ---
I sent a patch series but they are being slow to appear.

[Bug 47872] gdiplus:font fails in Japanese locale on Windows 10

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=47872

--- Comment #14 from Esme  ---
Patch links:
https://source.winehq.org/patches/data/181577
https://source.winehq.org/patches/data/181579

[Bug 47872] gdiplus:font fails in Japanese locale on Windows 10

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=47872

--- Comment #15 from Esme  ---
Should be fixed by
https://source.winehq.org/git/wine.git/?a=commit;h=689e94c597471bb5779268bf2...

[Bug 47872] gdiplus:font fails in Japanese locale on Windows 10

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=47872

Gijs Vermeulen  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
      Fixed by SHA1|                            |689e94c597471bb5779268bf21f
                   |                            |093f9668c163e
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #16 from Gijs Vermeulen  ---
There have been no failures on Windows for gdiplus:font for a long time,
marking FIXED.

[Bug 47872] gdiplus:font fails in Japanese locale on Windows 10

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=47872

Alexandre Julliard  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #17 from Alexandre Julliard  ---
Closing bugs fixed in 6.9.