fix(setup,docs): write INSTALL_TESSERACT from setup.ps1, correct the OCR upgrade note

setup.ps1 wrote OCR_ENABLED=true but never INSTALL_TESSERACT=true, so a
Windows user answering yes to the OCR question ended up with OCR on and no
engine in the image; it also claimed tesseract was "shipped in the Docker
image", which this change makes false, and offered OCR for the pre-built
Docker Hub images that cannot include it. Mirror setup.sh: skip the question
for hub images (naming all three settings the DeepSeek path needs), and bake
tesseract in for locally built ones.

The upgrade callout said earlier images always included tesseract. They never
did -- they included docling, and OCR ran on the RapidOCR engine bundled with
it, needing no system package. It also covered only OCR_ENABLED, missing
OCR_ATTACHMENTS_ENABLED, which is a separate switch onto the same native OCR
path.
This commit is contained in:
Alex committed 2026-09-04 15:13:23 +01:00
1 parent 6276158d0d
commit 2a9a02427f
2 files changed
+22 -8

No files matched your search

+6 -4
View File
@@ -72,10 +72,12 @@ there, point `OCR_ENGINE=deepseek` at a DeepSeek-OCR endpoint or install
unaffected).
<Callout type="warning" emoji="⚠️">
**Upgrading:** earlier images always included tesseract. If your deployment
runs `OCR_ENABLED=true` with the `tesseract` engine, add
`INSTALL_TESSERACT=true` to `.env` before rebuilding, or OCR of scanned pages
stops working after the rebuild.
**Upgrading:** earlier images always included docling, and OCR ran through the
RapidOCR engine bundled with it, so no system package was needed. The default
image now ships neither docling nor tesseract. If your deployment uses the
`tesseract` engine (the default) with `OCR_ENABLED=true` or
`OCR_ATTACHMENTS_ENABLED=true`, add `INSTALL_TESSERACT=true` to `.env` before
rebuilding, or OCR of scanned pages stops working after the rebuild.
</Callout>
## Installing the docling engine