feat: add compact_tables to ConvertDocumentsOptions

[rbx]

Adds compact_tables: bool = False to ConvertDocumentsOptions, exposing the compact_tables parameter that DoclingDocument.export_to_markdown() and save_as_markdown() already support - added to fix unbounded whitespace growth in markdown table export (#2907). A single wide cell in a column (e.g. a merged banner/disclaimer row) currently forces every other cell in that column to pad out to match, which can turn a small, sparse table into megabytes of near-entirely-whitespace output.

This was originally submitted directly to docling-jobkit in docling-jobkit#108, which added the field to ConvertDocumentsOptions there. That PR was redirected here because ConvertDocumentsOptions has since moved to live in this repo (docling-jobkit's copy is now just a compatibility re-export). This PR is that redirected change.

I've also looked at where this options could be used in docling-jobkit and there seem to be quite a few places. I prepared a potential PR for that, but not very confident if it covers everything. Can open if you like.

[github-actions]

✅ DCO Check Passed

Thanks @rbx, all your commits are properly signed off. 🎉

[mergify]

Merge Protections

🟢 Merge protection satisfied — ready to merge.

Show 1 satisfied protection

🟢 Enforce conventional commit

Make sure that we follow https://www.conventionalcommits.org/en/v1.0.0/

• title ~= ^(fix|feat|docs|style|refactor|perf|test|build|ci|chore|revert)(?:\(.+\))?(!)?:

[bitfinop]

This adds the field, but nothing consumes it yet: md_content is produced in docling-jobkit (docling_jobkit/convert/results.py:249), which calls export_to_markdown(image_mode=..., page_break_placeholder=...) and never reads compact_tables off the options. As it stands a client can send compact_tables: true and get padded tables back with no error.

Measured on docling-serve v1.29.0 (docling-slim 2.117.0, docling-core 2.88.0). Same xlsx, 137 267 B, 5 000 rows x 10 columns, one cell of 20 000 characters:

output	characters
md_content (padded)	100 630 121
md_content with compact_tables=True	580 033
text_content	100 630 121 (same serializer)
html_content	918 954

A production file from a downstream indexing service: 1 638 201 B xlsx -> 317 567 892 characters, 4 915 705 with the flag; padding was ~86% of the characters in its table chunks, and the conversion was OOM-killing their workers.

The wiring on the jobkit side is mechanical and has a precedent in the very same functions: md_page_break_placeholder is threaded through _export_document_as_content, _export_documents_as_files, _upload_document_as_presigned_artifact, _fan_out_document_to_processors and _process_remote_exportable_results, and set from conversion_options at three call sites. compact_tables follows that path, plus the two save_as_markdown calls in convert/export.py:298,315. One detail worth deciding explicitly: _build_document_completed_item (results.py:273) counts characters through its own export_to_markdown() call, so without the flag there num_characters no longer matches the body that was returned.

docling-jobkit#108 did this before ConvertDocumentsOptions moved into this repo; it was closed unmerged.

I can open the docling-jobkit PR - either after this one lands, or now marked as depending on it. Which do you prefer?