Robert Sachunsky

@webknjaz that is surprising (to say the least), and IMO directly contradicts the statements made in [setuptools documentation](https://setuptools.pypa.io/en/latest/setuptools.html): > Automatically include all relevant files in your source distributions, without needing...

> This won't break older versions right? I cannot imagine how. Adding `except +` will just convert C++ exceptions (instead of having them be handled by the C++ runtime). If...

Hi @sirfz, yes, I can see no reason not to include this in tesserocr. (Like I said, it's a soft dependency – it only acts if libtesseract throws C++ exceptions,...

We now have to start thinking about how to generate `ocrd-all-tool.json` (and the newly introduced `ocrd-all-config.yaml`, which could in principle itself be generated from the former, ~~if we would also...

Or perhaps this should rather be configurable? After all, this does loose information. So even a downstream task cannot as easily normalise linewrap as would be possible with the information...

Yes, that's a problem IMO. I don't recall exactly why we decided to catch this error in the first place. (It could have been that some processors misbehaved, and we...

> Now I wonder if the correction of this "feature" is worth the effort. It's a minute change.

> I agree that returning an empty dict for non-processor `ocrd-*` executables seems better. IIUC the only change in the function would be to not set `resource_locations` in that case....

I think I now know what's going on: https://github.com/OCR-D/ocrd_all/blob/56507f1f89fcef43eab7daac06cc8ef6143aee21/Dockerfile#L136-L142 So what is supposed to happen here is that we end up with `/usr/local/share/tessdata -> /usr/local/share/ocrd-resources/ocrd-tesserocr-recognize` with the preinstalled models. However,...

ocrd_anybaseocr has been refactored and updated, sbb_binarization removed