Snap and square symbols in system's popup

I’m going to do the echo of a problem that have been lasting for years now under at least fedora. From what I know, at least from fedora 31.
So it would be nice that one of the dev pops in on that matter.

And there is not the only one thread about it.
it’s happening whether it’s a fresh isntallation or not, whether it’s a vm with default settings so under wayland or under a bare metal desktop with xorg for nvidia and cuda drivers compatibility. So it’s obviously not related to that.
And the solution about recreating the fontcache is not doing a damn thing.
So it’s obviously a file missing or a dependency missing so could we at least a list of font dependency related ?

well, that thread you linked was kind of side stepping the other one at:

there is also a proposed workaround you could try:

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

I’d also recommend trying
sed -i '/cachedir prefix="xdg"/ d' ~/snap/example-snap/current/.config/fontconfig/fonts.conf

This instructs each snap to avoid using the users font caches. This was helpful for me when snaps using Gnome/KDE extensions (which use private system font caches) were struggling. Unfortunately each time the snap updates it’ll reset this command.

as I said but maybe I’ve mislead my explanation somehow, the workaround is not doing anything. I guess that’s more a ubuntu workaround since snap is more a ubuntu tech so might be normal that just a workaround might fix a little glitch. On other distributions, msot probably the problem is more profound than just that.

also fedora doesn’t store fontconfig in /var/cache

This doesn’t work because when I try the workaround before that, the fontconfig directory stays deleted. I’ve just tried it on bitwarden snap and on the relaunch of bitwarden the folder does not get recreated

location of the fontconfig system wide in fedora:

the issue does not happen on ubuntu, the workaround is for arch and fedora (as the title of the linked thread says) where the distro fontconfig version differs from the one the snap is linked against, often regenerating the cache fixes this discrepancy, sorry if it did not help you … note though that snap is definitely not an “ubuntu technology” (every single PR to the snapd code runs 30 test of which 24 are runtime tests on 24 different distros (2 centos and 3 fedora versions among them) … ubuntu is not the target of snaps, providing a distro agnostic packaging system is …

okey good to know then. I’ve always learned it was originally coming from ubuntu system so I was assuming it was canonical which had funded the project in the first place.
Especially when you hear discussions on the different fedora discussions threads where they recommend flatpak and ditching snap.

You can force the snaps to recreate their fontconfig folder by deleting .last_revision, E.G, rm ~/snap/example-snap/current/.last_revision, then when you run the snap next it’ll recreate the fontconfig folder to let you see if the sed command achieves anything for you.

okey give me a minute I’ m going to try that

and this is absoluely true, canonical funds and backs the project but that does not change the target that it had from day one when it started in 2014 (mainly with focus on IoT, clound and server in the begining, desktop support came only later) :wink:

… in 2016 redhat decided to go on their own and revived a mostly idling project called xdg-apps and renamed it to flatpak … no idea if that was because canonical originally funded snaps or if there are other reasons, i personally think they both have their good right to exist and would never recommend anyone to “ditch flatpak” …

okey good to know. I would not recommend those kind of debattable advice but they have the freedom to think that after all

Okey so indeed it gets recreated thanks to that but the sed command doesn’t change a thing at least on mattermost snap… Do you have any snap that you are using I could try on to see if it’s the snap specifics or if it s systeml wide?

mattermost is an electron snap … you could indeed try if using a different toolkit makes any difference here …

there is a gnome-font-viewer snap that should use GTK/gnome libs …

for Qt you could try zoom-client (or telegram-desktop) …

1 Like

okey let’s try telegram-desktop.
But are we sure that for those where it works, there is no added dependencies there might have been added because of another software or something alike? Because those unicode square gives me really the impression that this is because of a missing piece, not because of a cache corruption or anything like that.

So looking into it, Mattermost is using the Gnome 3-28 extension, I can’t remember if this extension is meant to have private font caches, but looking at the configure hook for this snap in particular, I don’t think this one does, so the sed workaround does probably do nothing.

Unfortunately I don’t have any other snaps off the top of my head to use as examples for Core18/Gnome-3-28, my main experiences is with my own snaps which I migrated to core20 ASAP since it aids with fonts issues.

If you’d be willing to try building your own version of the snap for testing purposes though, you’d probably find this branch would fix the font problem. It’s probably worth poking Alan here since what he was waiting for is now available properly.

If you just generally want a modern base + extensions electron app to use for comparisons sake to see if the fonts work as expected there, try Joplin, hopefully you should find the file > open dialogues and about > help work fine.

1 Like

funny i was using the installation recommended guildelines for joplin and not the snap. Will try it right now just to be sure

okey correct the telegram is usingly correclty.
So that’s nice to finally have.

Yes your version of joplin is working too.

Okey so ths is then a snapd version problem then, which means I will need to put 5 github tickets at least to remind them to rebuild their snap … yay ^^

thanks for the guidance guys

1 Like