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

CIDToGIDMap must be /Identity or a stream, nothing else

BlockerCheckpoint 31: FontsWCAG 1.3.1 (A)

CIDToGIDMap must be either the name /Identity or a stream mapping CIDs to glyph indices.

The condition, as the protocol states it. “A Type 2 CID font contains neither a stream nor the name Identity as the value of the CIDToGIDMap entry.”

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

Glyph lookup is undefined, so text extraction is unreliable.

What the entry is for

A composite font whose descendant is /CIDFontType2 is a TrueType font addressed by CID. TrueType programs do not know about CIDs: they draw glyphs by glyph index, a position in the program’s own glyf table. Something has to turn the CID the CMap produced into the glyph index the program understands, and that is /CIDToGIDMap:

13 0 obj
<< /Type /Font /Subtype /CIDFontType2
   /BaseFont /ABCDEF+Calibri
   /CIDSystemInfo << /Registry (Adobe) /Ordering (Identity) /Supplement 0 >>
   /FontDescriptor 16 0 R
   /W [ ... ]
   /CIDToGIDMap /Identity          % CID n is glyph n
>>

ISO 32000-1 allows it two forms. The name /Identity says the CID is the glyph index — the normal arrangement for an embedded subset written with an Identity-H encoding. A stream is a lookup table: two bytes per CID, big-endian, so the glyph for CID c sits at bytes 2c and 2c+1. That is what a producer writes when its CIDs come from a collection such as Adobe-Japan1 and the TrueType font numbers its glyphs differently.

This is not an East Asian corner of the format. A Latin document exported to PDF often sets its text in TrueType-based CID fonts — pdffonts lists them as CID TrueType — and every one of them has, or should have, this entry.

What counts as a failure

Condition 31-004 is a /CIDToGIDMap that is present but is neither of those: a different name, an array, a number, a dictionary. In practice the names are the interesting ones, because they come from small mistakes:

/Identity-H — the CMap’s name, written into the font’s slot.
/identity — PDF names are case-sensitive, so this is a different name from /Identity.

An entry that is missing altogether is the separate condition 31-005.

What breaks

The value controls glyph selection, and an invalid value leaves it undefined. A viewer has to do something, and what it does is its own choice: it might assume /Identity, which is right if that is what the producer meant, or treat the font as unusable and substitute or draw nothing. Two viewers can render the same page differently, and neither is wrong, because the file did not say.

The text a screen reader gets usually survives, because it comes from the ToUnicode CMap, which maps codes to Unicode without passing through /CIDToGIDMap at all. On the test file used for this page — a CIDFontType2 with /CIDToGIDMap /Identity-H and a correct ToUnicode — Poppler’s pdftotext complained and still extracted the text correctly. What can be lost is the page as drawn. Where a viewer guesses wrong, correct words are announced over wrong glyphs — the mismatch that a sighted reviewer, a low-vision user and a screen-reader user will each report differently.

How to check it free

Poppler reports it directly. Running pdffonts or pdftotext over the file prints:

Syntax Error: Invalid CIDToGIDMap entry in CID font

when it loads such a font. It does not say which font, so follow up with qpdf.

qpdf. pdffonts prints each font’s object number; qpdf file.pdf --show-object=12 shows the Type 0 font, and the object in its /DescendantFonts array is the one to read for /CIDToGIDMap.

veraPDF with its PDF/UA-1 profile tests the entry under clause 7.21.3.2.

Acrobat Pro shows it, read-only, in Preflight: All tools → Use print production → Preflight, then Options → Browse Internal PDF Structure, and open the font from the page’s Resources down to its DescendantFonts. Adobe’s documentation describes the window as a viewer: you can navigate the structure and fonts but not edit them.

How to fix it

Acrobat has no command for this. Adobe’s advice for character-encoding problems is to re-create the PDF, and re-exporting from the source is the dependable fix.

If you can establish what the producer meant, it is also a one-value edit. For a subset embedded with an Identity-H encoding, /Identity is the likely intent, and it can be tested: qpdf --json-output with --json-object writes the CIDFont out as JSON, you change the value to "/Identity", apply it with --update-from-json, and render the result against the source document. If the glyphs match, that was the mapping. If they do not, the producer meant a lookup table, the table is not in the file, and the source is the only way back.

What Taggart does

Taggart reports a Type 2 CID font whose /CIDToGIDMap is a name other than /Identity — /Identity-H, /identity — as 31-004. Names are case-sensitive, so /identity is reported too. A stream is accepted. A missing /CIDToGIDMap is a different condition, 31-005.

Until October 2026 the check took every value for a stream, because it looked for the method that reads stream data and, in the PDF library Taggart uses, every object has one. It reported nothing. A test in the repository now builds a file with exactly that value and expects the finding.

There is no fix for either in Taggart.

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

What are the two allowed values?

The name /Identity, meaning CID n is glyph n in the embedded TrueType program, or a stream of two-byte big-endian glyph indices, one per CID, so that the glyph for CID c is at bytes 2c and 2c+1. Nothing else is defined.

Is /Identity-H close enough?

No. Identity-H is a CMap — it belongs in the Type 0 font's /Encoding, not in the CIDFont's /CIDToGIDMap. PDF names are exact, so /Identity-H, /identity and /IDENTITY are all simply not /Identity.

Does this affect what a screen reader says?

Usually not directly. Glyph lookup is what this entry controls; text extraction normally comes from the ToUnicode CMap, which does not pass through it. What it affects is what is drawn — and a page whose glyphs are wrong is wrong for everyone reading it by eye, including people using magnification.

Does Taggart report it?

Not today. The check exists, but it decides whether the value is a stream in a way every value passes, so an invalid name is taken for a stream. Use Poppler or veraPDF for this one until that is fixed.

Where this sits in the standards

Standards this condition maps to
Standard	Reference
Matterhorn Protocol 1.1	Checkpoint 31 (Fonts), index 31-004
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.