Matterhorn 17-003 · PDF/UA-1 UA1:7.7-2

Maths symbols that render but cannot be read as characters

Mathematical glyphs — often from a symbol font with no ToUnicode — cannot be mapped to Unicode.

What a screen reader actually does

Operators and Greek letters are announced as replacement characters or dropped.

What the condition is

PDF/UA-1 clause 7.7 has two halves. The first puts every expression in a Formula with /Alt (17-001, 17-002). The second says the Unicode mapping requirements apply to mathematical expressions too: every character code in the formula has to resolve to a Unicode value, through a /ToUnicode CMap or one of the exemptions PDF/UA-1 lists for fonts (clause 7.21.7). Condition 17-003 is that second half failing.

It is the same requirement as 10-001 and 31-027, restated for maths because maths fonts are a common place for it to go wrong.

Why maths fonts in particular

Text fonts commonly use a standard encoding, and a standard encoding is a published table: byte 65 is A. Maths fonts often do not. TeX’s Computer Modern maths fonts each have their own layout — in cmsy10, slot 0 is the minus sign and slot 2 the multiplication sign — and they are typically embedded on that built-in encoding. Without a /ToUnicode map, nothing in the file says what slot 0 means.

$ pdffonts paper.pdf                       (columns abridged)
name                       type      emb sub uni
-------------------------- --------- --- --- ---
ABCDEF+CMR10               Type 1    yes yes yes
GHIJKL+CMMI10              Type 1    yes yes no
MNOPQR+CMSY10              Type 1    yes yes no

The body font maps; the maths fonts do not. The same happens with any symbol font set on a private encoding, and with fonts embedded as Identity-H CID fonts whose producer did not write a map.

What breaks

The page looks right. Then:

• Copy and paste of the formula gives nothing, boxes, or the wrong letters.
• Search for a symbol, or a Greek letter in an expression, finds nothing.
• A reader that reads the expression’s content, rather than its /Alt, gets replacement characters or skips the operators — the screen-reader line at the top of this page.
• Conversion of the formula to anything else — reflow, HTML, MathML — starts from characters it does not have.

With a good /Alt, a screen-reader user hearing the description may never notice. That is why this condition is easy to leave until someone tries to quote the equation.

How to check it free

Copy the formula into a plain text editor. If the operators come out wrong or missing, the mapping is broken.

pdffonts (Poppler, free). The uni column says whether each font has a /ToUnicode map. no on a font the formula uses is this condition, unless the font is exempt.

veraPDF. Rule 7.21.7-1 reports each glyph that cannot be mapped to Unicode. veraPDF’s PDF/UA-1 profile has no separate rule for the Unicode half of clause 7.7; maths glyphs are reported under that one. (veraPDF PDF/UA-1 rules)

Acrobat’s Accessibility Checker has a Character encoding rule. Adobe notes that some character-encoding problems are not repairable within Acrobat. (Adobe: Create and verify PDF accessibility)

How to fix it free

At the source — this is the real fix.

• pdfLaTeX: \input{glyphtounicode} and \pdfgentounicode=1 in the preamble make pdfTeX write /ToUnicode maps for Type 1 fonts from their glyph names. The mmap package extends cmap with coverage of Knuth’s maths fonts.
• LuaLaTeX or XeLaTeX with unicode-math set maths in OpenType maths fonts, which are encoded by Unicode, so a map can be written for them.
• Office documents: native equations rather than old Equation Editor or MathType objects, which arrive as pictures — a 17-001 problem rather than this one.

See LaTeX to accessible PDF for the tagging side.

In Acrobat, there is no repair to make. Adobe’s advice for character-encoding failures is to verify the fonts are installed, use a different font in the original document, and re-create the PDF.

Where Taggart differs

Taggart reports 17-003 once per document, when the document has at least one Formula and at least one font in use with no /ToUnicode map and no PDF/UA exemption:

The document contains 1 <Formula> element(s) and 1 font(s) with no usable Unicode mapping (/MathSym), so the mathematical characters cannot be extracted.

Four things about how it decides, so the finding reads correctly:

• It is document-wide. The fonts named are every unmapped font in use, not only the ones inside a formula. The same fonts are also reported as 10-001 and 31-027.
• Only a missing map counts. A /ToUnicode that exists but leaves out the operators is reported as 10-001, with the missing codes listed, and not as 17-003. Maps that send codes to U+0000 or to a byte-order mark are 31-028 and 31-029.
• The exemption test reads /Differences, not the font program. A Type 1 font on its built-in encoding — TeX’s maths fonts, or the standard Symbol font — is reported even where the glyph names inside the program might qualify it for the exemption.
• No Formula, no 17-003. An expression tagged as a paragraph in an unmapped font is reported as 10-001 and 31-027 only.

The repair, tounicode-repair, is never applied in bulk; it is proposed and waits for approval. It writes a map only where the mapping is a lookup rather than a guess: a published encoding, glyph names from the Adobe Glyph List, or the file’s own /ActualText where each glyph sits in a span of its own saying what it is. A font with either of the first two is usually exempt and never flagged here, so for 17-003 the third is the route that matters. A maths font with an Identity-H encoding and none of those is refused:

cannot recover a Unicode mapping for: /MathSym. Re-export the source document with the fonts embedded rather than letting Taggart guess.

The same refusal applies to a Type 1 maths font on its built-in encoding. A wrong map would make the formula extract confidently as the wrong characters, which is harder to notice than characters that do not extract at all.

How Taggart handles it

Taggart checks for this condition automatically and reports it as a blocker, with where in the file it found it.

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.

Where this sits in the standards

Related conditions

• 10-001 Character code cannot be mapped to UnicodeA glyph is painted whose character code has no Unicode equivalent reachable through the font's ToUnicode CMap, encoding, or glyph names. The text renders correctly but cannot be extracted.
• 31-027 A font dictionary does not contain the ToUnicode entry and no exemption appliesA 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.
• 17-002 Formula tag is missing an Alt attributeA Formula element has no /Alt giving the expression in words.
• 12-001 Stretched characters are not represented appropriatelyGlyphs stretched to fill space — kashida elongation in Arabic, stretched brackets in mathematics — must map to the character they represent, not to a sequence of repeated glyphs.

Other conditions in checkpoint 17

Checkpoint 17 covers mathematical expressions. These are its other failure conditions; the ones without a link are in the rule set but do not have a written page yet.

• 17-001 Content is a mathematical expression but is not tagged with a Formula tagAn equation is tagged as a paragraph or a figure rather than a Formula.
• 17-002 Formula tag is missing an Alt attributeA Formula element has no /Alt giving the expression in words.

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.