Matterhorn 31-014 · PDF/UA-1 UA1:7.21.4.2-3

CIDSet that leaves out glyphs the CID font contains

BlockerCheckpoint 31: FontsWCAG 1.3.1 (A)

CIDSet must accurately list the CIDs in the embedded subset.

The condition, as the protocol states it. “The FontDescriptor dictionary of an embedded CID font contains a CIDSet string, but at least one of the glyphs present in the font program is not listed in the CIDSet string.”

Matterhorn Protocol 1.1, checkpoint 31, index 31-014, section UA1:7.21.4.2-3. Software can decide this one on its own.

Processors may mis-handle the subset.

What CIDSet is

A CID font — the kind most producers use for Unicode text, including Hebrew, Arabic and CJK — refers to its glyphs by number, the CID. Its font descriptor may carry a /CIDSet stream saying which CIDs the embedded subset contains. It is a bitmap: one bit per CID, high-order bit first, so the first byte covers CIDs 0 to 7, the second 8 to 15, and so on.

PDF/UA-1 does not require it. If it is present, it must identify every CID present in the font program, used or not. This condition is a bit left clear for a CID that is there; a bit set for a CID that is not is 31-015.

In the file Taggart’s test suite uses for this page, the embedded TrueType program has four glyphs and an /Identity CIDToGIDMap, so CIDs 0 to 3 are present. The CIDSet is one byte:

/CIDSet  <E0>        % 1110 0000 → CIDs 0, 1, 2

CID       0  1  2  3  4  5  6  7
bit       1  1  1  0  0  0  0  0
program   ✓  ✓  ✓  ✓

CID 3 is in the program and on the page, and its bit is clear.

Nothing different. The page draws its three glyphs and pdftotext reads them; CIDSet plays no part in either. That needs saying, because the condition is reported as a blocker and a reader is not losing anything. The file is non-conformant because it describes its own subset wrongly, and the cost falls on software that believes the description — a processor deciding from CIDSet which glyphs it can reuse will think CID 3 is not available.

Where it comes from

A bitmap built from the text instead of the program. A producer that sets a bit for every CID its text uses has written the set of used CIDs, which is not what the field means. Anything the subset holds that the text does not use goes missing from it. The most predictable casualty is CID 0: it is .notdef, every TrueType program has it, and no text sets it on purpose. A CIDSet whose first bit is clear fails on that alone.

Glyphs that travel with other glyphs. A TrueType accented letter can be a composite that draws its base letter and its accent from other glyphs, so a subsetter keeps those too. They are in the program, and a bitmap built from the text leaves them out.

A program replaced without its descriptor. Re-subsetting or swapping the embedded program and copying the old CIDSet across leaves a bitmap for a different subset.

How to check it free

veraPDF tests it under clause 7.21.4.2, for fonts whose name carries a subset tag (ABCDEF+…). A full font with an inaccurate CIDSet is not checked by that rule.

Read the bits yourself. The bitmap is a few bytes and a short script lays it beside the program. This uses the free Python libraries pikepdf and fontTools, for TrueType-based CID fonts:

import io, sys
import pikepdf
from fontTools.ttLib import TTFont

with pikepdf.open(sys.argv[1]) as pdf:
    for fd in pdf.objects:
        if not (isinstance(fd, pikepdf.Dictionary) and "/CIDSet" in fd and "/FontFile2" in fd):
            continue
        bits = bytes(fd.CIDSet.read_bytes())
        listed = [cid for cid in range(len(bits) * 8) if bits[cid // 8] & (0x80 >> cid % 8)]
        glyphs = TTFont(io.BytesIO(bytes(fd.FontFile2.read_bytes())))["maxp"].numGlyphs
        print(fd.FontName, "CIDSet lists", listed, "- program has glyphs 0 to", glyphs - 1)

On the test file it prints CIDSet lists [0, 1, 2] - program has glyphs 0 to 3. With an /Identity CIDToGIDMap, CIDs and glyph numbers are the same; with a CIDToGIDMap stream, map each CID through it first.

Acrobat Pro shows the structure, though not the bits in this form. Following Adobe’s guide to advanced preflight inspections: select Use print production → Preflight from the All tools menu, then Options → Browse Internal PDF Structure to find the descriptor’s CIDSet, and Options → Create Inventory for the glyphs each font contains — Adobe’s page on Preflight reports describes what the inventory lists.

How to fix it free

Remove CIDSet. It is optional and the condition only exists when it is present, so deleting it resolves this without changing anything that is drawn or read:

import pikepdf

with pikepdf.open("in.pdf") as pdf:
    for obj in pdf.objects:
        if isinstance(obj, pikepdf.Dictionary) and "/CIDSet" in obj:
            del obj["/CIDSet"]
    pdf.save("out.pdf")

Acrobat cannot do this: Adobe’s page on the structure browser says you can navigate the PDF and its fonts there but not edit them, and Adobe documents no Preflight fixup that rewrites a CIDSet.

If the file also claims PDF/A-1, keep the entry and correct it instead, because PDF/A-1 requires CIDSet on CID font subsets. The 31-015 page has a script that rebuilds the bitmap from the program for the common /Identity case.

What Taggart does

Taggart does not detect this condition. It does not open embedded font programs, so it cannot tell which CIDs a program holds. On the test file it reports nothing about the font; the condition sits instead on the list of those Taggart asks a person to confirm before it will claim PDF/UA conformance.

What it does report under 31-014 is narrower: a descriptor with a CIDSet and no embedded program for it to describe.

/JBATCH+CIDSetShort declares a /CIDSet but has no embedded font program to describe.

That font also gets 31-009, which is the finding to act on — a CIDSet can only be right or wrong about a program that is there. For the condition on this page, use veraPDF or the script above before you confirm it.

How Taggart handles it

Software could decide this one, and Taggart does not check it yet. A clean report from Taggart says nothing about it either way. It is on the list of conditions Taggart asks you to confirm before it writes the PDF/UA claim into the file; check it by hand or with another validator, as 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

Does a wrong CIDSet affect what a screen reader reads?

No. A viewer draws from the font program and a reader takes characters from the ToUnicode CMap; neither consults CIDSet. The condition is about the file describing its own subset accurately, and its cost falls on software that trusts the description.

Is it safe to remove CIDSet?

For PDF/UA, yes: it is optional, and the requirement only applies when it is present. PDF 2.0 deprecates it. The exception is a file that also claims PDF/A-1, which requires CIDSet on every CID font subset; rebuild it there instead.

Why would CID 0 be missing?

Because it is never on the page. CID 0 is the .notdef glyph, which every TrueType program has and no text deliberately uses. A producer that sets bits only for the CIDs its text uses leaves bit 0 clear, and the font fails on that alone.

What is a CID, as opposed to a glyph index?

A CID is the number the PDF uses for a glyph in a CID font; the glyph index is the number the font program uses. For a TrueType-based CID font the /CIDToGIDMap connects them, and with the common /Identity map they are the same number.

Where this sits in the standards

Standards this condition maps to
Standard	Reference
Matterhorn Protocol 1.1	Checkpoint 31 (Fonts), index 31-014
PDF/UA-1 (ISO 14289-1)	Clause 7.21.4.2-3
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 does not check this condition yet, and lists it for you to confirm. Its validator is free and checks 75 of the 87 Matterhorn conditions software can decide — no watermark, no expiry, and no account needed up to 60 pages.

Check a PDF free

Taggart does not check this condition yet. A generated file that fails it is in the repository, with a test that fails the day Taggart starts catching it. Written on 2026-10-02. The Acrobat steps follow Adobe’s documentation and were not walked through by hand. Last updated 2026-10-02.