Package Details: noto-fonts-cjk-sc-vf 20220126-5

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 CJK variable fonts with Simplified Chinese as the default language
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.000052
First Submitted: 2021-07-26 14:38 (UTC)
Last Updated: 2022-08-07 09:34 (UTC)

Dependencies (0)

Required by (30)

Sources (8)

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 or LANGUAGE 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 or LANGUAGE 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 in fonts.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 own
outdated 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
  • 2022-08-20: Gnome 41 Flatpak runtime was updated to 41.8 and is based on Freedesktop 21.08.14 that includes the fix to HarfBuzz 3.0.0.
  • 2022-08-17: The Variable OTCs issue of HarfBuzz <3.3.0 is also affecting Electron releases older than v14.
  • 2022-08-07: Release assets were updated without tagging a new release. If you're upgrading this package(s) and your AUR helper is caching sources, then you might need to delete the cached tarballs.
  • 2022-05-21: Freedesktop 21.08, Gnome 42, KDE 5.15-21.08, and KDE 6.2 Flatpak runtimes were updated, and they now include the HarfBuzz patch.
  • 2022-04-01: The issue affecting Variable OTCs is related to HarfBuzz and was fixed in version 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.
  • 2022-02-23: A section about OpenType issue with Pango apps was added.
  • 2022-01-26: There are now variable Serif fonts for all the languages. The generated packages are much smaller.

Latest Comments

1 2 Next › Last »

st0ne commented on 2024-07-31 04:25 (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

Coelacanthus commented on 2024-02-19 18:20 (UTC)

@tinywrkb, I can confirmed font weight issue of Qt was fixed in Qt 6.7.

dough.mean commented on 2023-05-10 15:18 (UTC) (edited on 2023-05-10 15:18 (UTC) by dough.mean)

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.

tinywrkb commented on 2022-10-11 22:44 (UTC)

@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.

rapiz commented on 2022-10-11 04:28 (UTC)

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.

tinywrkb commented on 2022-08-09 23:03 (UTC)

@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.

Coelacanthus commented on 2022-08-09 22:31 (UTC)

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.

tinywrkb commented on 2022-08-07 10:13 (UTC) (edited on 2022-08-09 22:33 (UTC) by tinywrkb)

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.

omasanori commented on 2022-07-20 00:55 (UTC)

I succeeded! Thank you so much!

tinywrkb commented on 2022-07-19 14:57 (UTC)

@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.