# OCRmyPDF v17.7.1

- Product: OCRmyPDF (https://whatsnew.fyi/product/ocrmypdf)
- Vendor: ocrmypdf
- Date: 2026-07-17
- Version: v17.7.1
- Original notes: https://github.com/ocrmypdf/OCRmyPDF/releases/tag/v17.7.1
- Permalink: https://whatsnew.fyi/product/ocrmypdf/releases/v17.7.1

What's New is an index, not a publisher: every entry below links to the vendor's own release notes, which are the authoritative source. Entries are labelled where they are hand-curated sample data, pre-releases, or drawn from a secondary source such as a developer blog.

Reuse: the summaries, labels and curation here are © What's New. Quote freely with attribution and a link back; wholesale republication of the corpus is not permitted — terms: https://whatsnew.fyi/terms. The vendors' own release notes remain their publishers'.

---

- **fixed** — Fixed a severe Windows-specific performance regression in the scanning contents phase, most visible with --redo-ocr, by removing the 256 MiB pdfminer read buffer workaround now that upstream pdfminer.six has fixed the underlying token handling bug
- **changed** — Raised minimum pdfminer.six version to 20260107 to use the upstream fixes for token handling across buffer and stream boundaries
- **changed** — Font discovery now finds variable fonts such as NotoSansArabic[wdth,wght].ttf in addition to static -Regular.ttf/.otf files
- **changed** — Font discovery is now language-aware for CJK, mapping each Chinese, Japanese, and Korean language to its own per-language Noto family with the pan-CJK super font as a shared fallback
- **changed** — Reworded the no font found warning to explain that text is still added as a searchable, copyable layer but appears blank when highlighted, and to name the specific font family to install

- Fixed a severe, Windows-specific performance regression in the "Scanning
  contents" phase, most visible with `--redo-ocr` ({issue}`1662`). Since
  v16.4.3, OCRmyPDF forced pdfminer's read buffer to 256 MiB to work around a
  pdfminer bug that mishandled tokens split across the buffer boundary
  ({issue}`1361`). On Windows, CPython's `BufferedReader.read()` eagerly
  allocates a buffer of the requested size on every read, so the oversized
  buffer made each of pdfminer's thousands of reads cost tens of milliseconds
  (this allocation is lazy, and effectively free, on Linux). The underlying
  pdfminer bug was fixed upstream in pdfminer.six 20250327
  ([#1030](https://github.com/pdfminer/pdfminer.six/pull/1030)), with a
  follow-up for tokens split across streams in 20260107
  ([#1158](https://github.com/pdfminer/pdfminer.six/pull/1158)), so the
  workaround has been removed and the minimum pdfminer.six version raised to
  20260107.
- The font discovery used to build the OCR text layer now finds variable fonts
  such as `NotoSansArabic[wdth,wght].ttf`, the form shipped by Homebrew casks
  and current Google Fonts releases. Previously only static `-Regular.ttf`/`.otf`
  files were matched, so users who had installed the correct Noto font still got
  the glyphless fallback and a "No font found" warning ({issue}`1652`).
- Font discovery is now language-aware for CJK: each Chinese, Japanese, and
  Korean language maps to its own per-language Noto family (NotoSansSC, TC, HK,
  JP, KR), with the pan-CJK super font kept as a shared fallback, since the
  per-language fonts are region subsets that may lack glyphs from other scripts.
- The warning shown when no installed font has glyphs for some text was reworded
  to explain the consequence — the text is still added as a searchable, copyable
  layer but appears blank when highlighted in a viewer — and to name the specific
  font family to install.