Fix cell line overlap and page-split text bleed#169
Conversation
Two issues surfaced in DOCX-imported documents after #167 unified the cell paragraph layout with the body's layoutBlock. 1. Cells with stored `lineHeight: 0.7` (planted by docx-style-map's unconditional `line / 240` mapping for `<w:spacing w:line=...>` regardless of `lineRule`) collapsed every line below the font's own pixel height once cells started honoring the value, so characters from adjacent lines overlapped. Floor the multiplier at 1.0 inside `assignLineHeights` so a sub-1.0 value can never crash text into the line below. The DOCX `lineRule` mishandling is the underlying data bug; that import fix is left as a follow-up. 2. The cell text baseline used `runLineY + line.height * 0.75`, which places the glyph's ascent ~5% of the font size above the line's declared top whenever lineHeight is tight (≈ 1.0). At a paginated row split this leaked a sliver of the next page's first line into the previous page's clip region — the same line then rendered fully on the next page, producing a visible double-draw at the boundary. Switch to the centered formula already used by the body path in doc-canvas and the list-marker path in the same file: `(line.height + fontSize * 0.8) / 2`. The glyph ascent now sits inside the line box for any lineHeight ≥ 1.0, so the page-split clip cleanly excludes it. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
|
Warning Rate limit exceeded
To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Review rate limit: 0/1 reviews remaining, refill in 49 minutes and 50 seconds.Comment |
Verification: verify:selfResult: ✅ PASS in 121.6s
Verification: verify:integrationResult: ✅ PASS |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
1 participant
Summary
Two rendering bugs that surfaced in DOCX-imported docs after #167 unified the cell paragraph layout with the body's
layoutBlock. Both reproduce on the shared "지원서_양식" doc.lineHeight: 0.7for paragraphs imported from<w:spacing w:line="168"/>(docx-style-map divides by 240 unconditionally, ignoringlineRule). Unify cell paragraph layout with body layoutBlock #167 made cells honorblock.style.lineHeight; with 0.7, line height drops below the font's pixel height and characters crash into the line below. Floor the multiplier at 1.0 inassignLineHeights. The DOCXlineRulemishandling is the deeper data bug — left as a follow-up.runLineY + line.height * 0.75. At tight line heights (≈ 1.0) that places the glyph ascent ~5% offontSizeabove the line's declared top, so at a paginated row split the next page's first line bled a sliver into the previous page (and re-rendered fully on the next page). Switch to the centered baseline(line.height + fontSize * 0.8) / 2, matching the body path indoc-canvasand the list-marker path in the same file.Test plan
pnpm verify:fast(627/627 tests pass, lint/typecheck clean)floors cell paragraph lineHeight at 1.0 to prevent overlap🤖 Generated with Claude Code