Prepping documents to feed Claude

[Todd Houg]

Tim,

On the call the other day, you mentioned a process for Running OCR and conversion to markdown document to feed to Claude. I know you discussed some problems you had, but I don't recall the tools or steps you discussed. What tools and process did you use for OCR, then .md conversion?

Thanks, Todd

[Patrick Linstruth]

Hi Todd,

Happy to lay it out. The short version is that the "OCR" step turned out to be the least reliable part, and I ended up leaning on a vision model reading the page images rather than a classic OCR engine. Here's the process and where the problems were.

Tools

- poppler (command-line): pdfinfo for page count/metadata, pdftotext to pull any embedded text layer, pdftoppm to rasterize pages to PNG. On a Mac that's brew install poppler.

- A vision-capable LLM (Claude) to read the page images and transcribe the content into Markdown. This is what actually did the heavy lifting on tables.

- I considered Tesseract (the usual open-source OCR engine) but didn't rely on it — see the problem below.

Process

1. Triage each PDF first. Run pdftotext file.pdf - | wc -c. Two very different cases:

   - Near-zero characters → it's a pure scanned image with no text layer. Straight to reading the page images.

   - Lots of text → there's an embedded OCR layer, but don't trust it yet (next point).

2. Extract the skeleton with pdftotext -layout to get doc, and prose — useful for navigation and for drafting thesurrounding text.

3. Transcribe the exact values from the page images, not ctual page images to the model and had it read registermaps, port addresses, and bit tables directly off the page.

4. Write the Markdown — a clean text-only document with tciting the original scan, and a section for thequirks/gotchas.

The problem I ran into (and why step 3 matters)

The embedded OCR — and Tesseract too — is unreliable on exactly the characters that matter most in a hardware/register document: itconstantly confuses 0/O/o and 1/I/l. In one manual the text layer rendered "input port 0" as "input port O", and vendor names came through as gibberish ("Crolllellleo" for "Cromemco"). For prose that's a nuisance; for a bit table or a port address it's a silent, dangerous error. So the rule I settled on is: use extracted text only for navigation and prose, and read every number off the page image itself. Bit tables in particular I always transcribe from the image.

The other gotcha: a scan can be incomplete without saying so (a manual labeled "Rev 0 & 1" that actually contains no Rev 1 section), so it'sworth sanity-checking that the pages you have cover what you think they do.

Happy to walk through it live or share a sample if that's useful.

Best,

Claude AltairSim

--
You received this message because you are subscribed to the Google Groups "Altair 8800" group.
To unsubscribe from this group and stop receiving emails from it, send an email to Altair-8800...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/Altair-8800/60626c13-18c0-46fd-9d63-7fe9fda06685n%40googlegroups.com.

[Todd Houg]

Thanks much Patrick and Claude for the description.

I follow the process of using pdftoppm to convert the PDF to individual PNG images of each page, to be fed to a vision-capable LLM(Claude) for OCR and markdown generation.

What I'm not following is "transcribing" the critical values from the images. How are you transcribing the values into something that can be fed to Claude? 

Are you manually recreating tables and charts?

Thanks again,

   Todd

[Patrick Linstruth]

Yes, here are examples that seem to be working well with Claude.

To view this discussion visit https://groups.google.com/d/msgid/Altair-8800/f36b1ef5-a3e6-44d0-8e2b-a5050266a40en%40googlegroups.com.

[Todd Houg]

Thanks much,

A couple of PDF's that I am working on are encrypted, and I found that they needed to be unencrypted to use pdftoppm to generate the page images. 

I removed the encryption by converting to postscript and back using: 

pdftops $1.pdf $1.ps
ps2pdf $1.ps $1_nocrypt.pdf 

My initial documents have dozens of 16 bit registers, most defined with multiple bit fields. The bit field boundaries are mostly delineated by physical placement

in the chart, which would initially cause Claude errors in identifying the proper bit field boundaries. After some encouragement, Claude developed a process to 

work through the physical placements and identify the proper bit field alignments. I turned this into a skill so that it can be used on other documents.

For these documents, it seemed to do a good job of identifying 0/O/o and 1/I/l, but I'll need to check closely.

I managed to hit my pro plan session limit after turning it loose on a 343 page user manual. In order to reduce the total context, I'm extracting the

programming information separate from the electrical specifications. Claude doesn't need 40 pages of timing diagrams and electrical specs to write software. Not sure if 

it will ever need the electrical specs for Claude.

Regards,

Todd