Closed jbarth-ubhd closed 4 years ago
Thanks for reporting!
I believe this is an artifact of incomplete Python 2-3 porting. You can avoid it by leaving the file in gzip-compressed form (with .gz
extension).
The uncompressed case needs to use the same latin1
encoding IMO.
Tried it, but then ocr-cis-ocropy-recognize does not find the *.pyrnn.gz
That's odd. Relative paths should be searched:
__file__
's directory, e.g. venv/lib/python3.6/site-packages/ocrd_cis/ocropy
__file__
's models
subdirectory, e.g. venv/lib/python3.6/site-packages/ocrd_cis/ocropy/models
in any of the directories mentioned in ocrolib.ocropus_find_file
:
Result of searching $fname is the first existing in:
* $base/$fname
* $base/$fname.gz
* $base/model/$fname
* $base/model/$fname.gz
* $base/data/$fname
* $base/data/$fname.gz
* $base/gui/$fname
* $base/gui/$fname.gz # if gz
$base can be four base paths:
* `$OCROPUS_DATA` environment variable
* current working directory
* ../../../../share/ocropus from this file's install location
* `/usr/local/share/ocropus`
* `$PREFIX/share/ocropus` ($PREFIX being the Python installation
prefix, usually `/usr`)
3 probably won't help you, because the CWD is the OCR-D workspace directory in the processor's context, and you probably never installed ocropus
itself.
So, you should stick with 1 or 2, in the .gz
form (until we patched the uncompressed condition).
Perhaps you forgot to also add the .gz
suffix in the makefile/parameter file?
models:
file: https://digi.ub.uni-heidelberg.de/diglitData/jb/ocropy-test.jpg
command: