Skip to main content

Questions

Can I print a document from my application?

Yes, and with nothing to install. Every generated application ships with a print stylesheet: Ctrl+P — or “Save as PDF” — produces an A4 page stripped of the navigation, in black on white whatever theme is showing on screen. The summary statement goes further: it carries a deterministic “Print” button, its colour flats are faithfully reproduced, and its page breaks never cut an amount row in two. What you should know, on the other hand: the PDF is produced by the browser, not by a bundled library — so there is no invoice template on your letterhead, and no automatic emailing. This page states exactly what comes out of the printer, and what does not.

What every application already has: a clean A4 sheet

The print stylesheet is not an option to switch on: it is written into the stylesheet of every generated application, and it applies only when printing — the on-screen rendering stays identical to the character. What it does comes down to four gestures. It fixes the format to A4 with readable printer margins. It strips from the paper everything that has no business being there: the side navigation rail, the top bar, the session footer, the Blueprint badge and any element marked as non-printable — the “Print” button itself is one of them, so it never lands on the output.

It then forces the background to white and the ink to black, whatever theme is active at the time of printing: an application displayed in dark mode does not produce a black page, and contrast is guaranteed without burning through a cartridge. Finally — the least visible and most useful point — it gives the shell the behaviour of a document. On screen the application occupies the window height and scrolls its content inside; when printing, that mechanism would produce a page truncated at the first screen height. The rules neutralise it: the height follows the content, and a forty-row list comes out over as many pages as it needs.

The summary statement: a deliverable, with its button

A summary statement section — a figures recap, a document with headings — is by nature meant for paper or PDF. It therefore carries a “Print” button placed deterministically by the generator, with no dependency and no network call: it triggers the browser's print, and it is itself hidden from the output. The document is reworked accordingly: the drop shadow disappears, rounded corners are squared off, the width becomes full page, and internal horizontal scrolling is neutralised so that nothing stays off the paper.

Two details separate a document from a screenshot. First, the colour flats — header band, total line, subtotals — are faithfully reproduced, whereas browsers whiten them by default when printing: without that rule, the total line would lose exactly what distinguishes it from the others. Second, page breaks are enforced: an amount row is never cut in two across sheets, and a heading never stays orphaned at the bottom of a page — it travels with the rows it announces.

The PDF comes from the browser, and that is a choice

No PDF-generation library is bundled in the delivered application: the PDF is the one produced by your browser's print dialog, through “Save as PDF”. That choice cuts both ways, and it is better to know how. On the good side: it works offline, it costs nothing, it adds no dependency to maintain, and it works from a phone as well as from a computer. On the less good side: it is a manual gesture — there is no “send the PDF to the client” button — and the header, footer and file name come from the browser's settings, not from the application.

For line-item documents — an order recap, a detailed statement — the generator can produce the matching layout when the structure of your data warrants it: a parent, attached lines, and a line amount that is RECOMPUTED from the fields of the line. That last point is not a nicety: an amount recomputed at every render cannot drift from its components, whereas a stored amount can be checked against nothing. When the structure is ambiguous the generator abstains rather than producing a wrong document — no document beats a document that lies.

What it does not replace

Let us be plain: this is not an invoicing module. There is no invoice template on your letterhead, no legal numbering, no mandatory statements added automatically, no sending to the client — and an electronic invoice in the regulatory sense is not a PDF anyway, but a structured format transmitted through an accredited platform, a subject covered in its own question. What printing covers is the other need, the everyday one: producing a readable sheet to hand over, to pin up in the workshop, to take to a site or to file.

To move data rather than paper, every list also carries its CSV export button, which exports the rows you can see and shows their count on the button. And should a real PDF generator become necessary — a template in your own branding, numbering, automatic sending — adding one remains possible: the delivered code is an ordinary Next.js and Prisma project that belongs to you, and a developer can wire in what is needed. It is not provided turnkey; it is simply possible, which is not the case with a closed tool.

Going further

Related questions

Generate an application that prints cleanly