Repository navigation
Conversation
Reported in #911: long flowchart labels were cut off mid-word ("aurora, forwarding disabled P"), while GitHub, GitLab and Zed wrap the same diagrams onto two or three lines. Mermaid lays a label out on one line under an inline 200px max-width and switches it to wrapping only when it measures exactly 200px wide. At a fractional device scale the browser lays that cap out in device pixels and hands back a width just off it: 199.9953px at a 1.333 display scale, 200.0000152px at 120% app zoom on a Retina Mac. The check fails, the label stays on one line, its node is sized to the cap, and the rest of the text is clipped. Mermaid 11.17.2 and 12.1.0 still compare exactly, so an upgrade would not help. While mermaid lays a diagram out, a label measured within half a device pixel of its own max-width is now reported at exactly that width. Laying the cap out in device pixels moves it by far less than that, and a label genuinely that much narrower still fits on one line once mermaid wraps it, so nothing visible changes for it. Every surface that draws a diagram renders through this one helper (Preview, the live preview, the expanded view, PDF export, the share viewer, and the phone apps once they take this core), so they all get it. What it deliberately does not do: change mermaid's wrapping width or turn labels into SVG text. Diagrams look the way they always did; long labels now wrap. Verified in the built app over CDP with isolated stores and the reporter's two diagrams, across twelve scales: forced display scales 1.25, 1.333, 1.5, 1.666 and 1.75, app zoom 90% to 130% on a 2x display, and 90% and 120% on a 1x one. Seven of them hand back a cap width that is not exactly 200px. Before the fix 12 of 21 labels were clipped in both the live preview and Preview (observed at 90%, 120% and 1.333); after it, none are at any of the twelve, and the labels wrap the way Zed draws them. mermaid-render.test.ts feeds the measured widths through a stand-in mermaid and fails without the fix.
2.63.0's Mac apps were each notarized twice. electron-builder runs its own @electron/notarize step whenever the APPLE_* secrets are set and build.mac.notarize is left unset, and the afterSign hook (scripts/notarize.cjs) then submitted the same app again. On a slow Apple queue that doubled the wait: the 2.63.0 macOS job sat 95 minutes, and the first rebuild failed on the second x64 pass with an empty "unexpected result" from notarytool. build.mac.notarize is now false, which electron-builder 26 treats as an explicit skip (it logs "skipped macOS notarization"), so the hook is the only submission. The hook still demands the credentials when REQUIRE_MAC_SIGNING is set, and @electron/notarize staples the app after it is accepted, so the shipped apps come out the same: notarized and stapled. What it deliberately does not do: change which credentials notarize, or notarize the DMG itself. The release run's macOS log is the proof: one "[notarize] Notarizing" per architecture next to electron-builder's skip.
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ZenNotes 2.64.0.
Fixes
withCapAwareLabelMeasurementinlib/mermaid-render.ts).build.mac.notarize: falseturns off electron-builder's built-in step, so theafterSignhook is the only submission (2.63.0 notarized every Mac app twice).Cycle verification: the reporter's two diagrams in the built app over CDP at twelve scales (display scales 1.25 to 1.75, app zoom 90% to 130% on 2x, 90% and 120% on 1x): 0 of 21 labels clipped at every one, where 2.63.0 clipped 12 at 90%, 120% and 1.333.
mermaid-render.test.tsfails 3 of 5 without the fix.Local gates on
82943baf: typecheck 8/8 and test:run 6/6 with no turbo cache (shared-domain 1,896, app-core 3,127, quicklook 15, desktop 1,052),npm audit --omit=dev --audit-level=highclean (15 low or moderate remain in dompurify, ip-address and smol-toml).npm run packsigned the app (this Mac's codesign lost one timestamp over IPv6, so the pack finished against Apple's timestamp server by IPv4; CI signs on GitHub's runner), deep strict codesign OK, the pack log shows electron-builder's "skipped macOS notarization" next to the hook, bundledzn v0.6.3inResources/zn-cli(drwxr-xr-x), packaged launch check: page target in 1.4 s reporting 2.64.0. Smoke suites on the built app: vim-editor, sidebar-vim and editor-improvements passed on their first run. Demo clip: the packaged 2.63.0 at a 133% display scale cuts off 7 of the demo diagram's 9 labels, this build none.