Pattern: issued document

Does this belong in a CSS framework at all? — the grill verdict

The Accept for this pattern asked the question outright, and the honest answer is half yes, so it is written down rather than assumed:

• Not ours: producing the PDF. Headless Chrome, Gotenberg, wkhtmltopdf, a print server — that is infrastructure, it belongs to your stack, and a CSS framework that shipped one would be the virtualiser mistake again.
• Ours: what every one of those tools consumes — HTML and a print stylesheet. The document's shape, the page contract (@page margins, repeating table headers and totals, break control) and the black-and-white legibility rules are exactly this framework's job, and they already ship in the print layer.
• So this page documents the contract, not a generator: give your renderer this markup and these classes, and the output is a document. Zero new CSS was needed to build it — which is itself the evidence the contract was already complete.

The document

On paper this is one document, not a screenshot of a screen: the table header repeats on every page and so do the totals (<tfoot> is table-footer-group by browser default — measured, not assumed, which is why the framework adds no rule for it), the address blocks never split (.bo-u-avoid-break), and the print-only line appears only on paper.

Logo & barcode — any mark, any symbology

Both are supported the same way, and the split is the same as the PDF one: the framework does not generate either — barcode bitmaps come from a library (bwip-js, ZXing, a GS1 service) or a barcode font, and a logo is your asset. What decides whether the printed result actually works is placement, and that is entirely CSS:

<!-- Barcode: your renderer supplies the image; these classes and
     units are what make the printed result scan. -->
<figure class="bo-u-print-exact bo-u-avoid-break">
  <img src="/barcode/PO-88213.svg" alt="Barcode for document PO-88213"
       style="inline-size: 48mm; block-size: 14mm; padding: 3mm" />
  <figcaption>PO-88213</figcaption>   <!-- human-readable, always -->
</figure>

<!-- Logo: same utility, physical size, real alt text. -->
<img class="bo-u-print-exact" src="/brand/logo.svg"
     alt="Busy Office Supplies Ltd" style="inline-size: 26mm" />

This closes a loop the framework already had open on the other side: initScanInput() on the RF goods-receipt screen reads these barcodes off a handheld. The document that gets scanned in the warehouse is the one this pattern emits — emit and read are now both documented.

Page numbers & running headers — what browsers do, and what needs a renderer

Compared against the dedicated paged-media engines (Prince, WeasyPrint), which is what the CSS Paged Media and GCPM specs were written for. Two of their headline features matter for an ERP document, and they do not land the same way — measured here by printing a three-page table to PDF and reading the text back out, not by consulting a support table:

So page numbering is available to you today, in a plain browser, with no renderer and no JavaScript. It is not shipped as a framework default because @page is a document-global rule — it cannot be scoped to one route or one element, so shipping it would stamp page numbers on every print job in every consuming app, including screens where that is wrong. It belongs in the stylesheet of your document route:

/* your-document-route.css — paste as-is; verified in Chrome */
@page {
  margin: 1.6cm;                       /* the framework already sets this */
  @bottom-center {
    content: "Page " counter(page) " of " counter(pages);
    font-size: 9pt;
  }
  @bottom-right { content: "PO-88213"; }   /* the doc number on every page */
}

/* Server-renderer ONLY (Prince, WeasyPrint) — a running header that
   repeats the document title. Browsers ignore string-set entirely, so
   never rely on it for a document a user might print from the app. */
h1 { string-set: doctitle content(); }
@page { @top-center { content: string(doctitle); } }

The document above uses a plain .bo-u-print-only line carrying its number instead, because that works in both paths — the browser print dialog and the server renderer — and a loose page from a printed PO still identifies itself. Add the margin-box recipe on top when the document is rendered by a route you control.

Markup

<!-- The whole document is one .bo-print-report. No new classes:
     letterhead + parties + kv meta + lines + tfoot totals + terms. -->
<article class="bo-print-report">
  <header class="bo-u-avoid-break"> …sender / doc number / date… </header>

  <div class="bo-form-row bo-u-avoid-break"> …vendor / deliver-to… </div>

  <dl class="bo-kv bo-u-avoid-break"> …terms, incoterms, buyer… </dl>

  <div class="bo-data-table-container" tabindex="0">  <!-- screen: narrow
       viewports scroll the lines like a PDF; print ignores it -->
  <table class="bo-data-table" data-density="compact">
    <thead>…</thead>            <!-- repeats on every printed page -->
    <tbody>…lines…</tbody>
    <tfoot>…net / VAT / total…</tfoot>  <!-- repeats too, by default -->
  </table>
  </div>

  <footer class="bo-u-avoid-break">
    <p>Terms…</p>
    <p class="bo-u-print-only">Page totals continue overleaf · PO-88213</p>
  </footer>
</article>

Anatomy

1. Letterhead — who is sending, with the legal identifiers (VAT/company number) a document needs to be valid.
2. Document identity — type, number, issue date. The number is the thing every later conversation quotes. Not itself a monitoring signal — the human-monitoring surface for WHETHER documents were emitted lives on report and job monitor; this region is what makes an artefact self-evidencing once someone does open it.
3. Parties — vendor and ship-to as separate blocks, each .bo-u-avoid-break: an address split across a page boundary is a returned delivery.
4. Meta — key-value facts for terms, incoterms, dates, buyer.
5. Lines + totals — a data table with a real <tfoot>; both header and totals repeat per page because the print layer and the browser default already say so.
6. Terms & footer — the legal tail, plus .bo-u-print-only content that exists on paper only.

Data contract

The AI-manages / human-monitors split, stated: agents generate and dispatch these unattended, so the document itself carries every check a human later needs — the number, the issue date, the draft/copy marking, the totals. The monitoring surface for whether they were emitted is the report and the job monitor; this page's job is that each emitted artefact is self-evidencing.

States

Components used

complexity 2 of 4

• Data table
• Key-value facts
• Print utilities