{"slug": "i-thought-my-pdf-parser-was-done-then-i-ran-it-on-80-real-resumes", "title": "I thought my PDF parser was done — then I ran it on 80 real resumes", "summary": "A developer built pdfmuse, a PDF/DOCX parser designed for precise text extraction in RAG pipelines. After running it on 80 real resumes, 8 failed silently with zero characters due to unhandled form XObjects in Canva exports. The bug was fixed by recursing into form XObjects, and the developer warns that synthetic test suites can miss real-world failure modes.", "body_md": "Building RAG pipelines, the step that kept letting me down was the very first one: turning a PDF into text. Two runs of the same file could give slightly different output, tables collapsed into garbled lines, and Chinese PDFs were mostly a coin flip. When your chunks change between runs, so do your embeddings and your eval numbers — and you stop trusting the index.\n\nSo I wrote [ pdfmuse](https://github.com/casperkwok/pdfmuse): a PDF/DOCX parser with one goal — be a precise,\n\nThis post is partly about how it works, and partly about the humbling bug I only found by dogfooding it on real data. That second part is the one worth your time.\n\n`NeedsOcr`\n\nwarning, and OCR/layout inference are a pluggable backend.You can try it in your browser (WASM, nothing gets uploaded — your file never leaves the tab): ** https://casperkwok.github.io/pdfmuse/** — drag a PDF and watch it come apart into text-with-coordinates, tables, and Markdown.\n\n```\npip install pdfmuse        # or: npm i @pdfmuse/node  /  cargo add pdfmuse-core\npython\nimport pdfmuse\ndata = open(\"report.pdf\", \"rb\").read()\ntext = pdfmuse.to_text(data)       # plain reading-order text\nmd   = pdfmuse.to_markdown(data)   # headings + tables\ndoc  = pdfmuse.parse(data)         # full IR: chars/blocks with exact bboxes\n```\n\nI had a test suite. Snapshot tests, a fuzzer, cross-binding parity, a CJK suite — all green. I ran it on a handful of sample resumes and the output looked great. I was ready to call the extraction layer done.\n\nThen I ran it against **80 real resumes** pulled from a product database (I build a resume tool on the side). The plan was a boring \"shadow comparison\" vs PyMuPDF to confirm parity before switching anything.\n\n**8 of the 80 came back with zero characters.** Not garbled — *empty*. And it failed **silently**: no warning, no error, just an empty document. PyMuPDF read all 8 fine.\n\nThat's a 10% total-failure rate, invisible to my entire test suite, because my test files happened to be clean.\n\nThe 8 failing files all shared traits:\n\n`ToUnicode`\n\nmaps. So it wasn't a missing-CMap problem.There it was. Canva (and Chrome's PDFium, and plenty of design tools) draw the page's text *inside a form XObject*, invoked by a `Do`\n\noperator. My content-stream interpreter didn't handle `Do`\n\nat all — and, worse, a lazy-loading optimization I'd added skipped `/XObject`\n\nbodies for speed. So the actual page text was never even parsed. On a clean PDF where text lives in the page content stream directly, everything worked. On a Canva export, I silently got nothing.\n\nThe fix was to make the interpreter recurse into form XObjects (decode the stream, apply its `/Matrix`\n\n, build its own font map, recurse with a depth guard) and stop skipping them in the loader. After that:\n\nzero-char failures:\n\n8/80 → 0/80. The 10 form-XObject files now match PyMuPDF ~100%.\n\n**The lesson isn't \"I wrote a bug.\"** It's that a green test suite on synthetic fixtures told me nothing about the real distribution. Canva is one of the most popular resume builders on earth; \"10% of resumes\" is not an edge case. I only found it because I ran it on real data before trusting it. If you're swapping any parser into a pipeline, do the shadow-comparison on *your* corpus first — the demo files lie.\n\nWhile I was in there: I'd been claiming \"4× faster than PyMuPDF.\" For a Python user, that turned out to be… not quite true. The Rust core parses in ~1.3 ms, but if you `json.loads`\n\nthe full intermediate representation (every char with its bbox) back into Python, that deserialization costs ~3.5 ms and eats the win — you end up roughly on par with PyMuPDF.\n\nThe fix was obvious once measured: if you only want text, don't materialize the whole IR. `to_text()`\n\n/ `to_markdown()`\n\nnow return a string straight from Rust, and the Python text path is back to full core speed. Measure the path your users actually take, not the one that flatters your benchmark. (Profiling that same corpus later turned up two more hotspots — a table detector that mistook a dense figure for a 1000-cell table, and a form XObject re-parsed 18,000 times on a single page — and fixing those is what got it to winning every file.)\n\nThere are drop-in loaders for the three big frameworks, all emitting chunks with `heading_path`\n\n+ `bbox`\n\nmetadata (which section, where on the page):\n\n``` python\n# LangChain\nfrom langchain_pdfmuse import PdfmuseLoader\ndocs = PdfmuseLoader(\"report.pdf\", mode=\"elements\").load()\n\n# LlamaIndex\nfrom llama_index.readers.pdfmuse import PdfmuseReader\ndocs = PdfmuseReader(mode=\"elements\").load_data(\"report.pdf\")\n\n# Haystack\nfrom pdfmuse_haystack import PdfmuseConverter\ndocs = PdfmuseConverter(mode=\"markdown\").run(sources=[\"report.pdf\"])[\"documents\"]\n```\n\n`NeedsOcr`\n\n; OCR is a backend, kept out of the deterministic core.If you try it, I'd genuinely love the files it gets wrong — that feedback is worth more than stars. Thanks for reading.", "url": "https://wpnews.pro/news/i-thought-my-pdf-parser-was-done-then-i-ran-it-on-80-real-resumes", "canonical_source": "https://dev.to/zane_kwok_d4c4bb8b83e6959/i-thought-my-pdf-parser-was-done-then-i-ran-it-on-80-real-resumes-12pe", "published_at": "2026-07-12 17:29:53+00:00", "updated_at": "2026-07-12 17:45:32.797722+00:00", "lang": "en", "topics": ["developer-tools", "artificial-intelligence", "machine-learning", "natural-language-processing", "ai-infrastructure"], "entities": ["pdfmuse", "Canva", "PyMuPDF", "Chrome PDFium", "Casper Kwok"], "alternates": {"html": "https://wpnews.pro/news/i-thought-my-pdf-parser-was-done-then-i-ran-it-on-80-real-resumes", "markdown": "https://wpnews.pro/news/i-thought-my-pdf-parser-was-done-then-i-ran-it-on-80-real-resumes.md", "text": "https://wpnews.pro/news/i-thought-my-pdf-parser-was-done-then-i-ran-it-on-80-real-resumes.txt", "jsonld": "https://wpnews.pro/news/i-thought-my-pdf-parser-was-done-then-i-ran-it-on-80-real-resumes.jsonld"}}