Background
Follow-up from PR #832 (fix for #827), raised in review by @hryhoriiK97.
On iOS, applyBaselineOffset (packages/react-native-enriched-markdown/ios/utils/ParagraphStyleUtils.m) vertically centers text within its line height by applying a single baseline offset over a whole block/paragraph range, computed before layout:
targetLineHeight = max minimumLineHeight across the range (the configured lineHeight).
contentLineHeight = max font line height across the range (for math, max(text, mathBox)).
- It bails entirely when
targetLineHeight <= contentLineHeight.
- Otherwise every run gets the same
offset = (targetLineHeight - contentLineHeight) / 2.
Problem
Because contentLineHeight is the max over the entire block, a single tall run (e.g. one line with large inline code, or a tall-script glyph) makes contentLineHeight > targetLineHeight, so step 3 bails and no line in the block gets centered - including the normal-height lines that should be centered within a loose lineHeight. Those lines drop from centered to their natural baseline.
Now that PR #832 makes lines grow to fit tall content (the floor-not-clamp change), this "grown line" path is intended rather than clamped away, so the loss of centering on the surrounding normal lines is reachable in practice.
Visible only when lineHeight is meaningfully looser than the font and a run exceeds it; low impact but real.
Why it is not a drop-in fix
- Per-run centering (center each shorter run by its own deficit, leave over-tall runs at 0) restores centering for normal text and is identical to today for uniform paragraphs, but (a) it must use
targetLineHeight rather than the grown line height (unknowable in this pre-layout pass), so it only approximates centering inside a grown line, and (b) it changes the math-line centering path, where text is deliberately centered against the taller math box.
- True per-line centering (one offset per laid-out line) is correct but needs the line composition and grown heights from the layout manager. This function runs on the
NSAttributedString before layout and has no line info (hard breaks are already flattened to spaces), so there is no per-line range to key off.
Suggested direction
Investigate moving the centering to a post-layout pass (per line fragment via the layout manager), or a per-run approximation gated on device verification of: loose lineHeight + tall inline code, a math line, and a plain uniform paragraph (no regression).
Related
Background
Follow-up from PR #832 (fix for #827), raised in review by @hryhoriiK97.
On iOS,
applyBaselineOffset(packages/react-native-enriched-markdown/ios/utils/ParagraphStyleUtils.m) vertically centers text within its line height by applying a single baseline offset over a whole block/paragraph range, computed before layout:targetLineHeight= maxminimumLineHeightacross the range (the configuredlineHeight).contentLineHeight= max font line height across the range (for math,max(text, mathBox)).targetLineHeight <= contentLineHeight.offset = (targetLineHeight - contentLineHeight) / 2.Problem
Because
contentLineHeightis the max over the entire block, a single tall run (e.g. one line with large inlinecode, or a tall-script glyph) makescontentLineHeight > targetLineHeight, so step 3 bails and no line in the block gets centered - including the normal-height lines that should be centered within a looselineHeight. Those lines drop from centered to their natural baseline.Now that PR #832 makes lines grow to fit tall content (the floor-not-clamp change), this "grown line" path is intended rather than clamped away, so the loss of centering on the surrounding normal lines is reachable in practice.
Visible only when
lineHeightis meaningfully looser than the font and a run exceeds it; low impact but real.Why it is not a drop-in fix
targetLineHeightrather than the grown line height (unknowable in this pre-layout pass), so it only approximates centering inside a grown line, and (b) it changes the math-line centering path, where text is deliberately centered against the taller math box.NSAttributedStringbefore layout and has no line info (hard breaks are already flattened to spaces), so there is no per-line range to key off.Suggested direction
Investigate moving the centering to a post-layout pass (per line fragment via the layout manager), or a per-run approximation gated on device verification of: loose
lineHeight+ tall inline code, a math line, and a plain uniform paragraph (no regression).Related