Bug 2178389 - Qt application render very thin fonts after switch to VF version of Noto CJK fonts
Summary: Qt application render very thin fonts after switch to VF version of Noto CJK ...
Alias: None
Product: Fedora
Classification: Fedora
Component: qt5-qtbase
Version: 38
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Than Ngo
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedFreezeException
Depends On:
Blocks: F38FinalFreezeException
TreeView+ depends on / blocked
Reported: 2023-03-15 03:44 UTC by Qiyu Yan
Modified: 2023-03-23 00:16 UTC (History)
12 users (show)

Fixed In Version: qt5-qtbase-5.15.8-7.fc38
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2023-03-23 00:16:30 UTC
Type: Bug

Attachments (Terms of Use)
Some text from Telegram (40.86 KB, image/png)
2023-03-15 06:24 UTC, Qiyu Yan
no flags Details
Proposed patch (798 bytes, patch)
2023-03-17 07:17 UTC, Akira TAGOH
no flags Details | Diff

System ID Private Priority Status Summary Last Updated
Qt Bug Tracker QTBUG-111994 0 Not Evaluated Reported Deal with a font face at index 0 as Regular for Variable fonts 2023-03-17 10:42:21 UTC

Description Qiyu Yan 2023-03-15 03:44:34 UTC
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):

How reproducible:
Always, if on flatpak applications that do affected.

Steps to Reproduce:

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.

Comment 1 Qiyu Yan 2023-03-15 04:12:57 UTC
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?

Comment 2 Akira TAGOH 2023-03-15 04:15:49 UTC
Oh wait. Does this only happens on ASCII/Latin characters?
Can you provide any test document to try on Evince or screenshots?

Comment 3 Qiyu Yan 2023-03-15 06:24:29 UTC
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)

Comment 4 Akira TAGOH 2023-03-15 07:17:35 UTC
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

Comment 5 Akira TAGOH 2023-03-15 09:19:52 UTC
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.

Comment 6 Akira TAGOH 2023-03-17 07:17:07 UTC
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.

Comment 7 Than Ngo 2023-03-17 08:01:52 UTC
Akira, could you please forward this to upstream?


Comment 8 Akira TAGOH 2023-03-17 10:41:05 UTC
I did: https://bugreports.qt.io/browse/QTBUG-111994

Comment 9 Akira TAGOH 2023-03-17 10:50:51 UTC
Let me propose this as a freeze exception.

Comment 10 Than Ngo 2023-03-20 10:38:12 UTC
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?


Comment 11 Akira TAGOH 2023-03-20 12:45:41 UTC
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.

Comment 12 Adam Williamson 2023-03-21 00:03:38 UTC
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.

Comment 13 Fedora Update System 2023-03-21 07:32:08 UTC
FEDORA-2023-86d1102614 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-86d1102614

Comment 14 Than Ngo 2023-03-21 09:51:33 UTC
it would be great if someome of us can test and grant Karma!

Comment 15 Fedora Update System 2023-03-22 02:16:51 UTC
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.

Comment 16 Fedora Update System 2023-03-23 00:16:30 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.