Record fork chrome-fix evaluation: all superseded by darkmodelib

Evaluated the sumatrapdf-plus dark-chrome bug fixes against master; none
apply: the dark-to-light scrollbar reset is already handled (darkmodelib's
setDarkExplorerTheme resets the native theme when experimental dark is
inactive, and we call it on every theme change), frame border colors are
set via UpdateWindowFrameBorderColor/dwm::SetWindowBorderColor, and the
toolbar-separator work is tied to fork-only toolbar buttons. Details in
ai/super-themes.md; also record the F outcome in ai/plus-merge.md and a
PrintWindow verification gotcha in the verify skill.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
prompt: port fork theme/chrome improvements: evaluate remaining chrome fixes

Author: kjk

.claude/skills/verify/SKILL.md

@@ -39,6 +39,14 @@ postMessage(frame, 0x0010 /*WM_CLOSE*/, 0, 0);
 
 ## Gotchas
 
+- `captureWindowToPng` (PrintWindow) does NOT capture the custom caption row's
+  buttons (painted via `BeginPaint` directly on the frame DC) nor native
+  scrollbars (non-client area) — those regions come out blank. Screen capture
+  (`CopyFromScreen`) is also unavailable in this environment (blank desktop).
+  To verify such drawing code, dump its output to a bitmap via a temporary
+  harness (render into a `CreateDIBSection` DC, save with `HBITMAPToBmpFormat`
+  + `file::WriteFile`, view, then remove the harness).
+
 - `out/dbg64/SumatraPDF-settings.txt` exists (portable mode): the dbg build **loads** it even under `-for-testing` (which only prevents saving). Stale values there change app behavior in tests — e.g. a non-default `PdfDocumentColorMode` silently alters rendering. Check it when the app behaves unexpectedly at startup; it's written only by non-`-for-testing` (manual) launches.
 
 - Unit tests: `bun cmd/run-unit-tests.ts -dbg` (but verification = driving the app, not tests).

ai/plus-merge.md

@@ -274,7 +274,7 @@ additions (we generate via premake).
 | _(pending)_ | C. Ask AI | — | |
 | 2026-07-11 | D. Smart PDF dark mode | **merged** | as `86e5cb24c`; ported all 15 `PdfDarkMode*` modules + 2 unit-test files by hand (Vec API `.Size()/.at()` → `len()/[]`, `utils/`→`base/` includes, no `#pragma once`, PCH opt-outs). KEY FINDING: the fork ships with the object-level OKLab renderer compile-time OFF (`kPdfDarkModeRenderer = LegacyBitmapPostProcess` in PdfDarkModeColor.cpp) — the live feature is per-doc color mode + classifier-driven image preservation in the bitmap recolor; we kept it identically dormant (wired into RenderPage but unreachable). SEMANTIC ADAPTATION: fork keys dark mode off their dark themes (feature F recolors pages per theme); master's themes never touch page colors, so ours keys off the effective page colors (`FixedPageUI.InvertColors` / custom dark colors) — with invert on, `auto` preserves photos (new default), `black` = old invert-everything, `light` = don't invert PDFs. Integration: `RenderPageArgs.darkProfile` + `darkModeEpoch` (request/entry staleness) in RenderCache, `UpdateBitmapColors` extended with linkColor+skipRects, `GetBitmapRecolorSkipRects` (content-stream image collection + classifier gating) in EngineMupdf, `PdfDarkModeNoOp.cpp` for filter/preview/test_engines/mac, `fz_colorspace_n` added to libmupdf.def. Setting `PdfDocumentColorMode` (auto/black/light) + 4 commands. Verified end-to-end with a synthetic photo PDF (screenshots: photo preserved in auto, inverted in black, original in light; deterministic re-renders). Fork's RenderCache non-blocking CancelRendering + UpdateAfterThemeChange reorder (735894b11) still not taken — master's CancelRendering was already reworked. |
 | 2026-07-10 | E. CAD line enhancement (`735894b11`, `b058ba496`, `38006d0e8`) | **merged** | as `211f989d1`; ported by hand against master (fork base predates Pixmap/PCH/Str refactors). Key adaptations: `EngineeringDrawingEnhance` mode pushed via setter from `LoadSettings` (gDisableFormJavaScript pattern) instead of reading gGlobalPrefs in PdfCadDetect.cpp — so no `PdfCadEnhanceNoOp.cpp` needed; real files compile everywhere (incl. mac) with mode defaulting to Off outside the app. Fixed fork's read-after-free of analysis-device stats (stats now caller-owned) and their unguarded fz_rethrow out of DetectCadPdf. Added 12 missing fz_* exports to libmupdf.def (fork's approach was the NoOp stub instead). Skipped: their RenderCache/UpdateAfterThemeChange hunks (dark-mode toolbar fix, belongs to D). Setting editable in Advanced Settings dialog (enum values added). |
