Impossible to use "Noto [Sans/Serif] [SC/TC/JP/KR]" fonts in Google Chrome/MSEdge

[verdy-p]

All "Noto [Sans/Serif] [SC/TC/HK/JP/KR]" fonts, in all 7 weights.

Describe the bug It's still impossible to use "Noto [Sans/Serif] [SC/TC/JP/HK/KR]" fonts in Google Chrome/MSEdge, even if they are fully installed (all 7 weights from "UltraLight" to "Black", including "Regular" and "Medium") on the system (Windows), shown in Windows>Settings>Fonts.

Instead other fallback fonts from Windows (e.g. "SimSun", "SimSun-ExtA", "SimSun-ExtB") are used instead. This affects CJK characters in ALL planes (including in the BMP).

Apparently, the "Noto [Sans/Serif] [SC/TC/HK/JP/KR]" fonts have forgotten to include "[dlng]/[slng]" metadata, visibly required now by text rendering engines for Chromium-based web browsers:

This "[dlng][slng]" metadata is present in default Japanese/Chinese/Korean Windows OpenType fonts, like "SimSun*", and may explain why these system fonts are the only one selected and used as fallbacks. This "[dlng][slng]" metadata is preferred now to the older mechanism (broken and very slow) based on looking at character-to-glyph mappings, it is part of modern standards.

All Noto fonts should include the [dlng][slng] OpenType metadata. This is not the case for now. Any fonts without this (now required) metadata will never be used by modern web browsers, even if they are installed on the system; fallback fonts (listed in CSS, or implied by generic font names like "serif" or "sans-serif", or added in the default builtin list of browsers) will be used instead (if there are existing candidate fallbacks), or the web browser will just display "tofu" (not what the "Noto" fonts were designed for!).

To Reproduce Look at these example web pages with Google Chrome or MS Edge:

• https://commons.wikimedia.org/wiki/Category:Unicode_4E00-9FFF_CJK_Unified_Ideographs
• https://commons.wikimedia.org/wiki/Category:Unicode_3400-4DBF_CJK_Unified_Ideographs_Extension_A
• https://commons.wikimedia.org/wiki/Category:Unicode_20000-2A6DF_CJK_Unified_Ideographs_Extension_B
• https://commons.wikimedia.org/wiki/Category:Unicode_2A700-2B73F_CJK_Unified_Ideographs_Extension_C

Open the list of characters with the "[hide/display]" button, select a single character in the list, inspect details in Google Chrome's developer console, then go to the "style" panel, and look at the bottom of the "Computed" tab, that shows which fonts are used to display characters (see the example screenshot below).

Expected behavior "Noto Serif TC" should be used, but system fallback fonts (e.g. "SimSun", "SimSun-ExtA", "SimSun-ExtB") are used instead.

Screenshots

Additional context Google Chrome (current release) on Windows 11

[verdy-p]

Hmmm.. In fact the problem here is that there's no support in Noto fonts, for any CJK characters in Planes 2 (SIP) or 3 (TIP)... and not even for many characters in Plane 0 (BMP). So we always get fallback fonts (like SimSun or SimSun-ExtB on Windows) for them, or just tofus if they are not in system-provided fonts (notably for now, all CJK characters in Plane 3).

So Noto CJK fonts are still too much incomplete (why are they not complete at least in Plane 0? just like Microsoft's "SimSun", which also supports essential variants for SC/TC/JP/KR, but of course not all possible variants like Itaiji in Japan because of OpenType limitations in the maximum number of glyphs, unless fonts use "font linking" in their OpenType metatables, or with help of "meta-fonts").

And we'll still need additional Noto CJK fonts for plane 2 (like Microsoft's "SimSun-ExtB", possibly omitting some SC/TC/JP/KR variants) and plane 3.

[applecuckoo]

I'm going to ping in @simoncozens here, since if I remember correctly he's in charge of the Noto fonts. This might actually be a problem for the Adobe folks since it's their font.

[simoncozens]

I don't think it can be possible that you always get a fallback font because there isn't complete support for BMP. The characters included should be displayed. So something else is wrong here.

[verdy-p]

Note that I could finlly use Noto fonts, but only when asking for specific font-weight (in the example page shown above, listing characters, I forced using "font-weight:200" instead of the default weight)

May be something is wrong with the "regular" weight (not used by default); anyway the font-weigth:200 is also the most readable, to show distinctions notably for CJK ideographs with many strokes, including "kStrange" variants with more than 40 total strokes, and with a reasonable minimum font-size: that page is tuned to increase a bit the font-size, and reducing the default line-height, so that the list of characters is usable; this works with all CJK characters in planes 0 and 2, even if for now there's no font for plane 3, and plane 2 is only displayed by Microsoft CJK fonts; I'm still looking for more free CJK fonts available for planes 2 and 3, and with a reasonable quality). In the example pages linked above (showing the complete list of characters in each Unicode CJK ideographs block), I tuned and optimized the CSS to generate a longer list of fallback fonts (also taking into account the visitor's preferred language, to list fonts and fallbcks in different order) and now use the "font-weight:200" explicitly (and now I see some glyphs from Noto fonts, when they exist, otherwise I get appropriate fallbacks from Microsoft fonts).

But in all cases, the Noto CJK fonts are still largely behind Microsoft CJK fonts in terms of quality and completeness. Generally Noto fonts are rarely used in most pages, Microsoft fonts (listed as fallbacks or implicitly used as universal default fallbacks on Windows) are used instead; so there's a problem, probably related to the fact that Noto CJK fonts still do not have "dlng/slng" metadata.

---

There are many free glyphs available for CJK ideographs as SVG in GlyphWiki, and I wonder if another set of Noto CJK font could be built from there (they are in a free licence: may be a "Glyphwiki Han"?), rather than depending on Adobe limited support.

See also the work already done in KanjiVG (basically jsut for showing stroke orders with basic strokes and numbers displayed near their starting point). But CJK fonts can be built using the database of strokes already built for KanjiVG, ans a set of glyphs for stroke components. However the problems would be overlaps if replacing the line-strokes by filled shapes: you need a script to compute overlaps and resolve them, as for now OpenType does not provide support for computing them and eliminate these overlaps (including for variable-weight fonts).

Adobe made that work of computing the geometries in their fonts, but not with variable weight support, instead the glyphs were recomputed for a specific set of weights, but probably built using a similar database of stroke components, and a limited set of base glyphs for these components that could be scaled (and possibly hinted with custom hinting scripts) individually prior to generating the geometry for actual CJK character glyphs.

I think all this can be done in a free opensource project, that could rebuild all CJK fonts at all the 7 supported weights, as well as possibly variable fonts (but there, inserting font hinting instructions integrated in OTF fonts will be more complex thant generating the precomputed geometries for fonts with specific weights). This project could then map not jut the basic variants, but also all encoded variations, and generate "universal" CJK fonts that would work across all CJK languages (no longer needing "SC/TC/JP/KR" distinction in font names, but existing OpenType language-scoped "features"). Of course it will not be possible to build a single font for all planes. But it should be possible with one font for plane 0, one or two for plane 2 (note that the very large ideograph in block in plane 2 may not be supported entirely in a single OTF font due to the maximum number of glyphs, limited to 16-bit, that each OTF font can embed, but this problem can be solved using font-linking), and some other fonts for plane 3.

[simoncozens]

We already have some ideas for how to do the expansions: (a) obtain/derive sources, (b) convert to variable components, (c) fill in the glyphs from radical recipes.

[verdy-p]

Thanks, but how will we resolve the problem of overlapping glyphs (or glyph components)? Something is missing in OpenType specifications for that (and it is needed not just for CJK ideographs, but also all scripts and symbols that need to render ligatures and overlaps, including notably Arabic, Devagari, handwritten Latin/Greek/Cyrillic...). SVG has a limited support for them implemented in their renderers (see "fill-mode: non-zero", unfortunately limtied in use jsut for filling and not for deriving geometries).

In my idea, if OpenType had "full support" of overlaps, and the capability of computing derived geometries, if would be possible to generate very small CJK fonts and improve the rendering of all scripts, with much less work needed for font designers (most of the work would be done by the renderer, using technics already implemented for SVG filling, but as well for other graphical projects like cartography: computing geometries is also implemented in many SVG drawing tools). And it would greatly increase the support for variable fonts for other axis (e.g. shape variants for stroke ends: cap/rounded, serif vs. sans-serif). However all this will depend on technical evolutions of OpenType renderers (and its specs).

[simoncozens]

Something is missing in OpenType specifications for that

I'm not sure what you're implying, because there is an overflap flag on the glyph table.

At any rate, changing the opentype spec and all existing renderers is somewhat out of scope for a Noto CJK bug.

[verdy-p]

This "overlap" flag is apparently not implemented (we know the bug, you've even documented it in the Google Fonts site, notably for pages explaining if all sttyles can be used, this does not work for now for generating "outline" style (only borders with transparent filling, or semi-transparent filling where overlaps are also visible, even with the "filling-rule: nonzero" rather than "evenodd" where overlaps cause problems even for opaque filling, as they can create "holes").

I did not find anything in OpenType that discusses overlaps, and if it exists, it has been forgotten in many OpenType renderers or it was misunderstood due to possibly ambiguous specification (so then it creates unsolved compatibility problems).

Supporting overlaps is critical for using fonts with variable weight (this is already a problem for all existing Noto CJK fonts, and for Arabic, Devanagari, and handwritten cursive Latin styles, many ligatures needed for maths symbols, and many composed characters with diacritics which may overlap in some cases, notably at small font sizes or bold weights). Overlapping glyphs are not sufficiently specified, and not correctly implemented. This merits some further studies (even if for now you do not plan any change).

As well the initial bug remains valid (even if for now I used a workaround to avoid fallbacks in all cases) and we still need completion of CJK characters in the BMP, plus additional CJK fonts for planes 2 and 3. Using "dlng"/"slang" metadata is still needed (and would avoid using specific [SC/TC/JP/KR] variants. Everything is specified and ready in OpenType for them (with OpenType language/script feature tables) and as well as the support for linguistic variants and standard ideographic variations (registered in the Unicode IVD). Clearly, all Noto CJK fonts need completion and "cleanup" according to existing specs (just like what Microsoft did correctly in their default CJK fonts for Windows for Planes 0 and 2, but still not for Plane 3).