ZenNotes/zennotes v2.64.0

ZenNotes v2.64.0

on GitHub

ZenNotes 2.64.0 fixes Mermaid diagrams whose long labels were cut off mid-word. At a fractional display scale, such as 133%, or with the app zoomed to 90% or 120%, a label longer than about 200 pixels stayed on one line and was clipped at the edge of its box; it now wraps onto two or three lines, the way GitHub and other Markdown apps draw it (#911).

Released from 82943baf through #912 on 2026-10-08. All installers are verified.

Fixes

• Long Mermaid labels wrap instead of being cut off. Mermaid decides whether a label wraps by laying it out on one line under a 200px limit and checking whether it came back exactly 200px wide. At a fractional device scale the browser hands back a width a hair off, such as 199.995px at a 133% display scale or 200.00001px at 120% app zoom on a Retina Mac, so the check failed: the label stayed on one line, its box was sized to the limit, and the rest of the text was clipped ("aurora, forwarding disabled P"). Labels now wrap at every scale, in node boxes and on edges alike, in the editor's live preview, the Preview, the expanded diagram view, PDF export and shared notes. Diagrams that already fit look exactly as before (#911).

For contributors

• Mermaid (#911): the check is bbox.width === width in mermaid's addHtmlSpan, still exact in mermaid 11.17.2 and 12.1.0, so upgrading does not fix it. withCapAwareLabelMeasurement in packages/app-core/src/lib/mermaid-render.ts wraps mermaid.render: while a diagram lays out, an element inside a foreignObject with an inline px max-width that measures within half a device pixel of that cap reports the cap. The patch on Element.prototype.getBoundingClientRect is installed by the first overlapping render and removed by the last. Every mermaid render goes through renderMermaidSvg; keep it that way. mermaid-render.test.ts feeds the widths Chromium reported through a stand-in mermaid. Drop the workaround once mermaid compares with a tolerance.
• Packaging: macOS apps are notarized once. build.mac.notarize is false, which electron-builder 26 treats as an explicit skip, so the afterSign hook apps/desktop/scripts/notarize.cjs is the only submission (it staples through @electron/notarize). 2.62.0 and 2.63.0 notarized every Mac app twice, which doubled the wait on a slow Apple queue and failed one 2.63.0 rebuild.

Demos

In docs/releases/v2.64.0/media/ (local), 1080p with captions burned in and a .vtt beside it. The clip runs the same steps on the packaged 2.63.0 app, then on a 2.64.0 build, both on a scratch vault at a 133% display scale:

• 911-mermaid-labels.mp4 (16 s): a note with the reporter's first diagram in Preview. On 2.63.0, 7 of its 9 labels are cut off mid-word ("aurora: forwarding disa", "RB5009 ether2 at 10.255"); on 2.64.0 every label wraps onto two or three lines and reads in full.

Verification

How to test locally:

1. Build and launch at a 133% display scale with isolated stores: npm run build --workspace @zennotes/desktop, then ZENNOTES_USER_DATA_PATH=$(mktemp -d) ZENNOTES_CONFIG_DIR=$(mktemp -d) npx electron --force-device-scale-factor=1.333 apps/desktop/out/main/index.js. On a Retina Mac you can instead keep the normal scale and press ⌘= twice (120%) before opening the note.

2. Paste this into a note:

   ```mermaid
   flowchart TB
       admin["aurora: forwarding disabled PLUS SOME MORE EXTRA TEXT"]
       nic["USB NIC enp0s20f0u9 at 10.255.255.2/30"]
       rb["RB5009 ether2 at 10.255.255.1/30"]
       admin --- nic
       nic ---|"10.255.255.0/30 rb5009-rescue network"| rb
   ```

3. Before: every long label sits on one line and is cut off mid-word at the right edge of its box. After: each wraps onto two or three lines and reads in full, in the live preview and in Preview (⌘5). Short labels are unchanged.

4. Press ⌘0 afterwards to reset the zoom.

Distribution channels

• GitHub release: installers for macOS (Apple silicon and Intel DMG and zip), Windows (x64 installer and zip) and Linux (x64 and arm64 AppImage, deb, rpm, pacman, tar.gz), with the four update manifests.
• AUR: zennotes-bin 2.64.0-1 (AUR clone e38e04c, repo d12ef506), pinned to ZenNotes-2.64.0-linux-x64.tar.gz SHA-256 50064e0b…2c91 (GitHub's own digest for the asset), after the bump script checked the bundled CLI folder is world-readable; aur-check green.
• Nix: packaging/nix/release-data.json lifted from the update workflow (run 37846314968, bot PR #913 closed) as 91eb5c76; its desktopHash is the same digest as the AUR pin, and nix-build passed on main.
• nixpkgs: NixOS/nixpkgs#571881 proposes 2.63.0 -> 2.64.0 (the 2.63.0 PR merged upstream on October 7); the source hash comes from the tag tarball, and the same command reproduces master's 2.63.0 hash.
• Homebrew: zennotes 2.64.0 in the tap (b12f737), mirrored in ee446f50; both DMGs were downloaded and their SHA-256 matches the cask and GitHub's digest; brew style clean.
• Website: ZenNotes/website#64 merged at f1139db2: the releases page with the clip, and the share viewer moved from 2.63.0 to 2.64.0 so published notes wrap long Mermaid labels too. Its main tests and deploy passed (run 37850595354), Laravel Cloud's deployment succeeded at 22:07 UTC, and zennotes.org serves the 2.64.0 release entry, the clip byte for byte, and the 2.64.0 viewer next to the retained 2.63.0 and 2.51.0 ones, each matching its pinned hash.
• zn CLI: unchanged; this release bundles 0.6.3, and no CLI code has changed since.
• Server: ZenNotes/znserver v2.64.0 pins the published web-2.64.0-web.h6361544165aafa2b browser artifact; Docker adibhanna/zennotes:2.64.0, 2.64 and latest (linux/amd64 and arm64, one digest).
• Phones: iPhone 1.20.0 (36) and Android 1.1.34 (37) on core-2.64.0-core.hbc630bc258a16fbb (published), both in store review. They also carry onboarding text that no longer says notes are "never on our servers" (untrue for Cloud users) and a Welcome note without em dashes. Android's GitHub release v1.1.34 carries Play's signed universal APK.

Release validation

Cycle checks:

• #911 was reproduced in the built app over CDP on an isolated profile with the reporter's two diagrams, measuring each label's box against its text: at 120% and 90% app zoom on a Retina display, 12 of 21 labels were clipped in both the live preview and Preview. The first fix (snapping widths within a thousandth of a pixel) held at every app zoom but still clipped 12 labels at a forced 1.333 display scale, where the browser reports 199.9953px for the 200px cap; the shipped fix compares against the label's own cap instead. It was then run at twelve scales (forced display scales 1.25, 1.333, 1.5, 1.666 and 1.75; app zoom 90%, 100%, 110%, 120% and 130% on a 2x display; 90% and 120% on a 1x display): no label is clipped at any of them, and the labels wrap the way Zed draws the same diagrams. Seven of the twelve hand back a cap width that is not exactly 200px. The demo clip's before take confirms the shipped app: the packaged 2.63.0 at a 133% scale cuts off 7 of the demo diagram's 9 labels, and 2.64.0 none. Not run on Linux itself.
• mermaid-render.test.ts (5 tests) fails 3 of 5 without the fix; app-core's 3,127 tests pass and the typecheck is clean.

Release-time gates on 82943baf:

• npm run typecheck 8/8 and npm run test:run 6/6 with no turbo cache: shared-domain 1,896, app-core 3,127, quicklook 15 and desktop 1,052 tests passed. npm audit --omit=dev --audit-level=high is clean (15 low or moderate advisories remain, in dompurify, ip-address and smol-toml).

• npm run pack signed the app. Its first run lost a timestamp on this Mac (codesign's timestamp request failed over IPv6 while the build itself was green), so the pack finished against Apple's timestamp server by its IPv4 address; the signature carries a real Apple timestamp, and CI signs on GitHub's runner. codesign --verify --deep --strict passed, the pack log shows electron-builder's "skipped macOS notarization" next to the hook, the bundled CLI in Resources/zn-cli is world-readable and reports zn v0.6.3, and the packaged launch check found a page target in 1.4 s reporting 2.64.0.

• Smoke suites on the built app: test:vim-editor, test:sidebar-vim and test:editor-improvements passed on their first run.

• PR #912: all nine checks passed on 82943baf (macOS, Windows, Ubuntu x64 and arm64 builds, the installed-editor browser check, CodeQL and the production audit); main fast-forwarded to it and the annotated tag v2.64.0 points at it.

• Release run 37844595671 published every platform in one pass: Linux arm64 in 12 minutes, Linux x64 in 14, Windows in 37 and macOS in 44. Each Mac app was notarized once: the log shows electron-builder's "skipped macOS notarization" and then one [notarize] pass per architecture (arm64 about 2 minutes 47 seconds, x64 about 2 minutes 40 seconds), so the double notarization behind 2.63.0's delays is gone.

• All four update manifests and the 13 files they name passed size and downloaded SHA-512 verification. The apps in both DMGs passed notarization (Notarized Developer ID), staple and strict deep signature checks, report 2.64.0 and carry ZenNotesQuickLook.appex; the arm64 app bundles zn v0.6.3 in a world-readable Resources/zn-cli. GitHub latest is v2.64.0, and verify:channels -- 2.64.0 passed for Homebrew, AUR, Nix and all seven website download routes.