Repository navigation
Ligature characters (fi/fl/ffi) are dropped instead of expanded when extracting PDF text #172
Description
Summary
When converting a PDF that uses typographic ligatures (fi, fl, ffi, etc.), anydoc drops the ligature glyph entirely instead of expanding it to its constituent letters. This silently corrupts words in the output.
Repro
npx -y @firecrawl/anydoc "EU AI-Act-overview-30-May-2024.pdf" -o out.md
Source PDF: https://artificialintelligenceact.eu/high-level-summary/ (also mirrored at futureoflife.org)
Observed
| Expected | anydoc output |
|---|---|
| classifies | classi es |
| affected | a ected |
| influence | in uence |
| profiling | pro ling |
| identification | identi cation |
| traffic | traf c |
Reproduced consistently across the document (7+ occurrences), always at an fi/fl/ffi ligature boundary.
Expected behavior
The ligature glyph should be expanded to its plain-text equivalent (e.g. "fi" glyph → "fi"), not dropped. For comparison, a separate OCR pipeline (pdftotext-based) on the same PDF preserves these correctly, either as the literal Unicode ligature codepoint (fi, fl) or as decomposed ASCII — either of which renders/reads correctly, unlike anydoc's current output which deletes the letters.
Environment
- @firecrawl/anydoc version: 0.2.4
- Invocation: CLI, no --ocr flag (native PDF text extraction path — same result with --ocr hosted, since this PDF doesn't need OCR)
- OS: macOS
Activity
aashish254 commentedon Sep 27, 2026
This looks addressed by the pdf-inspector bump in #181 (1.14.2 → 1.25.0). The pdf-inspector CHANGELOG records several ligature-handling fixes that landed between those versions:
f_t,f_f_i,T_h) or aunisequence (uni00660069) decoding to the letters they stand for.Local verification: pdf-inspector HEAD's
tests/fixtures/ligature_glyph_names.pdfextracts cleanly through the builtpdf2md(no dropped letters). I have not re-run the reporter's specific EU AI-Act PDF end-to-end — maintainers or the reporter should confirm on the original file before closing.