Snapped app not loading fonts on Fedora (and Arch)

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.


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

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.

1 Like

Having worked around the UUID thing, I was able to narrow it down to this single commit.

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?


Debugging this further. The fonts work on Focal and Debian 10, both using libfontconfig 2.13.1. I’ve pulled the actual 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

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

Once you do fc-cache -f on the host, and then run the snap again, the font should be broken in snaps again. I haven’t been able to do it yet, but the next step is probably dissecting the cache file generated by 2.13.1 and 2.13.92+ to check the differences.

1 Like

Hi, had the same issue with CherryTree.
My fix was:

sudo rm /var/cache/fontconfig/*
rm ~/.cache/fontconfig/*
fc-cache -r

Thanks @vgm106

1 Like

Thank you for that fix. It makes one wonder why there is still font caching in Linux at all considering it takes about 600ms for fc-cache to run so why does it even exist? Seems like some relic of the Xfree86 days, as in 1986 presumably(?)

I discovered a thing while testing some stuff because of an issue I had with Standard Notes . I basically had the same issue described here: The fonts in the Electron app itself worked fine but all the fonts of system dialogs were broken. I’m on Fedora 32 and using the Roboto font. But changing font and GTK theme to system’s default doesn’t change anything regarding this issue. I tested with some more apps:


  • Standard Notes: Fonts broken in system dialogs, system dialog’s theme matches system GTK theme
  • Simplenote: Fonts broken in system dialogs, system dialog’s theme matches system theme
  • Polar Bookshelf: Fonts broken in system dialogs, system dialog’s theme matches system theme
  • "electrontestapp: Fonts not broken in system dialogs, system dialog’s theme doesn’t match system theme, but font actually is Roboto

Native (as in not Electron) apps:

  • Snap Store: Fonts broken for the whole app, theme matches system theme
  • Midori Browser: Fonts not broken, theme doesn’t match the system theme, but font actually is Roboto

I don’t know if this correlation can lead to any valuable conclusion (maybe it’s just that the non-matching apps ship their own stuff or something), I just wanted to get it out there.

1 Like

Could you test mattermost-desktop? Maybe this is an issue with the electron-builder tooling. The mattermost-desktop snap uses electron but not the electron-builder tooling.

I installed mattermost-desktop for testing: The system dialogs match my system GTK theme here. And again all fonts in those system dialogs are broken (= displayed as box characters).

This is a great test case, which is very difficult to reproduce. Could you please test the inkscape snap? There’s been a proposed fix for fontconfig mismatches in the inkscape snap and we would love to get confirmation that it works in cases like your’s.


I installed Inkscape for testing. I actually already have Inkscape installed as a regular rpm package.
They both look the same as far as I can tell. All fonts in the application interface seem to work fine, no boxes. The appliation’s theme matches the system’s theme and it uses the system’s font.
Also the fonts of system dialogs like for file opening are all working fine and the theme matches.

Seems like something is implemented differently in Inkscape compared to the other apps.

My setup shouldn’t be difficult to reproduce though. It’s just a fresh Fedora 32 install with snapd installed. At least as far as I understand the described broken font issue should exist and be reproducible for all Fedora 32 (and other) installs.

That’s great info!

It is pretty hard to reproduce, if you aren’t a daily Fedora user. I just did a fresh install of Fedora 32 earlier this week and couldn’t reproduce the font issue. I’ve tried this a number of times with different versions of Fedora in the past and never reproduced it myself. It’s all related to the version of fontconfig that was used to generate cache files on the host. How recent was your fresh install? Was your homedir preserved from a previous install?

Thanks for the info!

@ted ^^ confirmation the snap private font caches seem to fix the issue, thanks for being a guinea pig.


Oh ok, I really didn’t expect that. I installed Fedora 32 less than 1 week ago. I didn’t preserve any settings, everything was newly configured only using the default system tools. No manual config file changes or anything like that.

I tried to remove the caches several times. It never solved the issue for me.

Please make sure you remove ~/snap/inkscape/common/.cache/fontconfig directory first. FWIW the inkscape snap from edge works here on Arch too.

The gimp or glimpse-editor snaps segfault and render boxes in the splash screen, but as I understand those do not have the special sauce @kenvandine added.

1 Like

I don’t know if that was directed towards me but Snap Inkscape still works fine after I removed the Snap Inkscape fontconfig directory.