wardethan2000-eng makes scanned evidence searchable

This fork adds the document-processing layer needed to turn scans, photos and office files into material the assistant can actually use.

discoveryworkflow

For legal teams, the important change is not just broader upload support. It is that text trapped inside a scanned bundle can be recognised after upload, then used in previews, citations and assistant responses while retaining page references and clearly identifying OCR-derived text.

  • Scanned PDFs and photographs can be converted into searchable text.
  • Plain-text and several common office and image formats can enter the same document workflow.
  • PDF renditions support more reliable viewing and page-level reference.

The trade-off is operational: processing happens after upload and may be slow or memory-hungry, so a deployment needs enough capacity and the required document-conversion tools in place.

So what Litigation and investigations teams handling messy, scan-heavy evidence should care because this moves more of the real bundle into searchable, citable working material.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

1 commit from wardethan2000-eng/mike, oldest first. Source extracted verbatim from the harvested git log.

SHA Subject Author Date
35f39239 feat: read scans, photographs and plain text Ethan Ward 2026-08-18 ↗ GitHub
commit body
Mike accepted eight file types and could only read a PDF's existing text
layer, so a scanned document came back as page numbers and nothing else.

Accepted types now also cover jpg, jpeg, png, tif, tiff, bmp, gif, heic, heif,
webp, txt, md, csv, rtf and odt. An uploaded picture becomes a PDF and is read
by OCR; a PDF that turns out to be a scan is given a text layer. Either way the
document previews, quotes and cites by page like any other, and text that came
from recognition is flagged so it is quoted with care. A low-resolution image
warns the user at upload, while it can still be rescanned.

Reading happens after the upload is answered - roughly eight seconds a page,
minutes for a long bundle - and the document shows as processing until done.
A PDF that already has text is checked in about a second and never waits.

Notes for later:
- ocrmypdf is pinned to --jobs 1. Left to itself it runs one page per CPU and
  is killed by the OOM killer on a machine this size; a killed run reports no
  error at all, which is what that silence means.
- ImageMagick is never asked to write a PDF: Debian's policy forbids it. Images
  are normalised to PNG and wrapped with img2pdf instead.
- backfillOcr.js re-reads documents uploaded before this existed.

New code lives in new files (lib/ocr.ts, lib/documentRendition.ts) with the
smallest possible edits to upstream files, so merges stay cheap.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PoCRDAPyEq4wwBVFFbDzck

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-1254.md from inside the repo you want the changes in.

⬇ Download capture-thread-1254.md