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.
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?
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:
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?
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.
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.
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:
Thank you for all the comments and workarounds provided.
We are developing an application in Electron.js, the app works great in Ubuntu, but in Fedora, only the main views characters are rendered well, the dialogs show squares instead of letters:
Electron dialog in Fedora:
we did deleted the fontcofig cache, but just to check if it works, but it didn’t work.
we are using the default configuration of https://www.electron.build/configuration/snap to generate the snap build. are we missing something? is there anything we can include before creating the snap to make the app able to read the fontconfig and not require our users to apply workarounds ?
I’ve bisected libfontconfig versions between 2.12.6 (which we know to work), and current master (2.13.92+). I’ve made sure that there is only one source of fontconfig cache under /var/cache/fontconfig and no other location can be written to inside the snap.
The commit that broke it was correctly identified by @jamesh before:
If we want to get it working, we need to have a way of ensuring that the generated font cache is comptible with whatever the libfontconfig version is used by the snap (be it the core* one, or Gnome runtime one).
As I mentioned on IRC, it is quite possible that the breakage is earlier than this commit. The difference is that commits from this one on produce cache files that Bionic’s fontconfig can see (i.e. based on the MD5 of the file name), and the ones just before it don’t (i.e. a UUID matching the $dir/.uuid file).
It would probably be possible to bisect further back by generating a cache and then symlinking the UUID cache file to the equivalent MD5 name and see if the snap is still broken.
