PDF: drop-cap letter rendered as standalone text block mid-paragraph

[bfuerea]

Bug

When a PDF uses a drop cap (an oversized initial letter at the start of a paragraph), docling extracts it as a standalone single-character text block that floats between paragraphs, corrupting the reading flow.

Example from a real PDF:

...previous paragraph text.

R

ealized through a combination of...

The "R" is a drop cap that should merge with "ealized" to form "Realized".

Steps to reproduce

from docling.document_converter import DocumentConverter

converter = DocumentConverter()
result = converter.convert("fuerea_digital_transformation_2026.pdf")
md = result.document.export_to_markdown()

# The drop cap appears as a standalone paragraph
assert "\nR\n\n" in md  # Bug: "R" floating between paragraphs

Expected behavior

The drop cap should be detected (single uppercase letter with font size approximately 2x or more the body text average, baseline below the next line) and merged with the first word of the following paragraph.

Source location

page_assemble_model.py:118-176 (sanitize_text) - cluster text gets normalized but no font-size-aware merge logic exists. No mention of drop cap handling anywhere in the codebase.

Suggestion

Detect single-uppercase-letter clusters where the bounding box height is approximately 2x or more the page median line height, then merge with the next cluster's first word.

Docling version

2.115.0

Regression test PDF

• fuerea_digital_transformation_2026.pdf (1.5 MB) - two drop-cap instances (both "R") visible in the markdown output

[dosubot]

Thanks for the detailed report, @bfuerea. You're right — there is no drop cap handling anywhere in the codebase today. I searched across issues, PRs, and source code and confirmed this is a new gap.

Here's what's relevant to your report:

• sanitize_text() handles dehyphenation, ligature expansion, and typographic normalization, but has no font-size-aware or single-character merge logic [1].
• The reading order merge heuristics that decide which clusters to merge across pages/elements live in docling_ibm_models (reading_order_rb), not in the main docling repo [2]. That's likely where a drop-cap merge rule would need to be added — or alternatively as a post-processing step in PageAssembleModel.__call__() before elements reach the reading order stage.
• Related work on bbox-based merging exists: PR #2431 merges adjacent text fragments with very close bounding boxes (for duplicate character removal), and PR #3457 uses bbox-based thresholds for word-level cell merging. These patterns could serve as a model for drop-cap detection.
• Issue PDF: URL char-by-char spacing + metadata field leakage in references #3882 [3] reports a similar single-character spacing problem for URLs/metadata, suggesting the PDF backend (docling-parse) may already be emitting drop caps as isolated single-glyph cells at extraction time.

Your suggested heuristic (single uppercase letter with bounding box height ≥2× page median line height → merge with following cluster) seems reasonable. The main design question is where to implement it — either as a cluster-level post-processing step in PageAssembleModel (before text elements are created), or as a merge rule in ReadingOrderPredictor within docling-ibm-models.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.