Long story short: https://bugzilla.redhat.com/1845743 | v "fix" (well, workaround) was, in the end, as simple as: $ ln -s /etc/fonts/conf.d ~/.config/fontconfig Distribution (here Fedora) appears to do a great job of balancing the fonts regardless of what's installed at the moment, something that would get pitifully dismissed at the moment with sandboxing feature of WebKitGTK when run on Wayland-enabled environment (why only here and not with x11? cannot tell but perhaps some extension to X can act as a "font configuration" proxy of sorts?). At least that's what my observation tells. In my very case, it made a crucial difference between selecting nicely aliased Dejavu Sans font (without sandbox and/or with x11) in *.ttf vs. Cantarell in *.otf thas was apparently pixelated in closer examination (maybe the truth is more complicated but on the whole, said workaround restores exactly the desired behaviour, so I don't have an urge to dig deeper). The former is fully in-line with "fc-match sans" output. Users usually have no extra need to change the preferred fonts when the distribution mostly "just works" as per above. Thanks for reflecting the fontconfig preference more to its entirety. To be perfectly following everything, there are these $FONTCONFIG_PATH, etc. variables, but that would be rather overkill :-)
Huh, nope, false start, I think I must have been tricked with another, reliable workaround (export GDK_BACKEND=x11). Closing till I make more progress in investigating this, will reopen if there's anything WebKitGTK could do to help. Sorry for noise.
For the record, running MiniBrowser alone does _not_ appear to be equivalent to isolating this case further, starting with said Evolution usage: > GApplication is required for xdg-desktop-portal access > in the WebKit sandbox Indeed, fonts are always rendered just fine with GDK_BACKEND=wayland WEBKIT_FORCE_SANDBOX=1 Following is much closer and _will_ actually manifest the problem: GDKWEBKIT_FORCE_SANDBOX=0 bwrap --bind /run/user/1000/bus /run/user/1000/bus --bind .flatpak-info /.flatpak-info --args 0 /usr/libexec/webkit2gtk-4.0/MiniBrowser $ < bwrap-args \ WEBKIT_FORCE_SANDBOX=0 GDK_BACKEND=wayland \ bwrap --bind /run/user/$(id -u)/bus /run/user/$(id -u)/bus \ --bind bwrap-flatpak-info /.flatpak-info \ --args 0 \ /usr/libexec/webkit2gtk-4.0/MiniBrowser where: - bwrap-args: $ > bwrap-args { cat | tr '\n' '\0'; } <<EOF --die-with-parent --unshare-pid --unshare-uts --unshare-net --ro-bind /usr/bin /usr/local/bin --ro-bind /etc /etc --dev /dev --proc /proc --tmpfs /tmp --unsetenv TMPDIR --dir /run --symlink ../run /var/run --symlink ../tmp /var/tmp --ro-bind /sys/block /sys/block --ro-bind /sys/bus /sys/bus --ro-bind /sys/class /sys/class --ro-bind /sys/dev /sys/dev --ro-bind /sys/devices /sys/devices --ro-bind-try /usr/share /usr/share --ro-bind-try /usr/local/share /usr/local/share --ro-bind-try /usr/share /usr/share --ro-bind-try /lib /lib --ro-bind-try /usr/lib /usr/lib --ro-bind-try /usr/local/lib /usr/local/lib --ro-bind-try /usr/lib64 /usr/lib64 --ro-bind-try /lib64 /lib64 --ro-bind-try /usr/lib64 /usr/lib64 --ro-bind-try /usr/local/lib64 /usr/local/lib64 --ro-bind-try /usr/libexec/webkit2gtk-4.0 /usr/libexec/webkit2gtk-4.0 --ro-bind /usr/lib/systemd/resolv.conf /usr/lib/systemd/resolv.conf --ro-bind /usr/share/zoneinfo/Europe/Prague /usr/share/zoneinfo/Europe/Prague --bind-try /run/user/$(id -u)/$WAYLAND_DISPLAY /run/user/$(id -u)/$WAYLAND_DISPLAY --unshare-ipc --bind-try /home/$(id -un)/.cache/webkitgtk/applications /home/$(id -un)/.cache/webkitgtk/applications --bind-try /home/$(id -un)/.local/share/webkitgtk/mediakeys /home/$(id -un)/.local/share/webkitgtk/mediakeys --bind-try /home/$(id -un)/.local/share/webkitgtk/databases /home/$(id -un)/.local/share/webkitgtk/databases --bind-try /run/user/$(id -u)/pulse /run/user/$(id -u)/pulse --ro-bind-try /home/$(id -un)/.config/pulse /home/$(id -un)/.config/pulse --ro-bind-try /home/$(id -un)/.pulse /home/$(id -un)/.pulse --ro-bind-try /home/$(id -un)/.asoundrc /home/$(id -un)/.asoundrc --dev-bind-try /dev/snd /dev/snd --ro-bind-try /home/$(id -un)/.config/fontconfig /home/$(id -un)/.config/fontconfig --ro-bind-try /home/$(id -un)/.fontconfig /home/$(id -un)/.fontconfig --bind-try /home/$(id -un)/.cache/fontconfig /home/$(id -un)/.cache/fontconfig --ro-bind-try /home/$(id -un)/.fonts.conf /home/$(id -un)/.fonts.conf --ro-bind-try /home/$(id -un)/.config/.fonts.conf.d /home/$(id -un)/.config/.fonts.conf.d --ro-bind-try /home/$(id -un)/.local/share/fonts /home/$(id -un)/.local/share/fonts --ro-bind-try /home/$(id -un)/.fonts /home/$(id -un)/.fonts --ro-bind-try /var/cache/fontconfig /var/cache/fontconfig --ro-bind-try /home/$(id -un)/.local/share/gstreamer-1.0 /home/$(id -un)/.local/share/gstreamer-1.0 --bind-try /home/$(id -un)/.cache/gstreamer-1.0 /home/$(id -un)/.cache/gstreamer-1.0 --ro-bind-try /usr/libexec/gstreamer-1.0/gst-plugin-scanner /usr/libexec/gstreamer-1.0/gst-plugin-scanner --ro-bind-try /usr/libexec/gst-install-plugins-helper /usr/libexec/gst-install-plugins-helper --dev-bind-try /dev/dri /dev/dri --dev-bind-try /dev/mali /dev/mali --dev-bind-try /dev/mali0 /dev/mali0 --dev-bind-try /dev/umplock /dev/umplock --dev-bind-try /dev/nvidiactl /dev/nvidiactl --dev-bind-try /dev/nvidia0 /dev/nvidia0 --dev-bind-try /dev/nvidia /dev/nvidia --dev-bind-try /dev/kgsl-3d0 /dev/kgsl-3d0 --dev-bind-try /dev/ion /dev/ion --dev-bind-try /dev/v4l /dev/v4l --dev-bind-try /dev/video0 /dev/video0 --dev-bind-try /dev/video1 /dev/video1 --ro-bind-try /home/$(id -un)/.config/gtk-3.0 /home/$(id -un)/.config/gtk-3.0 --ro-bind-try /home/$(id -un)/.local/share/themes /home/$(id -un)/.local/share/themes --ro-bind-try /home/$(id -un)/.themes /home/$(id -un)/.themes --ro-bind-try /home/$(id -un)/.icons /home/$(id -un)/.icons EOF *** apparently, some tweaks may be needed, e.g. for another video device - bwrap-flatpak-info: $ > bwrap-flatpak-info cat <<EOF [Application] name=org.test.MiniBrowser EOF May I keep this open till the mechanics of the problem is nailed down?
sorry for the problem with the command above, diff: - $ > bwrap-args { cat | tr '\n' '\0'; } <<EOF + $ > bwrap-args tr '\n' '\0' <<EOF
Also skip the stray "GDKWEBKIT_FORCE_SANDBOX=0 bwrap" command (original that I gradually refined below that).
Somewhat minified bwrap-args: > bwrap-args tr '\n' '\0' <<EOF --die-with-parent --ro-bind /etc /etc --dev /dev --proc /proc --tmpfs /tmp --unsetenv TMPDIR --dir /run --ro-bind-try /var/lib /var/lib --symlink ../run /var/run --symlink ../tmp /var/tmp --ro-bind /sys /sys --ro-bind-try /usr /usr --ro-bind-try /lib /lib --ro-bind-try /lib64 /lib64 --bind-try /run/user/$(id -u) /run/user/$(id -u) --unshare-ipc --bind-try /home/$(id -un) /home/$(id -un) --dev-bind-try /dev/snd /dev/snd --ro-bind-try /usr/libexec/gstreamer-1.0/gst-plugin-scanner /usr/libexec/gstreamer-1.0/gst-plugin-scanner --ro-bind-try /usr/libexec/gst-install-plugins-helper /usr/libexec/gst-install-plugins-helper --dev-bind-try /dev/dri /dev/dri --dev-bind-try /dev/mali /dev/mali --dev-bind-try /dev/mali0 /dev/mali0 --dev-bind-try /dev/umplock /dev/umplock --dev-bind-try /dev/nvidiactl /dev/nvidiactl --dev-bind-try /dev/nvidia0 /dev/nvidia0 --dev-bind-try /dev/nvidia /dev/nvidia --dev-bind-try /dev/kgsl-3d0 /dev/kgsl-3d0 --dev-bind-try /dev/ion /dev/ion EOF In this form, it also supports setting GDK_BACKEND=x11 in the main "< bwrap-args" beginning command from [comment 2], and it exposes this paradox this whole seems to be about: - GDK_BACKEND=x11 -> nice fonts - GDK_BACKEND=wayland -> pixelated fonts On the same host, same session, same everything. I don't grok why this would happen. Can you advise, please?
Just added ~final iteration of the reproducing command also to original https://bugzilla.redhat.com/show_bug.cgi?id=1845743#c19: MINIBROWSER=$(which MiniBrowser 2>/dev/null \ || echo /usr/libexec/webkit2gtk*/MiniBrowser) WEBKIT_FORCE_SANDBOX=0 GDK_BACKEND=wayland bwrap \ --bind-data 0 /.flatpak-info \ --die-with-parent \ --dir /run \ --dev /dev \ --tmpfs /tmp \ --unsetenv TMPDIR \ --symlink ../run /var/run \ --symlink ../tmp /var/tmp \ --proc /proc \ --ro-bind /sys /sys \ --ro-bind /etc /etc \ --ro-bind-try /var/cache /var/cache \ --ro-bind-try /var/lib /var/lib \ --ro-bind-try /usr /usr \ --ro-bind-try /lib /lib \ --ro-bind-try /lib64 /lib64 \ --bind-try "/run/user/$(id -u)" "/run/user/$(id -u)" \ --bind-try "/home/$(id -un)" "/home/$(id -un)" \ --dev-bind-try /dev/snd /dev/snd \ --dev-bind-try /dev/dri /dev/dri \ $MINIBROWSER <<-EOF [Application] name=org.test.MiniBrowser EOF
Each time you leave a new comment, I just get more confused. ;) Does this fix the problem or not: $ ln -s /etc/fonts/conf.d ~/.config/fontconfig ?
Although antialiasing can be configured in fontconfig, there are two ways to configure it: it could be configured to override desktop (cairo/GTK) font settings, or it could be configured to be overridden by the desktop font settings. The later is much more common. So my guess is that the desktop font settings are broken inside your sandbox. Try running this test program with your bwrap command... does it give a different result than when run on your host? // gcc `pkg-config --cflags --libs gtk+-3.0` test-antialiasing.c #include <gtk/gtk.h> int main (int argc, char **argv) { GtkSettings *settings; gint antialias; gtk_init (&argc, &argv); settings = gtk_settings_get_default (); g_object_get (settings, "gtk-xft-antialias", &antialias, NULL); switch (antialias) { case -1: printf ("CAIRO_ANTIALIAS_DEFAULT\n"); break; case 0: printf ("CAIRO_ANTIALIAS_NONE\n"); break; case 1: printf ("CAIRO_ANTIALIAS_SUBPIXEL or CAIRO_ANTIALIAS_GRAY\n"); break; default: g_assert_not_reached (); } return 0; }
re [comment 7] Thanks for bearing with me, Michael :-) > Does this fix the problem or not: Sorry, that was really infamous late-night false start :-/ You see there are quite some moving parts in the picture, so brain farts on my side were likely imminent in this hassle to get one particular "detail" right. > Try running this test program with your bwrap command... > does it give a different result than when run on your host? Thanks a lot, if that's what WebKitGTK uses for decisions exclusively, we are down at the root cause: Outside (sway/Wayland): > CAIRO_ANTIALIAS_SUBPIXEL or CAIRO_ANTIALIAS_GRAY inside bwrap[*]: > CAIRO_ANTIALIAS_NONE but repeated with GDK_BACKEND=x11: > CAIRO_ANTIALIAS_SUBPIXEL or CAIRO_ANTIALIAS_GRAY But hey, correct me if I am wrong, XFT (as in gtk-xft-antialias) is an X extension only thing, hence it shall not be the main deciding factor when running solely under Wayland? Might it be the reason? My worries would then be that there's no such a generic counterpart in Wayland, perhaps only compositor specific ones. Anyway, I'll keep digging, this moved me forward a lot, indeed! [*] modification: - $MINIBROWSER <<-EOF + --ro-bind ./test-antialiasing /bin/test-antialiasing \ + /bin/test-antialiasing <<-EOF
Ok, I see more of the context now, which makes me think that it's unlikely this would be somehow unique to WebKitGTK + bubblewrap (IIUIC, Flatpak uses that very same sandboxing backend): https://github.com/flatpak/flatpak/issues/2861 The only difference is that with Flatpak, you actively ask for isolation to happen (hence can be reasonably sure that any problems inside do not necessarily map to your installation outside), whereas with Evolution, you naturally expect all-native (and therefore see something botched as a pressing question mark generator possibly affecting whole system in some way, as was in my case). The other, perhaps important difference, is that the process of sandboxing is fully at hands of WebKitGTK in this case, would any interim workaround be agreeable if applicable. Strangely, I've already independently tried to move to their proper locations (with installing full-blown gsd): /usr/share/glib-2.0/schemas/org.gnome.settings-daemon.plugins.xsettings.gschema.xml /usr/share/glib-2.0/schemas/org.gnome.settings-daemon.enums.xml (note the dependency, wasn't discussed with that Flatpak issue) files extracted from "dnf download gnome-settings-daemon.x86_64", followed with "glib-compile-schemas /usr/share/glib-2.0/schemas/". I even have the key-value inserted like this: $ gsettings get org.gnome.settings-daemon.plugins.xsettings antialiasing > 'grayscale But that alone didn't appear to help.
So I can close this again, since there are no upstram ramifications. Only upstream ones, if any. So my previous [comment 2] was close: > Strangely, I've already independently tried to move to their > proper locations (with installing full-blown gsd): > > /usr/share/glib-2.0/schemas/org.gnome.settings-daemon.plugins.xsettings.gschema.xml > /usr/share/glib-2.0/schemas/org.gnome.settings-daemon.enums.xml > > (note the dependency, wasn't discussed with that Flatpak issue) > > files extracted from "dnf download gnome-settings-daemon.x86_64", > followed with "glib-compile-schemas /usr/share/glib-2.0/schemas/" As usual, there was a missing piece of a puzzle, and that was: > systemctl --user restart xdg-desktop-portal{gtk,} Side note: this step is not enforceable/cannot be automated in post-install scripts, unless one iterates through all the logind user sessions explicitly (feels extremely nasty), correct? It fixes the problem for me! Closing here and will follow up at particular downstream, as there are quite some enhancements to make at the packaging level. One last thing regarding code in [comment 8]: Michael, do you know whether there is something similar (perhaps more extensive) that would accompany some of the respective packages (pango, cairo, gkt3...). If not, you see it was actually rather handy for troubleshooting, and you perhaps keep tabs on various projects where it might be added to be readily usable at distro level eventually. What do you think? It doesn't look the same as gsettings thing, correct?
And btw. I think I proved that MiniBrowser actually does _not_ perform the sandboxing by default per [comment 2]. Not sure whether it is expected or not, perhaps some clarification at least in the form of titlebar changed from "X" to "X [sandboxed]" or so, is appropriate.
(In reply to Jan Pokorný [poki] from comment #11) > One last thing regarding code in [comment 8]: > > Michael, do you know whether there is something similar (perhaps > more extensive) that would accompany some of the respective packages > (pango, cairo, gkt3...). If not, you see it was actually rather > handy for troubleshooting, and you perhaps keep tabs on various > projects where it might be added to be readily usable at distro > level eventually. What do you think? It doesn't look the same > as gsettings thing, correct? I don't know, but probably not. I just wrote that test after looking at Source/WebCore/platform/graphics/gtk/GdkCairoUtilities.cpp to see how WebKit computes whether or not to use antialiasing. (In reply to Jan Pokorný [poki] from comment #12) > And btw. I think I proved that MiniBrowser actually does _not_ perform > the sandboxing by default per [comment 2]. Not sure whether it is > expected or not, perhaps some clarification at least in the form > of titlebar changed from "X" to "X [sandboxed]" or so, is appropriate. Right, in MiniBrowser you have to manually enable the sandbox. Probably that no longer makes sense, but that's an issue for another bug, another day....
> Right, in MiniBrowser you have to manually enable the sandbox. > Probably that no longer makes sense, but that's an issue for another bug, > another day.... It's there so this won't get forgotten forever: [bug 213174]. Given the fonts used to be alright here all the time, I suspect the sandboxing was actually never activated, if I am not mistaken (again), not even with enablement via variable (and that was the reason I was force to devise reproducer using raw bwrap ... or I don't have any other explanation).
*** Bug 222883 has been marked as a duplicate of this bug. ***