` child per page — when the user asks for a page count or the design implies one: a one-page resume, a two-sided flier, a certificate, a brochure). If in doubt, ask the user. Keep the design's typography, colors, and imagery intact either way. For FLOWING documents the component pins no paper size — the print engine paginates onto the user's real paper. Explicitly paginated pages print at a FIXED page box with overflow hidden — letter by default (set size="a4" for a clearly metric user), the user's chosen paper when they export — and content that misses the box is clipped, never reflowed: design each page to FILL the page box and fit letter and A4 alike without overlap (no viewport units — they track the window, not the page). `orientation="landscape"` for landscape sheets. The component owns the sheet, the pagination, and all print geometry — do NOT write your own `@page` rule, print-CSS reset, page-card divs, hard-coded paper dimensions, or `break-after: page` fake sheets. In flowing documents use `break-before: page` only where a section genuinely starts a new chapter; long tables get a `` so the header repeats on every page. **A fixed-canvas design (poster, social graphic, infographic) also goes through the doc_page rebuild, with one decision: the page.** Print it at its true dimensions — ``, the page IS the design (use explicit width/height ONLY when the user gives or implies a real physical size) — or scale it onto standard paper — `` (`size="a4"` when the user is clearly metric), where the content lays out at its authored size and the component scales it to fit that sheet's printable area. Scaled-fit is the ONE place a named size still matters: the component must compute the fit against a known sheet (the export dialog re-fits to the user's actual paper choice at print time where available). When the user's intent between the two isn't clear from their request, ask — in plain terms (print it poster-sized, or fit it onto regular paper?) — before exporting. Never hand-scale with your own CSS transforms; the component owns the scaling either way. In every copy, add the color-adjust rule so backgrounds and colors match the preview — do NOT strip backgrounds from the design: ```css * { -webkit-print-color-adjust: exact; print-color-adjust: exact; } ``` **Jump animations to their end state.** Do NOT use `animation: none` (that reverts fade-ins to the hidden base). Instead freeze every animation at its final frame and disable transitions: ```css * { animation-delay: -99s !important; animation-duration: .001s !important; animation-iteration-count: 1 !important; animation-fill-mode: both !important; animation-play-state: running !important; transition-duration: 0s !important; } ``` 3. **Test the file** by showing it with `show_html`, then make sure there are no JS errors. No need to screenshot unless asked. 4. **Call the `show_pdf_export_dialog` tool** with the project-relative path to the print-ready file. The print-firing code is injected into the print copy automatically when you call this tool — do NOT write an auto-print or `window.print()` script yourself. Unless the export started from the user's own Export click, the tool does not open anything itself: it presents an export dialog, and the user's **Continue to export** click there is what opens the print view. The tool result says which happened — when it says the dialog is waiting on the user, the print view has NOT opened; say so plainly and never claim it has. The tool fails with a reason if the file (and its print source) is not print-based — the doc_page rebuild from step 2 is exactly what keeps the copy eligible. ### Important Notes - The goal is a file that prints cleanly on real pages — the doc_page component owns the pagination; your job is the content - Maintain visual fidelity — keep the design's typography, colors, and imagery intact - For `` decks, each slide stays on its own page; `` documents flow and paginate themselves - For prompt-driven exports, `show_pdf_export_dialog` waits on the user: the export dialog's **Continue to export** click opens the print view, and until then nothing has opened — report the state the tool result describes, not the state you expect - The `-print.html` is plumbing for the print tab, not a deliverable — `show_pdf_export_dialog` is the only delivery step. Do NOT `present_fs_item_for_download` it; its relative asset paths only resolve via the project file server and break when opened standalone.