TrulyFreeOCR – a Java OCR pipeline in a single fat JAR, zero native deps required

A developer released TrulyFreeOCR, an open-source Java OCR pipeline that converts scanned PDFs into searchable, compressed PDFs using a single fat JAR with zero native dependencies. The tool runs offline on CPU, uses business-friendly licenses (Apache 2.0/MIT/BSD), and achieves 5-10x file size reduction via MRC compression. It is designed for enterprise deployment where admin rights are unavailable and cloud APIs are prohibited.

I'm the author of TrulyFreeOCR, an open-source OCR pipeline that turns scanned PDFs into searchable, highly-compressed PDFs. Everything is Apache 2.0 / MIT / BSD — no GPL, no AGPL, no proprietary model weights. I needed an OCR pipeline for a document processing system where: Every dependency had to be business-friendly no GPL/AGPL Deployment required zero admin rights no sudo, no brew, no apt-get MRC compression was needed to hit 5-10x file size reduction vs JPEG-only Everything had to run offline on CPU — no cloud APIs, no GPU I surveyed 20+ existing tools https://github.com/msmarkgu/TrulyFreeOCR/blob/main/docs/opensource-ocr-tools.md full comparison in the repo's docs and none fit all requirements. OCRmyPDF is closest but needs Python + Ghostscript + Tesseract as system deps, and MPL-2.0 requires publishing modifications. The VLM models DeepSeek-OCR, GLM-OCR, etc. produce better text extraction but need GPUs and don't output PDFs at all. Input: any PDF scanned, born-digital, or mixed Output: searchable PDF with invisible text layer + MRC compression JBIG2/CCITT foreground + JPEG background Single fat JAR — one file to copy, one command to run Bootstrap script downloads everything JDK, Gradle, Tesseract, Leptonica, jbig2enc into project subdirs Fully offline, CPU-only PDF/A-2b output available 7 bundled language models, 100+ more downloadable Concurrent OCR configurable thread pool bash $ git clone https://github.com/msmarkgu/TrulyFreeOCR.git $ cd TrulyFreeOCR $ ./bootstrap.sh ./run.sh tests/simple-text.pdf -o output.pdf Tesseract-based accuracy — good for clean scans, not SOTA for noisy/photographed docs No table/formula extraction yet No handwriting recognition CPU-only is slower than GPU backends for high volume Would love feedback — especially from anyone who's tried to deploy OCR in an enterprise environment.