pdfce v0.11.0 - a search that no longer lies by omission

A search that no longer lies by omission

Yesterday's release made Type 3 fonts draw — the glyphs that are little
content streams rather than a font program. This one makes that text
searchable and copyable, and, where it cannot be, makes pdfce say so.

The problem, in one sentence

A search that returns 0 results for a word plainly visible on the page
looks exactly like a search for a word that genuinely is not there.

Why that happens

A Type 3 glyph is named by an arbitrary key inside the document — /g13,
/square — which means nothing outside that one file. So unless the file
carries a /ToUnicode character map, there is no way at all to know what
letter a shape represents. The text still draws perfectly. It simply cannot
be searched, copied or extracted.

Adobe Acrobat has the identical limit. The difference is that Acrobat
gives up silently. pdfce now tells you:

find-text report.pdf --needle "invoice"
...
matches=0 unreadable_codes=214 type3_no_tounicode=2 identity_no_tounicode=0

pdfce-cli: find-text: 2 Type 3 font(s) in this document carry NO /ToUnicode
  CMap (ISO 32000-1 §9.6.5) — their glyphs are content streams named by
  arbitrary /CharProcs keys, so text set in them RENDERS correctly and cannot
  be searched or copied. Acrobat is gated on the same entry
pdfce-cli: find-text: 214 of 3,180 character code(s) could not be mapped to
  Unicode ... A zero match count for this document is therefore not evidence
  the needle is absent

Each offending font is named individually, so you know which text on the
page is out of reach rather than just that some of it is.

Try it

tounicode_gate.pdf is attached — a three-line synthetic page built for this
release. The first line carries a character map and is findable; the other two
do not and are not. All three draw identically, which is the whole point.

pdfce-cli find-text tounicode_gate.pdf --needle "HI!"
pdfce-cli extract-text tounicode_gate.pdf
pdfce-cli render-page tounicode_gate.pdf --page 1 --output gate.png

Also in this release

• extract-text reports type3_no_tounicode= on its summary line and in its
  JSON output, and names each affected font on stderr.
• A second, wider defect was found and fixed on the way: pdfce's per-font
  diagnostics were keyed on the font's name, and the PDF standard gives a
  Type 3 font no name at all. The effect was worse than under-counting —
  the first unnamed font on a page silenced every unnamed font behind it,
  including warnings that had nothing to do with Type 3. Such fonts are now
  reported individually and identified by the name the page itself uses.
• New pdfce-core verb EditSession::search_text, returning the hits and the
  diagnostics together. find_text and find_text_with are unchanged.

Known, and named rather than left to be discovered

• Redaction by search does not yet disclose this. A "redact every match"
  run over text pdfce cannot read marks nothing and says nothing. Next up.
• Type 3 text cannot be edited. Acrobat cannot edit it in place either.

---

Windows x64, single folder, no installer, no registry writes. Extract and run
pdfce-gui.exe or pdfce-cli.exe. MIT licensed; third-party attributions
ship in the folder.