support sharing host fonts with toolbox

[juhp]

Is your feature request related to a problem? Please describe.

It would be cool to have a consistent way to use host fonts from within toolbox.

Describe the solution you'd like

I may be tricky to find a general consistent approach, though what I personally do
is for Fedora toolboxes (on Fedora):

sudo ln -s /run/host/usr/share/fonts /usr/local/share/

without running fc-cache.

Though apparently bad things can happen with this for Silverblue with fc-cache due to the timestamps.

FWIW, distrobox-init seems to do something like this:
https://github.com/89luca89/distrobox/blob/18053c254a83750c49c08e58df2e48a0f04aef48/distrobox-init#L2007

[debarshiray]

It would be cool to have a consistent way to use host fonts from within toolbox.

Yes, indeed. I don't know enough about fonts, so I never tried this on my own.

Describe the solution you'd like

I may be tricky to find a general consistent approach, though what I personally do is for Fedora toolboxes (on Fedora):

sudo ln -s /run/host/usr/share/fonts /usr/local/share/

without running fc-cache.

Is it noticeably slower if the font information cache is absent?

Where does the cache live? The fc-cache(1) manual says %cachedir%/*-%arch%.cache-%version% but I don't know what the values of those variables are. I don't see anything in /var/cache, but ~/.cache/fontconfig/ has some files.

Are the formats of the font files and the cache stable enough to be mixed and matched across the host and containers?

If they are stable enough, maybe we can bind mount /run/host/usr/share/fonts to the container's /usr/share/fonts, and add /usr/share/fonts to %_netsharedpath in /usr/lib/rpm/macros.d/macros.toolbox so that RPMs inside the container leave it alone? This way we could have less content in the Toolbx images, which is always better.

What do you think?

Though apparently bad things can happen with this for Silverblue with fc-cache due to the timestamps.

FWIW, distrobox-init seems to do something like this: https://github.com/89luca89/distrobox/blob/18053c254a83750c49c08e58df2e48a0f04aef48/distrobox-init#L2007

They are doing a bind mount instead of a symbolic link, but it's the same thing for the purposes of this issue.

[juhp]

Is it noticeably slower if the font information cache is absent?

Not to me. There may be a small start-up delay for GUI apps the first time?

The other discrepancy is missing /etc/fonts/conf.d/ files from the host.
But at a basic level just linking the fonts directory seems to work reasonably okay on Silverblue in my experience: so I don't feel it is harmful. Though it is possible if there are many extra fonts in installed on the host, the results might not be as predictable: I think in some sense it dependencies on the amount of overlapping font coverage - the default fontconfig conf.d rules should provide some minimal order at least.
(I think distrobox also doesn't link conf.d)

---

I believe the default system cache is in /usr/lib/fontconfig/cache/.

I think potential problems with sharing the fontconfig cache include:

• it is possible, specially for older OSes, for the host and toolbox fontconfig's to be incompatible (we have seen this also for flatpaks in the recent past, though I believe the handling has improved for recent fontconfig versions)
• also naively it may interfere with any fonts packages installed in the toolbox

In theory something could be done for these perhaps - though it may require non-trivial changes on the fontconfig side.

Anyway @tagoh is the expert here, I am just sharing my limited experience on this.

[debarshiray]

Thanks for bringing up Flatpak. It is always a good data point. How do fonts work in Flatpaks? Do the Flatpak containers have their own fonts, presumably through the runtime? Or are the fonts shared with the host?

I didn't know about /etc/fonts/conf.d. I see that it has symbolic links to configuration files installed by the fonts packages in /usr/share/fontconfig.

I think I don't know how fonts work and that's preventing me from imagining all the possibilities.

Maybe we can work out the use-cases around fonts? I can imagine that most users who are not font developers will be happy to have the fonts shared with the host. What about font developers? Will it somehow get in their way?

If we do bind mount the host's /usr/share/fonts into the container's /usr/share/fonts, then setting %_netsharedpath (see above) should block RPM from adding files to that location inside the container.