CIDSystemInfo must agree between font and CMap

PDF/UA check FONT_CIDSYSTEMINFO_COMPAT · Fonts & text encoding · severity High · PDF/UA 8.4.5.3.1 CIDSystemInfo · advanced check

↩ Back to the rules index · WCAG cross-reference

Advanced check. This is a file-internals rule. It is hidden from the standard report view and generally indicates a problem with the tool that produced the PDF rather than something an author did.

Why it matters#

Mismatched CIDSystemInfo entries cause character lookups to fail, breaking text extraction and screen reader output.

What you will see#

A Type 0 font declares different Registry/Ordering/Supplement values in its CIDFont and its CMap.

How to fix#

Make the Registry and Ordering values identical in the CIDSystemInfo dictionaries of both the CIDFont and the CMap, and set the CIDFont's Supplement greater than or equal to the CMap's. Alternatively, switch the font's Encoding to Identity-H or Identity-V, which allows any CIDSystemInfo values.

Step-by-step guide#

1. Identify the flagged Type 0 (composite) fonts. In Acrobat Pro, use File > Properties > Fonts for an overview, or All tools > Use print production > Preflight > Options > Create inventory to list each font's Encoding value and the CIDSystemInfo (Registry, Ordering, Supplement) of both the CIDFont and the CMap.
2. Choose one of the two configurations PDF/UA-2 clause 8.4.5.3.1 accepts: (a) the Type 0 font's Encoding is Identity-H or Identity-V, in which case any CIDSystemInfo values pass, or (b) the CIDFont and CMap CIDSystemInfo dictionaries are made compatible.
3. For path (b), set the Registry and Ordering strings in the CIDFont's CIDSystemInfo dictionary byte-for-byte identical to those in the CMap's CIDSystemInfo dictionary, and set the two Supplement values equal. The standard itself allows the CIDFont's Supplement to exceed the CMap's, but EQChecker requires an exact match, so equal values are the safe target.
4. For path (a), change the font's Encoding to Identity-H (or Identity-V for vertical text). This changes how content-stream character codes are interpreted and requires matching rewrites of the codes and the W array, which cannot be expressed in Acrobat - in practice it is only achievable by regenerating the file from its source.
5. Prefer fixing at the source: re-export the PDF from the authoring application with a current PDF exporter, which writes consistent CIDSystemInfo entries automatically.
6. If re-export is impossible, the producing application wrote incompatible CIDSystemInfo dictionaries and Acrobat Pro has no UI for editing them; the only reliable fix is regenerating the file from its source with a compliant export pipeline.

Verify: Re-run the EQChecker advanced scan and confirm FONT_CIDSYSTEMINFO_COMPAT reports zero errors. Copying text from the affected fonts should still produce correct characters.

Note: The rule applies only to Type 0 fonts whose Encoding is not Identity-H or Identity-V; Identity-encoded fonts pass with any Registry, Ordering, and Supplement values. The standard's Supplement rule exists so the CIDFont includes glyphs for every CID the CMap can reference; EQChecker demands equal Supplement values rather than merely greater-or-equal.

WCAG success criteria#

No WCAG success criterion maps cleanly to this check — it is a PDF/UA structural requirement. The PDF/UA clause above is the normative reference.

Standards#

This check contributes to the following standards:

PDF/UA