You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(layout-engine): render underlined tabs flush with text underline (SD-3330) (#3611)
* fix(layout-engine): align underlined tab to text baseline (SD-3330)
Underlined tab characters render their underline as a border-bottom on the
tab box. The box was the full line height and bottom-aligned, so the border
landed ~descent+half-leading below the text-decoration underline of adjacent
text, making a continuous underline look broken where text meets tabs.
Anchor the underlined tab box to the line-box top and end it at the baseline
offset derived from the resolved line metrics (ascent/descent/lineHeight), so
the border-bottom sits flush with the text underline. Gated to underlined tabs
only; non-underlined tabs keep their previous geometry to avoid any tab-stop
or line-layout regression.
Covers SD-3347 signature/fill-in line rendering. No DOM measurement is added
(SD-2957). Adds a regression test for both the inline and positioned paths.
* fix(layout-engine): unify tab underline rendering with text-decoration
Refactor the rendering of underlined tabs to use the same text-decoration mechanism as adjacent text, ensuring consistent baseline alignment and weight. This change addresses issues where the underline appeared misaligned due to the previous border-bottom approach. The tests have been updated to reflect these changes, ensuring that both underlined and plain tabs render correctly without unexpected borders. This aligns with the goal of maintaining visual fidelity across text and tab elements (SD-3330).
* fix(layout-engine): revert tab underline to border, keep matched weight (SD-3330)
The text-decoration approach for inline tab underlines required filling the tab
with transparent whitespace for the browser to underline. That filler is
selectable content, so selecting a line produced a broken/clipped selection
highlight across the tab region, and it complicated the editor underline flow.
Revert inline tabs to a border-bottom at the computed baseline offset (no filler,
no selectable content, no selection artifacts). Keep the matched weight: the
border width and text-decoration-thickness both use the shared font-scaled
underlineThicknessPx, so text and tab underlines render at the same integer-px
weight. Trade-off: the border position is a formula approximation of the text
underline baseline (within ~1px) rather than the browser's exact placement, but
it has no interaction side effects.
* fix(layout-engine): repaint tab when its underline changes (SD-3330)
Applying underline to an already-rendered tab in the editor did not show until
an unrelated edit forced a rebuild. Root cause: deriveBlockVersion (the paint
cache key the DomPainter compares to decide whether to reuse a fragment) encoded
a tab run as just text + "tab", omitting its marks. Toggling underline produced
an identical version, so the painter reused the cached, non-underlined fragment.
Include the tab's underline (style + color) in its version, matching how text
runs already encode their underline. Now a tab mark change invalidates the paint
cache and the underline appears immediately. Adds a regression test asserting the
version changes when a tab gains/recolors an underline.
Pre-existing; reproduced on main. Independent of the tab underline rendering fix.
* fix(layout-engine): give tab-only lines the paragraph font height (SD-3330)
A line containing only tabs was measured at the 12px default and rendered ~4px
shorter than a text or empty line in the same paragraph, so tab fill-in lines
sat at a different height than typed text.
Two parts:
- Adapter (paragraph converter): a bare tab carries no font of its own, so give
it the paragraph's resolved default font (mirroring the empty-paragraph run).
- Measuring: when a paragraph has no sized text run, fall back to any run that
carries a font size/family (e.g. a tab) instead of the 12px default, so the
tab's font drives the line height.
Add fontFamily/fontSize to the TabRun type (the tab legitimately carries them for
line height and underline weight) and drop the matching casts. Tab widths are
unaffected. Adds a measuring regression test asserting a tab-only line matches a
text line of the same font. Pre-existing; independent of the underline work.
0 commit comments