Expose host fontconfig conf.d?

[alexlarsson]

We currently export the font dirs from the host (i.e. /usr/share/fonts is available as /run/host/fonts in the app sandbox). For some fonts this might not be enough, as the fonts also ship xml config snippets in /etc/fonts/conf.d that might be needed. Unfortunately this directory (and files) contain a mix of all sorts of options, and they may not all make sense to expose to the sandbox.

Some of the things we want are font-specific aliases, and local-specific details for i18n fonts. But the font config snippets can contain e.g. font dirs specifications, cache dirs, etc that are not useful or safe in the sandbox.

@tagoh, @behdad: Do you have any ideas of how to best do this?

[ramcq]

Also it seems the syntax of these files change/break over time: https://bugs.freedesktop.org/show_bug.cgi?id=105818

[alexlarsson]

Ugh, yeah, doubleplus ungood...

[tagoh]

loading the necessary files only from memory through FcConfigParseAndLoadFromMemory() by any way? or you could have your own conf.d where contains necessary conf files from fonts and put a config on /etc/fonts/conf.d to load them? I mean you could have something like your own 50-user.conf.

[alexlarsson]

@tagoh so, we can easily map the contents of host /etc/fonts/conf.d somewhere in the sandbox and make the default config include that. The problem is more what is in the files there.

On my fedora system for instance, /etc/fonts/conf.d/75-levien-inconsolata.conf adds Inconsolata to the monospace family. If we put Inconsolata.ttf in the sandbox, it makes sense to also add this config file. But there are also a bunch of files in there that are part of fontconfig itself, which will already be bundled in the fontconfig from the runtime, and adding these are not obviously right to me. (I mean, it might be right to expose them, but i would need to study it closely to be sure of that.)

And even worse, there could be locally added files that add config options like dir, cachedir, or include, that refer to filesystem locations on the host that will break in the sandbox.

Also, an old fontconfig in the sandbox might not be new enough to read the config files on the host from a newer fontconfig, because the format is only backwards compat, not forwards compat.

[tagoh]

if sandbox modifies the default config exposed by fontconfig, your concern looks valid to me otherwise you could basically use it as is. or it may depends how sandboxes manages fontconfig configurations. if you have any plans to customize them on any UI, you should have your own config instead of using files shipped by fontconfig right.

and... yeah, there are no way to avoid such options added to the individual files so far. we should implement something in fontconfig to avoid it right.

and for last concern, we could implement the version checking between library and config files and if mis-matching, we could ask for some options, applying it anyway, ignoring config and/or warn it, if that helps.

[behdad]

I have no opinion or comments.

[memeplex]

Just trying to understand a bit more about this. I have a very innocuous fonts.conf file in my home direction (just basic antialiasing and hinting settings). This is in the standard location ~/.config/fontconfig/fonts.conf (I'm writing from my phone now but I believe that's the right path). Now: would this be automatically exposed to the app running in the sandbox? As the answer is probably "not at all" then: if I pass the filesystem option with a home value, or alternatively with this config file alone, will that do the trick? Will fontconfig see the file in the chroot environment as if it where in the current user home dir? Thanks.

[tagoh]

@memeplex It should AFAIU. however if it contains the filesystem specific thing like

. it may not work as you expected because it may be not exposed like your host has. there are no way to apply config so far only when running under sandboxes and/or specific sandboxes.

[tinywrkb]

It should be pointed out that in Arch Linux, distro font packages do not install config snippets into /etc/fonts/conf.d, and this folder has mostly symlinks to /usr.

In more detail (feel free to skip this):

A font package will only install a fontconfig snippets into /usr/share/fontconfig/conf.avail.
If the config should be enabled by default, then a symlink will also be packaged, pointing from /usr/share/fontconfig/conf.default to /usr/share/fontconfig/conf.avail.
A post installation hook will look into /usr/share/fontconfig/conf.default and create symlinks from /etc/fonts/conf.d to /usr/share/fontconfig/conf.default.

If the config should not be enabled by default, then to enable the config, the user is expected to manually create the symlink from /etc/fonts/conf.d or ~/.config/fontconfig/conf.d to /usr/share/fontconfig/conf.avail.

[mkhl]

i also use fontconfig to e.g. choose a default monospaced font or enable features on fonts.
this currently means that flatpaked applications use different fonts and features than i configured.

[Kimiblock]

fontconfig is used by CJK users to define a fallback list. This prevents e.g. Japanese fonts showing up in Chinese contents, vice versa.

[mcatanzaro]

fontconfig is used by CJK users to define a fallback list. This prevents e.g. Japanese fonts showing up in Chinese contents, vice versa.

If you can develop a default config that works for all users, then that config can be added to upstream fontconfig and go into the runtime. If it has to be customized on a per-user basis, then that's pretty unfortunate as probably the only option is to fix this bug, which will be hard. You can review #3947 to understand the challenges here; basically we'd need to change the Fontconfig configuration format such that it doesn't break if Fontconfig is newer or older in the runtime than it is on the host, among other considerations. I don't have enough Fontconfig expertise to understand whether that would be sufficient or not.

[tagoh]

The most problem is that fontconfig can't flatten the order of config files on multiple places. You could mount conf.d from host somewhere on flatpak but the outcome may be different compared to host's behavior because of that.
If we address it, maybe we can simply mount conf.d from host and combine all the config files on both host and container.

[Kimiblock]

I personally want to give the choice to users. That means an option allowing them to use configurations from the host. There are different CJK fonts exist, and everyone have their own preferences such as font family, weight, hinting etc.