Fonts look different in some flatpaked Java programs

[luni3359]

Linux distribution and version

KDE Neon User Edition 5.20 x86_64

Flatpak version

1.10.1

Description of the problem

Fonts are showing aliased in some flatpaked Java programs. Running these jars without a sandboxed environment results in proper, smoothed-out fonts.

First reported in the repo where I saw this problem occur, but down the line the maintainer told me the issue wasn't on their flatpak, not on their machine.
guihkx/com.teamshiginima.ShiginimaLauncher#1

Here's a picture of how the fonts differ (On org.jdownloader.JDownloader):

Another picture. This time the proportions of the windows look different. Top is native, bottom flatpak.

The maintainer told me they didn't experience issues on their system running GNOME.

Steps to reproduce

1. Run program
2. Program fonts are different

[zocker-160]

any updates on this?

I am experiencing exactly the same issue on Kubuntu with every Flatpaked Java application.

[luni3359]

It's still bad. I think there's a fonts issue with flatpak as a whole because if you try to run any flatpak with a Japanese locale, a different font is used which makes it impossible to read sometimes because characters are replaced with a square.
Here's some proof.

[zocker-160]

I think this should be reported to the openjdk extension repo?

[soredake]

Install xdg-desktop-portal-gtk and do sudo flatpak override --filesystem=xdg-config/fontconfig:ro

[zocker-160]

thanks you for this suggestion, sadly it does not solve the issue.

The text does look different, so it does something, but it is nowhere near where it should be.
here an example:

native:

flatpak default permissions:

flatpak with --filesystem=xdg-config/fontconfig:ro:

[soredake]

@zocker-160 can you check if that gtk portal is running?

[zocker-160]

@soredake I have xdg-desktop-portal-gtk installed and QDbusviewer does show me an org.freedesktop.impl.portal.desktop.gtk entry, so I think it is running and working

EDIT: I want to add, that this issue can be reproduced quite easily, all you need is a Kubuntu VM with literally any Java application inside Flatpak.

[soredake]

@zocker-160 to clarify, your problem is the used font(s) in jdownloader flatpak is different from the host?

[zocker-160]

@soredake not only JDownloader, it is true for any Java application running inside Flatpak.

As you can see on the images above, it is not only a different font, but also the anti aliasing does not seem to work properly. In terms of the last image, even the text color is different.

[soredake]

@zocker-160 there's three bugs here

1. KDE don't write AA settings to fontconfig file https://bugs.kde.org/show_bug.cgi?id=416140, you need to disable AA in kde settings and enable it again, then press apply (this need to be done once after installing system until it's fixed)
2. Flatpak does not read your host font settings, it uses font settings from freedesktop-sdk by default Expose host fontconfig conf.d? #1563, you can fix this by doing (example for noto fonts and hack (as they are used in kubuntu by default), if you want another fonts to be used, you need copy .conf files from /etc/fonts/conf.d):

