Description of problem: After https://fedoraproject.org/wiki/Changes/Noto_CJK_Variable_Fonts landed to f38 silverblue and google-noto-sans-cjk-ttc-fonts get replaced by google-noto-sans-cjk-vf-fonts. The font appears to be thinly rendered in some flatpak applications. Version-Release number of selected component (if applicable): google-noto-sans-cjk-vf-fonts-1:2.004-1.fc38.noarch How reproducible: Always, if on flatpak applications that do affected. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: Some flatpak applications are not affected (like Firefox and VSCode) and some do (like Evince and Telegram) Evince explicitly clains that it is using CJK-VF fonts when the problem appears. I don't know if non-flatpak application is affected, will check when have time to do. And my system language is set to ZH_CN, this should matter when selecting fonts.
And just tested layering evince package, the non-flatpak evince get fonts rendered correctly and it select Nimbus fonts instead of all noto-cjk-vf fonts. So it should be flatpak only I guess?
Oh wait. Does this only happens on ASCII/Latin characters? Can you provide any test document to try on Evince or screenshots?
Created attachment 1950869 [details] Some text from Telegram A screenshot of CJK text in Telegram is in attachments and another English pdf can be found https://texdoc.org/serve/latexmk/0 I believe this problem in Evince have 2 ingredients, one is that when running in flatpak somehow it is always selecting noto for standard fonts, another is switching to VF make things even worse. Problem with Telegram can be something like bug in handling the fonts? (the bold text in the screenshot is a disaster)
For Evince issue, that is actually a known issue and this is related to the change of google-noto-fonts. Please see some thread from here: https://github.com/fedora-silverblue/issue-tracker/issues/305#issuecomment-1442586241
Alright. I've tracked this down. I'd say this is a Qt bug actually. Let's see what happened there. When trying to open a Qt app, they request a font like this: FcConfigSubstitute editPattern has 7 elts (size 16) family: "Noto Sans CJK JP"(s) pixelsize: 13(f)(s) hintstyle: 1(i)(w) file: "/usr/share/fonts/google-noto-sans-cjk-vf-fonts/NotoSansCJK-VF.ttc"(s) index: 0(i)(s) lang: "ja"(w) prgname: "kwrite"(s) And We had Regular style in a font face at index 0 in TTC version of Noto CJK fonts though, in Variable font, Thin style is assigned to index 0. This means, in this case, earlier index has a priority if all the conditions are the same in the score. Given that the above request is really what Qt apps wants, they shouldn't matter what style of fonts it is. but actually not. The problem in Qt is that they assume that Regular should be available at first. Reassigning to Qt5.
Created attachment 1951406 [details] Proposed patch The short description is that Qt5 doesn't support Variable fonts well. we need to igure it for workaround and accept named-instances only from variable fonts. The long description is here: Qt5 tries to gether font information through FcFontList() and register it into Qt's font database. and requesting a best font with FcFontMatch() against it. In fact, not requesting weight and width doesn't matter because it is actually linked to the font face and font index. Let me explain a bit about variable fonts support in fontconfig. fontconfig has a special font pattern for variable fonts which has variable=true. this means "This is a variable font" and also contains some information which properties has "axis". applications can request some variations against it. There are the miscalculation here. this pattern has index 0 and no values for properties which has "axis", because it will be figured out when the real axis is decided. thus, we don't have style for them. However, Qt are going to fill in blanks with default values. Thus, this pattern becomes Regular. Furthermore, Noto CJK fonts assigns Thin style to index 0 after updates. then, they dealt with Thin as Regular. that's it. BTW apparently qt5-qtwayland seems linking qt5-qtbase statically. that really confused me a lot. applying this to qt5-qtbase doesn't get a fix on Wayland. we also need to rebuild qt5-qtwayland with this fixed qt5-qtbase.
Akira, could you please forward this to upstream? Thanks
I did: https://bugreports.qt.io/browse/QTBUG-111994
Let me propose this as a freeze exception.
Akira, I don't know how long it will take for upstream to look at the bug. So I would include your patch as a temporary workaround in qt5-qtbase and build rpm for f38. What do you think about this approach? By the way, have you also tested the patch if it works? Thanks!
That sounds good to me. and Yes, I tried that and confirmed the fix. please note that you also need to rebuild qt5-qtwayland with the fixed qt5-qtbase. otherwise the problem will still persists on Wayland. The test case is very easy. Once the fixed packages installed (also, making sure that you have google-noto-sans-cjk-vf-fonts installed), try to open a Qt app which has a font preference and find out one of "Noto Sans CJK JP/KR/SC/TC" and set a style to Regular and Thin. If the fix is properly applied, you'll see some changes on rendering.
Discussed at 2023-03-20 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2023-03-20/f38-blocker-review.2023-03-20-16.00.html . This is accepted as a freeze exception issue as it looks pretty bad for CJK users, and will certainly affect live environments and first boot after install so it cannot be fully addressed by an update.
FEDORA-2023-86d1102614 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-86d1102614
it would be great if someome of us can test and grant Karma!
FEDORA-2023-86d1102614 has been pushed to the Fedora 38 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-86d1102614 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-86d1102614 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.