[Bug]: Fonts look terrible #4571
Comments
|
What desktop environment/ window manager are you using? |
|
Xfce 4.16/Xfwm4 |
|
is |
|
|
Do you have |
|
|
Oh! This is pre-Gnome 40.0 release, then you need to install also The alternative is to copy the schema from |
Installed Native: Flatpak: |
|
Did you try to restart the system? Or at least |
Same result. XFCE does not start |
No, you don't need the Gnome Settings daemon running.
I'm not sure what's going on. Maybe try restarting the portals manually from the command-line and look for errors. Something like |
|
I've attached the output of both commands below, thanks for working on this. |
|
I'm not sure if this going to help, but Note that some apps do not split on colon as expected, or have a bad implementation of a value matching logic, though from my experience they are very few, and it's easy to override the variable value for these apps with Flatpak. Non-related, but clearly the Debian maintainer is wrong here for not including PipeWire as a runtime dependency of |
|
No luck with that screenshot below.
|
|
Also it seems XFCE does set it properly? In a fresh terminal: |
XFCE does not provide XDG Portal implementations, so unless its developers don't care about their users and Flatpak, as a desktop environment it should set the GTK portal implementations correctly. This means one of these two:
I'm running Sway, and last time I tried, I still needed to add
Then I'm not sure what's going on, and I'm not using Debian. |
It's a Recommends (via the Pipewire client library), which is "a strong, but not absolute, dependency" and "would be found together with this one in all but unusual installations" (Debian Policy §7.2). If you don't install Recommends, then you can expect some features not to work, including major features. |
That would not be true: XFCE is not a GNOME variant, and lots of things that would work in a GNOME session don't work in XFCE (in particular, various GNOME-specific portal implementations talk to GNOME Shell, but XFCE doesn't use GNOME Shell, so that can't work).
If XFCE developers want apps running on XFCE to use the However, if there is no backend that matches From the logs that @konomikitten provided, the So changing The next thing to check is the settings that The usual reason for "fonts look terrible" is antialiasing being disabled. The antialiasing setting is in the What is that setting set to? |
|
Other influential settings in In versions of GNOME before 40, font settings like those were in the Unfortunately, which set of settings will actually be used depends on the version of GTK that is used by the specific Flatpak app you're using, and whether it's using X11 or Wayland. Most Flatpak apps use the version of GTK from the freedesktop.org SDK, but I think Firefox is special and might be using its own binary build of GTK. |
Nothing it doesn't exist. |
|
Also just a reminder for everyone the work around I found was:
|
|
I decided to go have a poke around the GitLab for XFCE, is this issue helpful at all for this situation? https://gitlab.xfce.org/xfce/xfce4-settings/-/issues/179 |
|
I think the problem here might be similar to https://gitlab.xfce.org/xfce/xfce4-settings/-/issues/179, although not 100% the same (different settings keys are involved). When GNOME (specifically gnome-control-center or gnome-tweaks) configures font settings, it stores them using gsettings (which is an abstract interface for storing configuration, and in practice they end up in the dconf database). In recent versions of GNOME it's under When used in Flatpak apps (like Firefox in your case), GTK expects to be able to get font settings from the settings portal, which has an interface similar to gsettings. However, when you use XFCE tools to configure font settings, that probably doesn't store them via gsettings, at least not with the same keys that GTK is expecting: instead, it stores them in whatever way XFCE uses for settings (I think XFCE already had its own thing before gsettings/dconf existed?), and then some XFCE component analogous to GTK can read those settings from various places: when using X11 it can get them from Xsettings, when using Wayland and not in a Flatpak it can get them from gsettings (implemented by dconf), and when in a Flatpak I think it unconditionally ignores Xsettings and asks the settings portal instead. So, one possible way to get this stuff into Flatpak apps would be for XFCE to write the settings into
Presumably the fontconfig configuration on your host system enables at least some level of antialiasing and/or hinting. We're looking at GTK settings to enable these instead, for these reasons:
|
|
I don't intend to keep the work around I just went back to native Firefox for now, I'll probably wait awhile and come back around to Flatpak or maybe try it again at some stage if I am not using XFCE. Thanks everyone for all the help. |
As a more minimal workaround, you basically only need |
I had the same issue with plain Gnome 42, Wayland, Debian 11 and this works for me also. |
|
yessss!!! working for Debian testing, Gnome 43, Wayland |
This introduced another issue: Non-latin (especially CJK) languages' font packages usually include a fontconfig to ensure font fallback and locale-specific variant configurations are applied to work as expected. (Example from Arch Linux With the current behavior, it's very likely for users of those locales have a broken font rendering e.g. Using bitmap fonts or low quality fonts instead of the supplied one / Inconsistent font family and/or wrong locale-specific glyph on the same text element. Also, some users bind their generic font family names ( As stated above and based on the current situation, I suggest to reconsider the solution on fontconfig. |
|
One user on reddit recommended to remove the metapackages xfonts-100dpi and xfont-75dpi and it works. |
I confirm this is the ONLY correct solution to this issue. I will explain in another comment thread. |
The only correct solution to this issue is to remove x11 fonts.This issue occurs mostly in Debian and openSUSE based distros with x11 fonts installed. Fedora and RHEL-based distros are usually not affected by default. The issue happens due to the following:
For example, in a Wikipedia webpage, the title of the topic uses 'Linux Libertine', 'Georgia', 'Times', serif; in that order. In default Debian and openSUSE installation Linux Libertine and Georgia are not installed. The next candidate is Times which is provided by an old x11 bitmap font. In Fedora, Times as x11 font is not present, therefore it fallbacks to serif which the flatpak runtime environment provides as TeX Gyre Termes. What we need is to remove x11 fonts so we can have that fallback mechanism just like with other distros. In Debian remove x11 fonts using: In openSUSE based distros, use this code: |
|
In Debian remove x11 fonts using: sudo apt remove xfonts-base xfonts-100dpi xfonts-75dpi This is about to remove task-desktop, xorg x11-session-utils, x11-apps and so on and so on. |
Some of these packages are meta packages. I have Debian 12 gnome/debian 12 testing gnome on several devices and have had no problems on wayland. If you are afraid and don't want to do this you can try the other solutions listed above. Such as:
|
|
Currently running Cinnamon/Wayland on Debian bookworm, and also had this issue. If I recall correctly, the issue was also present in plain Gnome. Native firefox on this setup did not have this issue. I removed I ended up using a variant of the solution proposed by @behrmann. Fonts now look normal. |
|
On debian next/testing (trixie) this problem no longer exists. If I have time later I will still check on a fresh install of debian 12.1. |
Wow, indeed, I'm surprised and it must be quite new ! |
|
Interestingly, this problem still exists in opensuse thumbleweed. |
|
Ok debian 12.1 continues to have this problem then I don't know if this problem can be closed but it is good that it is finally solved in debian next. |
|
I have the same issue in Debian 12, kernel 6.1.0-12, and Firefox 117.0 (64-bits) via Flatpak. The work around of @konomikitten (thanks) still work:
and then:
Then restart the browser. But, making this, your config fonts will not updated with your fonts config of your distro in the future. |
|
Was seeing the same thing on Void Linux with KDE. Installing Not a major distraction as that app gets rarely used in my case, but odd that the issue remains. |
Can confirm as of nov 7/2023. Solved it by adding this line to ~/.var/app/org.mozilla.firefox/config/fontconfig/fonts.conf
|
Kubuntu 23.10 update lead me here again with weird looking fonts and cursors, and of course it offers only KDE Plasma 5.27.8 , the font config doesn't seem to help, and it also wouldn't help with the cursor also behaving oddly. For anyone still on Kubuntu 23.04, maybe stick to that version while it's still supported, it was actually pretty decent especially for Flatpak heavy usage. Edit: Found a solution that might be Kubuntu specific. Edited Not sure if restarting both is excessive, but after that and reopening affected programs, Flatpak packaging no longer makes them visually a "second-class citizen". |
|
In Plasma 5.27.8 I believe you can simply use Flatseal to disable the "socket=wayland" for any needed application and it will revert back to x11 fonts. It solved the issue for me with Parabole/Flatseal/Warpinator. It's neat and reversible any time Plasma 5.27.9 drops. |
This: #4571 (comment) works!
|
Thank You! |
Checklist
Flatpak version
1.12.2
What Linux distribution are you using?
Debian
Linux distribution version
Debian GNU/Linux 11 (bullseye)
What architecture are you using?
x86_64
How to reproduce
Expected Behavior
For fonts to be rendered as the native version of Firefox does.
Actual Behavior
The fonts on GitHub and some other websites look terrible.
Additional Information
If I do the following work around fonts for Firefox are fixed but font settings won't be updated when my distribution updates them.
cp /etc/fonts/conf.d/*.conf ~/.var/app/org.mozilla.firefox/config/fontconfig/conf.d/The text was updated successfully, but these errors were encountered: