Snapped app not loading fonts on Fedora (and Arch)

we have the feature to send out mails to packagers about security issues in their snaps, i wonder if it is possible to use that system to mail all packagers of snaps plugging the desktop interface perhaps ?
i guess the store team would know if such a feature exists (or is easy/hard to implement) …

boxy-svg (file dialog), shapezio (file dialog) all have the issue and no workaround works currently.

1 Like

AFAIK, this is only for snaps, like snap-store, that use the gnome extension edit: it turns out both the gnome extension and the kde extension do this. The fix in 4.4+ does not apply generically to all snaps, just those that use the gnome extension. So either snaps that continue to not work need to switch to using the gnome-extensions (which is not possible in all cases), or snapcraft needs some more work to enable perhaps just a “fonts” extension which DTRT regardless of whether the snap is using the gnome extensions or not and then push people who can’t switch to using the gnome extension to use just the fonts extension.

Both of these snaps use gnome platform snaps, so perhaps all that’s necessary are rebuilds with newer versions of snapcraft, I think @popey can just trigger a rebuild with a newer version of snapcraft and shapezio will be fixed like :rainbow: :unicorn: while I don’t know if the boxy-svg maintainer is here, but there is a contact set for the snap so you could try reaching out that way.

I just triggered and uploaded a new build of shapezio. Let me know if that helps?

1 Like

The update didn’t fix the issue, but I noticed I did the workaround wrong.

The correct workaround is:

rm -r ~/snap/snapname/common/.cache/fontconfig
touch ~/snap/snapname/common/.cache/fontconfig

instead of the ~/snapname/current/.config/fontconfig which I did by accident. That works atleast for now.

1 Like

However, that workaround is not ideal as it causes the dialog boxes to take a long time to open up every time you launch the program.

I have a similar issue on Ubuntu Core 18 with squares instead of fonts and not working icons in my gtkmm application using gnome-3-28. My application is built with the core 18 image. Snap works fine on Ubuntu16.04 and ubuntu18.04 but it fails on Ubuntu core 18 with mir-kiosk and wayland. Non of the workarounds above works for me in this case. Also when I run application I got warnings:

gtk-update-icon-cache: The generated cache was invalid.
WARNING: icon cache generation failed for /root/snap/gsapples/x1/.local/share/icons/Humanity-Dark
gtk-update-icon-cache: Could not rename /root/snap/gsapples/x1/.local/share/icons/Humanity/.icon-theme.cache to /root/snap/gsapples/x1/.local/share/icons/Humanity/icon-theme.cache: No such file or directory
WARNING: icon cache generation failed for /root/snap/gsapples/x1/.local/share/icons/Humanity

note that the gnome extension only ships the dejavu font, if your kiosk app uses or expects anything else you should ship the expected fonts in your app snap … (and make sure the fonts can be found in the font path).

also recent snapcraft generates a configure hook for you that calls fc-cache i think, not sure how that works in case of kiosk snaps … (the only one i have that is using the gnome extension atm doesnt need any fonts (https://github.com/ogra1/picviewer-kiosk))

Right now I’m using sans font, which counts as dejavu I think - so it is not non default font problem.

For the similar test to the one that was done earlier in this thread I installed Inkscape in ubuntu core 18 and effect is simillar - no fonts. No one really needs Inkscape in Ubuntu Core so it is not a problem in itself - but it shows that “build once and install anywhere” does not work in Ubuntu Core for Gtk applications.

I use snapcraft 4.4.2, so I think that this is up to date version. This configure hook, is it something that I have to specify in my snapcraft.yaml file explicitly or is it something that suppose to just work in newer snapcraft version?

as i understood it should just work (though my own desktop related snaps simply already use that config hook and their own font cache (i.e. see the zoom-snap) similar to what inkscape does) … if inkscape does not work this indicates that the fix wont work on core either …

OTOH i dont think anyone ever stated anything about “build once and install everywhere” in regards to Ubuntu Core which is completely focused on embedded, IoT and industrial currently. Graphical apps o Core are expected to be standalone, separately packaged kiosk apps that ship everything necessary along in their package.

Ubuntu Core does not even have a user concept ATM and is lacking any pieces to spawn a user session beyond providing an ssh login for developers (the typical use-case is completely user-less, managed through an agent snap that is hooked up to a central fleet management service or as an appliance with a minimal initial configuration tool)

Ok, I understand. I just wanted to show to you my error because I thought it is simillar to the error from this thread. I don’t think that every desktop app should work out of the box on Ubuntu Core system - I understand the system purpouse and its limitations. In earlier post though you stated that gnome extensions package dejavu fonts inside. The fact that these fonts are not displayed in installed app looks like the error worth to be mention here, especially that official documentation and tutorials claim to support gtk on Ubuntu Core systems.

well, i actually think they should :wink: (to have a kiosk picviwewer, why not be able to install the eog snap and be able to call "snap set eog kiosk=true) but today it isnt like that and you need to snap the whole set of supporting bits inside your package …

gtk apps work fine on Ubuntu Core on top of mir-kiosk as do electron, java, Qt or nodejs apps but the packaging has rather different requirements and you need to explicitly include all bits and pieces inside your kiosk snap to make it work, it isnt just a seamless “install this desktop app” but rather a “create a kiosk snap from scratch including all desktop pieces the app requires”

note that the gnome extensions are not being tested (or designed) in this context currently, so yes, for a future where we can simply use the extensions on core this is definitely worthy to be mentioned but will not help the issue with desktop systems (where the reason likely is a version discrepancy between the fontconfig running on the desktop environment vs the version running inside the snap package)

VSCodium still not fixed.

https://github.com/VSCodium/vscodium/issues/426#issuecomment-734314190

2 Likes

Hi, I think my snap packaging of Folding at Home has some users hitting the same problem -> Missing fonts issue

Same issue in openSUSE Tumbleweed (KDE desktop). Fonts appear as squares in dialog boxes, within the following snaps:
hey-mail, teams, telegram-desktop, standard-notes

I’ve had a user who experienced this issue even after upgrading to use Gnome extensions built with 4.4+; the old fix of regenerating font config caches didn’t work, instead, but this seemed to have some effect.

sed -i '/cachedir prefix="xdg"/ d' ~/snap/example-snap/current/.config/fontconfig/fonts.conf
(Change the snap name as relevant)

It’ll reset everytime the snap upgrades to a new revision and need to be run again. A substantial amount of font caches will still exist in $SNAP_COMMON, mitigating any delay this would probably cause.

3 Likes

Probably the same as what starfox saw, but on arch rather than openSUSE. Dialog boxes that show up when clicking the teams tray have all text replaced with squares, while general text within the app itself works fine.

Switching to teams from AUR fixed it.

This worked for me as well, for Signal, on Fedora 33.