This issue one of the desktop team priorities, so I thought I’d start a discussion with the aim of getting the necessary changes merged to snapd.
The basic problem is that at the moment strict confined snaps need to ship their own fonts. This is a problem for a number of reasons:
- The bundled font(s) may not cover the end user’s native language.
- If the snap bundles many fonts, it will significantly increase the size of the snap. For example, the Noto font family covering CJK languages is 285 MB on disk.
- If the user has selected a different interface font, then there is no guarantee that the snap includes it.
So there are good arguments to allow a snap to use fonts from outside sources. Since font formats are relatively stable (unlike themes), giving a snap access to the fonts on the host system seems like a reasonable path to take. It will also ensure that a font capable of displaying the user’s native language is available.
The standard system for managing fonts on Linux systems is fontconfig, so the end goal is to make the fonts available via that system. This is going to involve access to the following data:
- Read-only access to Font files, which might be stored in:
- Read-only access to fontconfig cache files stored in:
~/.cache/fontconfig(this one can probably be skipped)
- Read-only access to configuration files, which are stored in:
As pretty much every graphical application is going to display text, I think it would make sense to make the font access rules part of the new
While fontconfig can regenerate its caches in the user cache directory, this will slow down application start up on first run (or any time fonts are changed on disk). Making the existing cache files available is desirable. The caches contain only information derived from the font files, so it shouldn’t represent an information leak.
One issue is that cache files reference the full path name of the directory they cover. This means that if the fonts are bind mounted to a different location, the cache will be invalid. There is some work to solve this upstream (fontconfig bug 101889, but perhaps we can use the layouts feature to help? Or maybe just make sure the core snap contains empty directories at the right locations to use as bind mount points.
Fontconfig configuration files
There are a number of things fontconfig’s configuration files may be used for:
- Users remapping what the abstract
monospacefont names map to
- System wide configuration for fonts, either restricting a font to a particular language or marking it as a substitute for some other font it is metric compatible with.
Without access to this configuration data, confined applications may pick different fonts compared to those outside the sandbox.