Which system fonts draw every Vietnamese letter?

This morning I set out to give the garden's typography a proper once-over, and found that for four months I had only ever looked at it in one browser.

Every number below was counted on one Mac running macOS 26.5, with a script that lives in the repo.

Tiếng Việt: Font hệ thống nào vẽ đủ dấu tiếng Việt?.

What broken Vietnamese looks like

The garden loads no web font. I promise that on the colophon: no font CDN, no request to anyone else's server. The price of that promise is that Vietnamese looks however your machine's own fonts make it look.

When a font lacks one letter, the browser borrows just that letter from another font, mid-word. The word ngắm can come out as ng in one typeface, ắ in another, m back in the first. The marks sit at a different height, the strokes change weight, and it reads like a ransom note. A Vietnamese reader sees it at once, even without a name for it.

I was bitten once already, in June: the first serif in the list was Iowan Old Style, and every ự on every page was off. I fixed it by switching to ui-serif, saw it looked fine in Safari, and stopped there.

Counting all 146 letters

This time I didn't want to judge by eye. Vietnamese has 12 vowels (a ă â e ê i o ô ơ u ư y), each with 6 tones, plus đ. That makes 73 lowercase letters, and 146 with capitals.

"Does this font have every mark?" is a question a machine can answer, no eyes needed. On macOS, CoreText will tell you, per font, whether a character has a glyph. scripts/design/vi-fonts.ts builds those 146 letters, reads the font stacks out of the garden's CSS, asks CoreText letter by letter, and prints which font is missing which letters. It takes about a second.

Here is what my machine says:

Palatino lacks exactly one letter, and it is ớ. That sounds small, but lớn (big), mới (new), với (with) and nhớ (remember) are on every page. A font that scores 145 out of 146 still breaks in the first sentence you write.

Iowan and Charter lack all 24 horned letters. That is June's bug, now with a number: the two nicest serifs on a Mac have no ơ and no ư. And Chalkboard lacks even đ, so the single word đường (road) breaks.

Try it on your machine

Each line below sets one font on the same sentence. If your machine lacks that font, the line falls back to your default, so every machine draws a different table.

In Chrome, a letter missing its horn doesn't borrow another font: it just loses the horn. I opened this table in Chrome, and in the Iowan line mới (new) turned into mối (termite), ướt into uốt, lớn into lốn, and từng (each) into tùng (pine). So it stops being a question of looks: the reader reads a different word. Safari borrows the glyph from another font instead, so the letter looks off but stays right.

Having every letter is not the same as drawing it right. CoreText says Palatino has ầ. Yet in the Palatino line above, both Safari and Chrome draw mầm with the grave flung off to the left, and in dần the grave vanishes, so it reads dân (people). Having a glyph is one thing, placing its mark is another, and my script only sees the first.

Chrome has never heard of ui-serif

The surprise was somewhere else. The garden's serif stack starts with ui-serif, meaning "the operating system's serif". In Safari that is New York: all 146 letters, and lovely.

Chrome 156 ignores ui-serif outright, and ui-monospace too. I built a test page with font-family: ui-serif, monospace and opened it in headless Chrome. The text came out in typewriter type: Chrome skipped ui-serif and dropped straight to monospace.

So a reader on Chrome on a Mac walks on down the list: Palatino Linotype (a Windows font the Mac doesn't have), then Times New Roman. For four months they read the garden in Times, the typeface of a leave-request form. Every mark present, and nothing like the garden.

The fix is one word: put Georgia right after Palatino Linotype. Georgia has 146/146, ships on both Mac and Windows, and is much warmer than Times. Safari still takes New York because ui-serif comes first, and Windows still takes Palatino Linotype as before. Only Chrome on a Mac changes, and I took before and after screenshots to be sure.

Two things I got wrong in June

Only after counting did I see two of my own old sentences were wrong. The CSS comment said "Georgia drops the stacked marks", so I had left Georgia out on purpose. The fix note said "Marker Felt lacks Vietnamese". On this machine both have 146/146.

Maybe back then I looked at a page broken by Iowan and lumped a few other fonts in to be safe. Or maybe Georgia on macOS has changed since. I don't know which. The lesson is clear, though: a "this font is broken" with no count attached outlives the truth it was about.

The hand font had its own story. After Marker Felt and Chalkboard SE, the fallback was Comic Sans MS, and the Mac copy has 54/146. The poem on the home page is set in the hand font, so a machine without those two Mac fonts would see it lose nearly every mark. I dropped Comic Sans, added Noteworthy (146/146), and let the hand font fall back to the serif. A little less playful, but every letter intact.

What I still don't know

• I only counted on one Mac. The Windows copies of Comic Sans, Cambria or Georgia may well be more complete than the Mac ones. I have no Windows machine to ask.
• CoreText only answers "is there a glyph", not "does it look right". A font with every letter whose marks collide would still pass.
• Menlo lacks 46 letters and I kept it for code anyway, because code is nearly all English and its borrowed marks blend in. I may be wrong here.
• I haven't tried Android or Linux. Noto Serif is complete according to its docs, but I haven't counted it myself.

If you open this page on Windows or a phone and a line in the test breaks differently from what I describe, write me a letter below. I'd like to know what that table looks like on your machine.