[Bee] reading order step crash because of `_has_sequence_interruption` in reading_order_rb.py

[yqliving]

Bug

When the layout model generated clusters almost sharing the boundaries, you may get the error in reading_order_rb.py, for example, i.bottom=302.7814025878906, j.top=302.78204345703125

self._init_ud_maps(page_elements, state)\n  File \"/usr/local/lib/python3.12/site-packages/docling_ibm_models/reading_order/reading_order_rb.py\", line 360, in _init_ud_maps\n    if not self._has_sequence_interruption(\n           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n  File \"/usr/local/lib/python3.12/site-packages/docling_ibm_models/reading_order/reading_order_rb.py\", line 386, in _has_sequence_interruption\n    candidates = list(spatial_idx.intersection((x_min, y_min, x_max, y_max)))\n                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n  File \"/usr/local/lib64/python3.12/site-packages/rtree/index.py\", line 809, in intersection\n    p_mins, p_maxs = self.get_coordinate_pointers(coordinates)\n                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n  File \"/usr/local/lib64/python3.12/site-packages/rtree/index.py\", line 359, in get_coordinate_pointers\n    raise RTreeError(\nrtree.exceptions.RTreeError: `Coordinates must not have minimums more than maximums`

Root Cause of the Bug

pelem_i.b = 302.7814025878906, pelem_j.t = 302.78204345703125
The is_strictly_above check (called before _has_sequence_interruption) uses an epsilon of 0.001 --> passed
_has_sequence_interruption: y_min = 302.78204345703125, y_max = 302.7814025878906 → y_min > y_max → crash

Fix:

in function _has_sequence_interruption around line 386: add two lines:

y_min, y_max = min(y_min, y_max), max(y_min, y_max)
x_min, x_max = min(x_min, x_max), max(x_min, x_max)

Docling version

docling: 2.107.0
docling-ibm-models==3.13.0

Python version

3.12
...

[yqliving]

please evaluate the fix in the description, thanks.

[Anai-Guo]

The crash is in the docling-ibm-models package (docling_ibm_models/reading_order/reading_order_rb.py), so I opened the fix there: docling-project/docling-ibm-models#174.

Root cause matches your analysis: _has_sequence_interruption sets y_min = pelem_j.t, y_max = pelem_i.b, and the pair is only guarded by is_strictly_above (eps 1e-3), so pelem_i.b can slightly exceed pelem_j.t and leave y_min > y_max. The PR clamps the query rectangle to keep min ≤ max on every axis, with a version-independent regression test.

[PeterStaar-IBM]

merged.