[stone@arch conf.avail]$ sudo fc-match -s | grep CJK
NotoSansCJK-Regular.ttc: "Noto Sans CJK SC" "Regular"
NotoSerifCJK-Regular.ttc: "Noto Serif CJK JP" "Regular"
NotoSerifCJK 默认还是 Noto Serif CJK JP
Git Clone URL: | https://aur.archlinux.org/noto-fonts-cjk-vf.git (read-only, click to copy) |
---|---|
Package Base: | noto-fonts-cjk-vf |
Description: | Google Noto Japanese variable fonts |
Upstream URL: | https://www.google.com/get/noto/ |
Licenses: | custom:SIL |
Conflicts: | noto-fonts-cjk |
Provides: | noto-fonts-cjk |
Submitter: | tinywrkb |
Maintainer: | tinywrkb |
Last Packager: | tinywrkb |
Votes: | 4 |
Popularity: | 0.000034 |
First Submitted: | 2021-07-26 14:38 (UTC) |
Last Updated: | 2022-08-07 09:34 (UTC) |
[stone@arch conf.avail]$ sudo fc-match -s | grep CJK
NotoSansCJK-Regular.ttc: "Noto Sans CJK SC" "Regular"
NotoSerifCJK-Regular.ttc: "Noto Serif CJK JP" "Regular"
NotoSerifCJK 默认还是 Noto Serif CJK JP
@tinywrkb, I can confirmed font weight issue of Qt was fixed in Qt 6.7.
Hey, this is a more of a request, but can you make packages for the static version of the font? The variable version of the font feels a lot more blurry compared to the static ones on my low-res monitor.
@rapiz, thanks for confirming that there's an issue.
I don't have the time to look into this ATM, to test in a KDE environment, and to try to reproduce.
I added this to my todo list, but it's unlikely I will get to it any time soon.
Consider reaching out to a KDE dev. There should be a couple of relevant Matrix rooms that you can drop by.
If you can't or don't have the time, then that's also alright.
I encountered the same issue as @Coelacanthus
KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.6 Graphics Platform: X11 fontconfig: 2:2.14.0-1 freetype2: 2.12.1-1 No user fonts-config files or local.conf System fonts set to Noto Sans
After switching to the language-specific OTFs, the issue was resolved. I think it may relate to Qt handling variable fonts.
I remembered once there were packages about language-specific OTFs but I can't find them now.
@Coelacanthus I can't say I notice such a problem.
I do have the following in my $XDG_CONFIG_HOME/fontconfig/fonts.conf
, and I mostly need Chinese (Simplified) and Korean characters rendering in the webbrowser, Fcitx5, and Electron apps.
<alias>
<family>sans-serif</family>
<prefer>
<family>Noto Sans</family>
<family>Noto Sans CJK SC</family>
<family>Noto Color Emoji</family>
<family>Noto Emoji</family>
</prefer>
</alias>
<alias>
<family>serif</family>
<prefer>
<family>Noto Serif</family>
<family>Noto Serif CJK SC</family>
<family>Noto Color Emoji</family>
<family>Noto Emoji</family>
</prefer>
</alias>
<alias>
<family>monospace</family>
<prefer>
<family>Noto Sans Mono</family>
<family>Noto Sans Mono CJK SC</family>
<family>Noto Color Emoji</family>
<family>Noto Emoji</family>
</prefer>
</alias>
<alias>
<family>Source Code Pro</family>
<prefer>
<family>monospace</family>
<family>Noto Sans Mono</family>
<family>Noto Sans Mono CJK SC</family>
<family>Noto Color Emoji</family>
<family>Noto Emoji</family>
</prefer>
</alias>
When comparing KWrite and Text Editor, and setting the font as Noto Serif CJK SC
in both, I'm seeing no difference.
I do use the Flatpak apps in both cases. KWrite is using Qt 5.15, while Text Editor is using GTK4.
Regular weight display too thin in qt app. GTK app doesn't have this problem, can be reproduced on both X11 and wayland, 4K screen.
Release artifacts were updated again, breaking packaging, and requiring manual intervention if your AUR helper is caching sources. If you will not remove the existing tarballs, then packaging will fail on the verifying sources step.
On the other hand, we finally don't have the archived ../LICENSE
file, and the Mono OTC is included in the Sans tarball.
I succeeded! Thank you so much!
@omasanori I can reproduce, I think the issue is that makepkg is extracting the sources, and this was due to the use of globbing in noextract
. I believe that it's fixed now.
Pinned Comments
tinywrkb commented on 2021-07-26 15:52 (UTC) (edited on 2022-08-20 14:54 (UTC) by tinywrkb)
What's up with all these split packages?
That's a lot of split packages, I suggest that you start by reading the fonts formats documentation in the
README.md
files of the Sans or Serif fonts before asking what you should install.There are 3 types of packages here:
noto-fonts-cjk-vf
:Variable OTCs
It's recommended to set the
LANG
orLANGUAGE
environment variables (e.g.LANG=zh_CN.UTF-8
),which will select the correct glyphs.
Without it, the fonts will likely fall back to Japanese glyphs when the language of a text cannot be defined or
auto-recognized (or too costly to recognize) by the application, and the OpenType locl is not being set.
Other environment variables:
FC_LANG
,PANGO_LANGUAGE
.For this to work correctly, HarfBuzz 3.3.0 or newer is required, see more details below.
noto-fonts-cjk{-language}-vf
:Variable Multilingual OTF
Multi-lingual CJK with a default language set for applications that don't apply OpenType locl.
You can still set
LANG
orLANGUAGE
environment variables and this setting will be respected,but if you don't then it will use the default language set in the font.
noto-fonts{-language}-vf
:Variable Region-specific OTF
Containing only a subset version of the font for a specific language.
Multi-lingual monospace font is packaged because there aren't subset versions of monospace fonts.
I'm not completely sure about the font config for the monospace font, so feedback would be appreciated.
Variable OTCs and HarfBuzz <3.0.0
Before HarfBuzz 3.3.0, the
Variable OTCs
fonts were pretty much unusable with apps that use Pango for rendering fonts.It was possible to make them sorta work by explicitly configuring apps to load the specific regional/language
font variant (e.g.
Noto Sans CJK SC
), and by using the<alias>
and<prefer>
elements infonts.conf
(see details in the Arch Wiki),but it was a hit-and-miss, and it should have worked without any extra setting, automatically loading the missing glyphs from the fonts.
From what I can tell, it's fixed in HarfBuzz
3.3.0
and newer releases, but anything that brings it ownoutdated
libharfbuzz.so
will still be broken. This means Flatpak, AppImage, proprietary, etc.I suspect that Electron releases older than
v14
are also affected by this.My MR backporting the needed changes to the Freedesktop Flatpak runtime was merged,
and this issue is fixed now for applications that use the following runtimes or newer:
Freedesktop 21.08
,Gnome 41
,KDE 5.15-21.08
.Updates
Gnome 41
Flatpak runtime was updated to41.8
and is based onFreedesktop 21.08.14
that includes the fix to HarfBuzz 3.0.0.<3.3.0
is also affecting Electron releases older thanv14
.Freedesktop 21.08
,Gnome 42
,KDE 5.15-21.08
, andKDE 6.2
Flatpak runtimes were updated, and they now include the HarfBuzz patch.3.3.0
.This is fixed not only for system installed applications, but soon also with Flatpak applications that
use runtimes based on
Freedesktop 21.08
, as the runtime's libharfbuzz 3.0.0 is patched with the fix.