proofing procedures

[bobcdy]

I've been looking for the best way to proof an ocr document, and it's been recommended to eventually save the doc as a text file and run it through the Project Gutenberg procedures - gutcheck, etc. This is supposed to eliminate most of the very common errors in ocr, such as substituting 'hut' for 'but', 'be for 'he', etc.

I haven't been doing this, but wondered if it's worthwhile to use gutcheck. Do most of you working on ebooks use this procedure, or do you use very careful reading of document for proofing?

[mncowboy]

Nothing beats the human eye! Regardless of the solution you use, proofreading needs to be the final step.

[HarryT]

There's only one way to properly proof-read a book, and that's to read the original text and the eBook in parallel, and compare them line by line, word by word, comma by comma. Anything else is not worthy of the name "proof-reading".

[bobcdy]

mncowboy & HarryT,
Thanks for the input. I've been using HarryT's suggestion of comparing the epub with the original document, epub on my 6" ereader and image pdf files on my 10" android, for proofing, and this works well although tedious and time-consuming. I've worried a bit, though, about overlooking mispellings of really common words such as 'be'.

Yesterday I tried using gutcheck (wingui) but found it didn't work correctly (wingui worked but the gutcheck plugin did not) so to continue with it I'd probably need to spend a lot of time finding the problem and it's solution. I guess I'll just continue without gutcheck because I'd still need careful proof-reading.

[Doitsu]

Originally Posted by bobcdy

Yesterday I tried using gutcheck (wingui) but found it didn't work correctly (wingui worked but the gutcheck plugin did not) so to continue with it I'd probably need to spend a lot of time finding the problem and it's solution. I guess I'll just continue without gutcheck because I'd still need careful proof-reading.

If you plan to release your book as an .epub, there's no point in converting it to a text file for spellchecking; you can spell-check it in Sigil, which comes with English, French and Spanish spellcheck dictionaries.
There's also a Modify ePub Calibre plug-in that'll convert straight quotes to curly quotes.

[mncowboy]

Proofing is the least fun part of the whole process. The human mind is wonderful at overlooking mistakes in order to grasp the whole concept. I've found the easiest way for to catch minute mistakes is to read the book backwords, sentence by sentence. Errors seem to jump out easier that way.
Bob

[HarryT]

Catching things like "he" instead of "be" isn't too hard. The really nasty ones are where letters have been joined up by the OCR process, so you get things like "dock" instead of "clock", "comer" instead of "corner" (that's a REALLY nasty one to spot), and so on.

I find that it helps to proof with a much larger text size than you'd normally read with, to make these errors stand out.

[Elfwreck]

Originally Posted by HarryT

Catching things like "he" instead of "be" isn't too hard. The really nasty ones are where letters have been joined up by the OCR process, so you get things like "dock" instead of "clock", "comer" instead of "corner" (that's a REALLY nasty one to spot), and so on.

My favorite was "modem methods of birth control."

Cigarette bums are also common.

[HarryT]

Yes, rn -> m is a common one, and tough to see.

[bobcdy]

HarryT - thanks for the suggestion to use larger print size for proofing. I'll try that next time

Doitsu - gutcheck is not really a spell checker, it is more like a context checker. For example a spell checker wouldn't catch 'he' for 'be', but probably gutcheck would find many these out-of-context problems (although perhaps not for 'dock' for 'clock'; also gutcheck looks for extra spaces and many other common errors that spell checkers would ignore. 'Aspell', a spell checker, is a plugin for gutcheck.

Thanks for the info on the calibre plugin for conversion of straight to curly quotes - I used curly quotes for my last upload, and although regex really helped I still had some problems and I don't know if I changed all the initally straights to curlies.

[graycyn]

HarryT is right about larger fonts helping, I like to do proofreading on my Sony 350 because of the extra crisp higher resolution text. Makes it easy to catch the periods where commas should be and vice versa.

Also, using large fonts on that smaller 5" screen really sort of isolates the text more, making it easier to catch any other errors I might've missed doing the OCR to scan comparison on the computer.

My other trick is to never go right in to proofing a book on my reader straight after doing proofing on that same book on the computer. It's just too much of the same book at once, making it more likely my eyes will gloss over something I should catch.

[Elfwreck]

Another trick for proofing: start at the end and move backwards. Less chance of getting caught up in the story that way. The typos and OCR errors are a lot easier to notice when they're taken out of context.

[Jellby]

Besides using a large font, using a different (ugly but effective) font may help. In particular, DPCustomMono2 is designed to make it easier to spot those pesky scanning mistakes.

[graycyn]

Originally Posted by Elfwreck

Another trick for proofing: start at the end and move backwards. Less chance of getting caught up in the story that way. The typos and OCR errors are a lot easier to notice when they're taken out of context.

Yes, I like to mix up chapters to avoid getting caught in the story. So I might proof chapter 15, then go to chapter 2, and so on at random.

[GrannyGrump]

I was going to suggest using a mono-space font, but I see Jellby already did that.

I use Monaco, which uses a slashed zero, and wonderfully differentiates between upper-case I, lower-case l, and number 1. It falls down on em-dash though, they are very slightly longer than the hyphen/en-dash and hard to tell apart, so before proofing I temporarily replace all the em-dashes with a unique character, such as @ or #.