Snapped app not loading fonts on Fedora (and Arch)

snap
15

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
16

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?

17

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
18

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
19

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
20

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.

21

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.

22

As I understand it, they didn’t bump the cache version because:

  1. the file format did not change, and
  2. 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.

23

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.

24

If it is important for anyone in future, here is my solution:

sudo rm /var/cache/fontconfig/*
rm ~/.cache/fontconfig/*
3 Likes
25

Is deleting the font cache the only workaround?

26

Don’t know, but it has fixed my issues

27

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?

28

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. cherrytree02

29

Hello!

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:
image

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 ?

Thank you in advance!

1 Like
30

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).

2 Likes
31

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.

1 Like
32

Having worked around the UUID thing, I was able to narrow it down to this single commit.
https://gitlab.freedesktop.org/fontconfig/fontconfig/commit/0f9bbbcf8f6f8264efb0a2ded4d8d05f3b10f7a4

Reverting the commit in full and regenerating the cache, made the fonts works again. In your view, what is the best way to proceed with the upstream?

3 Likes
33

Debugging this further. The fonts work on Focal and Debian 10, both using libfontconfig 2.13.1. I’ve pulled the actual libfontconfig.so.1.12.0 binary from Debian and font files. Also mounted an empty tmpfs over /etc/fonts (and then /etc/fonts/conf.d) to make sure we’re using a vanilla config. Then symlinked the MD5-named cache file expected by gnome-3-28-1804 is symlinked to the right UUID-name file as expected by the Debian version.

In the end fonts were still rendering as boxes, suggesting that perhaps problem is somewhere else in the stack. I need to consult with @jamesh on how to proceed with debugging this.

1 Like
34

Clearing fontconfig cache fixed this problem for me on Arch Linux. I use infinality patched font BTW