The batch OCR feature is simply not fit for purpose and needs completely replacing.

1. When performing a batch OCR the application is entirely locked into the process and is unable to do any other tasks. Acrobat installs itself as the default PDF viewer, so you cannot even view a PDF by default when the OCR process is running. There needs to be a way to run these batch processes as true background tasks that do not interfere with other Acrobat functions, or the ability to open multiple instances of Acrobat.

2. The batch process will often crash without warning or error message, I simply come back later and find Acrobat is closed and only a few of my files were converted.

3. On the Mac (latest OS) when a batch is running it does NOT behave nicely with the rest of the system. It sets the cursor pointer to the 'busy wristwatch' SYSTEM WIDE, not just for when the actual Acrobat app is in focus. It also likes to bring the Acrobat window to the front a LOT, which means you have to drag Acrobat off screen to stop it interfering with other things.

The automation for OCR is clearly a hack that's been put on top of an architecture that was never designed to be automated.

When will we get a modern application that justifies the monthly fees we pay for this?

We use Acrobat Pro 2017 Classic on MacOS High Sierra. Before the school holidays, we bought a license for Acrobat Pro 2020 Classic that is installed on the same machine.

We mainly use Acrobat to OCR screenshots and combine them into one PDF. Such a PDF contains between 40 and 200 OCRed pages. Sometimes we use TIFF, sometimes we use PNG as source images that need to be "PDFed".

The workflow is this:
1- Combine source images into one PDF in Acrobat Pro
2- Crop borders of each page in Acrobat
3- Export each page to a directory as a separate pdf file (1)
4- Close (and discard) combined PDF
5- Batch OCR each PDF file in source folder and save the OCRed pdf page in another directory
6- Combine OCRed PDF into one PDF
7- Safe PDF

(1) We do this because we discovered that the OCRed results are better when we ask Acrobat to OCR page by page instead of per multi-page document. Next to this Acrobat has a limit of OCRing 500 pages.

Now that we have Acrobat Pro 2020, we noticed that Acrobat Pro 2017 sometimes mixes up page order. Source images normally have a number like IMG0626.PNG, IMG0627.PNG, IMG_0628.PNG, etc.

The error in Acrobat 2017

This mixup error happens in workflow step 1 when source pages are combined into one PDF in Acrobat Pro. It doesn't matter if we import PNG of TIFF files. The error remains.
In the test set of 46 pages, pages 24 and 25 are swapped. In larger file sets there can be several spontaneous mixups of pages.

Q: Are the sources pages correctly sorted (so page 24 and page 25 are not swapped)?
A: yes. Page 24 and 25 are NOT swapped in the source directory. They are sorted as expected.

Q: Will the same error happen when I replace the file names of the PNG of TIFF files by a sequence number nnn so we get 001.PNG, 002.PNG, 003.PNG?
A: yes

Q: Will the same error occur when I turn toggle bookmark creation when combining?
A: yes

Q: When you combine the OCRed pages back into one PDF, does the mix up happens there also?
A: no

Acrobat 2020 is dead slow combining a pdf (compared to Acrobat 2017). Is it caused by a bug?

Importing a 85MB PNG file takes 3 to 4 seconds per page in Acrobat 2017. In Acrobat 2020 it takes 10 to 11 seconds.
Importing that same source file of about 100MB in (uncompressed) TIFF takes 3 to 4 seconds In Acrobat 2017. In Acrobat 2020 it takes 14 to 16 seconds.
Combing PDF files goes fast in both Acrobat Pro releases.
In both cases Acrobat Pro is installed on the same Mac Pro 2010 running High Sierra on a 1TB SSD disk with plenty (+/- 30%) of free storage. I did reset my Adobe preferences as suggested in the Adobe Acrobat forum.

I really hope that a bug is causing Acrobat Pro 2020 Classic for taking its time to combine source images to a PDF.

OCRing

What seem to go faster is OCRing in Acrobat 2020 compared to Acrobat 2017 when OCRing to editable text and images. OCRing the same set in Acrobat 2017 takes about 32 to 52 seconds. In Acrobat 2020 it takes about 11 to 20 seconds. To be OCRed text language is Dutch.

Rare crash of Acrobat Pro when OCRing

Another error that result in a crash of Acrobat Pro is that it fails to OCR a page. It simply crashes. My source pages have a border that I crop away before OCRing. In most cases when I keep the border at a page Acrobat Pro crashes, Acrobat Pro is -- in most cases -- able to OCR the page.

This is a rare crash. I did not yet come to a page so I can test it in both Acrobat Pro 2017 and 2020 to see if this is a bug related to one or both versions of Acrobat Pro.

I am happy to provide the support team the test set that I used (compressed to a 173MB ZIP file). Unfortunately it contains copyrighted material so I can't attach it just to this ticket.

Acrobat DC for Mac's OCR continuously mis-recognizes standardized OCR characters such as those on checks and commercial forms. Those characters are designed to be highly readable at high speed and a standard quality scan (let alone a high quality one) should be sufficient for proper recognition by Acrobat.

Similarly, it routinely tries to translate address codes (the string of full and half-height vertical bars used by postal readers to sort mail), even if it does occasionally recognize the entire code as one "word." Fortunately, it usually includes it for review, but it shouldn't be difficult to recognize the standardized format, or even catch that "IiIII1II1IIi!ii" is highly unlikely to not be text, especially when it goes on for 2-3+ inches. (If anything, I would expect Acrobat to recognize the code as its alphanumeric translation--not a feature I'm requesting.)

QR-type codes also should be recognizable as such. Both the large consumer size and the small "thumbnail" commercial size found on forms and bills are a standard that Acrobat's OCR engine "knows" and doesn't try to recognize as text characters.

All cases are consistent errors based on 300 ppi black & white scans with no compression, from "crisp" printing and no background. This has been replicated on four scanners from three separate manufacturers, two sheet-fed only (Brother and Epson) and two both sheet-fed and single page from the platen glass (high- and mid-grade HP OfficeJet series).

The user review feature of OCR allows limited correction of Acrobat's low-confidence recognition instances. After--or separate from--that process, users should be allowed to correct any recognized text--often, even when using the review feature, words are broken up, making search difficult. Users should be able to combine or split Acrobat's character groupings--to separate or connect those text blocks to match the word / sentence structure for proper searching. Basic Machine Learning (and even decades old OCR) used dictionary matching to help assess the probability of correct interpretation--this also should be able to determine that "correction" is a more likely translation than "cor" "rection". Even if it didn't users, should be able to link the two to one word--or split "userreview" to "user" "review". (Hypothetical examples but very similar to actual document translation at 300ppi high-contrast, high quality, black and white, no background.)

Hello,

I have a "problem" with the OCR technology in Acrobat Pro 2017 for Mac. When I edit a scanned file with OCR ("Searchable image", 300 dpi), the words and letters are recognised correctly, but the character spacing (when selecting the words) does not match the original font width (see screenshot). I noticed that this problem also occurs with Acrobat Pro 2020 for Mac, but not with the Windows version. On the other hand, this problem did not occur with Acrobat Pro XI for Mac.

I would be very grateful if you could solve this problem. My Mac is running macOS Big Sur 11.2.3. and the latest update for Acrobat Pro 2017.