https://bugs.winehq.org/show_bug.cgi?id=41797
Bug ID: 41797 Summary: switching LANG for the second app on the server is incomplete Product: Wine Version: 1.9.23 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wineserver Assignee: wine-bugs@winehq.org Reporter: galtgendo@o2.pl Distribution: ---
The component (wineserver) is likely incorrect.
If one app is run in one locale, then - while it's still running - another is launched in the same prefix, but different locale via LANG, not all of the locale dependent variables are reinitialized.
Specifically, if the first locale is Polish and the second is Japanese, font glyphs are still rendered as if the initial locale was in effect, which leads to some of the font glyphs being rendered too wide and long strings not fitting their cells and getting cut off.
Not sure if this is *supposed* to work, but if it works with most of the other locale dependent settings, it seems inconsistent it doesn't with this one.
https://bugs.winehq.org/show_bug.cgi?id=41797
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|wineserver |-unknown
--- Comment #1 from Nikolay Sivov bunglehead@gmail.com --- I guess it could be specific to programs you're running too, because I can't reproduce this with notepad and winecfg. First running notepad with en_US, then winecfg with ja_JP.UTF-8 gives me winecfg in Japanese.
https://bugs.winehq.org/show_bug.cgi?id=41797
--- Comment #2 from Rafał Mużyło galtgendo@o2.pl --- @comment 2:
Seems I wasn't quite clear enough.
As I've said, *most* of locale dependent setting do get toggled, like language of the interface, language of WINEDEBUG messages, even the font itself (wrt. things like System font and the similar artificial sets).
Yet for some reason, the *'spacing'* (for the lack of the proper term) of the font doesn't follow suite, it stays within first locale settings.
https://bugs.winehq.org/show_bug.cgi?id=41797
--- Comment #3 from Nikolay Sivov bunglehead@gmail.com --- Ok, I'll need a test application for that. There's no way to guess what breaks exactly in your case. In my testing Japanese text in winecfg is displayed as it should. Also it's possible that your application depends on particular font to render Japanese, and when running on wine it ends up using some other one from your system.
https://bugs.winehq.org/show_bug.cgi?id=41797
--- Comment #4 from Rafał Mużyło galtgendo@o2.pl --- No, AFAICT the same font is picked both if the japanese app is run first and if not (at least going by the glyph shapes, the WINEDEBUG=font logs seem too large to be useful), just in the first case string fit, in the second they don't.
https://bugs.winehq.org/show_bug.cgi?id=41797
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1
--- Comment #5 from Dmitry Timoshkov dmitry@baikal.ru --- This problem is known for a long time already, and usually only not unicode applications get affected. Since Wine builtin apps use unicode APIs directly they can't be used for reproducing this bug.
Probably a WONTFIX since gdi32 creates locale dependent font mappings for not unicode apps, and that's unavoidable.
https://bugs.winehq.org/show_bug.cgi?id=41797
--- Comment #6 from Rafał Mużyło galtgendo@o2.pl --- @comment 5: well, the apps in question most likely are non-unicode, yet the question remains why the values in question aren't getting reset by LANG, despite that other are.
I would WONTFIX it too early, perhaps it's time to tinker a bit more at wine locale handling; after all it's not the only locale dependent problem (you do recall string collation should be - but currently isn't - locale dependent ?)
https://bugs.winehq.org/show_bug.cgi?id=41797
--- Comment #7 from Rafał Mużyło galtgendo@o2.pl --- ...
...I wouldn't WONTFIX...(obviously)
https://bugs.winehq.org/show_bug.cgi?id=41797
--- Comment #8 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Rafał Mużyło from comment #6)
@comment 5: well, the apps in question most likely are non-unicode, yet the question remains why the values in question aren't getting reset by LANG, despite that other are.
They are reset, but they clash with the values set from another process. And since the locale dependent font mapping in registry is prefix-global you can't expect that once one app has changed a vital locale setting another app won't break because of that.
I would WONTFIX it too early, perhaps it's time to tinker a bit more at wine locale handling; after all it's not the only locale dependent problem (you do recall string collation should be - but currently isn't - locale dependent ?)
If I recall correctly the Wine policy for patch acceptance didn't change since then: the patches are welcome (they sometimes get ignored, but that's a different problem).
https://bugs.winehq.org/show_bug.cgi?id=41797
--- Comment #9 from Rafał Mużyło galtgendo@o2.pl --- (In reply to Dmitry Timoshkov from comment #8)
They are reset, but they clash with the values set from another process. And since the locale dependent font mapping in registry is prefix-global you can't expect that once one app has changed a vital locale setting another app won't break because of that.
Wouldn't some kind of caching (per-app) those values be possible ? After all, in Windows, while AppLocale didn't cover all the cases, it did suffice quite often. I'm not saying it would be easy, cause (AFAIU) it would involve treating certain regkeys differently than the rest, but that doesn't have to mean it's impossible.
I wouldn't WONTFIX it too early, perhaps it's time to tinker a bit more at wine locale handling; after all it's not the only locale dependent problem (you do recall string collation should be - but currently isn't - locale dependent ?)
If I recall correctly the Wine policy for patch acceptance didn't change since then: the patches are welcome (they sometimes get ignored, but that's a different problem).
...and as I've said back in that bug, not only would that require something like icu, but would be somewhat over my programming skills: I suspect a significant performance hit, which I don't expect to be able to compensate for and am not sure of the proper place for checking the locale value (most likely it would involve caching the startup value).
https://bugs.winehq.org/show_bug.cgi?id=41797
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Status|NEW |RESOLVED
--- Comment #10 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to Rafał Mużyło from comment #9)
They are reset, but they clash with the values set from another process. And since the locale dependent font mapping in registry is prefix-global you can't expect that once one app has changed a vital locale setting another app won't break because of that.
Wouldn't some kind of caching (per-app) those values be possible ?
Registry is a prefix-global thing, and font mappings is not a Wine invention.
https://bugs.winehq.org/show_bug.cgi?id=41797
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #11 from Austin English austinenglish@gmail.com --- Closing.
-
wine-bugs＠winehq.org