firecrawl / firecrawl/anydoc

PDF support via to_document / per-page extraction

Open
#62 2 comments 9 reactions 0 assignees View on GitHub
enhancement P2
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.