SUMMARY Kind of opposite of https://bugs.kde.org/show_bug.cgi?id=431649. Most non-KDE applications do not respect KDE font settings Currently Plasma doesn't create the file. If it is already there, Plasma adds hinting=true and hintstyle=hintslight. OBSERVED RESULT `fc-match 'sans'` returns DejaVu Sans or Nimbus Sans or some other font because no explicit font configuration is added. Example - Telegram uses 'Open Sans',"Lucida Grande","Lucida Sans Unicode",Arial,Helvetica,Verdana,sans-serif; and on Arch Linux used to fall back to DejaVu or Nimbus. People complained enough that ttf-opensans has now been marked a dependency of Telegram there. EXPECTED RESULT Fonts set in the KCM should be used everywhere. SOFTWARE/OS VERSIONS Linux: 5.10.17-1-lts KDE Plasma Version: 5.21.0 KDE Frameworks Version: 5.79.0 Qt Version: 5.15.2
I mused on this with Sebastian Kuegler years ago but nothing ever came of it, and I have been thinking about it every once in a while ever since. I really don't think us dumping random settings is the way to go. In fact, the way we currently consider defaults is super fishy to begin with. One way to look at this is that if the platform, e.g. Arch has DejaVu as default set then we should represent that and consider that the default in systemsettings. After all, as you rightly point, applications that aren't affected by Plasma's platform integration don't know or care about what we may or may not consider implicit defaults. The other way to look at it certainly is that inside a Plasma session everything should be looking Plasma so we should force our settings. The trouble with that is a) this overrides both the platform and other desktops b) if every desktop starts dumping their notion of defaults into the shared configs it'd become impossible to tell if a value is set because a desktop dumped their settings there or because the user actually configured this as their preference (e.g. if xfce starts writing their default font to the config then that will forever be the default font of that user because we'd have to assume that it was the user who configured it). The additional complication is also that things outside the users realm of influence still won't be correct - think about SDDM for instance. With that in mind I believe how font defaults work actually needs revisiting in general. The default ought not be some arbitrary made up default of Plasma, but the actual default of the system. Just like with locales Plasma doesn't pretend it is en_GB when the system is en_US, it also shouldn't pretend it is Noto Sans when the system is Open Sans. In fact, that is how half the KCM already works, making it all the more confusing that part of it doesn't. Acknowledging that font design and rendering are still integral parts of the desktop experience we should instead provide a set of default fontconfigs that a distribution may choose to install to deliver a "Plasma experience".
> Dumping random settings There is already the GTK daemon that overwrites all GTK settings. A similar one can be added for fontconfig. Also, I just noticed that fontconfig looks at $XDG_CONFIG_HOME/fontconfig/conf.d/ as well. Files can be added to or removed from there by the daemon. > Arch has default Arch doesn't really have a default font. Every font that has a file in /etc/fonts/conf.d/ has a "alias sans-serif to refer to me" in there and fontconfig parses the files sequentially. A basic Arch install with Plasma actually uses Noto fonts by default for everything. Adding Firefox changes that to DejaVu because ttf-dejavu is a dependency of firefox and the file it adds in /etc/fonts/conf.d/ is later on in the sequence. Same with installing Calibre which pulls in gsfonts (Nimbus). > SDDM The synchronise feature in sddm-kcm already copies $XDG_CONFIG_HOME/fontconfig/fonts.conf to /var/lib/sddm/.config/fontconfig/ if the file is present.
Sorry, I meant a basic Arch install with Plasma and noto-fonts as the provider for ttf-font (multiple fonts provide the virtual package and none of them conflict with each other).
All of these were examples. Think of Fedora instead of Arch and GDM instead of SDDM if you will. The point holds though. If Arch wants a Plasma system to have Plasma UX then the plasma config would simply have to outscore all the other stuff (e.g. firefox). Same for any other distro. Somehow you are arguing against my point but you are not actually explaining why the dumping settings options would be better than using fontconfig proper. Fontconfig is a system through which the font behavior is configured in a cross toolkit, cross desktop kind of way. Why would we put a whole lot of code on top to beat fontconfig into submission when we can simply have fontconfig do what it is built to do by working with it rather than against it, i.e. by install a config with high enough lexicographical order.
Oh, I did not even know that there are ways other than the XML files to configure fontconfig. I did see the fontconfig developers reference, but I assumed that those were the internal functions fontconfig used to parse the XML files and that the reference was for developers working on fontconfig itself.