[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 <fgouget at codeweavers.com> ---
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#k217

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.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.