Matterhorn 31-001 · PDF/UA-1 UA1:7.21.3-1

CIDSystemInfo Registry mismatch between CMap and font

BlockerCheckpoint 31: FontsWCAG 1.3.1 (A)

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

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

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

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

One font, several objects

A composite font in PDF — /Subtype /Type0, the kind used for Chinese, Japanese and Korean text and for many other embedded fonts — is not one dictionary. Two objects work in sequence to draw it:

The CMap, named in the font’s /Encoding, reads the bytes in the content stream and turns them into CIDs — character identifiers.
The CIDFont, in /DescendantFonts, turns each CID into a glyph to draw.

Alongside them, a ToUnicode CMap, if there is one, turns the same codes into Unicode for extraction.

A CID is just a number. It only means a particular character inside a character collection, which is named by three values in a /CIDSystemInfo dictionary: /Registry, /Ordering and /Supplement. Both the CMap and the CIDFont carry one:

12 0 obj                                  % the Type 0 font
<< /Type /Font /Subtype /Type0
   /BaseFont /ABCDEF+JPMincho-Regular
   /Encoding 14 0 R                       % an embedded CMap
   /DescendantFonts [ 13 0 R ]
   /ToUnicode 15 0 R >>

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 CMap stream's dictionary
<< /Type /CMap /CMapName /Custom-H
   /CIDSystemInfo << /Registry (Adobe) /Ordering (Japan1) /Supplement 6 >>
   /WMode 0 /Length 2210 >>

The CMap produces CIDs in its collection; the font interprets them in its collection. PDF/UA requires the two Registry strings to be identical, because if they are not, the numbers coming out of one are being read against a different list by the other. Under Identity-H and Identity-V the rule is waived: those CMaps pass codes through unchanged and do not claim any collection.

What Registry is, in practice

Registry names who defined the collection. Every predefined CMap in ISO 32000-1 Table 118 — the GB, CNS, JIS and KSC families, the Uni… Unicode CMaps and Identity — is in the Adobe registry. So when the two Registry strings disagree, it is typically because one side says (Adobe) and the other says something else: a vendor’s own name, a producer’s name, an empty string.

The comparison is exact. (adobe) is not (Adobe), and a trailing space is a different string.

What breaks, and what the reader hears

A screen reader does not read glyphs. It reads whatever Unicode the viewer can derive for each code, and for a CID-keyed font there are three routes to it:

The ToUnicode CMap. Code straight to Unicode. A Registry mismatch does not touch this route, and if the map is correct the reader hears the right text.
A Unicode CMap. If the encoding is one of the Uni…-UTF16 or UCS2 CMaps, the code is the Unicode value and a viewer can read it off directly.
The collection’s own table. Adobe publishes a CID-to-Unicode mapping for each of its collections, and PDF/UA lets a font in one of those collections leave ToUnicode out (that exemption is 31-027’s). This route needs the viewer to know the collection — and the two dictionaries disagree about which one it is.

So the honest answer is: with a correct ToUnicode the reader probably hears the right words, and the file still fails, because it contradicts itself. Without one, a viewer that trusts the CMap and a viewer that trusts the font come to different conclusions, and one of them has no table to look the CIDs up in. That is a font that draws and does not read — silence, or characters that are not the ones on the page.

Where it comes from

Not from authors. A Registry mismatch is made by tooling that builds the CIDFont dictionary and the CMap separately: a converter that rewrites the font’s /CIDSystemInfo with its own values and keeps the original CMap, or an editing step that replaces a font and leaves the old CMap pointing at it. The page can look entirely right, because the glyphs were chosen correctly by whatever produced them and only the label is wrong.

How to check it free

pdffonts (Poppler). It does not print CIDSystemInfo, but it tells you which fonts are worth looking at. A Type 0 font whose encoding column says Identity-H is exempt. One that says Custom has an embedded CMap — that is the case to inspect:

name                                 type              encoding         emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
ABCDEF+JPMincho-Regular              CID Type 0C       Custom           yes yes yes     12  0

qpdf (free). Read the three objects and compare the strings by eye: qpdf file.pdf --show-object=12 for the font, then the object numbers it points to for /DescendantFonts and /Encoding.

veraPDF with its PDF/UA-1 profile checks CIDSystemInfo compatibility under clause 7.21.3.

Acrobat Pro can show you the same dictionaries but not change them. All tools → Use print production → Preflight, then Options → Browse Internal PDF Structure, and walk down from the page’s Resources to the font. Adobe’s documentation for that window is explicit that you can navigate the structure but not edit it.

How to fix it

Acrobat has no tool that edits a font’s CIDSystemInfo. For the character-encoding failures its own Accessibility Checker reports, Adobe’s guidance is to re-create the PDF — with the fonts installed, with a different font in the source, or with a newer Distiller — and that is the answer here too.

Re-export from the source. An export that writes the font with an Identity-H encoding and a ToUnicode CMap is exempt from this condition entirely, and is what current exporters commonly produce for embedded fonts.

Correct the label, if you know it is the label. With qpdf --json-output and --update-from-json you can rewrite a single string in a single object. That is a real repair only when the font genuinely is the collection the CMap names and something mislabelled it. If the font’s CIDs are its own numbering, the CMap is what is wrong, and changing the Registry to match makes a file that passes a validator and lies to every reader.

What Taggart does

For every Type 0 font that text is actually set in, Taggart compares the two /CIDSystemInfo dictionaries and reports a mismatch as a blocker, with the first page the font appears on, its object number and both values:

/ABCDEF+JPMincho-Regular: the CIDSystemInfo /Registry differs between the CMap (‘Adobe’) and the descendant CID font (‘Vendor’).

It skips Identity-H and Identity-V, as the rule does.

It has a gap that matters. Taggart compares against the CMap’s CIDSystemInfo only when the CMap is embedded in the file. When the font names a predefined CMap from Table 118 — /UniJIS-UTF16-H, say — that CMap’s collection is defined outside the file, Taggart does not look it up, and a descendant font in another registry is not reported. A clean Taggart report says nothing about that case, so read the CIDFont’s /CIDSystemInfo yourself and compare it with the collection the CMap belongs to — UniJIS… CMaps are Adobe-Japan1, UniGB… Adobe-GB1, UniCNS… Adobe-CNS1, UniKS… Adobe-Korea1.

There is no fix. 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 Registry, in a PDF font?

The first part of a character collection's name. A collection is written Registry-Ordering-Supplement — Adobe-Japan1-6, say — and the Registry is the organisation that defined it. Every CMap in ISO 32000-1 Table 118 belongs to the Adobe registry, so in practice a mismatch means one side is not describing an Adobe collection at all.

Does this apply to fonts with an Identity-H encoding?

No. Identity-H and Identity-V pass each code straight through as a CID and claim no collection, so the CID font may carry any CIDSystemInfo it likes. The condition only applies when the CMap is something else — a named CMap such as UniJIS-UTF16-H, or one embedded in the file.

If the text extracts correctly, can I ignore it?

You can understand it, but not ignore it. If the font has a correct ToUnicode CMap, extraction does not depend on the collection and the reader is probably unaffected. The file still fails PDF/UA, and it still says two contradictory things about what its CIDs mean, which is exactly what a different viewer may resolve differently.

Can I just change the string so they match?

Only if you know which side is right. If the font really is an Adobe collection and something wrote the wrong Registry into it, correcting the label is a true repair. If the font's CIDs are its own private numbering, relabelling it Adobe makes the file pass and tells every reader a falsehood.

Where this sits in the standards

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