Paul Schlyter wrote:
Michael J. Mahon wrote:Shawn B. wrote:For a while I was assisting Mike Harvey to OCR source code from his Nibble scans. Anything less than 600 DPI was a major headache. For example, I must have easily spent over 20 hours of time converting just one program (in failed attempts) scanned at 300 DPI. When we tried at 600 DPI, the quality of the OCR (using OmniPage Pro 14/15 Acrobat 7) was very good, but the shear number of fixups... when started over and tried at 600 DPI took only about 6 hours or so to get 200 lines of AppleSoftt BASIC tested and running.For text and manuscript, there'd be very little effort for the human. But for source code (HEX especially and ASM doubly and BASIC last) it is a huge pain to verify the sometimes confused "B" for "8" (vise versa) and "0" (zero) for "O" (capital O) and "l" (small L) for "1" (number 1). Sometimes the $ would get messed up and the paranetheses are always a pain. In all, you have to hand very each and every line of code and without special help (a special mono-spaced font) that more clearly defines the differences (underlining numbers for example) you're in for a treat.It would take a lot less than 6 hours to type in a 200 line Applesoft program, so I'd say that OCR is worse than useless in this case.Indeed! 200 lines in 6 hours will give you 1.8 minutes per line. This is plenty of time for typing e.g.: 3200 RETURN :-) ....but to be fair, a lot of lines are of course much longer than that. And one will also need time for proofreading, no matter if the text has been typed or OCR'ed. High resolution of the scans is essential for low error rates in the subsequent OCR. The human eye is much better than OCR software at correctly recognizing letters and digits in low resolution.
I have OCR'ed some program listings. Using Caere OmniPage (came with the AGFA scanner), it does have a monospaced/matrixprinter mode that works fairly well. I would use it in an interactive way so I could tell it legal words and after a while it got quite good (TRS-80 basic and at an other time z80 assembly).
It could have been much better if I could tell it to assume basic syntax and that it would assume numbers in certain places like after a goto or gosub, at the beginning of a line etc. Applesoft basic wouldn't be as bad as the TRS-80 basic I was doing since it adds/enforces spaces between statements.
In all that I did it was fairly long listings and typing them in would have taken a long time so all in all I think I saved quite a bit of time OCR'ing. I would afterwards use MultiEdit (used for its good brief emulation, actually better than the real brief) to substitute certain bad guesses OmniPage did and look for 2/Z 5/S 1/l 8/S and 0/O by using substitute in rectangles and the whole file. The final test would come when loading/compiling it where the last bugs would be weeded out. One feature of MultiEdit that came in handy was the configurable context coloring. I defined the basic/asm statements and errors would stand out as black...
It still took some time but it was well worth it, typing in is very tedious when it is a long listing (and not very interesting to read).
One of the worst I remember from back then was Scott Adams' pirates adventure, the version that was printed in Byte, December 1980. It was awfully long and the adventure data was a lot of gibberish. Me and a friend did it together taking turns reading and typing, then taking turns reading back and verifying. We also did a lot of debugging during gameplay... loading or saving took about 20 minutes on tape. Those were the days. Playing the game in the end, was just wonderful.
:-) Knut