https://bugs.winehq.org/show_bug.cgi?id=42606
Bug ID: 42606 Summary: wine doesn't *fully* respect locale settings in some corner cases Product: Wine Version: 2.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: galtgendo@o2.pl Distribution: ---
This time it's a problem even if this is the only app currently running in the prefix.
Download address for the engine: http://kikyou.info/dl_redirect.php?%2Ftvp%2Ffiles%2Fkr2_232r2.zip Instruction for setting up a project: http://kirikirikag.sourceforge.net/contents/Prepare.html (instructions seem to be for a different archive, but get the point across)
So, when running 'LANG=ja_JP.utf8 wine krkr.eXe'(as it's different from my standard locale) and starting that project, most of the things seem to work correctly (as I've got the standard overrides for Gothic/Mincho set already in place), yet...
When right clicking the engine console (not the game window), there's mojibake in that menu.
WINEDEBUG=font log shows that for some reason CreateFontIndirectExW for Tahoma is called with charset determined by my standard locale, instead of the Japanese one. That somehow results in the text being treated as encoded in that locale's Windows codepage, instead of cp932 (or is that vice versa ?).
https://bugs.winehq.org/show_bug.cgi?id=42606
--- Comment #1 from Rafał Mużyło galtgendo@o2.pl --- Created attachment 60851 --> https://bugs.winehq.org/attachment.cgi?id=60851 patch fixing the problem
Well, it took a significant number of stabs in the dark and a relay log, but I've found both the reason (SystemParametersInfo:SPI_GETNONCLIENTMETRICS) for this problem and a simple, yet pretty solution.
Already sent the patch to the list, but just in case it gets stuck somewhere, attaching it here too.
https://bugs.winehq.org/show_bug.cgi?id=42606
--- Comment #2 from Rafał Mużyło galtgendo@o2.pl --- Given the patch didn't get anywhere (though no valid alternative solution had been proposed either), just updating with a nearly trivial bit: as of 7.2 the patch should be applied to the same file in win32u instead.
https://bugs.winehq.org/show_bug.cgi?id=42606
--- Comment #3 from Nikolay Sivov bunglehead@gmail.com --- Is this possible to test this change on Windows?
https://bugs.winehq.org/show_bug.cgi?id=42606
--- Comment #4 from Rafał Mużyło galtgendo@o2.pl --- Not really.
It's kind-of-yet-not a theming issue.
The way wine caches theme fonts is with their charset.
The problem here is that if your standard charset and the one of the locale you're overriding it with don't match, 'funny' things may happen.
That's bit hard to simulate on Windows, as there locale switch forces necessary font changes.
https://bugs.winehq.org/show_bug.cgi?id=42606
--- Comment #5 from Rafał Mużyło galtgendo@o2.pl --- On a somewhat amusing note: the last patch sent to the list before going full gitlab had been on this very topic and used the very same solution (well, perhaps LOGFONT16 *might* work a bit differently, but haven't yet check if that would be the case).
It seems its author didn't feel like submitting it as a merge request (gee, I 'wonder' why...).
https://bugs.winehq.org/show_bug.cgi?id=42606
--- Comment #6 from Rafał Mużyło galtgendo@o2.pl --- With mr4388 getting merged, this should be fixed with the next release.
https://bugs.winehq.org/show_bug.cgi?id=42606
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED
--- Comment #7 from Rafał Mużyło galtgendo@o2.pl --- So, fixed way back in 8.21 (completely forgotten about this being fixed).
https://bugs.winehq.org/show_bug.cgi?id=42606
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #8 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 9.22.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla