Missing glyphs U+01CF–U+01DC (ǐ ǒ ǔ ǖ ǘ ǚ ǜ): pinyin third-tone i/o/u and all ü tones fall back to another font

[Atcold]

Version: 2407.024 (v2407.24, the current release)
Variant: Cascadia Code
Format: .ttf (variable)
Platform: macOS 26.6.2 (25G83)
Other software: Apple Terminal (Monokai profile, CaskaydiaCove NF ExtraLight 22 pt, Nerd Fonts 3.4.0). Also reproduces with the unpatched CascadiaCode.ttf.

What happened

Cascadia Code covers U+01CD/U+01CE (Ǎ ǎ) and then stops: U+01CF through U+01DC are absent from the font entirely — no cmap entry and no glyph. That range is Ǐ ǐ Ǒ ǒ Ǔ ǔ Ǖ ǖ Ǘ ǘ Ǚ ǚ Ǜ ǜ. (U+1E3F ḿ is also absent.)

Because the codepoints are missing, the terminal substitutes another font for those characters. On macOS 26.6.2 the substitution resolves to Helvetica — a proportional face — so the character renders in a different typeface at a non-matching advance width, breaking the monospace grid. Beside its neighbours it does not read as an "i with a caron" at all: different skeleton, different stroke weight, and a square diaeresis where Cascadia's is round.

The reported symptom is therefore "this glyph is drawn wrong", but the cause is that it is not in the font.

Why this range matters: it is pinyin

Of the 24 tone-marked vowels in Hanyu Pinyin, seven fall in this gap — the third tone of i, o and u, plus all four tones of ü. First, second and fourth tones render correctly, because they live in Latin-1 and Latin Extended-A.

So nǐ hǎo, qǐng, xiǎo, lǚxíng come out with most syllables right and only the third-tone ones visibly wrong, which is a confusing failure mode — it looks like a design inconsistency rather than missing coverage. ǐ in particular is unavoidable for anyone reading Chinese: 你 nǐ, 起 qǐ.

What should render

The same precomposed letters the font already builds for the rest of the caron set, on the standard monospace advance.

Notes toward a fix

The components are already present:

• dotlessi (U+0131) exists, at the standard 1200/2048 advance
• uni030C (combining caron) exists, at 0 advance
• the font already builds uni01F0 (ǰ) as uni0237 + uni030C — exactly the construction icaron needs, with a dotless base
• uni01CE (ǎ) is built as a + uni030C

These look like composite-glyph additions following an established pattern rather than new drawing work.

Relationship to #707

This appears to be the remainder of #707, closed as completed in March 2024. The affected codepoints are still absent both in the current release and in sources/CascadiaCode-Regular.ufo/glyphs/ on main, which contains acaron, ecaron, jcaron and ncaron but no icaron, ocaron, ucaron or ü-caron glyphs.

I will attach a rendering of the fallback in a follow-up comment.

[Atcold]

Renderings of the fallback, produced with CoreText using the affected font so the substitution is reproduced rather than simulated.

The gap, in context. Rows that fall back to another face are marked; the first, second and fourth tones render from Cascadia, the third does not:

Close up, at 90 pt — i í ǐ beside a ǎ, where ǎ is present in the font and ǐ is not:

And the fix, demonstrated. I assembled the missing letters locally as composites of glyphs the font already ships — dotlessi + uni030C for ǐ, o + uni030C for ǒ, and the ü tones as udieresis plus a raised mark. No outlines were drawn. This is the result, rendered from the patched font:

Every component was already present at the correct monospace advance — dotlessi at 1200, uni030C at 0 — and the font already builds ǰ as uni0237 + uni030C, the same construction with a dotless base. So closing this gap looks like adding composites in the established pattern rather than new drawing work.

[DHowett]

Reads like LLM slop.

[kenmcd]

Duplicate of #776

[Atcold]

Dustin L. Howett (@DHowett), excuse me?
Did you first check my profile??
I've been contributing to open source project for the last 15 years!

[Atcold]

kenmcd This is not a duplicate of #776.

#776 is about Pe̍h-ōe-jī and Tâi-lô, which need combining marks positioned over arbitrary bases, including U+030D over m and n. This issue is about precomposed codepoints that are absent: U+01CF through U+01DC have no cmap entry and no glyph.

Neither can fix the other. Pinyin text is NFC, so i + U+030C composes to U+01D0. The shaper never sees a combining sequence, so no amount of mark attachment or GPOS work makes U+01D0 render. The codepoint has to exist in cmap.

The closer relative is #707, "Letters with diacritical marks in Latin Extended-B block", closed as completed in March 2024. U+01CF–U+01DC sit in that block and survived it, so this reads as an incomplete fix rather than a new request.

The components already ship: dotlessi at 1200, uni030C at 0, and the font already builds ǰ as uni0237 + uni030C, the same construction with a dotless base.

[DHowett]

Did you first check my profile??

There are 10 em-dashes in your original message, plus seven other "tells" of LLM-based writing. I didn't need to check your profile to see that.

If you have been contributing to open source for that long, you should know that open source software is a deeply human endeavor and that it is gravely disrespectful of maintainers' limited time and limited energy to dump a wall of autogenerated text on them. And if you do not know that, now is your chance to learn.

[Atcold]

I do use em dashes in my writing.
Yes, I asked a full analysis of the bug, to verify it was legitimate and to avoid creating a duplicate.
The second post showcases the issue.

I agree there is more text than necessary in the first message.
I can prune that, if it bothers you.
Yet, the bug exists, it has been fully described, it's not a duplicate, and there's a user behind it, who's fully committed to helping resolve it.

Let me know how you intend to procced.
Thanks.

[DHowett]

Thank you. I'm sorry I gave you a hard time.