2.5.0 #10
Loading…
Reference in a new issue
No description provided.
Delete branch "2.5.0"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Rather a large PR. Most of it due to name change from oAI -> Confab.
Rune retested after the previous merge fix (bigger token budget, stronger instruction) with the exact same DDNS Docker debugging conversations and got the identical failure — same error text, same models. Logs showed a single ~86s request with a large prompt (31k tokens cached) and no truncation signal available to check. The remaining suspect: the transcript was formatted as "**User:**" / "**Assistant:**" markdown, which closely mimics a live chat turn format. Over a long, noisy transcript that includes something reading like a directive ("no more editing", etc), the model can lose track of "this is data to merge" and slip into continuing/replying to it instead — matching exactly what was observed. Replaced the transcript markers with synthetic, non-chat-like tokens (<<<USER_TURN>>> etc) and added an explicit "this is not a live conversation" framing both before and after the transcript block, not just once at the top. Also: log OpenRouter's finishReason when it's "length" (i.e. the response was actually cut off) so a future failure like this is distinguishable from a formatting/instruction-following miss without guessing from the log lines Rune already has available.Empirically reproduced this outside the app (standalone WKWebView + createPDF script, inspecting real PDF page bounds via PDFKit) instead of guessing again. Findings: - WKPDFConfiguration.rect left at default captures the webview's frame size verbatim when content fits within it, and auto-grows to a single tall page matching full scrollable content when it overflows. It does not paginate, and setting rect explicitly just clips to that one rect instead. - The scrollHeight-based frame resize added last round (to "fix" this same bug) was itself the problem: resizing the frame before calling createPDF produced a page that didn't match the resized frame at all (e.g. resized to 816x295, captured page came out 799x375) — a small, badly-proportioned page that made ordinarily-sized text look enormous relative to it. Removed entirely. - A visible scrollbar during capture shaves ~17pt off the captured page width. Added ::-webkit-scrollbar { display: none } to prevent that. Verified against a 12-message realistic conversation: clean single page, correct proportions, readable text, matches the intended CSS layout. The text-size-adjust/viewport-meta fix from last round turned out to be unnecessary (computed font-size was correct all along) but is harmless, so left in place.Two things were fighting the previous dark-PDF attempt, both confirmed by direct experimentation: - prefers-color-scheme is ignored entirely by the print pipeline — identical CSS printed light even with the webview's appearance forced to dark. Screen dark-mode media queries just don't apply to NSPrintOperation rendering. - Even with dark colors set unconditionally (no media query), the print pipeline still dropped every background color and printed white — browsers/WebKit strip background-color/background-image by default when printing, to save ink, unless told otherwise via print-color-adjust: exact. PDF now has its own always-dark stylesheet (pdfCss) instead of the prefers-color-scheme-driven one HTML export still uses, plus `* { print-color-adjust: exact }` so the dark backgrounds actually survive the print pass. html(name:messages:) takes a new forceDarkCSS parameter (default false, unchanged for HTML/other callers); pdfData passes true. Dropped the now-pointless webView.appearance forcing, since dark is unconditional now. Verified with the same standalone repro-script + Read-the-PDF method: dark page background, colored message boxes, dark code block, all correctly surviving the real A4 print pipeline.