Repository navigation
fix(ocr): find the snap's bundled tessdata under its tesseract prefix - #192
Merged
Merged
Conversation
The snap (base core22) stages Ubuntu 22.04's tesseract-ocr debs, so the binary is $SNAP/usr/bin/tesseract and the language data is $SNAP/usr/share/tesseract-ocr/4.00/tessdata. _find_tessdata never looked there: the versioned lookup was hard-wired to /usr/share and the prefix derivation only tried the flat <prefix>/share/tessdata. It returned None, TESSDATA_PREFIX was never set, and tesseract fell back to its compiled-in /usr/share/tesseract-ocr/4.00/tessdata, which inside the snap resolves against the core22 base, where no Tesseract data is installed. OCR in the published snap (rev 43, 1.15.0) fails with "Error opening data file". Add a versioned lookup under the binary's own prefix, <prefix>/share/tesseract-ocr/<version>/tessdata, newest first, on Linux and macOS, right after the adjacent tessdata probe. Deriving it from the binary instead of pinning $SNAP or 4.00 also finds the tesseract-ocr/5/tessdata layout of the Tesseract 5 debs, and does not send a tesseract outside the snap to the snap's data when SNAP leaks into its environment. For /usr/bin/tesseract it is the same lookup as before, and the Windows lookup is unchanged. A tesseract under another prefix that carries its own versioned tessdata, such as /usr/local, now gets that directory ahead of /usr/share, even when it holds fewer languages. Move _find_tesseract and _find_tessdata to app/tools/_ocr_paths.py, which imports neither Qt nor app.*; app.tools.ocr keeps both names bound. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Deploying pdfapps with
|
| Latest commit: |
fde39cb
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://17212479.pdfapps.pages.dev |
| Branch Preview URL: | https://fix-snap-ocr-tessdata.pdfapps.pages.dev |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
OCR is broken in the published snap (rev 43, 1.15.0):
_find_tessdata()returns
None,TESSDATA_PREFIXis never set, and tesseract falls back toits compiled-in
/usr/share/tesseract-ocr/4.00/tessdata, which inside thesnap resolves against the core22 base, where no Tesseract data is installed.
OCR fails with "Error opening data file".
The snap stages Ubuntu 22.04's
tesseract-ocrdebs, so the data lives at$SNAP/usr/share/tesseract-ocr/4.00/tessdata. This PR adds a versionedlookup under the binary's own prefix,
<prefix>/share/tesseract-ocr/<version>/tessdata(newest first, Linux andmacOS only), right after the adjacent-tessdata probe.
_find_tesseract/_find_tessdatamove toapp/tools/_ocr_paths.py(no Qt or
app.*imports of its own);app.tools.ocrkeeps both namesbound.
tests/test_ocr_tessdata.py: 34 tests, including a pattern-aware fakeglob and an import allowlist for the new module.
Behaviour change
/usr/bin/tesseractgets the same lookup as before, and Windows isunchanged. A tesseract under another prefix that carries its own versioned
tessdata (e.g.
/usr/local/bin/tesseractwith/usr/local/share/tesseract-ocr/<v>/tessdata) now gets that directoryahead of
/usr/share, even when it holds fewer languages.Verification
in a container, with the snap's environment and Python 3.10: current
mainreturnsNoneand fails; this branch finds$SNAP/usr/share/tesseract-ocr/4.00/tessdata, OCRs to.txtand.pdfwith the right text, and lists deu, eng, fra, osd, por, spa.
_find_tessdata, over 638,976 layout/binary/platformcombinations: differences only where the binary sits under
/usr/local,/opt/homebrewor the snap with a versioned tree under its own prefix.Tesseract: every behavioural mutant is killed.
(with and without Tesseract installed).
app.tools._ocr_pathsis in the bundle.Not exercised: real snapd confinement (AppArmor/seccomp), a core24 snap,
macOS.
Known issues, not addressed here
entry, so with this fix the first OCR in the snap runs in German whatever
was selected. Pre-existing; separate fix to follow before the release.
gs_init.ps(needsGS_LIB), soCompress silently skips its Ghostscript pass. Same class of defect;
separate fix.
🤖 Generated with Claude Code