CJK Font Rendering Issues w/ Flatpak Browsers

[Eoin-ONeill-Yokai]

Describe the bug On a recent version, I seem to no longer have CJK (Chinese, Japanese and Korean) fonts rendering as expected when running browsers installed via flatpak. The browsers tested so far are Firefox, Vivaldi and Chromium, of which only Chromium renders CJK characters correctly. I do remember this working previously on Silverblue with the same layered packages, but I cannot find the specific version as I don't have it pinned.

In general, I feel that there should be more documentation focused on non-english font and input for silverblue.

To Reproduce Please describe the steps needed to reproduce the bug:

1. Install firefox or vivaldi via flatpak and run it.
2. Go to any webpage with CJK font, you'll notice tofu characters (blank boxes, often with characters inside.) Example page of Japanese content: https://fedibird.com/@ysd/109839348470538607

Expected behavior CJK font should render if cjk fonts are installed on the system.

Screenshots

OS version:

State: idle
BootedDeployment:
● fedora:fedora/39/x86_64/silverblue
                  Version: 39.20240210.0 (2024-02-10T00:38:06Z)
               BaseCommit: 665c2eab5bdc91bb41c61961e3a0f78fee9e029241d03d74e320792cbc8a9085
             GPGSignature: Valid signature by E8F23996F23218640CB44CBE75CF5AC418B8E74C
      RemovedBasePackages: firefox firefox-langpacks 122.0-5.fc39
          LayeredPackages: ckb-next ddcutil distrobox gamescope git git-lfs gnome-shell-extension-gsconnect google-noto-sans-cjk-fonts
                           htop langpacks-en nautilus-gsconnect openssl python3-pyusb realtime-setup rocm-hip syncthing vim vim-enhanced
                           vnstat

Additional context It could very well be that firefox is looking for a specific CJK package other than google-noto-sans-cjk-fonts. If this is the case, simply knowing which package I should install would be a good start.

[Eoin-ONeill-Yokai]

I should also add that this issue is also observable on system-level title bars when trying to view CJK content that changes the title bar. For example, with that same blog post above, I get the following fonts on the title bar:

[chrisawi]

You shouldn't need to layer any font packages for this. I don't have any here, and that page renders correctly in flatpak Firefox.

When you asked about this on Matrix, I thought you meant you were seeing empty boxes. Seeing codepoint boxes sounds more like it's selecting the wrong font than the cache issue I was thinking of.

As I asked before, please run flatpak run --command=sh org.mozilla.firefox, and then run fc-match -b ':charset=81ea' inside the sandbox. What is the file: line? You can also try it outside the sandbox for comparison.

Curiously, it uses different fonts here inside (DroidSansJapanese.ttf) and outside (NotoSansCJK-VF.ttc) the sandbox, but both fonts come from the Silverblue base image. I guess this is due to the absence of fontconfig xml configuration inside the sandbox.

[travier]

This is likely https://discussion.fedoraproject.org/t/chinese-font-issue-on-fedora-silverblue-39/100015/22 but I haven't had the time to investigate yet. Help appreciated.

See also:

• https://github.com/flathub/com.valvesoftware.Steam/issues/1070
• https://fedoraproject.org/wiki/Changes/Noto_CJK_Variable_Fonts

People suggested re-installing google-noto-sans-cjk-fonts to fix it.

[Eoin-ONeill-Yokai]

You shouldn't need to layer any font packages for this. I don't have any here, and that page renders correctly in flatpak Firefox.

When you asked about this on Matrix, I thought you meant you were seeing empty boxes. Seeing codepoint boxes sounds more like it's selecting the wrong font than the cache issue I was thinking of.

As I asked before, please run flatpak run --command=sh org.mozilla.firefox, and then run fc-match -b ':charset=81ea' inside the sandbox. What is the file: line? You can also try it outside the sandbox for comparison.

Curiously, it uses different fonts here inside (DroidSansJapanese.ttf) and outside (NotoSansCJK-VF.ttc) the sandbox, but both fonts come from the Silverblue base image. I guess this is due to the absence of fontconfig xml configuration inside the sandbox.

Mine reads file: "/usr/share/fonts/dejavu/DejaVuSans.ttf"(s)

[chrisawi]

Mine reads file: "/usr/share/fonts/dejavu/DejaVuSans.ttf"(s)

So it's using a font from the runtime, not from the host. Does this return anything when run inside the sandbox?:

fc-list | grep -Ei '(japanese|cjk)'

I only see that Droid Sans Japanese font. All the Noto CJK fonts are missing. My speculation is that whatever is keeping fontconfig from seeing those fonts here is also hiding Droid Sans Japanese for you.

[Eoin-ONeill-Yokai]

Mine reads file: "/usr/share/fonts/dejavu/DejaVuSans.ttf"(s)

So it's using a font from the runtime, not from the host. Does this return anything when run inside the sandbox?:

fc-list | grep -Ei '(japanese|cjk)'

I only see that Droid Sans Japanese font. All the Noto CJK fonts are missing. My speculation is that whatever is keeping fontconfig from seeing those fonts here is also hiding Droid Sans Japanese for you.

Running that command returns no output.

[chrisawi]

I managed to track down the problem on my end to the user fontconfig cache (~/.cache/fontconfig). Removing that directory restored the Noto CJK fonts inside flatpak. Unfortunately, I can't debug any further because I neglected to preserve the cache files. (I did save the ls -l output though.)

