Would you consider adding an opt-in API that returns Markdown alongside source spans and bounding boxes?
Currently, extract_text_with_positions_bytes provides positioned text, while extract_pages_markdown_bytes returns Markdown without a mapping back to those positions. This makes it difficult to reliably highlight the PDF source of a passage or extracted value, particularly in tables and documents with repeated text.
Ideally, each source span would include:
A start offset and length in the generated Markdown, with a documented offset unit.
The source page number.
One or more bounding boxes covering the source text.
This would let applications map Markdown passages back to PDF locations directly, without fuzzy matching or aligning the two extraction outputs afterward.
Since Markdown generation already uses positioned text through functions such as to_markdown_from_items and to_markdown_from_items_with_rects, could that source information be preserved during serialization?
An initial implementation could support block- or line-level spans, plus table-cell spans where practical. Keeping it opt-in would preserve existing behavior for callers who only need Markdown.
I’d be interested in contributing a PR. Would this fit the project’s direction, and what span granularity and API shape would you prefer?
Would you consider adding an opt-in API that returns Markdown alongside source spans and bounding boxes?
Currently, extract_text_with_positions_bytes provides positioned text, while extract_pages_markdown_bytes returns Markdown without a mapping back to those positions. This makes it difficult to reliably highlight the PDF source of a passage or extracted value, particularly in tables and documents with repeated text.
Ideally, each source span would include:
A start offset and length in the generated Markdown, with a documented offset unit.
The source page number.
One or more bounding boxes covering the source text.
This would let applications map Markdown passages back to PDF locations directly, without fuzzy matching or aligning the two extraction outputs afterward.
Since Markdown generation already uses positioned text through functions such as to_markdown_from_items and to_markdown_from_items_with_rects, could that source information be preserved during serialization?
An initial implementation could support block- or line-level spans, plus table-cell spans where practical. Keeping it opt-in would preserve existing behavior for callers who only need Markdown.
I’d be interested in contributing a PR. Would this fit the project’s direction, and what span granularity and API shape would you prefer?