Taggart
Check a PDF free

Matterhorn 31-027 · PDF/UA-1 UA1:7.21.7-1

Missing ToUnicode CMap: the PDF looks fine and extracts nothing

Blocker Checkpoint 31: Fonts WCAG 1.3.1 (A)

A ToUnicode CMap is required unless the font uses MacRoman/MacExpert/WinAnsi encoding, or is a Type 1/Type 3 whose glyph names are all in the Adobe Glyph List or the Symbol set, or is a Type 0 whose descendant uses a standard Adobe character collection, or is a non-symbolic TrueType.

The condition, as the protocol states it. “A font dictionary does not contain the ToUnicode entry and none of the exemptions in 7.21.7-1 apply.”

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

What a screen reader actually does

Text renders but extracts as nothing. This is the number-one cause of "the PDF looks fine but the screen reader is silent".

Why a PDF can be text and not text

A PDF content stream does not contain characters. It contains instructions to draw glyphs:

BT /F1 11 Tf 1 0 0 1 72 700 Tm <0037 0048 0055 0050 0056> Tj ET

Those are glyph indices in a subsetted font. Whether they mean Terms or something else depends entirely on what the font dictionary says. PDF/UA-1 clause 7.21.7 requires a /ToUnicode CMap unless one of a short list of exemptions applies:

  • the font uses MacRomanEncoding, MacExpertEncoding or WinAnsiEncoding;
  • it is a Type 1 or Type 3 font whose referenced glyph names are all in the Adobe Glyph List or the Symbol set;
  • it is a Type 0 font whose descendant CIDFont uses Adobe-GB1, Adobe-CNS1, Adobe-Japan1 or Adobe-Korea1;
  • it is a non-symbolic TrueType font.

If none applies and there is no /ToUnicode, the characters cannot be recovered. Condition 31-027 fires.

A ToUnicode CMap is an ordinary PostScript-style CMap stream:

/CIDInit /ProcSet findresource begin
12 dict begin
begincmap
/CMapName /Adobe-Identity-UCS def
/CMapType 2 def
1 begincodespacerange
<0000> <FFFF>
endcodespacerange
5 beginbfchar
<0037> <0054>    % glyph 0x37 is "T"
<0048> <0065>    % "e"
<0055> <0072>    % "r"
<0050> <006D>    % "m"
<0056> <0073>    % "s"
endbfchar
endcmap
CMapName currentdict /CMap defineresource pop
end
end

How to check a file free

Copy and paste. Select a paragraph in any viewer, paste it into a plain text editor. If you get boxes, question marks or the wrong letters, the mapping is broken. This catches most of it in five seconds.

Search inside the PDF. Ctrl/Cmd + F and type a word you can see on the page. No match means no extractable text.

pdffonts (Poppler, free). pdffonts file.pdf lists every font with an uni column. no in that column is a font with no ToUnicode:

name                    type         emb sub uni
----------------------- ------------ --- --- ---
ABCDEF+HelveticaNeue    Type 1C      yes yes no

veraPDF or PAC. Both report 7.21.7 violations by clause. Both are free.

How to fix it, and when you cannot

If the source document exists, re-export. This is the real fix and it is free. In Word: File → Save as Adobe PDF, or Export → Create PDF/XPS with Document structure tags for accessibility ticked. In InDesign: export as Adobe PDF (Interactive) or (Print) with Create Tagged PDF on. Both write correct ToUnicode data. In LaTeX, add \usepackage{cmap} before fontenc, or switch to LuaLaTeX or XeLaTeX with fontspec, which produce correct mappings by default.

If the font is standard, nothing is wrong. A font using WinAnsi encoding is exempt and extracts correctly without a ToUnicode CMap at all. Check the encoding before you go looking for a problem.

If it is a subsetted font with an Identity encoding and no ToUnicode, the information is not in the file. It cannot be recovered by any tool, because there is nothing to recover it from. Your options are the source document, or OCR over the rendered page — accepting that OCR introduces its own errors, and that those errors are invisible to a sighted reviewer, which is condition 08-001.

Acrobat’s Preflight (Print Production → Preflight) has fixups for some font problems, but none of them invent a Unicode mapping, and that is correct behaviour.

Where Taggart differs

Taggart evaluates the exemptions rather than just looking for the entry, so it does not report a WinAnsi font as broken. For each font it reports what it found:

ABCDEF+HelveticaNeue has no ToUnicode CMap and none of the PDF/UA exemptions apply. Text set in this font renders but does not extract.

It also parses the CMaps that are present, and reports the two ways they fail quietly: codes mapped to U+0000 (31-028) and codes mapped to U+FEFF or U+FFFE (31-029). Both pass a presence check and both destroy extraction.

On the repair, Taggart is deliberately conservative. Where the encoding is recoverable it says so and explains that no CMap is needed. Where it is not, it refuses to write one and tells you why:

Cannot recover a Unicode mapping for: ABCDEF+HelveticaNeue. Re-export the source document with the fonts embedded rather than letting Taggart guess.

A wrong ToUnicode is worse than a missing one. A missing one is detectable; a wrong one silently corrupts every extraction, every search index and every screen reader from that point on, and looks conformant while doing it.

How Taggart handles it

Taggart detects this condition automatically. It is reported as a blocker, with the page, the structure path and the object id of every occurrence.

The fix is Repair ToUnicode CMaps. It changes what the document means, so Taggart proposes it and waits for your approval rather than applying it unattended.

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

The text is visible. How can it not be text?

Because a PDF paints glyphs by index, not by character. The content stream says 'draw glyph 47 of this font'. Which character glyph 47 represents is only recoverable if the font declares it — through a ToUnicode CMap, a standard encoding, or glyph names in the Adobe Glyph List. Without any of those, glyph 47 is a shape with no meaning attached.

Why does Acrobat's checker sometimes pass a file that extracts as gibberish?

Acrobat checks for the presence of a mapping, not its correctness. A ToUnicode CMap that maps every code to U+0020, or to zero, satisfies a presence check and destroys the text. Those are separate conditions — 31-028 covers zero targets and 31-029 covers byte-order marks — and they are worth checking for explicitly.

Can this be fixed automatically?

Only sometimes, and a tool that claims otherwise is guessing. If the font uses WinAnsi or MacRoman encoding, or its glyph names resolve through the Adobe Glyph List, the mapping is recoverable and no ToUnicode is even required. If it is a subsetted font with meaningless glyph names and no encoding, the information is simply not in the file, and inventing it silently corrupts every extraction from that point on.

Is this an OCR problem?

No, and the distinction matters. A scanned page has no text at all and needs OCR. A page with a broken ToUnicode has real text that cannot be read. Running OCR over it would discard perfectly good glyph positions and replace them with a guess. The fix is to repair or replace the font mapping, or to re-export from the source.

Where this sits in the standards

StandardReference
Matterhorn Protocol 1.1 Checkpoint 31 (Fonts), index 31-027
PDF/UA-1 (ISO 14289-1) Clause 7.21.7-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 — every machine-checkable Matterhorn condition, no page cap, no watermark, no account needed.

Check a PDF free

Verified against a real document on . Last updated .