[junereycasuga]

Summary

Fixes clipped mermaid diagram labels in the preview by ensuring text metrics are measured against the same loaded font that will paint the final SVG.

Mermaid measures text in a temporary element appended to document.body. We were passing fontFamily: "inherit" in the theme, so the measurement font could resolve differently from the font actually used inside .prose-zen. Rendering also often ran before the active font finished loading, so labels were sized for a fallback font and then clipped once the real font painted.

Changes

• Read --z-text-font as a concrete font-family stack and pass it to mermaid's themeVariables.fontFamily.
• Await document.fonts.ready before calling mermaid.render() so text metrics are computed against the loaded font.

Screenshots

Before

After

[adibhanna]

Merged into the v2.21.0 release branch as 9ee84c8. Thank you, this is a good catch and the diagnosis was exactly right.

For anyone reading later, the root cause in one line: body uses --z-interface-font (sans) while .prose-zen uses --z-text-font (mono by default), and mermaid measures HTML labels in a temp element attached to body. So fontFamily: "inherit" measured sans and painted mono, and every label came out narrower than its own text.

Verified by driving the built app over CDP and measuring each label's content width against its foreignObject box:

	labels overflowing	worst overflow
before	15 / 15	20.0px
after	0 / 16	0px

Three extra checks beyond the screenshots:

• With a user-chosen text font (text_font = "Georgia"), the --z-text-font read path resolves and measures correctly. Worth noting since the variable is unset until someone picks a font, so the default case only exercises the hardcoded fallback.
• Sequence, pie, and class diagrams, which mermaid measures with its own font config rather than themeVariables, show no regression.
• document.fonts.ready sits after the blocks.length === 0 early return, so notes without mermaid never wait on it. That ordering matters because preview swaps in its whole DOM only after renderMermaidBlocks resolves.

One follow-up commit on top (dd6bc46): the fallback stack was written twice in one file, as readThemeFont's default parameter and again at the only call site. It is now a named constant with a comment tying it to the --z-text-font fallback in index.css, since a drift between the measured stack and the painted stack is precisely what brings the clipping back. Resolved stack is byte-identical, no behavior change.

Closing here because the merge landed on the release branch rather than through the GitHub button, so this cannot auto-close. Ships in 2.21.0.

[junereycasuga]

thanks @adibhanna