Rune compared our PDF against a normal reference PDF and the
difference was structural, not just a font-size tweak: the reference
was 6 standard A4 pages (595x842pt); ours was ONE continuous page
850x6886pt — nearly 8 feet tall. That's what createPDF() actually
does when content overflows its frame (confirmed in the prior commit)
— it auto-grows to fit everything as a single non-standard-sized
page, never paginating. There was no page of a familiar size to judge
the "normal" font size against, which is what actually read as "huge"
even after the sizing fixes.
Replaced with WKWebView's real print pipeline: build an NSPrintInfo
for US Letter (612x792pt) with normal margins, get a print operation
via webView.printOperation(with:), and run it silently (no panel) to
a temp file, dispatched off the main actor since NSPrintOperation.run()
blocks synchronously. This is genuine multi-page pagination — same
mechanism any app's real print-to-PDF uses.
Also added break-inside/page-break-inside: avoid on .message so a
single message doesn't get split awkwardly across a page boundary.
Verified with a standalone reproduction script (same method as the
prior fix) using the actual exported CSS and realistic multi-message
content: clean 2-page US Letter output, message boundaries respected
across the page break, normal-looking document proportions.
rune
7f5374dce0