The default font changed again.
The real fix is to compile qt against a >= 10.8 sdk, but this is simple enough to backport to 0.10 to avoid having to do that there.
Note: NSAppKitVersionNumber is a double and there's no official value for NSAppKitVersionNumber10_10. Since == isn't reliable for doubles, use Apple's guidelines for testing versions here: https://developer.apple.com/library/mac/releasenotes/AppKit/RN-AppKit/
Unfortunately this doesn't fix #5165. I spent most of the day chasing my tail on this and got nowhere. Unless someone else is interested in looking into this, we have 2 options for 0.10: busted Chinese for Yosemite, or building against the 10.8 sdk.
Will test this. Can I just gbuid master?
Busted Chinese on Yosemite 10.10 sounds more sane than switching to 10.8 in rc4 IMO.
Uploading a binary, 2min.
@jonasschnelli https://bitcoincore.org/cfields/bitcoin-qt-10.6_quickfix2-9ca6e0479 . I'm inclined to agree.
Tested. Fixes #5657 but leaves #5165 open.
The problem of #5165 is, that the 'Lucia Grande' font does not support Chinese characters. We now substituting the system font by a non-Chinese-capable font.
I think a quick fix could be to check within the 10.10 'if structur' if the users language is zh_CN (maybe there are others?) then substitute the font to "Henti TC" (OS X standard font for Chinese). A one or two-liner with low risks (only Chinese 10.10 users will see the change). Easy, sane, effective IMO.
@jonasschnelli I wasn't sure if we could do that, but since we require a restart to change fonts, that sounds good to me.
It seems that all cjk fonts are broken in 10.10 due to the new aliasing system. Hard-coding for those 3 indeed sounds like a reasonable hack for 0.10.
If #5165 only affects Chinese, then this + a Chinese-specific workaround for 0.10 is great. I hope other languages with non-latin characters aren't affected, tracking down the font for each locale would be a crazy scavenger hunt (just what unicode was supposed to fix in the first place :( ).
And indeed, for master we shouldnt bother with this and switch the build SDK.
The current substitute font 'Lucida Grand' on osx 10.10 has only support for Greek, Hebrew, Cyrillic, Latin.
So in general we should consider not giving substitutes for fonts because i assume the OS will care about switching fonts within a textflow or support extra fonts with mixed charsets.
Currently the 'Lucida Grand' font has no support for: Hiragana, Birman, Arabic, Hangul, Thai, Traditional Chinese, Simple Chinese, Singhalen, Yi (maybe more) Do we support a language with one of these font script?
ACK on this change to fix #5165 but longterm we should update to 10.8 as build os and remove font substitution.
SubstituteFonts() has been moved to after app identification so that QSettings
are accessible.
Well that took quite a bit of trial+error, but all good now. Fixes #5165. It's not optimal... Chinese font-names don't show in English (when you're in English and going to select Chinese/Japanese from the menu, those characters are blocks). After switching it works fine though.
The last commit avoids the hard-coded use of Arial, which does not always work correctly with Chinese. Seems sane to me, but I'm not sure if there was a specific reason for its use.
The substitutions are all wrapped up in ifdefs, so they're safe for master now and in the future. The only functional change for master (after we bump the sdk to 10.8) is the Arial change.
Test binary here: https://bitcoincore.org/cfields/bitcoin-qt-10.6_quickfix3-437de97c As far as I'm concerned, ready for merge/backport.
If it wasn't clear, the Arial change wasn't arbitrary... the splash is all boxes in Chinese otherwise.
415 | + if (language == "zh_CN" || language == "zh_TW" || language == "zh_HK") // traditional or simplified Chinese 416 | + QFont::insertSubstitution(".Helvetica Neue DeskInterface", "Heiti SC"); 417 | + else if (language == "ja") // Japanesee 418 | + QFont::insertSubstitution(".Helvetica Neue DeskInterface", "Songti SC"); 419 | + else 420 | + QFont::insertSubstitution(".Helvetica Neue DeskInterface", "Helvetica");
Why we substitute the default Font with Helvetica?
Looks good but leads to new problems (see other comment).
Still issues (see screens below). I would even say it's more broken then before this pull (with all respect of your highly a valued work).
I only see one direction: -> build against 10.8 with a -min of 10.6. Im pretty sure QT won't use any methods not available in 10.6. The native osx implementation within the #ifdefs are sane because i did the most and i did always check during runtime if a method is available before calling it. Of course it's a hard admission in rc3 to change the building framework. But IMO it should be sane. I could also offer extensive testing in 10.6, 10.7, 10.8, 10.9 and 10.10.
zh_CH:
de_DE:
ja:
Font mix in de_DE:
The default font changed again.
The real fix is to compile qt against a >= 10.8 sdk, but this is simple enough
to backport to 0.10 to avoid having to do that there.
Note: NSAppKitVersionNumber is a double and there's no official value for
NSAppKitVersionNumber10_10. Since == isn't reliable for doubles, use Apple's
guidelines for testing versions here:
https://developer.apple.com/library/mac/releasenotes/AppKit/RN-AppKit/
Chinese and Japanese fonts have been hard-coded as well, otherwise they fail to
show up at all.
They may not contain all necessary characters for a language
Tested ACK. Still have minor issues in CN/JA. This will be fixed in the next release when we might upgrade to 10.9 as build os.
Screens:
After some discussion on IRC, I believe @jonasschnelli and I have reached a compromise here. German is fixed up now, and Chinese and Japanese work with the exception of a few artifacts. We're willing to accept that for 0.10, with the understanding that they'll be fixed in the future by the bumped sdk.
Cherry-picked to 0.10 branch as 58259ad1edf14a4f514fe5f837ac7d1d99b58422
Milestone
0.10.0