Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 922794 - kde-plasma/plasma-integration: Don't depend on noto
Summary: kde-plasma/plasma-integration: Don't depend on noto
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo KDE team
URL: https://phabricator.kde.org/D2377
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-01-23 23:12 UTC by Christopher Smith
Modified: 2024-03-01 05:54 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info (emerge-info.txt,8.56 KB, text/plain)
2024-01-23 23:12 UTC, Christopher Smith
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Smith 2024-01-23 23:12:58 UTC
Created attachment 883011 [details]
emerge --info

plasma-integration has a non-USEd dependency on media-fonts/noto. While useful, noto has the obnoxious property of installing literally hundreds (on my system, 360 `style=regular`) fonts, which makes using a font selector an exercise in frustration. "How do I hide Noto font variants?" is a widespread question online (e.g., see below), and I don't believe that KDE actually *requires* it to function.

If it is desired to keep noto as a default dependency, at least provide a USE flag to be able to omit it.

https://forum.endeavouros.com/t/how-to-get-rid-of-noto-fonts-clutter/5042
https://bbs.archlinux.org/viewtopic.php?id=230195
Comment 2 Christopher Smith 2024-01-24 16:31:21 UTC
Thanks for the link; I'm trying to track down the actual logic for the `find_package(FontNotoSans)` call. Absent an upstream change, might there be a possibility of either splitting the `media-fonts/noto` package into a "basic" and "full" or of USE-flagging it? (There's already `USE=extra`.) I understand that the goal of Noto is to support literally every character in existence, but its implementation as separately-named fonts is a usability catastrophe.
Comment 3 Andreas Sturmlechner gentoo-dev 2024-02-06 18:22:12 UTC
(In reply to Christopher Smith from comment #2)
> Thanks for the link; I'm trying to track down the actual logic for the
> `find_package(FontNotoSans)` call.
There's not much to track down here. It is marked as a RUNTIME dependency, placed by the upstream devs specifically to notify packagers of having to provide this as a runtime dependency. Failure to do so would put us at a disadvantage when users begin filing bugs upstream as a result of missing these dependencies.
Comment 4 Christopher Smith 2024-02-06 22:29:43 UTC
I want to determine *exactly what* the rule is checking for; for example, is it looking for a specific TTF file, or a package-manager package somehow? If the former, might it be possible to split the Gentoo package into a `noto-core` and `noto-all` to limit the surface area? (etc.)
Comment 5 Niklāvs Koļesņikovs 2024-03-01 05:54:57 UTC
I'll note that there's two issues with Noto: file count and total size. I think both of these stem from the same limitation that some font properties are language specific but possibly(?) limited to be file specific, which results in many large font files which all contain seemingly the same glyphs but with slight differences in, I believe, character spacing or the like.

It would be most ideal if KDE would stop insisting on this particular font and picked something more reasonable like any one Noto variant is enough or, really, just accept that fontconfig is meant to provide something sensible when asked for "Noto Sans" or any other typeface defining string. And, if any distro out of the box has an actually problematic behavior when asked for a common typeface, then that should be treated as a distro bug.

All in all, whether it's Noto, DejaVu or some other common typeface, they're all, IMVHO, close enough that the exact font metrics should not matter and the result should be reasonable UI. It's also worth noting that Qt and Plasma are supposed to obey user configured fonts in the first place, so it feels very strange to insist upon a Google's typeface in the first place.