Embedded font with unverified glyph mapping
The document embeds a font whose glyph mapping this engine could not read, so the extracted text may differ from what a reader sees.
How the text is hidden
A document can ship the font it is rendered with, under word/fonts/, ppt/fonts/ or xl/fonts/. That font's cmap decides which glyph each character paints, so the stored text and the drawn page can disagree with no markup signal whatsoever — no <w:vanish/>, no white colour, no sub-readable size. PowerPoint normally writes Embedded OpenType, often MicroType Express compressed; Word writes a plain .ttf or an .odttf obfuscated with a key held in fontTable.xml.
Why a model still reads it
The text extracts exactly as written — every extractor, this one included, reads what the XML says. The claim here is the inverse of the raster disclosure's: not that content went unread, but that the text this engine did report may not be the text on the page.
What we do about it
Every font part is inflated and read where it can be — a plain sfnt directly, an .odttf deobfuscated against each key found in fontTable.xml, an uncompressed EOT wrapper skipped past its header, a MicroType Express one decompressed and read through CTF. Fonts that were read drop off this list entirely; what remains is disclosed by part name, stored size, and where the bytes themselves say so, a reason (eot-microtype-express, eot-xor-encrypted, eot-unsupported, obfuscation-key-missing). Presence is the signal with no size floor, on the reasoning that a small subset font can remap the digits in a payment term as well as a large one. Informational, action: "disclosed", chars: 0; nothing is stripped or flagged, and certified goes false.
How often it fires
Not measured. We publish a rate only where one has been measured against a named corpus of the right format, and no figure exists for this technique yet. Absence means unknown — never low.
Check your own file
Three commands: a key, credit, a verdict.
Start with the API