mkdir $HOME/.config/fontconfig/conf.d
cp /etc/fonts/conf.d/*noto* /etc/fonts/conf.d/*hack* "$HOME/.config/fontconfig/conf.d"

3. Flatpak does not read your user fontconfig settings [feature] Expose xdg-config/fontconfig to sandbox by default #3947, to fix this do flatpak override --user --filesystem=xdg-config/fontconfig:ro, this will give access to ~/.config/fontconfig/fonts.conf and ~/.config/fontconfig/conf.d

After doing all those three, fonts should look as they need to be.

Additionally you can try flatpak override --user --env=_JAVA_OPTIONS='-Dawt.useSystemAAFontSettings=on -Dswing.aatext=true' or flatpak override --user --env=_JAVA_OPTIONS='-Dawt.useSystemAAFontSettings=on'

[zocker-160]

@soredake thank you a lot for looking into this, I highly appreciate it.

All 3 issues you listed to me sound like missing file permission, but I tried with --filesystem=host which should include everything above but it still looks the same.

I also copied the entire conf.d folder from /etc/fonts to ~/.config/fontconfig/conf.d with still no difference.

-Dswing.aatext=true does actually do something, it looks aliased now which is something I guess.

To me this sounds like some fundamental issue with Flatpak, since with full access to the host files, the application should have everything it needs.

[soredake]

@zocker-160 --filesystem=host will not give access to /etc as flatpak have it's own /etc.

Can you show me output of systemctl --user status xdg-desktop-portal-gtk.service and cat ~/.config/fontconfig/fonts.conf

[zocker-160]

@soredake

--filesystem=host will not give access to /etc as flatpak have it's own /etc.

understood, but I copied the entire folder to ~/.config/fontconfig

[zocker-160]

oops I pressed enter too soon, will post outputs any moment

[soredake]

@soredake

--filesystem=host will not give access to /etc as flatpak have it's own /etc.

understood, but I copied the entire folder to ~/.config/fontconfig

I know, just saying that sharing host /etc is not supported #4525

[zocker-160]

here my outputs:

$ systemctl --user status xdg-desktop-portal-gtk.service
● xdg-desktop-portal-gtk.service - Portal service (GTK/GNOME implementation)
     Loaded: loaded (/usr/lib/systemd/user/xdg-desktop-portal-gtk.service; static)
     Active: active (running) since Sun 2022-09-11 10:25:52 CEST; 6h ago
   Main PID: 3025 (xdg-desktop-por)
      Tasks: 4 (limit: 38257)
     Memory: 4.9M
        CPU: 117ms
     CGroup: /user.slice/user-1000.slice/[email protected]/app.slice/xdg-desktop-portal-gtk.service
             └─3025 /usr/libexec/xdg-desktop-portal-gtk

Sep 11 10:25:52 Zocker-KDE systemd[2838]: Starting Portal service (GTK/GNOME implementation)...
Sep 11 10:25:52 Zocker-KDE systemd[2838]: Started Portal service (GTK/GNOME implementation).

$ cat ~/.config/fontconfig/fonts.conf
<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>
 <dir>~/.fonts</dir>
 <match target="font">
  <edit mode="assign" name="hinting">
   <bool>true</bool>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="hintstyle">
   <const>hintslight</const>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="rgba">
   <const>rgb</const>
  </edit>
 </match>
 <match target="font">
  <edit mode="assign" name="antialias">
   <bool>true</bool>
  </edit>
 </match>
</fontconfig>

I know, just saying that sharing host /etc is not supported #4525

understood yeah you are right, good to know and good point

[soredake]

@zocker-160 yeah, everything is setup correctly. If your fonts are different in flatpak'ed java apps that can mean three things:

1. Maybe internal flatpak fontconfig files overriding your fonts (as file which loads your settings are lower priority than flatpak internal configs)
   

2. Probably different java versions render/read font config differently. You can report your problem here https://github.com/flathub/org.freedesktop.Sdk.Extension.openjdk17

Jdownloader on host uses 1.8.0 (really old) java, flatpak version uses 17 (recent) java, other flatpaked apps probably use newer (or older) java than on host too. Fonts at least should be antialiased if you done flatpak override --user --filesystem=xdg-config/fontconfig:ro

For me (at least in fedora kde vm), fonts in jd2 are same in host and flatpak, and AA working after that command, but rendering is different.

[zocker-160]

@soredake I did some further testing with one of my own applications which uses Java 17.

And while it does indeed look very similar (way more similar than with a Java 8 or 11 project) to native, it is absolutely not the same.

native:

flatpak:

Now I hear you saying, that one would need to pixel peep in order to see the difference, I agree, BUT this is more a fundamental question, because IMO packaging a software in a different format should absolutely never change how the application looks.

This does not happen for DEB, RPM or Appimage for that matter, so it shouldn't for Flatpak either.

If you want to try yourself, this is my Flatpak manifest I used for testing:
com.github.zocker_160.AdK-BIN-Editor.txt

[soredake]

@zocker-160 don't forget that flatpak is not only a package format but also have sandboxing (that for now causes problems with integration with system fonts), you can as i said report problem here, maybe java sdk maintainer can help you, or complain here #1563
#3947

[zocker-160]

don't forget that flatpak is not only a package format

@soredake yes I know and I highly appreciate the sandboxing as well. I hope the Java SDK maintainers know better what is going on and how to potentially fix it.

Thank you very much for your time and effort to help out with this issue.

[soredake]

native:

flatpak:

Judging by screenshots it looks like another font is used, so my theory about flatpak internal fonts taking precedence is maybe right, one idea is to remove files from /var/lib/flatpak/<path to runtime's conf.d folder> and leave only 50-flatpak.conf, this will in theory will load only your fonts.

[zocker-160]

oh I see, inside the runtime that I am using org.freedesktop.Platform there are a lot of fonts placed in /etc/fonts/conf.d which are completely different from the ones I have on my host.

How can I get rid of them for testing?

[soredake]

@zocker-160 I'm not sure if this will work, but you can try:

1. find fonts/conf.d folder of your runtime find /var/lib/flatpak -type d -path '*/fonts/conf.d'
2. delete all files except 50-flatpak.conf and 50-user.conf
3. copy all host's /etc/fonts/conf.d content to $HOME/.config/fontconfig/conf.d

