pdf_oxide

here were a ton of edge cases in the layout, esp. related to column, footnote and sidebar handling, or things like "Hebrew RTL text accidentally disappears if text breaks weirdly", "1-bit image compression", etc. I have nothing against AI, I use it heavily myself, but what is annoying is people completely ignoring the years of work of existing projects that do the exact same thing - instead of just forking, but instead re-tokenizing the exact same work again. Most likely the author didn't research "does this already exist" and that's annoying, then you get 100 of similar projects reinventing the world with tokens again and again. Sometimes its beneficial and can lead to faster exploration of new approaches, but in most cases its not and misses edge cases that were solved before.

roduce garbage on CJK documents. Benchmarks (Mean / p99 / Pass Rate) on 3,830 PDFs: pdf_oxide: 0.8ms / 9ms / 100% (MIT) PyMuPDF: 4.6ms / 28ms / 99.3% (AGPL-3.0) pypdfium2: 4.1ms / 42ms / 99.2% (Apache/BSD) pypdf: 12.1ms / 97ms / 98.4% (BSD) Performance was profiling-driven. A bulk page tree cache turned a 10,000-page PDF from 55s to 332ms (O(n^2) to O(1)). Quick Start (Python): from pdf_oxide import PdfDocument doc = PdfDocument("document.pdf") for i in range(doc.page_count()): print(doc.extract_text(i)) Quick Start (Rust): use pdf_oxide::PdfDocument; let mut doc = PdfDocument::open("document.pdf")?; for i in 0..doc.page_count()? { println!("{}", doc.extract_text(i)?); } Capabilities: Text/Markdown/Image extraction, PDF creation from Markdown/HTML, form filling, and OCR (PaddleOCR via ONNX Runtime). GitHub: https://github.com/yfedoseev/pdf_oxide Docs: https://oxide.fyi I would love to hear what you think—especially if you throw it at PDFs that other libraries struggle with. The best way to improve is finding edge cases in the wild.