Please mv ~/.cache/fontconfig ~/.cache/fontconfig.save and then try running a flatpak app.

Also, inside that directory, what cache versions do you see? (.cache-8, .cache-9, etc.) The current flatpak runtime uses a newer version of fontconfig that uses cache version 9, whereas F39 is still using version 8. My cache directory had some .cache-9 files; I'm not sure where they came from.

[Eoin-ONeill-Yokai]

Please mv ~/.cache/fontconfig ~/.cache/fontconfig.save and then try running a flatpak app.

Awesome, that worked.

Yeah I see a bunch of .cache-7, .cache-8 and .cache-9 files. Any reason why something like this would happen? I noticed that the new directory only has .cache-8 files, but I'm not sure if there's a significance.

Anyway thanks for the help, at least now I have an idea of what was going wrong here.

[chrisawi]

Yeah I see a bunch of .cache-7, .cache-8 and .cache-9 files. Any reason why something like this would happen? I noticed that the new directory only has .cache-8 files, but I'm not sure if there's a significance.

F39's version of fontconfig only makes .cache-8 files, but I also had some .cache-9 files (37 in total). I do have a F40 toolbox, but the files were all dated 2023-04-18, far too old for any Fedora package. I must have been using fontconfig from git somehow (?).

Do you have any toolbox/distrobox containers with fontconfig 2.15?

Because of the cache version mismatch, each time you run a new flatpak app, it has to generate .cache-9 files for host fonts, but those should end up in ~/.var/app/<APP_ID>/cache/fontconfig, not ~/.cache/fontconfig.

I don't understand fontconfig in any detail, but I'd guess that only the .cache-9 files would be used by fontconfig 2.15 inside the flatpak sandbox. Figuring out where they came from might offer a clue as to the cause of the problem.

@tagoh Do you have any suggestions on how to proceed? (Summary: fontconfig user cache files seem to be preventing fontconfig 2.15 in the flatpak runtime from seeing certain host fonts installed in the ostree image).

[Eoin-ONeill-Yokai]

Do you have any toolbox/distrobox containers with fontconfig 2.15?

That would be it. I'm generally pretty good about creating a "virtual home" for all of my distrobox instances, so toolbox would be the likely culprit here. Maybe I have an older fedora version on the toolbox that interrupted my font config.

Well, at least I have a way to fix this again if it happens in the future.

[chrisawi]

Maybe I have an older fedora version on the toolbox that interrupted my font config.

AIUI, only a newer (i.e. F40) version with fontconfig 2.15 could have created the .cache-9 files. If you don't have any F40+ toolboxes (or another distro with that fontconfig version) they must have come from somewhere else.

If you still have the old cache files, you could try only restoring the .cache-9 ones to see if that makes it break again.

[tagoh]

Nothing more than removing broken cache files. You may tried a development version of fontconfig before directly or indirectly.

It may be time to reconsider caches. Hmm.

[Peque]

Deleting the cache worked perfectly. :blush:

[tagoh]

Please note that this workaround means there was something caused this broken cache issue. If they still use older and broken fontconfig somewhere else, and are going to update cache for some reason, you may see same issue again.

[Peque]

@tagoh Yeah, I wasn't suggesting to close this issue as solved. There are probably many users living with this issue right now. I, for example, lived with it for several days, hoping for a fix in some system/Firefox update. It was only after all these days that the annoyance overcame my laziness and I searched for a solution online (fortunately I don't use these fonts that often). :smile:

[PVermeer]

Deleting ~/.cache/fontconfig also worked for my issue on 'Bazzite' gnome image that I'm testing out.

My layered vscode install would not display some special character, in my case the ➜ character. This happened in open files and the terminal. I did however tried the flatpak version before I installed the native app (layered).

So it might not be a flatpak issue.

[ghost]

I faced a similar issue but with Bangla font rendering. I have found out that running VSCodium would generate the ~/.cache/fontconfig folder Otherwise the folder simply doesn't exist even when using other apps

Leading me to believe this is a Chromium/CEF-related issue.

[tagoh]

Thank you for useful information. There might be more but that sounds like VSCodium needs to be rebuilt with 2.15 to get rid of this breakage at least. Please report it to https://github.com/flathub/com.vscodium.codium (I assume it is a flatpak app and from flathub? If not, reread it as appropriate).

[ghost]

Thank you for useful information. There might be more but that sounds like VSCodium needs to be rebuilt with 2.15 to get rid of this breakage at least. Please report it to https://github.com/flathub/com.vscodium.codium (I assume it is a flatpak app and from flathub? If not, reread it as appropriate).

I ran VSCodium from a Fedora 39 distrobox I installed it from here : https://github.com/VSCodium/vscodium/releases/tag/1.87.0.24060 the el7 rpm package

I'll let the devs know, but there should be further investigation whether this issue is only limited to VSCodium or if it affects other Chromium/CEF apps too.

[ghost]

I also have samples of the initial problematic fontconfig folder and a new one that didn't have an issue. But it seems that deleting the initial fontconfig folder resolved the issue completely, and if I later restored the initial fontconfig folder to it's usual ~/.cache/fontconfig location the issue didn't resurface

[tagoh]

All the cache files, including system caches has to be same timestamp when you've ever tried. otherwise cache files you've restored may considered as outdated.