Summary: | KFontChooser sometimes selects a non-regular style by default | ||
---|---|---|---|
Product: | [Frameworks and Libraries] frameworks-kwidgetsaddons | Reporter: | Noah Davis <noahadvs> |
Component: | general | Assignee: | Christoph Feck <cfeck> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | a.samirh78, alexander.shchadilov, kdelibs-bugs, nate |
Priority: | VHI | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | https://commits.kde.org/kwidgetsaddons/b52622993b45a61c4060d19517a5c3b833b3b854 | Version Fixed In: | 5.70 |
Sentry Crash Report: |
Description
Noah Davis
2020-04-19 05:09:23 UTC
Git commit b52622993b45a61c4060d19517a5c3b833b3b854 by Ahmad Samir. Committed on 19/04/2020 at 11:05. Pushed by ahmadsamir into branch 'master'. [KFontChooser] Make styleIdentifier() more precise by adding font styleName Summary: styleIdentifier() tries to get the correct font style based on weight, style, and stretch; this "styleID" could be the same for different font styles in the same family, and it worked in most cases because "Regular"-like styles usually are ordered first in the family styles list from QFontDatabase. However this breaks for font families that provide many font styles, e.g. Noto Sans, where "SemiCondensed" comes first in the list. Make it more precise by adding the font "styleName" property to the "styleID" we concatenate, this makes it more precise. Also handle empty styleName font prop. (we strip it on purpose, see KConfigGroupGui::writeEntryGui() for more details), try to pick the correct one so that we highlight it in the font style list view. Test Plan: kfontchooserdialogtest app, with the initial font set to "Noto Sans", before this change it'd select "SemiCondensed"; now it selects "Regular" as expected. FIXED-IN: 5.70 Reviewers: #frameworks, dfaure, cfeck, bport Reviewed By: dfaure Subscribers: ndavis, kde-frameworks-devel Tags: #frameworks Differential Revision: https://phabricator.kde.org/D28974 M +27 -2 src/kfontchooser.cpp M +1 -1 tests/kfontchooserdialogtest.cpp https://commits.kde.org/kwidgetsaddons/b52622993b45a61c4060d19517a5c3b833b3b854 I'm not seeing that the above commit fixed the issue. Opening the Fonts dialog in the Fonts KCM still results in "SemiCondensed" being set by default, and if you don't change it, you'll get very narrow fonts when you click OK. Git commit 0325d698181055cdaaa93b24ee80172132822d35 by Ahmad Samir. Committed on 05/05/2020 at 13:00. Pushed by ahmadsamir into branch 'master'. [Fonts KCM] Remove redundant nearestExistingFont() Summary: It seems that nearestExistingFont() gets the same result as `fc-match font-name`, which is basically the sans serif default font on the system; this seems redundant as KFontChooser will fallback to selecting the first font family in the list if the initial font it was called with doesn't exist _and_ KFontChooser always puts "Sans Serif", "Serif" and "Monospace" at the top of the list. Removing nearestExistingFont() solves the issue in bug 420287 as the font it returns will have the styleName property set, after we went to so much trouble to clear that property so that setBold() can work. Test Plan: Before the patch: - In kdeglobals [General] set: fixed=Blah Mono,12,-1,5,50,0,0,0,0,0 toolBarFont=Bogus Serif,12,-1,5,50,0,0,0,0,0 - Load the fonts KCM, and open the font dialog for Fixed and Toolbar, in both cases the default "sans serif" font on the system is selected, in my case it's "DejaVu Sans" Apply the patch and repeat, the "Sans Serif" entry is selected, which is an alias to "DejaVu Sans" on my system. Reviewers: #plasma, bport, ngraham Reviewed By: bport, ngraham Subscribers: ngraham, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D29155 M +0 -66 kcms/fonts/fonts.cpp https://commits.kde.org/plasma-desktop/0325d698181055cdaaa93b24ee80172132822d35 Is there anything left to fix here? It's working for me now. Yeah, should be fixed now. Great, thanks! Given the behavioral change in a framework, perhaps the Plasma patch should be on the stable branch too, or else people will still get this broken until Plasma 5.19 is released. Updating the report here, Plasma 5.18 still uses QFontDialog, so this bug report isn't directly related. However if the ",Regular" bit is removed from kdeglobals, QFontDialog will probably select the wrong style sometimes. (In reply to Ahmad Samir from comment #8) > Updating the report here, Plasma 5.18 still uses QFontDialog, so this bug > report isn't directly related. However if the ",Regular" bit is removed from > kdeglobals, QFontDialog will probably select the wrong style sometimes. Does this mean 5.18 LTS branch will never be fixed? If yes, could you provide more information for a workaround, like where in ~/.config/kdeglobals ",Regular" should be placed? I can reproduce the following behaviour in Kubuntu 20.04 (5.18.4) and openSUSE Leap 15.2 (5.18.5): 1. Place *.ttf file of Noto Sans SemiCondenced or ExtraCondenced to ~/.fonts if neither are presented in the system. 2. Open "System Settings"/"Fonts". 3. Change "General" font to Noto Sans Regular with any size other than default size. 4. Press "Apply" in "System Settings"/"Fonts". 5. Close "System Settings". After this after every restart of "System Settings"/"Fonts" font settings for "General", "Fixed width", "Small", "Toolbar" will be silently set to one of the styles from step 1 (if font family in the option is Noto Sans). This means that a user who came to settings e.g. to tweak sub-pixel rendering will involuntary change fonts' styles, you even do not need to touch font choosers for that. @Alexander: what's the version of the Frameworks in Ubuntu and openSuse (and do both use the plasma LTS version?). Note that there well could be a discrepancy between what the fonts KCM shows and what's actually stored in the config file ~/.config/kdeglobals. My guess is that you have Frameworks > 5.66, which means it has the new kconfig where the style name is dropped from the font settings so that calling setBold(true) can actually work properly. (In reply to Ahmad Samir from comment #10) > @Alexander: what's the version of the Frameworks in Ubuntu and openSuse (and > do both use the plasma LTS version?). Kubuntu 20.04 (tested in live session from installer) KDE Plasma Version: 5.18.4 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 openSUSE Leap 15.2 (my main PC, not a live session) KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.71.0 Qt Version: 5.12.7 > Note that there well could be a discrepancy between what the fonts KCM shows > and what's actually stored in the config file ~/.config/kdeglobals. Discrepancy exists, in a sense: user can see an asterisk in a titlebar right after opening "System Settings"/"Fonts". After clicking "Apply" changes in kdeglobals become real and applications start to use new font styles. Strangely, "Menu" and "Window title" are not affected because SemiCondenced and ExtraCondenced styles of Noto Sans are not presented when clicking these categories. Sorry for the delay. I think I know what the problem is, and I am working on a fix for Plasma 5.18. Supposedly there is a limited number of installations affected by that, it just happened that openSUSE provide a large set of Noto Sans by default. I see that in Debian & Co. fonts are separated in fonts-noto-core and fonts-noto-extra, same in Arch with noto-fonts and noto-fonts-extra. A workaround: click "Defaults" button right after opening "System Settings"/"Fonts", then make corrections you need, click "Apply". Git commit e5e5f5ed51aadfac99bfbdf3d2db5be16a12443b by Ahmad Samir. Committed on 10/08/2020 at 12:52. Pushed by ahmadsamir into branch 'Plasma/5.18'. kcm_fonts: Make the font selection dialog select the correct "Regular"-like style Due to KConfig dropping QFont styleName property (for "Regular"-like font styles, see [1] for more details), the font selection dialog invoked by the KCM could end up selecting the wrong style; this change sets the appropriate "Regular" style on the QFont object before invoking the font selection dialog to fix/workaround the issue. Note that in Plasma master branch the issue is handled differently, since we switched from QFontDialog to KFontChooserDialog (the latter has that logic built-in). [1] https://phabricator.kde.org/D27735 M +56 -5 kcms/fonts/fonts.cpp M +1 -0 kcms/fonts/fonts.h M +2 -5 kcms/fonts/package/contents/ui/FontWidget.qml M +2 -2 kcms/fonts/package/contents/ui/main.qml https://invent.kde.org/plasma/plasma-desktop/commit/e5e5f5ed51aadfac99bfbdf3d2db5be16a12443b |