@jamesh would it be possible to patch fontconfig to not error on invalid attributes? Seems like it should be reasonable to warn on those rather than error. Thoughts?
TBH this looks like another evidence in favor of carrying our own /etc.
that would mean we woulnd’t find the system fonts, unless you’re saying we should read the system’s font config and translate it into something the snap understands. Which, … WAT.
From the sound of all this, the issue is that fontconfig and fonts.conf seem to be a matched pair, but in a snap world, one’s in the snap and the other’s in the system, so they can get mismatched. I don’t know why fontconfig lives in the snap – I know almost nothing about all this – but that may be an untenable situation. In the best case, patching fontconfig in the snap to ignore unknown attributes will mean that snapped apps have a different font configuration and thus look different from non-snapped apps, which is a bad place to be and causes people to reject snapped apps as looking out of place (as it does when a snapped app ignores the system theme, which I know some work has recently gone into). In the worst case, the promise of snapped apps (“build a snap once and it’ll work everywhere”) becomes “build a snap once and it’ll work some places, unless the people have customised their system, in which case it won’t work”, which makes me think “oh, then building a snap is not as useful as I thought”.
1 Like
If libfontconfig failes to parse /etc/fonts/fonts.conf, it will instead load up a compiled in default configuration file:
https://gitlab.freedesktop.org/fontconfig/fontconfig/blob/master/src/fcinit.c#L38
This is essentially enough to find fonts in /usr/share/fonts and ~/.local/share/fonts, and cache files in /var/cache/fontconfig and ~/.cache/fontconfig. So while we’re definitely seeing errors related to unknown XML elements and attributes, it isn’t obvious that this is what is causing the font lookup failure.
I’ve definitely seen snaps exhibiting the same error messages when they ship an old libfontconfig and encounter new configuration files and still display fine, so there must be something else going on here.
As for patching fontconfig to make its config file parsing forward compatible, that’s still not going to get rid of all the snaps that have packaged ancient versions of the library. And if you are going to update a snap, you may as well upgrade to a newer fontconfig that will both fix the config file parsing and be compatible with the cache files on newer distros.
2 Likes
A user reported the same problem on Arch. I can reproduce it locally, here’s my gnome-logs: https://i.imgur.com/5sLAJTs.png
My fontconfig version is:
fontconfig 2:2.13.91+23+g65087ac-1
Looking at the change in PKGBUILD, it got updated just recently:
-pkgver=2.13.1+12+g5f5ec56
+pkgver=2.13.91+23+g65087ac
Anything I can do to debug this?
Edit:
this is the list of font related path the snap app touched: https://paste.ubuntu.com/p/C39dpbfyHC/ collected with snap run --strace='-e openat')
The log with FC_DEBUG=5 https://paste.ubuntu.com/p/83CNv4NncM/
So I’ve narrowed it down a bit.
- krita, Qt5, fonts are rendered correctly
- poedit, gtk3, uses gnome-3-26-1604, fonts are rendered correctly
- spotify, electron, fonts are rendered correctly
- gnome-logs, gtk3, uses gnome-3-28-1804, fonts are rendered incorrectly (boxes)
- gnome-calculator, same as gnome-lgos, fonts are rendered incorrectly (boxes)
In case of poedit and gnome-* snaps, fonts.conf comes from the content snap, which is gnome-3-26-1604 and gnome-3-28-1804 respectively. At this point it seems that the problem is more in the gnome-3-28-1804 snap than anything else. @jamesh @kenvandine any ideas what to try next?
1 Like
I think this is more likely a problem related to the snaps using core18. Any snap using gnome-3-28-1804 has a base of core18. Maybe @mvo has some ideas?
I’m not sure. Krita is a core18 snap and the problem is not observed there. Besides, core18 does not deliver libfontconfig*, it’s part of gnome platform snaps:
maciek@galeon:~ find /snap/gnome-3-2*-*/current/ -name '*fontco*.so*'
/snap/gnome-3-26-1604/current/usr/lib/x86_64-linux-gnu/libfontconfig.so.1
/snap/gnome-3-26-1604/current/usr/lib/x86_64-linux-gnu/libfontconfig.so.1.11.1
/snap/gnome-3-28-1804/current/usr/lib/x86_64-linux-gnu/libfontconfig.so.1
/snap/gnome-3-28-1804/current/usr/lib/x86_64-linux-gnu/libfontconfig.so.1.10.1
Krita comes with the same version of libfontconfig as gnome-3-26-1604 though:
maciek@galeon:~ find /snap/krita/current/ -name '*fontco*.so*'
/snap/krita/current/usr/lib/x86_64-linux-gnu/libfontconfig.so.1
/snap/krita/current/usr/lib/x86_64-linux-gnu/libfontconfig.so.1.10.1
It is almost definitely related to the fontconfig cache files rather than access to the fonts themselves.
Presumably the core18 snaps are trying (and failing) to use the host system fontconfig cache files, while the core16 snaps ignore the host system caches as too new. I wonder if there have been any changes to the data structures between 2.13 and 2.13.91 without a corresponding bump in the cache version?
1 Like
So, it looks like the big change in 2.13.91 is the revert of the UUID-based cache file manangement code introduced in 2.13:
https://gitlab.freedesktop.org/fontconfig/fontconfig/commit/c4324f54ee16e648ba91f3e9c66af13ab3b1754c
It looks like this is still “cache version 7”, which it has been since fontconfig 2.11.95. If anything, this should be more compatible with the older fontconfig found in gnome-3-28-1804.
2 Likes
Thanks for the tip. I’ve tweaked the mount namespace of the snap and mounted a clean tmpfs over /var/cache/fontconfig. At this point the fonts were rendered correctly, although the start time was obviously longer.
Now, the questions remains is how we can address this in most hands-off fashion for the users.
That sounds like the cache version should have been be bumped. Would this warrant a bug report for fontconfig upstream? As I understand, this will reach Ubuntu at some point too, probably around 20.* time frame.
As I understand it, they didn’t bump the cache version because:
- the file format did not change, and
- the file names for UUID and MD5-directory-name based cache files would never collide, due to the different lengths and extra dashes.
Further more, if the 2.13 libfontconfig encountered a read-only directory without a UUID file, it would fall back to checking for an MD5 cache file.
Looking at the 2.13.91 source, it looks like it will also be able to reuse existing valid UUID based cache files, but will attempt to remove UUID files from writeable directories.
So, can you give me some workaround for this issue pls (Arch linux)?
Part of my snap-apps can’t start
user@thinkpad$ libreoffice.writer
Fontconfig warning: FcPattern object weight does not accept value [40 210)
Application Error
and the other part starts without letters…
BTW, code (VSCode) and telegram work pretty well… Maybe they use some internal fontconfig.
If it is important for anyone in future, here is my solution:
sudo rm /var/cache/fontconfig/*
rm ~/.cache/fontconfig/*
3 Likes
Is deleting the font cache the only workaround?
Don’t know, but it has fixed my issues
I still have this rectangle boxes instead of text issue with snap-store. I am running 5.4.13-arch1-1.
I have Opera installed from snap without issues.
I have tried the following with no avail:
sudo rm /var/cache/fontconfig/*
rm ~/.cache/fontconfig/*
fc-cache -r
Any new updates on this issue?
I am having the same issue with Cherrytree on Manjaro KDE and the above steps did not fix it, any good workaround to fix this. 