Radicals: split the excess height of the radical glyph above and below (as in TeX), instead of hanging all of it below #344

Problem

Per § 3.3.3, the radical glyph is stretched to the target size RadicalRuleThickness + radical gap + ink height of the base, and the surd is painted from the line-over edge of the overbar downwards. When the stretched glyph is taller than the target, which is the normal case since size variants come in discrete steps, all of the excess ends up below the base.

Fonts often have coarse radical variants: Latin Modern Math has 1.0, 1.2, 1.8, 2.4, 3.0 em, and STIX Two Math has 1.19, 1.86, 2.37 em. A radicand just past a threshold therefore gets a radical that reaches up to ~0.6 em further below the baseline than needed. Common formulas hit this, e.g. anything with a subscript like \sqrt{2I_j}. Users notice: https://issues.chromium.org/issues/343889867 and https://bugzilla.mozilla.org/show_bug.cgi?id=1900097 report exactly this for Temml output, in both engines. Both engines follow the spec, so neither can fix it on its own.

How TeX does it

TeXbook, Appendix G, rule 11: after choosing the radical sign (height + depth ≥ h(x) + d(x) + ψ + θ), "if the height plus depth of the radical sign exceeds h(x) + d(x) + ψ + θ, increase ψ by half the excess". So the excess is split evenly between the gap above the radicand and the part of the radical below it. This is why \sqrt{2I_j} looks fine in LaTeX and KaTeX even with the same 1.0/1.2/1.8 em size steps.

For comparison: pdfLaTeX (Computer Modern) puts the bottom of \sqrt{2I_j}'s radical 0.34 em below the baseline in display style. Firefox 155 and Chrome both put it about 1.0 em below with Latin Modern Math, which has the same radical sizes.

Proposal

In § 3.3.3.1, after shaping the radical glyph: let Δ be the radical glyph's line-ascent + line-descent (box metrics) minus the radical target size. If Δ > 0, increase the radical gap by Δ/2 for the purposes of §§ 3.3.3.2/3.3.3.3 (the line-ascent of the math content and the position of the overbar). The surd stays painted from the line-over edge of the overbar, so the glyph and the overbar move up together by Δ/2 relative to the base, and the radical's depth below the base shrinks by Δ/2.

This only affects cases where a variant overshoots the target. The gap never becomes smaller than today's, and the layout grows upwards by at most half a size step.

Illustration

Attached: fcomp-split-chromium.png. Seven OpenType math fonts at 32px in Chromium 153, Temml output. For reference: pdfLaTeX with Computer Modern, which has the same radical sizes as Latin Modern Math and already uses TeX's rule, and KaTeX. Left: current behavior. Right: the proposed rule, simulated after layout by moving each <msqrt> up by Δ/2 and its base back down by Δ/2 (CSS relative positioning). Chromium lays out the <msqrt> box as § 3.3.3 specifies, so Δ is computed from the box metrics and the font's MATH constants. The shifts are rounded to whole device pixels, so the snapped overbar stays aligned with the surd.

Chromium currently paints the overbar RadicalRuleThickness/2 and the surd RadicalRuleThickness too low (https://issues.chromium.org/issues/570892028). That affects both columns equally and is independent of where the excess goes.

The biggest improvements are for Latin Modern Math and STIX Two Math, e.g. √(2I_j) in display style. Fonts with fine radical steps (Libertinus Math, the TeX Gyre fonts) barely change.

The proposal doesn't remove the deeper cause for these two fonts, the coarse size steps (plus, for 2I_j, the font's SubscriptShiftDown pushing the radicand past a threshold). It halves the visible effect for every font, though, and matches what authors coming from TeX expect.

Related

• Ink ascent/descent #78 (ink ascent/descent) is about how the target size is measured, not about where the excess goes. Orthogonal to this.