After you've done experimenting you can repair runtimes with flatpak repair

[soredake]

Or you can change priority of 50 files to 100 to make them load your fonts last overriding flatpak defaults.

[soredake]

Another option is to create custom runtime and run your app with flatpak run --runtime=<your runtime>
#4042 (comment)

[zocker-160]

alright so I did some further testing today and your suggestion sadly makes things even worse, now the fonts are not only ugly but also very small.

I also tried copying the /fonts/conf.d folder from the host into the runtime and that seems to be the most promising so far, it looks the closest to native in terms of font rendering, but the font used is still different.

Maybe I need to copy the actual fonts from the host also into the runtime?

[soredake]

Maybe I need to copy the actual fonts from the host also into the runtime?

You can try this, 50*.conf files from flatpak should load your host fonts if IIRC, dunno why it's not working.

[zocker-160]

@soredake I managed success!!!

I am sure this "solution" is ugly as fk and IMO this should be addressed by flatpak devs, no user should have to do any of this.

Here is what I did:

• reset all flatpak runtimes, no changes are needed there (flatpak repair)
• mv ~/.config/fontconfig/fonts.conf ~/.config/fontconfig/fonts.conf.bak
• cp -r /etc/fonts ~/.config/fontconfig
• cp -r /usr/share/fonts ~/.config/fontconfig
• add <dir>~/.config/fontconfig/fonts</dir> to fonts.conf

I think the main issue is, that the Flatpak cannot access the fonts inside /usr/share/fonts and /usr/local/share/fonts

[zocker-160]

adding an overwrite for /usr/share/fonts does not work, the folders have completely different contents

on my host:

$ ls -l /usr/share/fonts
insgesamt 36
drwxr-xr-x  2 root root 4096 Aug 13 13:22 cmap
drwxr-xr-x  2 root root 4096 Aug 13 13:22 cMap
drwxr-xr-x  3 root root 4096 Jun 12  2021 eot
drwxr-xr-x  6 root root 4096 Jun 12  2021 opentype
drwxr-xr-x  3 root root 4096 Jun 12  2021 svg
drwxr-xr-x 62 root root 4096 Aug 13 13:34 truetype
drwxr-xr-x  5 root root 4096 Nov  4  2020 type1
drwxr-xr-x  3 root root 4096 Jun 12  2021 woff
drwxr-xr-x  6 root root 4096 Jul 31  2020 X11

inside flatpak:

$ ls -l /usr/share/fonts/
insgesamt 28
drwxr-xr-x 2 nfsnobody nfsnobody 4096  1. Jan 1970  dejavu
drwxr-xr-x 2 nfsnobody nfsnobody 4096  1. Jan 1970  gnu-free
drwxr-xr-x 2 nfsnobody nfsnobody 4096  1. Jan 1970  google-crosextra-caladea
drwxr-xr-x 2 nfsnobody nfsnobody 4096  1. Jan 1970  google-crosextra-carlito
drwxr-xr-x 2 nfsnobody nfsnobody 4096  1. Jan 1970  liberation-fonts
drwxr-xr-x 2 nfsnobody nfsnobody 4096  1. Jan 1970  noto-emoji
drwxr-xr-x 2 nfsnobody nfsnobody 4096  1. Jan 1970  tex-gyre

I think this is the key issue here.

[soredake]

I think the main issue is, that the Flatpak cannot access the fonts inside /usr/share/fonts and /usr/local/share/fonts

Your host fonts are mounted at /run/host/fonts/ which should be loaded with right configuration (/etc/fonts/conf.d/50- 50-flatpak.conf), but, i'm not an expert with fontconfig.

[RalfJung]

FWIW this does not just affect Java applications. I am seeing this in vscodium, where the text in flatpak is somehow wider than in a vscode running in firejail.

flatpak override --user --filesystem=xdg-config/fontconfig:ro helped though. :) Something like that should be the default.