[Bug 47872] New: gdiplus:font fails in Japanese locale on Windows 10
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: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com 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? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47872 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47872 Vincent Povirk <madewokherd(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd(a)gmail.com --- Comment #1 from Vincent Povirk <madewokherd(a)gmail.com> --- "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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47872 Sagawa <sagawa.aki+winebugs(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sagawa.aki+winebugs(a)gmail.c | |om --- Comment #2 from Sagawa <sagawa.aki+winebugs(a)gmail.com> --- 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? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47872 --- Comment #3 from François Gouget <fgouget(a)codeweavers.com> --- 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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47872 --- Comment #4 from Vincent Povirk <madewokherd(a)gmail.com> --- 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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47872 --- Comment #5 from Vincent Povirk <madewokherd(a)gmail.com> --- 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.) -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47872 --- Comment #6 from François Gouget <fgouget(a)codeweavers.com> --- (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? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47872 --- Comment #7 from Vincent Povirk <madewokherd(a)gmail.com> --- 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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47872 --- Comment #8 from Vincent Povirk <madewokherd(a)gmail.com> --- Created attachment 66667 --> https://bugs.winehq.org/attachment.cgi?id=66667 possible fix My mistake, here it is. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47872 --- Comment #9 from François Gouget <fgouget(a)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.
https://bugs.winehq.org/show_bug.cgi?id=47872 maniikarabera(a)protonmail.ch changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |maniikarabera(a)protonmail.ch -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47872 --- Comment #10 from Vincent Povirk <madewokherd(a)gmail.com> --- 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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47872 --- Comment #11 from Esme <madewokherd(a)gmail.com> --- 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? -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47872 --- Comment #12 from Esme <madewokherd(a)gmail.com> --- 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. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47872 --- Comment #13 from Esme <madewokherd(a)gmail.com> --- I sent a patch series but they are being slow to appear. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47872 --- Comment #14 from Esme <madewokherd(a)gmail.com> --- Patch links: https://source.winehq.org/patches/data/181577 https://source.winehq.org/patches/data/181579 -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47872 --- Comment #15 from Esme <madewokherd(a)gmail.com> --- Should be fixed by https://source.winehq.org/git/wine.git/?a=commit;h=689e94c597471bb5779268bf2... -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47872 Gijs Vermeulen <gijsvrm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |689e94c597471bb5779268bf21f | |093f9668c163e Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- There have been no failures on Windows for gdiplus:font for a long time, marking FIXED. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=47872 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #17 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 6.9. -- 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.
participants (1)
-
WineHQ Bugzilla