Matterhorn 31-003 · PDF/UA-1 UA1:7.21.3.1-1

CID font Supplement older than its CMap: lost characters

BlockerCheckpoint 31: FontsWCAG 1.3.1 (A)

The font's character collection supplement must be at least as new as the CMap's, or the CMap may reference CIDs the font does not define.

The condition, as the protocol states it. “A Type 0 font dictionary with encoding other than Identity-H and Identity-V has a value for Supplement in the CIDSystemInfo dictionary of the CID font that is less than the value for Supplement in the CIDSystemInfo dictionary of the CMap.”

Matterhorn Protocol 1.1, checkpoint 31, index 31-003, section UA1:7.21.3.1-1. Software can decide this one on its own.

Some characters resolve to .notdef and are lost.

Supplements only ever add

A character collection such as Adobe-Japan1 is a numbered list of characters, and a CID is a position in it. Adobe extends a collection in Supplements: each one appends CIDs to the end and leaves every earlier CID exactly as it was. The full name of a collection includes the Supplement — Adobe-Japan1-6, Adobe-Japan1-7 — and both the CMap and the CIDFont of a composite font declare one in /CIDSystemInfo.

PDF/UA requires the font’s Supplement to be greater than or equal to the CMap’s (outside Identity-H and Identity-V, which name no collection). The CMap’s Supplement says how far down the list its codes can reach. The font’s says how far down the list it has glyphs for. If the CMap reaches further than the font, some codes lead to CIDs the font has never heard of.

A concrete case: Supplement 7

Adobe-Japan1-7 is the smallest Supplement Adobe-Japan1 has. Published in April 2019, it added exactly two CIDs: 23058 and 23059, the horizontal and vertical forms of ㋿ (U+32FF, SQUARE ERA NAME REIWA), the two-kanji ligature for the Japanese era that began on 1 May 2019. Supplement 6 ends at CID 23057.

So consider:

13 0 obj                                    % the CIDFont
<< /Type /Font /Subtype /CIDFontType0
   /BaseFont /ABCDEF+JPMincho-Regular
   /CIDSystemInfo << /Registry (Adobe) /Ordering (Japan1) /Supplement 6 >>
   /FontDescriptor 16 0 R >>

14 0 obj                                    % the embedded CMap
<< /Type /CMap /CMapName /Custom-UTF16-H
   /CIDSystemInfo << /Registry (Adobe) /Ordering (Japan1) /Supplement 7 >>
   /WMode 0 /Length 3410 >>

Every character the CMap maps to CID 23057 or below is fine. The moment the text contains ㋿ — in a date, on a form — the CMap maps it to CID 23058, and the font has no CID 23058.

What happens, on screen and in speech

A CID the font does not define is drawn with the font’s .notdef glyph: a blank, or an empty box, depending on the font. A sighted reader sees a gap in a date. A low-vision reader magnifying the page sees the same gap, larger.

What a screen reader says depends on where the viewer gets Unicode from. If the file has a ToUnicode CMap that maps the code to U+32FF, the reader may well hear the era name while everyone looking at the page sees a box — the document now says different things to different people. If the ToUnicode map was generated from the font’s own glyphs, a .notdef glyph has no Unicode value and the character is dropped from the speech too. Either way the file has stopped meaning one thing.

Japan1-7 is a two-glyph example. Earlier Supplements were not: Supplement 4 alone added 6,090 CIDs (9354 to 15443), and a CMap from after it over a font from before it can lose whole runs of characters.

Where it comes from

The CMap and the font come from different places and different years. A producer encodes text through a current CMap — Adobe updates its Unicode CMaps when a Supplement is published — and embeds a font that was made against an older one. Or a CIDFont is labelled /Supplement 0, which is lower than any CMap that uses a later Supplement; when that label is Adobe-Identity-0 it fails 31-002 as well.

How to check it free

qpdf. qpdf file.pdf --show-object=12 prints the Type 0 font; follow /DescendantFonts and /Encoding and compare the two /Supplement integers. The font’s must not be the smaller.

veraPDF with its PDF/UA-1 profile tests it under clause 7.21.3.1.

pdffonts (Poppler) shows the encoding of each font: Identity-H and Identity-V are exempt, anything else is where to look.

