Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OCR_BINARY seems to be useless #63

Closed
mtonnie opened this issue Aug 11, 2020 · 6 comments
Closed

OCR_BINARY seems to be useless #63

mtonnie opened this issue Aug 11, 2020 · 6 comments
Labels
Fixed. Waiting for feedback. Issue was fixed. Waiting for feedback.

Comments

@mtonnie
Copy link
Contributor

mtonnie commented Aug 11, 2020

It looks like the setting OCR_BINARY isn't taken into account.

The path for tesseract is hardcoded in mglib, as all other binaries.

I would really apriciate to have the ability to define binaries or paths with configuration file.

@ciur
Copy link
Owner

ciur commented Aug 11, 2020

You are right, OCR_BINARY setting is ignored.
I will fix this problem.

@ciur
Copy link
Owner

ciur commented Aug 11, 2020

Hi @mtonnie

I pushed couple of commits:

Also notice that instead of OCR_BINARY was renamed to BINARY_OCR. This is to be consistent with rest of BINARY_ settings:

  • BINARY_FILE default value is "/usr/bin/file"
  • BINARY_CONVERT default value is "/usr/bin/convert"
  • BINARY_PDFTOPPM default value is "/usr/bin/pdftoppm"
  • BINARY_PDFINFO default value is "/usr/bin/pdfinfo"
  • BINARY_IDENTIFY default value is "/usr/bin/identify"
  • BINARY_OCR default value is "/usr/bin/tesseract"
  • BINARY_PDFTK default value is "/usr/bin/pdftk"

All above settings can be added to papermerge.conf.py to modify path of respective executable.

Also notice that mglib version was incremented.
This code is very fresh (I just pushed). According to my couple of tests it works pretty well. Anyway, tomorrow I will update documention and perform couple of more tests.

To be continued...

@mtonnie
Copy link
Contributor Author

mtonnie commented Aug 12, 2020

Hi @ciur,

I guess the checks in core/checks.py should also take into account the variables.
If not these checks may fail when the location of the binary isn't inculded in PATH enironment variable.

What do you think?

@ciur
Copy link
Owner

ciur commented Aug 13, 2020

Hi @mtonnie ,

correct! I absolutely agree. Here is the fix.

Documentation update.

@mtonnie thank you for your great feedback!
If the case above changes solved your problem with hardcoded binary paths - please close this ticket/issue.

Thank you again!

@ciur ciur added the Fixed. Waiting for feedback. Issue was fixed. Waiting for feedback. label Aug 13, 2020
@mtonnie
Copy link
Contributor Author

mtonnie commented Aug 14, 2020

Thanks a lot, looks good so far.
I'll test it with synlology package soon, I have focus on installation wizard the last few days.

@ciur
Copy link
Owner

ciur commented Aug 15, 2020

@mtonnie, yes I saw your packaging progress.I pinned that issue - as I consider it very important one. Awesome work! Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Fixed. Waiting for feedback. Issue was fixed. Waiting for feedback.
Projects
None yet
Development

No branches or pull requests

2 participants