That is specific for this implementation. Note that cursive/handwritten text will continue to be an issue, but machine printed is pretty solid and especially easy if you can narrow down the scope of the expected result (somewhere in this thread someone wonders of it would be possible to prefer 0 to o etc - sure). Note that

a) it's not possible to consistently reach 100% (and depending on the source material and circumstances far less) recognition (have to educate customers about that..)

b) errors are a tradeoff between 'dunno' and 'might be a zero' aka miss vs. false positive. Benchmarks/evaluations usually consider the latter far worse, prefering jf?oster to jf0ster by a long shot. So that's what you'll try to archive.

Source: Approaching ten years (yeah..) in a company that sells OCR solutions and more, integrating Abby, Oce and another half a dozen commercial engines.

> machine printed is pretty solid

You mean OCR in general or ocradJS? I tried cropping a picture down in the later and I can't get it to come even close: http://imgur.com/cesg0IE

I work at a publisher with millions of digitized historical books that we OCR and Abbyy is what we use. Nothing else came close to Abbyy. It is incredibly good, but incredibly expensive.

in my humble experience using OCR programs, there is always a considerable amount inaccuracy. no matter what font I use or font size, I always either end up proof reading the scanned document or just typing it by hand. the letter "O" is almost always translated by the OCR as a "0" or a zero is translated as an "O". it can be pretty frustrating.

I used the ABBYY orc engine to digitize printed documents (idk why they couldn't just keep around the file used to print) and it was quite accurate. At worst one out of a couple hundred would have enough issues where readability was an issue.

Similar experience here, when building a mobile app that did OCR + translations.. As long as the source image was in decent shape, ABBYY did very well. It's also incredibly expensive.

I wish there was a library that allowed you to input expected data (ex: we expect to see zeros 20% more often then the letter O), then the interpreter could compare against that fact and determine the likelihood of it being each letter. As it stands for most libraries that I'm aware of, you just have to get the data and run your own tests to see whether it should be an O or a zero.

Ocrad is not very powerful, it uses hand-written recognisers (one per character) to identify the shapes of the characters. Compare this with more modern libraries such as Tesseract which use neural networks and OCRopus which adds language modelling.