(Indeed this is what one does with Acrobat Pro. (This happens with Acrobat Pro.) If that is the case, a solution would be to implement an option of running OCR on a specified range of pages, so that a user can OCR a document not in one go but in smaller steps. My (technically illiterate) suspicion has been that, with larger files the memory runs out and causes the OCR process to halt. I can upload an example document which gives me grief, as well as a verbose log taken during an attempt at OCR-ing it. But this is unpredictable, and I often have to try a number of times. Sometimes, one of the two “PDFpenOCR” dies and the other keeps going, and OCR is completed. The application (PDFpenPro) itself thereby hangs, and I have to force quit it. What happens (which one can see from Activity Monitor is that one or two processes called 'PDFpenOCR' start when I run the “OCR document” command, and after a while these processes slow down, and eventually halt. I am hoping that the new support team at Nitro might offer further help.
I have raised this issue a couple of times with the Smile support team. This has been a problem for me since before version 10. PDFpenPro's OCR process often stalls when being run on a relatively long document, whether it is run with the document open, or from the “OCR files…” command.
Pdfpenpro ocr document for mac#
I am using PDFPenPro 13.1 for Mac on MacBook Pro (13-inch, 2016, Four Thunderbolt 3 Ports), running macOS Mojave 10.14.6 (18G9323).
0 kommentar(er)
