Extended Latin / Vietnamese
Vietnamese text in a PDF
Vietnamese is Latin with two diacritics stacked on one letter, and most Latin fonts contain the characters while positioning the second mark badly or not at all.
A font with the characters is not enough
A Vietnamese vowel can carry a quality mark, such as a circumflex or a horn, and a tone mark on top of that. Two marks on one base letter is unusual in Latin typography, and fonts handle it in two ways: as a single precomposed glyph for each combination, or by positioning a combining mark with the font's GPOS anchors. A font that has the precomposed glyphs looks perfect. A font that lacks them and has no anchor data stacks the second mark at a default offset, which lands it on top of the first one or floating above the line. Whether you get one or the other also depends on Unicode normalisation: the same text in NFC form asks for a precomposed glyph and in NFD form asks for base plus combining marks, and a font can support one and not the other.
What the failure looks like
Text that is legible and visibly wrong: tone marks sitting too high, colliding with a circumflex, or drifting sideways off the letter. It is the kind of failure a reviewer who does not read Vietnamese will approve, because every character is present.
Line breaking
Ordinary Latin word breaking, with the caveat that a base letter and its combining marks are one grapheme cluster. Any per-character truncation can separate a tone mark from its vowel, leaving a mark attached to whatever character now precedes it.
The markup and the CSS
The language attribute is doing real typographic work in every one of these examples. It is what lets the engine choose a regional glyph form, a case mapping or a hyphenation dictionary, and leaving it off is the most common single omission in a multilingual document.
<p lang="vi" class="vietnamese">Hóa đơn của bạn đã sẵn sàng.</p>
<style>
@font-face {
font-family: "Brand Sans VN";
/* Choose a face whose Vietnamese support is stated rather than assumed.
"Latin Extended" in a specimen does not mean the stacked marks are
positioned, only that the code points exist. */
src: url("https://assets.example.com/fonts/brand-sans-vn.woff2")
format("woff2");
}
.vietnamese {
font-family: "Brand Sans VN", sans-serif;
/* Stacked marks are taller than a Latin ascender. */
line-height: 1.6;
}</style>
<!-- Normalise to NFC before rendering, so the text asks for precomposed
glyphs, which is what fonts support best:
const text = raw.normalize("NFC"); -->The mistake people make
Testing with a name that happens to use only one mark. Nguyen renders correctly in almost any font. The failure appears on a vowel carrying both a quality mark and a tone, so a test string has to include one. If you cannot read the language, render a known-good reference image alongside and compare, rather than judging by whether it looks like text.
How to test this without reading the language
Render a string you know is correct, and compare it against a reference rendering from a system that definitely handles the script, such as a browser on a machine with the language installed. Comparing against nothing tells you only that characters appeared, and for most of the scripts on this site characters appearing is not the same as text being right. Where you can, get one native reader to look at one page once; it is faster than any amount of specification reading.
Frequently asked
Why does Vietnamese look wrong when every character is there?
Text that is legible and visibly wrong: tone marks sitting too high, colliding with a circumflex, or drifting sideways off the letter. It is the kind of failure a reviewer who does not read Vietnamese will approve, because every character is present. The underlying reason is that a font is two things: a set of glyphs and a set of layout tables that say how those glyphs combine and position. Character coverage is the first half. Most of the failures on this page are the second half.
Does the lang attribute actually change the rendering?
Yes, and it is not an accessibility nicety here. It selects regional glyph forms where a code point has more than one correct shape, it picks the case mapping for a text transform, it chooses a hyphenation dictionary, and it triggers the locl OpenType feature. A document with no lang attribute gets whatever the font defaults to, which is usually right for one language and wrong for the others.
Can I subset the font to keep the file small?
Carefully, and not with a tool configured for Latin. Subsetters routinely drop the GSUB and GPOS tables that shape and position glyphs, because for Latin those are largely optional. The subset renders without error and every complex feature in it is broken. Test a subset by rendering real text and looking at it, never by checking that the file got smaller.
Related writing systems
Scripts with a related mechanism, and one from each of the other families.
Devanagari text in a PDF
Hindi, Marathi, Nepali and Sanskrit are written in a script where the order characters are stored in is not the order they are drawn in.
Thai text in a PDF
Thai is written without spaces between words and stacks marks up to three levels above the baseline, so both line breaking and line height need deciding rather than defaulting.
Japanese text in a PDF
Japanese shares code points with Chinese while wanting different glyph shapes for them, and has line-breaking rules that no default implements.
Cyrillic text in a PDF
Most Latin fonts include some Cyrillic, usually the Russian subset, and several languages written in Cyrillic need letters or letter shapes that subset does not have.
Custom fonts falling back to a default
The adjacent problem, covered in full there rather than repeated here.
Every writing system covered
The nine that needed a page, and the eight existing pages that cover the rest.
Paste a real string in this script into the playground and compare the output against a reference. It is the only test that means anything if you do not read the language.