-| _(pending)_ | F. Themes & chrome | — | |
+| 2026-07-11 | F. Themes & chrome | **ideas ported** | analysis + outcome in [super-themes.md](super-themes.md): light/dark toggle + System theme as `0de700a15`, Light Warm palette as `8797b20f3` (Dracula/black already existed), Win11 caption glyphs as `c837e3d92`; their page-color-driving theme philosophy rejected (kept master's chrome-only themes); all dark-chrome bug fixes evaluated and found superseded by master's darkmodelib handling |
 | _(pending)_ | G. Ebook engine work | — | |
 | 2026-07-10 | H. Selection toolbar (`db0b32b7a` + follow-up polish) | **merged** | as `dba10007e`; ported `SelectionToolbar.{cpp,h}` by hand; folded the shared `FloatingPopupStyle.{cpp,h}` helpers into it (they only exist to share chrome with WordLookup, feature B). Buttons rewritten on top of master's `CommandAvailability` (`GetCommandVisibility`, `CommandSurface::Toolbar`): Copy, Read Aloud, Highlight, Underline, Squiggly, Strike Out; dropped fork's Ask AI / Look Up buttons (features C/B). Theme colors mapped to master's Theme.h (`IsLightColor(ThemeWindowBackgroundColor())` for dark detection). Setting `Annotations.SelectionToolbar` (bool, default true). Skipped unrelated hunks bundled in `db0b32b7a`: Menu.cpp UINT_PTR fix (master already fixed via CommandAvailability refactor), `EngineMupdfGetAnnotations` quick-load/no-pagesLock change (master's locking was rewritten; possible perf win for large docs — evaluate separately), `HwndSetIcon` ICON_SMALL addition (unrelated; could take separately). |
 | _(pending)_ | I. Home page list view | — | |

ai/super-themes.md

@@ -78,6 +78,37 @@ polish. Commit series `1cd0c85d6`→`b0002c393`.
    theme; maximized frame edge color in dark themes). The rest is presumed
    superseded by darkmodelib.
 
+## Outcome (2026-07-11)
+
+1. Done as `0de700a15` (System theme + `CmdToggleLightDarkTheme` +
+   `LastLightTheme`/`LastDarkTheme`).
+2. Done as `8797b20f3` — only **Light Warm** was added; the fork's Dracula and
+   pure-black palettes already exist in master as the `Dracula` and `Dark`
+   themes.
+3. Done as `c837e3d92` (`src/CaptionGlyphs.{cpp,h}` +
+   `tools/gen_caption_glyphs.py`, wired into `DrawCaptionButton`).
+4. **All evaluated chrome fixes are superseded on master — nothing ported:**
+   - scrollbar reset (`597f0c47d`): master calls
+     `DarkMode::setDarkScrollBar(hwndCanvas)` on *every* theme change and
+     darkmodelib's `setDarkExplorerTheme` passes `nullptr` (reset) when
+     experimental dark is inactive, so switching back to a light theme already
+     resets the scrollbar. The fork fixed a code shape (dark-only call) master
+     doesn't have.
+   - maximized frame edges / border color (`c4018ec06`): master already has
+     `UpdateWindowFrameBorderColor` + `dwm::SetWindowBorderColor` on theme
+     change.
+   - toolbar separators (`0e493c658`, parts of `c4018ec06`): tied to their
+     extra toolbar buttons; master's toolbar has since been reworked (overlay
+     mode etc.); no symptom observed.
+   - `81defc78b` (Light-Warm menubar without tabs), `36468333a` (broad dark
+     polish): fork-theme-specific; master themes chrome via darkmodelib's
+     `setWindowMenuBarSubclass`/`setChildCtrlsSubclassAndTheme`.
+
+Verification note: neither the custom caption nor native scrollbars render
+into `PrintWindow` captures (caption paints via `BeginPaint` on the frame DC;
+scrollbars are non-client) — glyphs were verified by dumping
+`DrawCaptionSysButtonGlyph` output to bitmaps via a temporary harness.
+
 ## Gotchas
 
 - Fork's theme code assumes their fixed 5-theme indexes (`kThemeIdx*`) —