PDF support via to_document / per-page extraction
- Dominant language
- Rust
- Stars
- 21.5k
- Forks
- 1.3k
- Avg merge
- 42m
- Merged PRs (30d)
- 17
Description
## Context
We're evaluating anydoc as a replacement for our current Python-based extraction pipeline (PyMuPDF, openpyxl, python-docx, python-pptx). anydoc is dramatically faster and leaner — 378x faster on a 2.2MB XLSX, 40x less memory.
For PDFs, we're currently using `pdf-inspector` directly (`extract_pages_markdown_bytes`) to get per-page markdown. This works great, but it means we need two separate libraries for what feels like one job.
## Request
Would it be possible to support PDFs in `to_document()` — or add a page-aware extraction mode to anydoc itself?
Currently:
- `to_document()` raises `UnsupportedError` for PDFs ("PDF converts directly to Markdown; use to_markdown or to_markdown_bytes")
- `to_markdown_bytes()` returns one blob with no page boundaries
- `pdf-inspector` has `extract_pages_markdown_bytes()` which returns per-page markdown with page numbers, OCR flags, and table detection — exactly what we need
Ideally anydoc could either:
1. Support `to_document()` for PDFs with page-level blocks, or
2. Expose a `to_markdown_pages()` / `to_markdown_bytes_pages()` that wraps pdf-inspector's per-page extraction
This would let consumers use one library for all formats with consistent per-page output.
## Workaround
Using `pdf-inspector` directly for PDFs and `anydoc` for everything else works fine — just adds a second dependency.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by tracing the existing to_document() and to_markdown_bytes() paths, then compare them with pdf-inspector's extract_pages_markdown_bytes() behavior. Resolve whether PDFs should produce page-level document blocks or a separate page-aware markdown API. Done means PDFs have consistent per-page output with the requested page boundaries and metadata.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100