Page count is the wrong unit for estimating a PDF-to-text job

When estimating the cost of converting PDFs to text, the number of pages is not the best metric to use. In a test, seven English documents were run through a PDF extractor, and it was found that page count alone is a poor predictor of how many edits will be required. One example is a book printed in 1734, which had more editing needed per page than an arXiv paper with only two pages.

The type of edit also matters more than the number itself. For instance, a wrong, missing or extra word, a fused line, a word broken across a line end, two conflicting versions of one line, or a block in the wrong position all count as spots. These spots are counted once, regardless of how many characters they cover. Page furniture, such as running heads, footers, and page numbers, is not included in the count because they are typically stripped anyway.

To test this, four synthetic files were created with known content, while two scanned public-domain books were transcribed and compared using Python's difflib, which counts moved phrases twice. The PDF extractor used was ImgIng's Extract PDF content with OCR on Auto. The results showed that spots can be categorized into three groups: fixes that a script can handle, spots that need a person to look at, and spots where editing is the wrong move and the page should be rerun through OCR.

The script can fix up to 85% of the issues, but a person is needed for the remaining spots, which highlights the limitations of using page count for estimating a PDF-to-text job.