Summary
Follow-up to #222 / PR #228 (shipped in v0.17.0).
PR #228 made layout_box_para_iter raise the flow floor after every paragraph and shift a cached paragraph whose v_pos restarts as a rigid block, so multi-paragraph cells never overlap. A shift is bounded by the cell bottom: lines that would cross it are clipped and reported as table_cell_content_overflow.
That bound is the wrong outcome for one legitimate case: a genuine Hancom cache resets v_pos to 0 where a cell continues on the next page. In that case the paragraph should be fragmented onto the continuation page, not clipped.
Reproduction (committed fixture)
fixtures/samples/report-tables.hwpx, sec0/p40 table, cell (1,3): three paragraphs, the third (sentence 47) restarting at v_pos: 0 because Hancom continued the cell on the next page. The row is about 31.3pt high while the first two paragraphs already end at about 44.2pt.
Root cause
Routing the reset through cached_cell_split_plan was implemented during the #228 review and found ineffective for this fixture: the plan is built (row 1, two groups, split at the reset, second group on a fresh page) but layout_table_cell_fragments discards it because the col-0 cell of that row has rowSpan=2, which trips the row-span-with-cell-fragment guard in the fragment emitter (row_group_counts[row] > 1). Separately, a table that fits its page never enters layout_table_cell_fragments, so the container bound is the only guard for the in-page case.
Expected
A reset that marks a page continuation (cumulative cached content exceeds the stored row height) should fragment the cell at the reset and continue it on the next page, including when a neighbouring cell in the same row spans rows. The clip-and-report behaviour should remain only as the fail-closed fallback.
Notes
Summary
Follow-up to #222 / PR #228 (shipped in v0.17.0).
PR #228 made
layout_box_para_iterraise the flow floor after every paragraph and shift a cached paragraph whosev_posrestarts as a rigid block, so multi-paragraph cells never overlap. A shift is bounded by the cell bottom: lines that would cross it are clipped and reported astable_cell_content_overflow.That bound is the wrong outcome for one legitimate case: a genuine Hancom cache resets
v_posto 0 where a cell continues on the next page. In that case the paragraph should be fragmented onto the continuation page, not clipped.Reproduction (committed fixture)
fixtures/samples/report-tables.hwpx,sec0/p40table, cell (1,3): three paragraphs, the third (sentence 47) restarting atv_pos: 0because Hancom continued the cell on the next page. The row is about 31.3pt high while the first two paragraphs already end at about 44.2pt.hwp render --reportlists atable_cell_content_overflowissue for the cell.Root cause
Routing the reset through
cached_cell_split_planwas implemented during the #228 review and found ineffective for this fixture: the plan is built (row 1, two groups, split at the reset, second group on a fresh page) butlayout_table_cell_fragmentsdiscards it because the col-0 cell of that row hasrowSpan=2, which trips the row-span-with-cell-fragment guard in the fragment emitter (row_group_counts[row] > 1). Separately, a table that fits its page never enterslayout_table_cell_fragments, so the container bound is the only guard for the in-page case.Expected
A reset that marks a page continuation (cumulative cached content exceeds the stored row height) should fragment the cell at the reset and continue it on the next page, including when a neighbouring cell in the same row spans rows. The clip-and-report behaviour should remain only as the fail-closed fallback.
Notes
cell_paragraph_shift_is_clipped_at_the_cell_bottomand the sentence-47 assertions incrates/hwp-render/tests/render.rs; they will need updating when fragmentation lands..planning/phases/03.1-cell-paragraph-fidelity-issues-220-225/03.1-REVIEW-FIX.md(not committed) and the PR fix(render): advance the layout flow floor per paragraph so cell paragraphs cannot overlap #228 review comment.