Matterhorn 31-005 · PDF/UA-1 UA1:7.21.3.2-1

Missing CIDToGIDMap: a default PDF/UA will not rely on

BlockerCheckpoint 31: FontsWCAG 1.3.1 (A)

The entry is absent entirely.

The condition, as the protocol states it. “A Type 2 CID font does not contain a CIDToGIDMap entry.”

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

Glyph lookup is undefined, so text extraction is unreliable.

The entry, and its default

A composite font whose descendant is /CIDFontType2 draws its text from a TrueType program. TrueType addresses glyphs by glyph index; the CMap hands the font CIDs. /CIDToGIDMap is the bridge between the two: either the name /Identity (CID n is glyph n) or a stream of two-byte glyph indices, one per CID. Condition 31-004 is a value that is neither. This one is no value at all:

13 0 obj
<< /Type /Font /Subtype /CIDFontType2
   /BaseFont /ABCDEF+Calibri
   /CIDSystemInfo << /Registry (Adobe) /Ordering (Identity) /Supplement 0 >>
   /FontDescriptor 16 0 R
   /DW 1000
   /W [ 3 [ 226 ] 17 [ 525 498 ] ]
>>                                   % no /CIDToGIDMap

In ISO 32000-1 that is legal. The entry is optional and its default is /Identity. PDF/UA-1 overrides the default: a Type 2 CID font has to say which mapping it uses.

Why a file that works still fails

This is one of the conditions where the document usually behaves perfectly. Any viewer that implements the default treats the missing entry as /Identity, and for the ordinary arrangement — a subset embedded with an Identity-H encoding, its CIDs numbered to match its glyphs — /Identity is exactly right. The page draws, the ToUnicode CMap supplies the text, and a screen reader reads it.

But “usually” is a property of viewers, not of the file. A file that writes its mapping down can be checked against its own font program — does every CID the text uses reach a glyph that exists (31-011)? — without assuming anything about who opens it. Making the entry mandatory turns an assumption about viewers into a statement in the file.

How to check it free

qpdf. pdffonts gives each font’s object number; the ones listed as CID TrueType are the Type 2 CID fonts. qpdf file.pdf --show-object=12 prints the Type 0 font, and the object in its /DescendantFonts array is where /CIDToGIDMap should be. Unlike an invalid value (31-004), a missing one produces no warning from Poppler — the file is valid PDF — so you have to look.

veraPDF with its PDF/UA-1 profile reports it under clause 7.21.3.2.

Acrobat Pro. Document Properties (File → Properties, or Menu → Document Properties in the newer interface) → Fonts lists each font with its type — see Adobe’s description of the tab. To see whether the entry exists, use Preflight: All tools → Use print production → Preflight, Options → Browse Internal PDF Structure, then open the font from the page’s Resources down to DescendantFonts. That window is read-only (Adobe).

How to fix it

Acrobat cannot add a key to a font dictionary; Preflight’s structure browser only displays.

Re-export from the source, through a PDF writer that includes the entry.

Or add the one key. If the page renders correctly now in a viewer that applies the standard’s default, Identity is the right mapping, and stating it changes nothing a reader can see. With qpdf:

qpdf --json-output in.pdf font.json --json-object=13,0
# add "/CIDToGIDMap": "/Identity" to the object's value
qpdf in.pdf --update-from-json=font.json out.pdf

Compare a rendering of out.pdf with the original before you keep it. If the page did not render correctly, the font needed a lookup table that is not in the file, writing /Identity would make a wrong mapping official, and the source is the only place to get the table from.

What Taggart does

For every Type 0 font that text is set in whose descendant is a /CIDFontType2, Taggart checks for the entry and reports its absence as a blocker, with the font’s object number and the first page it appears on:

/ABCDEF+Calibri is a Type 2 CID font with no /CIDToGIDMap entry.

It does not report CFF-based /CIDFontType0 fonts, which do not use the entry. It checks Type 2 CID fonts whether or not their program is embedded; an unembedded one is also reported under 31-009, which is the more urgent of the two.

Taggart has no fix for this condition and does not add the entry, though in the common case above the repair is a single key. The finding stays a blocker until the file is re-made or edited as described, and Taggart will not write the PDF/UA identifier while it stands.

How Taggart handles it

Taggart checks for this condition automatically and reports it as a blocker, with where in the file it found it.

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

If the default is Identity, what is actually wrong?

Nothing a reader of the base PDF format would notice: ISO 32000-1 says a missing CIDToGIDMap means Identity, and conforming viewers apply that. PDF/UA-1 removes the option and requires the entry to be written, so the file states its glyph mapping instead of leaving it to be inferred.

Can I just add /CIDToGIDMap /Identity?

If the page renders correctly today, yes. A viewer that draws it correctly is already applying the Identity default, so writing /Identity states what was already happening and changes nothing on the page. If the glyphs are wrong, the font needed a lookup table that is not in the file, and adding /Identity only makes the wrong mapping explicit.

Does this apply to CFF-based CID fonts?

No. CIDToGIDMap belongs to Type 2 CID fonts, whose outlines are TrueType. A CIDFontType0 font looks its glyphs up by CID directly and never has one, and Taggart does not report it on them.

Will a screen reader user notice?

Almost never, because text extraction normally runs through the ToUnicode CMap, which does not use this entry. The condition is about the file stating how its glyphs are found, which is what makes rendering — and any check of rendering against the font program — deterministic.

Where this sits in the standards

Standards this condition maps to
Standard	Reference
Matterhorn Protocol 1.1	Checkpoint 31 (Fonts), index 31-005
PDF/UA-1 (ISO 14289-1)	Clause 7.21.3.2-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.