obsproject
UI: Fix Chinese default font
Description
Add Microsoft YaHei (Microsoft YaHei UI) to font-family
Motivation and Context
Default Chinese font on Windows Vista+ should not be the old SimSun, it should be Microsoft YaHei.
How Has This Been Tested?
Replace the qss and verified it was fixed.
Types of changes
Bug fix (non-breaking change which fixes an issue)
Checklist:
- [x] My code has been run through clang-format.
- [x] I have read the contributing document.
- [x] My code is not on the master branch.
- [x] The code has been tested.
- [x] All commit messages are properly formatted and commits squashed where appropriate.
- [x] I have included updates to all appropriate documentation.
Thanks for updating the patch. Next time, try force-pushing the branch of the pull request, which updates it. That way, you don’t need to close the old and open a new one.
Adding my comment from the previous PR so this is not accidentally merged.
I am still unconvinced this is the correct way to fix this issue. I would like more information on the cause, and I would like more verification this is affecting every user instead of just one at this point.
To answer your questions on the other PR:
Is this a locale issue that should really be upstreamed as a bug to Qt? Why is the default not being selected properly? Surely there must be a reason.
There is a reason: backwards-compatibility. Qt doesn't want an app to look different (well, mostly) if you upgrade Qt, so they stick with the old defaults. We override font selection on Windows/macOS for the same reason.
I'm not entirely opposed to this change if it is a real issue, but I feel this might have unintended consequences as a manually defined font for non-Chinese locales, and would like to understand why it's choosing a legacy font in the first place. Do we know if this currently affects all users with a Chinese locale setting, or if it might something environment specific?
As said above, backwards compatibility is why it's using the legacy font. This should affect every user with a chinese environment.
Perhaps calling this a "bug fix" is mischarachterising it (since it's more of a tweak or general improvement), but previous PRs with font changes have also been marked as such.
I would like more verification this is affecting every user instead of just one at this point.
I can be sure that all Windows Chinese users have this problem
As said above, backwards compatibility is why it's using the legacy font.
As far as I can tell from a skim of QTBUGs, Qt should be selecting "Microsoft YaHei UI" by default in Qt 6 if the system locale is set to Chinese.
After looking at the Qt code again I found https://github.com/qt/qtbase/blob/067b53864112c084587fa9a507eb4bde3d50a6e1/src/gui/text/windows/qwindowsfontdatabasebase.cpp#L692 which leads to https://bugreports.qt.io/browse/QTBUG-58610
It would appear that Qt is still using an older Windows API in many places so it doesn't fall back to the new font. But in some cases (like QPlainTextEdit) it actually uses the newer API so things are correct. Yay?
It still seems like a reason for this is backwards-compatibilty (that they could probably drop at this point). The comment on the QTBUG also says the DirectWrite font database is still considered experimental although without digging deeper I couldn't tell if this is actually part of that.
I still don't think there's an issue with manually specifying a better fallback font though (at least until Qt actually changes this).
I tried to change the windows language to Japanese. I found that the default display font of Japanese is not the same as the Simplified Chinese. (use the dark theme can to see the default display font)
| Language | Screenshot |
|---|---|
| Simplified Chinese |  |
| Japanese |  |
This method can only fix users displayed in Simplified Chinese, but cannot fix users displayed in other languages.
I'm afraid this PR is not ok for Japanese. The font becomes YaHei and some Japanese characters are wrong such as 将.
28.0.1 (without this PR):
ge31589274 (this PR)
I guess we'll have to look into something else then. Perhaps we'll have to manually do an override in code. Not something I'm particularly fond of.
(Or we'll just wait until Qt fixes the issue... in like 4 or 5 years)
(Or we'll just wait until Qt fixes the issue... in like 4 or 5 years)
I'm still not sure there's something there to fix. As I said, from a brief skim of QTBUGs that discuss font selection, YaHei was selected as the default font on systems set to Chinese. If we want to point the finger at Qt, then we'd need a simple reproducer. If one of the existing example apps will suffice, all the better.
The comment on the QTBUG also says the DirectWrite font database is still considered experimental although without digging deeper I couldn't tell if this is actually part of that.
Circling back around to this, QTBUG-58610 leads to QTBUG-74917, which says that QWindowsDirectWriteFontDatabase was implemented in Qt 6.0. Comments on QTBUG-58610 indicate that that bug should actually be marked Resolved.
I really think this is an underlying QTBUG, though I do not know if there is an applicable one that is already open. I also think that this fix cannot be accepted because it demonstrably causes negative effects for other locales.
@RytoEX Should we close this then? I sympathise with the wish to have one's language presented properly in the UI but if this is indeed necessary for Qt to fix (or provide us with a way to globally opt-in to the improved font files) then there's nothing we can do right now.
An alternative would be for us to select specific fonts for non-latin character sets (similar to us using Open Sans) and ship those so that we're not relying on the OS.
@RytoEX Should we close this then? I sympathise with the wish to have one's language presented properly in the UI but if this is indeed necessary for Qt to fix (or provide us with a way to globally opt-in to the improved font files) then there's nothing we can do right now.
I think we should close it. I'm not going to merge something that is demonstrably detrimental (see @norihiro 's comments above).
An alternative would be for us to select specific fonts for non-latin character sets (similar to us using Open Sans) and ship those so that we're not relying on the OS.
Not sure how we would do this while specifying different character sets for Japanese and Chinese, unless we forcibly switched them based on the user's language selection. That said, I'd rather determine if there is an underlying bug in Qt's own font selection for locales, and report that to Qt if such a bug exists.