Description of problem: After switch to use Noto CJK variable fonts, the Chinese characters with Bold style become very thick in Qt 5. Version-Release number of selected component (if applicable): qt5-qtbase-gui-5.15.8-6.fc38.x86_64 How reproducible: Launch dolphin file manager, the Bold text about the path becomes very thick, and hard to read. Steps to Reproduce: 1. Upgrade Fedora Kinoite to latest version to install Noto CJK VF fonts 2. Switch desktop to use Chinese locale or set LANG and LC_ALL to use Chinese locale 3. Launch dolphin and change to Desktop directory, and the "桌面" text becomes very thick Actual results: The rendering result is thicker than the normal Noto CJK fonts, and hard to read. Expected results: The rendering result is the same as the normal Noto CJK fonts. Additional info:
I investigated this too. This is because Qt renders texts with the synthetic emboldening when they choose a variable font. I've opened an issue on upstream issue tracker here: https://bugreports.qt.io/browse/QTBUG-112136 See more details there.
It seems the following environment variable works around this issue. $export QT_NO_SYNTHESIZED_BOLD=1 $dolphin
Akia, thanks for reporting this issue by upstream.
Created attachment 1952248 [details] Draft patch to fix the bold style issue The named instance comes from a GX or OpenType variation font, assume that the font contains the bold style. This draft patch disables embolden with the GX or OpenType variation font.
(In reply to Peng Wu from comment #4) > Created attachment 1952248 [details] > Draft patch to fix the bold style issue > > The named instance comes from a GX or OpenType variation font, assume that > the font contains the bold style. > > This draft patch disables embolden with the GX or OpenType variation font. Peng, could you please forward your draft patch to upstream for review (https://bugreports.qt.io/browse/QTBUG-112136)? Thanks!
Okay, I just uploaded the patch and added some comment.
Created attachment 1952660 [details] Screenshot of the bold style Chinese text The Chinese text in the red frame is very thick and hard to read.
Apparently you are misunderstanding the problem. They did the synthetic emboldening because they got a Regular font even though they requested a Bold font. thus, they just considered there are no Bold font available for it. So preventing the synthetic emboldening is the wrong fix. and your patch will introduces another issue that you don't get rendering with Bold on VF.
Created attachment 1953537 [details] Yet another proposed patch This patch actually contains two fixes. One is to pull in proper information from FcPattern. As I said earlier, fontconfig doesn't evaluate FC_INDEX to estimate the best font against a query on FcFontMatch(). it may just works in some case but we need to pick up a correct FcPattern corresponding to FC_FILE and FC_INDEX because only these two properties are reliable on Qt since they store them only from polulating fonts from FcFontList(). Another one is to estimate weight properly for variable fonts. they don't have FT_STYLE_FLAG_BOLD in face->style_flags for the named-instance of Bold. Peng's patch ignores the synthetic emboldening for named-instance anyway, but this could be a problem if varlable fonts doesn't have weight axis. we have to estimate proper weight value to see if they really need to do the synthetic emboldening.
Created attachment 1953864 [details] v2 I should do the null-check for FT_MM_Var.
Akira, could you please forward your patch to upstream for review? Thanks!
i built qt5-qtbase/qt5-qtwayland including your patch for rawhide and f38. https://koji.fedoraproject.org/koji/buildinfo?buildID=2176339 https://koji.fedoraproject.org/koji/buildinfo?buildID=2176011 https://koji.fedoraproject.org/koji/buildinfo?buildID=2176329 I will push them into f38 update today.
FEDORA-2023-de53467a12 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-de53467a12
I tried the qt5-qtbase and qt5-qtwayland updates in the update from comment 13. I find that it causes all of my Qt program windows to lose all of their menu text and many of the controls also shrink. This could be because the compositor seems to think that there is no font present, maybe it now doesn't find any suitable font? I am using a standard en_GB locale and the default fonts in my GNOME Wayland desktop. I'm not using any Chinese fonts or locales.
FEDORA-2023-de53467a12 has been pushed to the Fedora 38 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-de53467a12 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Discussed during the 2023-03-27 blocker review meeting: [0] The decision to classify this bug as an "AcceptedFreezeException (Final)" was made as it is a clear visual quality issue that will be encountered on live boots by CJK users. [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2023-03-27/f38-blocker-review.2023-03-27-16.00.txt
I unpushed the update sin(In reply to Brian Morrison from comment #14) > I tried the qt5-qtbase and qt5-qtwayland updates in the update from comment > 13. > > I find that it causes all of my Qt program windows to lose all of their menu > text and many of the controls also shrink. This could be because the > compositor seems to think that there is no font present, maybe it now > doesn't find any suitable font? > > I am using a standard en_GB locale and the default fonts in my GNOME Wayland > desktop. I'm not using any Chinese fonts or locales. I unpushed the update based on this comment. You should have tested a scratch build at least before pushing an unverified fix or wait until it lands upstream.
Created attachment 1954086 [details] test screenshot
(In reply to Jan Grulich from comment #17) > I unpushed the update sin(In reply to Brian Morrison from comment #14) > > I tried the qt5-qtbase and qt5-qtwayland updates in the update from comment > > 13. > > > > I find that it causes all of my Qt program windows to lose all of their menu > > text and many of the controls also shrink. This could be because the > > compositor seems to think that there is no font present, maybe it now > > doesn't find any suitable font? > > > > I am using a standard en_GB locale and the default fonts in my GNOME Wayland > > desktop. I'm not using any Chinese fonts or locales. > > I unpushed the update based on this comment. You should have tested a > scratch build at least before pushing an unverified fix or wait until it > lands upstream. I have tested it under both KDE and GNOME. It worked flawlessly for me (look at above my test screenshot). It may be that under certain conditions such problem can occur. We need to test it intensively. @Akira, @Peng, Can you please test it? Thanks a lot!
Yes, I can confirm this regression. This seems to happen with some variable fonts such as Cantarell and some variants of Noto Sans. I'm looking into it now.
I can reproduce this issue. I guess if login with CJK locale like Chinese, it will be easier to reproduce this issue.
Created attachment 1954106 [details] Draft patch for the bold style issue v2
As Akira Tagoh said, there are two issues in the code, so I just updated my patch. 1. The usage of FcFontMatch may be not correct, as it doesn't compare the FC_INDEX when matching. In the patch, I switch to use FcFontSort, the FcFontSort code will match FC_FILE; and after the FcFontSort function return, we compare the FC_INDEX to get the correct font face. 2. Switch to use the embolden value from the fontconfig, instead of computing it in the freetype code in Linux. The freetype code will override the embolden value from fontconfig, so the patch also disables the freetype code to compute the embolden value in Qt.
BTW, the patch disables the freetype code about embolden value in Qt with Linux only. And in fontconfig, the similar logic of the freetype code is implemented in the /etc/fonts/conf.d/90-synthetic.conf file.
You can't replace FcFontMatch with FcFontSort. I'm not sure if there are really any such code paths though, they set FC_FILE and FC_INDEX only when QFontEngine::FaceId has a filename. This implies that filename and index isn't always available; maybe application specific font? Anyway, you still need to fallback to FcFontMatch in that case as I wrote it that way in my patch. Apparently you didn't seem to read it though.
Created attachment 1954381 [details] v3 I'm almost consluding that we need to implement full-support of variable fonts if we want to fix this in a legitimate manner. Apparently FreeType considered applications is capable to process variable fonts if one uses some variable fonts related APIs such as FT_Get_MM_Var(). This may be the reason why we saw the fail of loading glyph error from FreeType with my patch. We need to set coordinates with axis. Honestly implementing complete code for variable fonts in f38 timeframe isn't realistic. So I gave up to fix this that way. FWIW I partly agree with Peng's code, particularly leaving the emboldening conditions to fontconfig. Actually this is the same to what cairo does. However, I wonder if it is really only used for Linux because there are MinGW package for Qt and they could use fontconfig. I picked it up to my patch and updated a bit to get it work without ifdef. See attached. Also, I built qt5-qtbase (only this time; so you need to try it with X11 only) on copr: https://copr.fedorainfracloud.org/coprs/tagoh/qt5-qtbase/ You can try to test if you like. I did. that works for me.
Created attachment 1954384 [details] v4 Oops, attached old one. this is.
I downloaded and tested Akira's build, confirmed that it also works for me. Thanks Akira and Peng for the fix! @Brian and other, could you please test Akira's build and report the result before i do officical build? Thanks!
I can only see x86_64 rpms, my system has 2 .i686 rpms and I can't run the upgrade without them. If someone can provide a scratch build with all arches present then I will try that.
I tested https://download.copr.fedorainfracloud.org/results/tagoh/qt5-qtbase/fedora-38-x86_64/05725782-qt5-qtbase/ too on X11 in Fedora-KDE-Live-x86_64-38-20230328.n.0.iso and now CJK output renders again in the konsole (eg `LANG=ja_JP.utf8 date` and `sudo dnf ...` output).
(In reply to Brian Morrison from comment #29) > I can only see x86_64 rpms, my system has 2 .i686 rpms and I can't run the > upgrade without them. > > If someone can provide a scratch build with all arches present then I will > try that. there is scratch build with all arches https://koji.fedoraproject.org/koji/taskinfo?taskID=99281689 Please test it only on X11. Thanks!
So it is not going to work on GNOME Wayland?
(In reply to Brian Morrison from comment #32) > So it is not going to work on GNOME Wayland? For GNOME Wayland we need to rebuild qt5-qtwayland against new qt5-qtbase. I will do this later. For quick test we just test it on X11.
OK, I will test it once the qt5-wayland packages are available too.
OK, I have tried this using the qt5-qtbase*5.15.8-10 packages and qt5-qtwayland*5.15.8-4.1 packages. Stopping and restarting a Qt application now seems to work OK, I have menus and the controls are the correction sizes and work too. This looks like it is good enough for updates-testing.
FEDORA-2023-c7a23026f7 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-c7a23026f7
I have tried the qt5-qtbase*5.15.8-10 and qt5-qtwayland*5.15.8-6 packages from https://bodhi.fedoraproject.org/updates/FEDORA-2023-c7a23026f7 and they also work as expected.
FEDORA-2023-c7a23026f7 has been pushed to the Fedora 38 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-c7a23026f7 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Brain, thanks for testing and feedbacks! Could you and other please grant the karma in https://bodhi.fedoraproject.org/updates/FEDORA-2023-c7a23026f7 ? Thanks
FEDORA-2023-c7a23026f7 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.