OCRmyPDF
OCRmyPDF copied to clipboard
ocrmypdf
--rotate-pages is being done but its results are ignored when --skip-text is enabled
Hi, we have observed that in pdfs with text, e.g. a pdf where all the pages except the last one contain text, the rotation process is performed but the resulting pages are ignored, i.e. all those pages with text that should be rotated are left unrotated. We expected two alternative behaviors (but not this one):
- When the page has text, no rotation process is performed, i.e. even if the page should be rotated, it is left as it was.
- If a page with text should be rotated, then rotate it.
We do not understand the current behavior, so if anyone could explain us it it will be fantastic. Thanks in advance and congratulation for your nice tool!
Hi,
We are using a PDF where both pages are exactly the same with the exception that the first one has text while the second one has none. The command we run is the following:
$ ocrmypdf --language spa --clean --deskew --rotate-pages --rotate-pages-threshold 3 --skip-text
and the shell outputs the following:
example.pdf outexample.pdf
INFO - 1: page already has text! – skipping all processing on this page
INFO - 2: page is facing ⇦, confidence 3.77 - will rotate
INFO - 1: page is facing ⇦, confidence 25.70 - will rotate
INFO - Optimize ratio: 1.00 savings: 0.3%
INFO - Output file is a PDF/A-2B (as expected)
As we can see in the output PDF, although both pages need rotation, only the one that has no text has been rotated. This would have sense if skip-text flag simply ignored the first page. However, since the rotation process is being run in this page, then we do not understand why it is left unrotated.
Thanks in advance!
@tamarit curious to know if you figured out a resolution to this problem and how exactly? Thanks.
@jbarlow83 I'm assuming this happens because --skip-text forces all processing to be skipped on the page that has existing text, including the page rotation that's needed. Any way around this? Or, is an enhancement needed to the processing logic for this scenario when both --skip-text and --rotate-pages need to be used in the command?
@ajab21 As you suspected, and if I'm reading it right, the current code skips all processing on the page once it finds existing text. @jbarlow83 is this by design? As you're looking for the most conservative handling of the original PDF?
The current behavior wasn't quite planned. Yes it does calculate the orientation for skipped pages and says they will be fixed but then does not fix them.
For skipped pages, no files/symlinks be generated that match the weave_layers regex (which selects ocr.oriented.pdf but not skip.oriented.pdf). This means the loop that rotation fixes will not iterate over pages that were skipped.
Unfortunately I can't address this for a few weeks.
I haven't decided on what the correct behavior should be. I'm considering --rotate-pages --skip-text means no evaluation or rotation of pages that have text, and --rotate-pages --redo-ocr means consider re-rotation of all pages.
hi @jbarlow83, please keep us posted on what you decide. improvement here with the code better understanding config intention would be great plus. thanks!
It would me great to have the option to run the page rotation routine outside of OCR. In my case I OCR'd ~300 files using 12 cores and it took 2 days. Would be nice to not have to run the whole process again. Maybe with the option to import ocrmypdf as a module now, I can figure that out.
Similarly, looking at importing optimize.py as a module, but so far the dependencies fail for me, but should be possible, yes?
@ajab21 No change in behavior for 9.0.0, which I really wanted to get out for other reasons.
@jrk2401 I think you could monkeypatch it but this isn't quite exposed behavior. I'm still working on plugins and hooks at major decision points, but I cut that feature from this release.
You should be able to import optimize or even run it as python3 -m ocrmypdf.optimize. What dependencies fail?
Leptonica for one, but my environment variables might be to blame, as Leptonica is installed for sure. It's quite possible I broke my working installation of OCRmyPDF just messing about. Will try a clean installation of the latest version and see how that goes.
On Mon, Jul 29, 2019, 3:52 PM jbarlow83 [email protected] wrote:
@jrk2401 https://github.com/jrk2401 I think you could monkeypatch it but this isn't quite exposed behavior. I'm still working on plugins and hooks at major decision points, but I cut that feature from this release.
You should be able to import optimize or even run it as python3 -m ocrmypdf.optimize. What dependencies fail?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jbarlow83/OCRmyPDF/issues/324?email_source=notifications&email_token=AGJSVFNFH22JFHSQXCXF3MTQB5C77A5CNFSM4GKHBCP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3B2FMI#issuecomment-516137649, or mute the thread https://github.com/notifications/unsubscribe-auth/AGJSVFNSA2AMX377XBBLLN3QB5C77ANCNFSM4GKHBCPQ .
@jbarlow83 actually python3 -m ocrmypdf.optimize works a treat, thanks for the hint. I'm going to upgrade anyway. I figure I can fix the rotated pages with pikepdf once I have a list of them.
Has there been any progress in allowing for rotation without actually rewriting the OCR layer?
One of my use cases is just for detecting and then rotating pdf pages to their correct orientation. But this seems to only work if I either generate an OCR layer (if none exists), or overwrite with --force-ocr (if already present).
Is there an alternate way of achieving this? OCR takes a lot of time and CPU, and sometimes I just want to quickly correct the pdf rather than wait for the full process (which I could schedule and batch later)
You could use a plugin that allows rotation detection to occur as normal, but suppresses regular OCR. That wasn't available when this issue was live. Pretty much just "subclassing" the existing OCR plugin. That would make it more doable to have a "autorotatemypdf".