Acrobat Pro. All tools → Use print production → Preflight, then Options → Browse Internal PDF Structure, and open the font from the page’s Resources to read both dictionaries. The window is for inspection only; Adobe’s documentation says you cannot edit the structure or the fonts there.

How to fix it

Acrobat cannot edit CIDSystemInfo, and Adobe’s guidance for character-encoding failures is to re-create the PDF. Here that means one of three things in the source:

Use a font at the CMap’s Supplement or newer. For Japanese, a font that declares Adobe-Japan1-7 covers every CID any Japan1 CMap can produce.
Export with Identity-H and a ToUnicode CMap. The collection drops out of the question.
Keep the older font and avoid the newer characters — writing the era name as two ordinary kanji rather than the ligature, for instance. The file will still fail the condition if its CMap’s Supplement stays higher, so this fixes the page, not the PDF/UA result.

Editing the CIDFont’s /Supplement upwards to make the numbers agree is not a repair unless the font genuinely contains the newer glyphs. Raising the number does not add them; it removes the only signal that they are missing.

What Taggart does

For each Type 0 font that text is set in, with a CMap other than Identity-H or Identity-V, Taggart compares the two Supplements and reports a blocker when the font’s is lower:

/ABCDEF+JPMincho-Regular: the CID font’s CIDSystemInfo /Supplement (6) is lower than the CMap’s (7), so the CMap may reference CIDs the font does not define.

A font at the same Supplement as its CMap, or a newer one, is not reported.

The comparison only runs when the CMap is embedded. A font that names a predefined CMap from ISO 32000-1 Table 118 — /UniJIS-UTF16-H over a font declaring Supplement 0, say — is not compared, because that CMap’s own Supplement is defined outside the file and Taggart does not look it up. Check those by hand.

There is no fix in Taggart. The finding stays a blocker until the file is re-made, and Taggart will not write the PDF/UA identifier while it stands.

How Taggart handles it

Taggart checks for the common form of this condition automatically and reports it as a blocker. The check does not cover every form of it; what it misses is described above.

Whatever Taggart changes, the page still looks identical. Fixes edit the PDF object model, not the content streams, and every remediation is re-rendered and compared against the original at structural similarity ≥ 0.999 before you get the file back. A tool that quietly reflows your document is worse than no tool.

Frequently asked questions

What is a Supplement?

A numbered addition to a character collection. Adobe-Japan1 has gone from Supplement 0 to 7, each one appending CIDs to the end of the list without changing the ones before. A font or CMap that says Supplement 6 covers everything up to the end of Supplement 6.

Is a font with a higher Supplement than its CMap a problem?

No. The rule only runs one way. A font that defines more CIDs than the CMap can ever produce simply has glyphs nobody asks for. The failure is the reverse: a CMap that can produce CIDs past the end of the font.

Does every code in the text fail?

No — only codes that map to CIDs added after the font's Supplement. A document can fail this condition and render every character correctly, because it never uses the newer ones. The condition is about what the file permits, not what this page happens to contain.

Why does a font labelled Adobe-Identity-0 fail this as well as 31-002?

Because 0 is lower than whatever Supplement the CMap declares. The label is wrong as a whole — wrong Ordering and wrong Supplement — so both conditions fire for the one mistake.

Where this sits in the standards

Standards this condition maps to
Standard	Reference
Matterhorn Protocol 1.1	Checkpoint 31 (Fonts), index 31-003
PDF/UA-1 (ISO 14289-1)	Clause 7.21.3.1-1
WCAG 2.1	1.3.1 Info and Relationships — Level A
EN 301 549 / Section 508 / ADA Title II	All three point at WCAG 2.1 Level AA for non-web documents, so a Level A or AA criterion here is in scope for each of them.

Other conditions in checkpoint 31

Checkpoint 31 covers fonts. These are its other failure conditions; the ones without a link are in the rule set but do not have a written page yet.

Check your own file. Taggart’s validator is free and unlimited — 75 of the 87 Matterhorn conditions software can decide, with the other 12 listed for you to confirm; no watermark, no expiry, and no account needed up to 60 pages.

Check a PDF free

Checked with Taggart on a generated file that fails this condition on 2026-10-02. The Acrobat steps follow Adobe’s documentation and were not walked through by hand. Last updated 2026-10-02.