Why Text Copied From a PDF Turns Into Symbols

The page looks right, the words are readable, and yet copy and paste gives question marks, boxes or letters that are plainly wrong. Searching the document for a word you can see finds nothing. This is not a bug in your viewer: it is how PDF stores text, and it can be traced to a specific font.

A PDF draws glyphs

A PDF page says "draw glyph number 57 from this font at this position". It does not need to say that glyph 57 is the letter "g". For display that is enough. For copying, searching and screen readers, the viewer needs to turn glyph codes back into text, and it does this with information inside the font: a /ToUnicode CMap that maps codes to Unicode (ISO 32000-1, clause 9.10.2), or failing that a standard encoding, or the font program's own character table.

When none of that is reliable, the viewer guesses, and you get symbols. Typical situations:

• A composite (CID) font with Identity encoding and no ToUnicode map. The codes are glyph numbers; only the map could say what they mean.
• A Type 3 font, whose glyphs are little drawings inside the PDF. They have no letter identity unless a ToUnicode map is added.
• A simple font with a custom encoding whose glyphs are named generically (g12, glyph034) and no ToUnicode map.
• A ToUnicode map that maps to private-use code points or to the replacement character, so the text is "valid" but unreadable.
• Text converted to outlines or drawn as pictures, which has no text at all.
• Legacy fonts, common for Bangla (SutonnyMJ and other Bijoy-style fonts): the text is real, but it is Latin characters that only look right in that font. The Bijoy PDF to Unicode tool converts such text.

Finding the cause

The PDF Copy-Paste Text Health Checker does two things. It inspects every font for these patterns, and it extracts the text of each page and scores how much of it is ordinary text: the share of characters that are letters, digits, punctuation and symbols after removing replacement characters, private-use code points, control characters, "(cid:123)" placeholders and the tell-tale sequences of UTF-8 read as Latin-1. The result names the font and the pages. The score is a heuristic: it cannot see letters that are valid but wrong, which is why the font table and the page preview matter as well. For a plain list of the fonts, with embedding and subset status, use the PDF Font Checker.

Different viewers use the mapping differently, so a page that copies well in one viewer can fail in another. If a PDF is a scan, there is no text to copy; it needs OCR first, and the hidden text layer that OCR adds should then be checked with the PDF OCR Layer Alignment Checker.

Fixing it at the source

• Export again from the original program with fonts embedded and a ToUnicode map (most "Save as PDF" and "PDF/A" settings do this; "convert text to outlines" and "print to PDF" through a driver that draws glyphs as shapes do not).
• Avoid Type 3 fonts in the source document where you can; bitmap fonts from old LaTeX setups are a classic cause.
• For legacy Bangla fonts, use a Unicode font in the source document.
• If you only need the words, a PDF-to-text converter or OCR on the rendered page can recover them, at the cost of possible recognition errors.

A PDF with a sound text mapping also works better for search, accessibility and archiving, which is why a copy test is a cheap check before you publish a file. See also the guide to text extraction and OCR.