Linux
Welcome to c/linux!
Welcome to our thriving Linux community! Whether you're a seasoned Linux enthusiast or just starting your journey, we're excited to have you here. Explore, learn, and collaborate with like-minded individuals who share a passion for open-source software and the endless possibilities it offers. Together, let's dive into the world of Linux and embrace the power of freedom, customization, and innovation. Enjoy your stay and feel free to join the vibrant discussions that await you!
Rules:
-
Stay on topic: Posts and discussions should be related to Linux, open source software, and related technologies.
-
Be respectful: Treat fellow community members with respect and courtesy.
-
Quality over quantity: Share informative and thought-provoking content.
-
No spam or self-promotion: Avoid excessive self-promotion or spamming.
-
No NSFW adult content
-
Follow general lemmy guidelines.
view the rest of the comments





My guess is this has nothing to do with KDE and is a font and/or
fontconfigissue. Figure out which default fonts your apps use, then see what they get substituted for for different character sets. I have never done the latter, but I know it's possible. The former isfc-match "default font"There's a lot
fontconfigcan do to influence what actual fonts apps end up choosing.This seems to be correct.
Also seems to be correct.
I skimmed through the primer and checked whats on the default fontconfig config:
I tried removing "Synthetic emboldening" here but it doesn't seem to change anything so I put it back. I also tried removing
fonts.confbut it still doesn't change anything. My gut feeling is that there is a fontconfig config somewhere changing the way Noto Sans CJK is being rendered in KDE/QT. I just couldn't figure out where or what. The fonts themselves are fine in LibreOffice so I don't think there's any issue with the package.Now reading through the primer again, I checked the configs in
/etc/fonts/conf.dand found all the configs there. There's a lot so I'll look through it and see which one might be changing the way CJK is rendered.That's not what I meant. You mention differences between dolphin (not ok) and Firefox (ok). So you need to check what they use as default fonts respectively. If there are differences you know what to do.
They're both already using Noto Sans. IIRC Firefox has its own way of rendering fonts so it's likely a KDE/Qt font rendering issue.
For all/relevant encodings?
Have you considered that maybe Noto developers made a choice there, to render Kanjoi thicker than Chinese characters? I know, that doesn't explain why Dolphin would render them in a way that is more pleasing to you. Have you tried using other fonts altogether?
As far as I understand (Firefox Font settings, using fc-match, fontconfig, etc), it's properly configured.
Assuming you meant Kana (and Hangeul as well), I'm not sure why they would do that because it makes it appear so inconsistent.
You mean Firefox (and the Firefox file picker) because Dolphin doesn't render it well at all. I actually tested a few things. I uninstalled the Noto Sans CJK package to see what other fonts it would fall back to. It falls back to Droid Sans and it looks pretty good in my opinion. It doesn't become thick like Noto Sans CJK. So maybe it's really something intentionally done by the Noto developers.
BUT Noto Sans CJK looks fine in Firefox, LibreOffice, and GIMP.
A few more things I tested:
~/.config/fontconfig/fonts.confto Droid Sans Fallback (I also tried setting it to Noto Sans CJK Light), then confirming changes usingfc-match. Restarted and clearedfc-cache. Dolphin and Strawberry did not respect my changes. Nautilus does though. (Qt issue?)Something tells me it's a KDE or Qt thing, or maybe it's a Fedora thing? It works fine with GNOME and GTK apps like Nautilus. This is beyond what I know at this point so I'll just post this over to the Fedora forums.
Qt does render fonts differently than GTK.