PDF export prints the live window, and the print stylesheet is a list of things being subtracted back out

[PathGao]

PDF export prints the live window, so anything on screen can end up on the page. #99 #103 #158 #163 #173 #232 #261 #328 #332 #359 #377 #382 #407 #411 #363 are all this — fifteen over five months, each looking like a different bug (spacing, images, theme, split width, find highlights, blank pages).

What it is today. print_pdf is one line:

// src-tauri/src/commands.rs:238
window.print().map_err(|error| error.to_string())

So the paper is whatever DOM is on screen — title bar, tab strip, splitter, find bar, TOC overlay, plus fold state and the current theme. @media print in styles.css is a list of things being subtracted back out, and it grows by one every time a new UI part is added. Miss one and it silently lands in someone's PDF.

The HTML export does the opposite: buildExportArticle re-renders from rawContent into a detached wrapper. That is why the two exports disagree — your own comment in styles.css says folds "disagreed with the HTML export, which renders every fold open".

Which way do you want to go?

1. PDF renders through buildExportArticle, like HTML already does. One export path, and a new UI part can never leak onto paper. Cost: printed output changes for everyone — folds all open, screen theme no longer carried, and anything people currently rely on seeing in the PDF because it was on screen.
2. Keep window.print(), keep subtracting. Zero risk today, and the @media print list keeps growing. fix(print): make an editor-mode PDF export contain the document #407 already had to add syncPreviewForPrint() because in edit mode the preview DOM was never updated — a fix that exists only to compensate for printing the live window.
3. Something in between you have in mind.

I lean 1, but it changes what people get on paper, so it is your call. Happy to do the work either way.