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

CMap and CID font name different collections (Ordering)

BlockerCheckpoint 31: FontsWCAG 1.3.1 (A)

The CMap and the descendant CID font must agree on the character collection ordering.

The condition, as the protocol states it. “A Type 0 font dictionary with encoding other than Identity-H and Identity-V has values for Ordering in both CIDSystemInfo dictionaries that are not identical.”

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

Character codes resolve to the wrong glyphs, so extracted text is wrong.

A CID is a position in a list

In a composite (Type0) font, the CMap turns the bytes in the content stream into CIDs, and the descendant CIDFont turns CIDs into glyphs. A CID is a number, and on its own it means nothing. It means a character only inside a character collection: a numbered list published by Adobe, named by /Registry, /Ordering and /Supplement — Adobe-Japan1-6, Adobe-GB1-5, Adobe-CNS1-7, Adobe-Korea1-2.

/Ordering is the part that says which list. Japan1 and GB1 are different lists, of different lengths, compiled independently; CID 5000 in one is not CID 5000 in the other. So when the CMap and the font each carry a /CIDSystemInfo, PDF/UA requires their Ordering strings to be identical — unless the CMap is Identity-H or Identity-V, which pass codes through without claiming any collection.

One shape it takes: Identity under a real CMap

A font labelled Adobe-Identity-0 under a CMap from a real collection:

13 0 obj                                   % the CIDFont
<< /Type /Font /Subtype /CIDFontType2
   /BaseFont /ABCDEF+JPSerif-Regular
   /CIDSystemInfo << /Registry (Adobe) /Ordering (Identity) /Supplement 0 >>
   /CIDToGIDMap 17 0 R
   /FontDescriptor 16 0 R >>

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

Identity is a reasonable label for a TrueType font: it says the CIDs are the font’s own numbering, with a /CIDToGIDMap to turn them into glyph indices. But the CMap above is producing Japan1 CIDs. One of the two is describing something other than what the file does. If the producer built the CIDToGIDMap from Japan1 CIDs, the page draws correctly and the label is what is wrong; if it did not, the label may be accurate and the CMap is the mistake.

Because the Supplement is part of the same label, this file also fails 31-003: the font says 0, the CMap says 6.

What the reader hears

A screen reader gets whatever Unicode the viewer derives. For a CID-keyed font there are three ways to derive it, and this condition touches one:

ToUnicode. Codes straight to Unicode, no collection consulted. Correct map, correct speech.
A Unicode CMap. With UniJIS-UTF16-H and its relatives the code is itself the Unicode value.
The collection’s table. Adobe publishes a CID-to-Unicode mapping for each collection, and PDF/UA lets a font in Adobe-GB1, -CNS1, -Japan1 or -Korea1 rely on it instead of shipping ToUnicode (the exemption in 31-027). To use it, the viewer has to know the collection.

On that third route the mismatch is not cosmetic. A file whose font says Japan1 under a GB1 CMap, read by a viewer that trusts the font, is looked up in the wrong table: the user hears Japanese characters that are not on the page, or, where the CID is beyond the end of the list, nothing. A font that says Identity has no table at all, so on that route there is nothing to extract and the text is silent. Which viewer trusts which dictionary is not something the file controls, and that is the reason for the rule.

Where it comes from

From pipelines that write the CIDFont and the CMap at different times. A converter turns a TrueType font into a CIDFont and labels it Adobe-Identity-0 — the ordinary label for a font with no standard collection — while the text is encoded through a Japanese or Chinese CMap chosen by another stage. A merge combines a font object from one file with a CMap from another. Authors do not cause it and cannot see it.

How to check it free

pdffonts (Poppler) narrows it down. In its encoding column Identity-H and Identity-V are exempt; a CMap name or Custom (an embedded CMap) is where the rule applies.

qpdf shows both dictionaries. qpdf file.pdf --show-object=12 prints the Type 0 font; follow /DescendantFonts to the CIDFont and /Encoding to the CMap, and compare the /Ordering strings.

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

Acrobat Pro. Document Properties (File → Properties, or Menu → Document Properties in the newer interface) → Fonts lists each font with its type and encoding, per Adobe’s description of that tab. To see CIDSystemInfo itself use Preflight: All tools → Use print production → Preflight, then Options → Browse Internal PDF Structure and open the font from the page’s Resources. The window is read-only (Adobe).

How to fix it

There is no Acrobat command that edits either dictionary. Adobe’s own advice for character-encoding failures is to re-create the PDF, and that is the reliable route here.

Re-export from the source, ideally to Identity-H with a ToUnicode CMap, which is outside this condition altogether.

Or decide which side is lying, then edit that side. Render a page and compare it with the source: if the glyphs are right, the CMap’s collection is what the CIDToGIDMap was built for, and the font’s label is the mistake. Changing the CIDFont’s /Ordering (and /Supplement) to match the CMap is then a true statement, and qpdf --json-output with --update-from-json can make that one change. If the glyphs are wrong, the label may be right and the CMap is the problem — and no string edit fixes that.

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 Ordering strings and reports a difference as a blocker with both values:

/ABCDEF+JPSerif-Regular: the CIDSystemInfo /Ordering differs between the CMap (‘Japan1’) and the descendant CID font (‘Identity’).

On the Identity-under-Japan1 shape above it reports 31-003 alongside, because the Supplements also disagree.

The comparison runs only when the CMap is embedded. When the font names a predefined CMap — /UniGB-UTF16-H on a font labelled Japan1, for instance — the CMap’s collection is defined outside the file and Taggart does not look it up, so that mismatch is not reported. For those files, compare by hand: UniJIS… CMaps are Japan1, UniGB… GB1, UniCNS… CNS1, UniKS… Korea1.

There is no fix in Taggart. The finding is 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 does Ordering name?

The character collection itself: Japan1, GB1 (simplified Chinese), CNS1 (traditional Chinese), Korea1, or Identity. Each is a numbered list of characters, and a CID is a position in one of those lists. The same position in two lists is two different characters.

My font says Adobe-Identity-0. Is that wrong?

Not on its own. Identity means the font's CIDs have no standard meaning — they are its own glyph numbers — and that is correct for most embedded TrueType fonts. It becomes a failure when the CMap is not Identity-H or Identity-V, because then the CMap is producing CIDs from a real collection and the font has just said it does not use one.

Why does one file fail 31-002 and 31-003 together?

Because the label is usually wrong as a whole. A font marked Adobe-Identity-0 under a CMap from Adobe-Japan1-6 disagrees on Ordering (Identity against Japan1) and on Supplement (0 against 6), so both conditions fire for one mistake.

Will a screen reader actually read the wrong characters?

Only on one route. If the font has a correct ToUnicode CMap, or the CMap is a Unicode one, the viewer gets Unicode without consulting the collection, and the reader hears the right text. If it falls back on the collection's own CID-to-Unicode table, it has to choose between the two Orderings, and choosing the wrong one gives different characters from the ones on the page.

Where this sits in the standards

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