[Bug]: [Bug]: Cross-page table highlights only show on the first page with MinerU backend when clicking a chunk in the preview.

[one985]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (Language Policy).
• Non-english title submitions will be closed directly ( 非英文标题的提交将会被直接关闭 ) (Language Policy).
• Please do not modify this template :) and fill in all the required fields.

RAGFlow workspace code commit ID

16283

RAGFlow image version

0.26.1

Other environment information

Using MinerU as the OCR backend.

Actual behavior

When clicking a chunk that spans multiple PDF pages (e.g., a cross-page table on page 7 and page 8), the PDF preview on the left only highlights the first page. The subsequent page's text/table rows are not highlighted at all.

I have traced the entire data flow (Frontend -> RAGFlow Backend -> MinerU -> RAGFlow Backend -> Frontend) to debug this issue. The root cause is located in the RAGFlow backend's processing of the data provided by MinerU. MinerU outputs complete coordinates for all pages of the cross-page table in its raw _middle.json file, but the RAGFlow backend only extracts the coordinates of the first page when generating the chunk data. As a result, the frontend receives an incomplete positions array, which causes the highlights on the subsequent pages to be entirely missing.

Expected behavior

No response

Steps to reproduce

1. Upload a PDF file that contains a table spanning multiple pages.
2. Use MinerU as the OCR backend for parsing the document.
3. Go to the "Parsed Chunk" preview page (`/chunk/parsed`).
4. Find a chunk that contains the cross-page table.
5. Click on this chunk in the right sidebar.
6. Observe that only the first page's table content is highlighted in the left PDF viewer, while the rest of the pages are not highlighted.

Additional information

No response

[dosubot]

This issue has two layers — one in the backend (MinerU parser not emitting per-page positions for cross-page tables) and one in the frontend (scroll logic only targeting the first highlight). There's a closely related issue already filed:

Existing issue: #16735 reports the same cross-page table highlighting problem [1]. The root cause analysis there found that:

1. Backend data is correct — add_positions in rag/nlp/__init__.py does store all (page, left, right, top, bottom) tuples from the parser. However, MinerU's content_list.json may only carry the first page's bbox for a merged cross-page table, so positions for subsequent pages may never reach the backend in the first place.

2. Frontend scroll limitation — pdf-preview.tsx always calls ref.current(state[0]), scrolling only to the first page's highlight [2]. Even when multi-page positions are stored correctly, the viewer doesn't scroll to subsequent pages.

Your diagnosis aligns with this: MinerU's raw _middle.json contains complete per-page fragment coordinates, but the current deepdoc/parser/mineru_parser.py code reads content_list.json and extracts only a single page_idx/bbox per block [3]. There's no code yet that reconstructs multi-page positions from middle.json.

In short, the fix likely needs both:

• Backend: Parse middle.json fragment data to emit one position entry per page that a cross-page table spans.
• Frontend: Update the scroll logic to navigate through all pages covered by a chunk's highlights, not just state[0].

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[zeweihan]

Excellent root-cause trace — the OP isolating "MinerU emits complete per-page coordinates in _middle.json but the RAGFlow backend only serializes the first page's coordinates into the chunk's positions[]" is the whole bug in one sentence.

A framing worth adding: this is not a highlight-UX defect, it's a citation-anchor defect. For a chunk whose source span crosses pages 7→8, positions[] covering only page 7 is the machine-readable equivalent of a footnote that cites "p.7" for a quotation that actually runs onto p.8. The citation is structurally valid (non-empty, correct for the bytes it does cover) but materially incomplete for the bytes it doesn't — and nothing flags the gap. dosubot's split into "backend (truncation)" + "frontend (scroll targets first page)" is right, but the frontend half inherits the backend's loss; the frontend can't highlight coordinates it was never handed.

Why the severity is higher than "second page isn't highlighted":

1. positions[] is load-bearing as provenance, not just as render data. It is the chunk→source binding: the thing a reviewer clicks to answer "was this clause actually extracted from the document, and from where?" When the binding only covers the first page of a multi-page fee schedule / penalty matrix / amendment comparison table, the operative rows often sit on the unhighlighted second page. A reviewer who clicks the highlight, sees page 7 light up, and approves the chunk as grounded is confirming provenance for half the source. The second page's rows are in the chunk text with full retrieval confidence but with no clickable binding — the silent-loss signature: content present, binding half-absent, zero degradation signal, looks "working" because something highlights.

2. This is a one-way data door at the serialization boundary, not a parser limitation. The OP proved MinerU already has the complete per-page coordinates in _middle.json. The authoritative source has the full binding; the backend's chunk construction drops it. Same structural shape as the export-layer losses in the doc-parsing stack (OCR text survives the layout model but vanishes when a region is serialized as <!-- image -->; table cells survive parsing but vanish when reading-order linearization runs) — content survives upstream, binding/coordinate is stripped at the export step, the two consumers (here: highlighter vs. retriever) see different documents with no error.

3. Cross-page tables are not an edge case for the corpora this pipeline is built for. Fee schedules, tariff matrices, multi-page reference appendices, signature blocks that span a page break — these are the operative content types, and they're the content types most likely to be long enough to cross a page boundary. A pipeline whose highlight/provenance binding silently degrades exactly on long tables degrades exactly on the highest-value content.

Cheapest companion (orthogonal to the pass-through fix, which is the right primary fix): when a chunk's serialized positions[] is non-empty but the chunk's content/text derived from a span that the backend knows crosses a page boundary, surface a positions_coverage field — {expected_pages_from_span, covered_pages, cross_page: bool, complete: bool}. That turns "second page didn't highlight" from a UI quirk the operator infers by clicking, into a queryable invariant the pipeline can assert (complete == false on any chunk = incomplete binding). The invariant is cheap: "every page the chunk's content derives from must have a corresponding position entry" — the OP already demonstrated the upstream has all the pages, so a mismatch is a serialization bug, not missing data.

The pass-through fix (don't truncate to page 1 when MinerU gives all pages) closes correctness; the coverage flag closes discoverability so the next backend variant that reintroduces truncation is caught at ingest rather than noticed weeks later when a reviewer asks "why does this highlight stop at the page break."