Font Rendering Broken on macOS Tahoe 26.5 Beta

[bpmore]

Solo: Font Rendering Broken on macOS Tahoe 26.5 Beta

Summary

This issue has stopped me from working in my favorite app.

Terminal text in Solo v0.5.9 renders as garbled/malformed glyphs on macOS Tahoe 26.5 beta (build 25F5042g). The underlying text data is correct (copy/paste to another app renders properly), but the visual rendering in the terminal pane is unreadable. The sidebar UI text renders correctly. This is a regression from 26.4, where everything worked.

Environment

• Solo version: 0.5.9
• macOS: Tahoe 26.5 beta (build 25F5042g)
• Architecture: Apple Silicon (arm64)
• Reproduced on: Two separate machines after upgrading to 26.5 beta

Steps to Reproduce

1. Install macOS Tahoe 26.5 beta
2. Launch Solo Terminal
3. Open any terminal or command process
4. Observe the terminal output pane

Expected Behavior

Terminal text renders normally with the selected monospace font.

Actual Behavior

Terminal text renders as garbled/malformed glyphs. Characters appear as wrong or composite glyphs (e.g., letters rendered with incorrect glyph IDs). The text is correct underneath: selecting the garbled text and pasting into another application produces the correct characters.

Key observation: The sidebar UI (project names, section headers like "AGENTS", "TERMINALS", "COMMANDS", process names) renders perfectly. Only the terminal output pane is affected.

Root Cause Analysis

Solo is a Tauri v2 app (Rust backend + WKWebView frontend). The architecture is:

1. Rust backend manages terminal state using vt100 crate (v0.16.2) and portable_pty for PTY management
2. Process output is sent to the frontend as raw byte chunks (ProcessOutputChunk) via Tauri's event/channel system
3. SvelteKit frontend in a WKWebView renders the terminal output
4. Font selection is stored in WebKit LocalStorage (terminalFontFamily, default: "Menlo")

The sidebar text uses standard DOM/CSS text rendering (which works fine). The terminal pane uses a different rendering path for the process output, which is where the WebKit regression manifests.

Why this is a WebKit regression, not a Solo bug

• Worked on 26.4, broken on 26.5 with no Solo update in between
• Sidebar (DOM text) renders correctly, only the terminal output pane is broken
• Font changes have no effect: swapping terminalFontFamily from "Menlo" to "SF Mono" via LocalStorage produces the same garbled output
• Apple has a known report of WKWebView rendering TTF fonts incorrectly with garbled composite glyphs (Apple Developer Forums thread 814745)
• Tauri has existing font rendering issues with WKWebView on macOS ([bug] <select> renders wrong font tauri-apps/tauri#13747, [bug] Font rendering differs in browsers and Tauri tauri-apps/tauri#12638)

What Was Ruled Out

Hypothesis	Result
Missing data/config	Not the issue. Fresh installs reproduce.
Copying WebsiteData from working machine	No effect
Font selection (Menlo vs SF Mono)	Both produce garbled output
Font cache reset (sudo atsutil databases -remove)	No effect
Solo SQLite database (~/.config/soloterm/solo.db)	Font settings not stored here
WebKit IndexedDB/storage	Effectively empty

Solo's Data Locations (for reference)

Location	Contents
~/.config/soloterm/solo.db	Projects, processes, license, settings (no font settings)
~/Library/WebKit/com.soloterm.solo/WebsiteData/.../LocalStorage/localstorage.sqlite3	UI state including terminalFontFamily, terminalFontWeight, terminalFontScale (stored as UTF-16LE encoded JSON blob)
~/Library/Application Support/com.soloterm.solo/	Empty
Per-project solo.yml	Process configs only

LocalStorage Schema (font-related settings)

The key solo-ui-storage in WebKit LocalStorage contains:

{
  "state": {
    "theme": "system",
    "sidebarWidth": 240,
    "fontScale": 1,
    "terminalFontScale": 1,
    "terminalLineHeight": 1,
    "terminalLetterSpacing": 1,
    "terminalFontFamily": "Menlo",
    "terminalFontWeight": "400",
    "terminalFontWeightBold": "600"
  },
  "version": 0
}

Suggested Fix

Since this is a WebKit regression in the system font resolution path, possible workarounds for Solo:

1. Bundle a web font (e.g., embed a WOFF2 monospace font in the app assets) and use @font-face declarations instead of relying on system font name resolution through WKWebView's CoreText integration
2. Use CSS font-family with explicit fallback chain including generic monospace keyword
3. If the terminal pane uses <canvas> text rendering (e.g., fillText/measureText), consider providing a DOM-based fallback renderer, as canvas text rendering appears more susceptible to the WebKit regression than DOM text
4. Enable isInspectable in debug/beta builds so users on beta macOS can provide Web Inspector diagnostics (currently locked out in release builds)

Related Issues

• Apple Developer Forums: WKWebView Occasionally Renders TTF Font Incorrectly
• Tauri: Font rendering differs in browsers and Tauri
• Tauri: <select> renders wrong font (CoreText error)
• Ghostty: Poor font rendering on macOS Tahoe external display

Workaround for Users

None currently available. Changing fonts in Solo's settings UI has no effect since the issue is in the WebKit rendering layer, not font selection. Users on macOS 26.5 beta should downgrade to 26.4 until either Apple fixes the WebKit regression or Solo implements a workaround.