Frequent readers of my blog might (in between existential crises) recall that I’ve been devoting a lot of thought lately to how we can improve the font-selection process on desktop Linux systems. There are, for instance, lots of spots where the plumbing layer short-changes the user experience we can present to a GNOME user as compared to a mac OS or Windows user: we frequently don’t include all the necessary metadata in distro-packaged fonts, and as a result the contemporary generation of font managers — none of which are installed by default — don’t have much useful information to present that would let somebody decide that yes, in fact, they do want to install font X. The general system-package manager application has even less to show. Fair enough; we can work out what needs to be improved, open issues against the software projects and the font packages, and incrementally improve matters.
Fast forward. A couple of weeks ago, I sat in on the GNOME Metered-Data / Parental Guidance Hackfest at Red Hat in London. And I do mean sat in, because I contributed virtually nothing. (But it was a good experience; I’ve never lived close enough to a hackfest site before, so I was really wanting to see the whole feature-idea-to-implementation process, start to finish, up close. Very educational.)
ANYway, along the way I got into a handful of side conversations about fonts and script support and, in one of those, Richard Hughes pointed out how complicated font packages make matters for newer distro initiatives, like the Flatpak and Snap application formats and Fedora’s Silverblue. Because fonts want to be installed in protected system directories (at least when they come from the distribution) like /usr/share/, they punch holes in the security models that Flatpak, Snap, and Silverblue are in part driven by.
Tangent: Silverblue is one of those “immutable system image” distribution ideas, wherein the OS image is read-only and the user is generally meant to only modify it by installing per-user packages like Flatpaks, which are overlays that exist only in tightly defined sandboxy containers. The OS updates are transactional; you have to reboot the system to swap over to the new immutable OS filesystem. Ubuntu Core is the same model, give or take, and there are others (or I’m pretty sure there are; Ubuntu Core I know about because it’s been around a while. There used to be another Fedora incarnation called Atomic, and I think it’s been done other places I’m simply less familiar with.).
Trouble is, nobody wants to reboot their machine just to install a font. And as it turns out, you can’t just package a font in a Flatpak, either, because the sandbox keeps other sandboxed apps (i.e., the applications you might actually want to use the font in) from being able to see it. Snap gives you pretty much the same set of constraints. And, for some reason, the OS developers seem down on the idea that there would be hundreds of overlay filesystems installed, on a one-overlay-per-font basis.
Richard’s first thought was how we could streamline what’s included in a font package, but quickly enough we got to the question “what if the distributions stopped packaging fonts altogether?” Or, at least, what if the distros only worried about a small set of basic, language-support fonts in the core OS, and repurposed other fonts as user-level packages. Most desktop Linux boxes, we’re told, are single-user systems anyway … so if the font packages all installed to ~/.local/share/ then most users would never notice the difference.
It’s interesting to think about. Font managers for the desktop would only need to worry about one directory instead of two, and font packages themselves would be a lot more cross-distro-compatible. It would, however, mean altering all of those font packages, and that would be a ton of work. I’m not really clear if it’s possible for Debian packages or RPMs to install stuff into the user’s home directory anyway (legally speaking). If not, then you’d suddenly be talking about a different package format altogether.
And I get the impression that the system-engineering folks out there would be looking to offload the maintenance of the font packages themselves to a third party — but there really isn’t one that can take up the slack.
But consider the ancillary gains, too: gone would be the problem of “recommended font” sets (an untenable idea that occurs regularly); instead users in the know could devise and publish their own recommendations just like The Kids Today do with their Spotify playlists. If per-user fonts were the norm, distributions could phase out fonts that need superceding with a lot less pushback. And it would (at least in theory) be drastically easier to synchronize the set of installed fonts between two desktop machines running different distributions. It might even be possible to persuade more upstream font projects to maintain the “packages” themselves, reducing lag time.
This is not likely to happen. But it’s worth chasing down how it would work, I think, because it leads to some intriguing side effects. But enough from me: thoughts?