I used to check this by opening the PDF and scrolling through it. With alot of forms across several kits that stopped working, so now the build script checks every page and fails if anything doesn't fit. It's plain HTML and CSS, Chrome in headless mode, and about 40 lines of Python.

1. One fixed-height div per page

Each form is a .page div with a fixed height. US Letter is 11in tall, minus 0.5in margins top and bottom, so 10in:

@page { size: letter; margin: 0.5in; }
* { box-sizing: border-box; }
html, body { margin: 0; padding: 0; }
body { font: 10pt/1.3 Arial, sans-serif; }
.page { height: 10in; overflow: hidden; break-after: page; }
.page:last-child { break-after: auto; }

overflow: hidden keeps a long page from pushing everything after it onto the wrong sheet. That's good for the PDF and bad for testing, because now nothing looks broken. The content just gets cut off at the bottom. Counting pages in the PDF won't catch it either. I had a test form with 60 line items and the PDF still came out at exactly 2 pages, with half the table missing.

2. Measure the overflow in the browser

The fix is to ask the browser how much content is hiding. For an element with overflow: hidden, scrollHeight - clientHeight is the number of pixels that didn't fit. 0 means it fits.

So the build writes a second copy of the HTML just for measuring. It adds this script, which writes the numbers into the page itself:

<script>
window.addEventListener('load', () => {
  const r = [];
  document.querySelectorAll('.page').forEach(p => {
    r.push(p.dataset.key + ':' + (p.scrollHeight - p.clientHeight));
  });
  const pre = document.createElement('pre');
  pre.id = 'ov';
  pre.textContent = 'OVERFLOW ' + r.join(' ');
  document.body.appendChild(pre);
});
</script>

Then Chrome's --dump-dom flag prints the DOM after scripts run, and Python reads the numbers back out. No Puppeteer, no Node, just the Chrome binary.

One catch. --dump-dom lays the page out on screen, not on paper, so the .page divs would be as wide as the default window. Text wraps differently at a different width and the heights come out wrong. The probe copy pins the width to the printable width (8.5in minus two 0.5in margins):

@media screen { .page { width: 7.5in } }

3. The build script

import os, re, subprocess, sys

CHROME = ["google-chrome", "--headless=new", "--no-sandbox", "--disable-gpu"]
CSS = open("page.css").read()
PROBE = open("probe.html").read()  # the <script> from step 2

def write(path, body, extra_css="", script=""):
    with open(path, "w") as f:
        f.write(f"<!doctype html><html><head><meta charset=utf-8>"
                f"<style>{CSS}{extra_css}</style></head><body>{body}{script}</body></html>")

def url(path):
    return "file://" + os.path.abspath(path)

def check_and_print(body, name):
    # 1. measure: same HTML, screen width pinned to the printable width
    write(f"{name}-probe.html", body, "@media screen { .page { width: 7.5in } }", PROBE)
    dom = subprocess.run(CHROME + ["--virtual-time-budget=3000", "--dump-dom", url(f"{name}-probe.html")],
                         capture_output=True, text=True).stdout
    m = re.search(r'<pre id="ov">OVERFLOW ([^<]*)', dom)
    res = dict(x.split(":") for x in m.group(1).split()) if m else {}
    over = {k: int(v) for k, v in res.items() if int(v) > 0}

    # 2. print the real PDF
    write(f"{name}.html", body)
    subprocess.run(CHROME + ["--no-pdf-header-footer", f"--print-to-pdf={name}.pdf", url(f"{name}.html")],
                   check=True, capture_output=True)
    return res, over

body = open("invoice-body.html").read()  # <div class="page" data-key="invoice">...</div> etc.
res, over = check_and_print(body, "invoice")
print("overflow px per page:", res)
if over:
    print("OVERFLOW:", over)
    sys.exit(1)

With 10 line items it prints {'invoice': '0', 'terms': '0'} and exits 0. With 60 it prints OVERFLOW: {'invoice': 391} and exits 1, so the build stops before a broken PDF goes anywhere.

Things that bit me

• --virtual-time-budget matters. Without it Chrome can dump the DOM before web fonts finish loading. Then you measure with the fallback font, and the real font is a little wider and pushes text down a line.
• --no-pdf-header-footer turns off the date, title and file path Chrome otherwise prints in the margins. Older Chrome versions called it --print-to-pdf-no-header.
• Add -webkit-print-color-adjust: exact; print-color-adjust: exact; to body if you have colored header bars or table headers. Otherwise Chrome may drop the backgrounds when printing.
• Use break-inside: avoid on blocks that shouldn't split, like a totals table. On a fixed-height page it mostly matters for multi-column checklists.
• Check m before trusting the result. If the probe never ran (a script error, a bad path), the script above gets an empty dict and reports nothing. Failing when a page key is missing from res is an easy fix.

The same one-page layout is behind my free invoice templates for contractors, if you want to see how it comes out printed. My site, no signup.

Here's how the pieces work.

1. The link itself

Google has a URL that opens the "write a review" box for a business directly:

https://search.google.com/local/writereview?placeid=<PLACE_ID>

That's the whole trick. The hard part is getting a clean Place ID out of whatever people paste. Contractors don't know what a Place ID is untill you show them, so they paste all sorts of things: the bare ID, a Maps URL with query_place_id= in it, the g.page/r/.../review link from their Business Profile, or the ID with "Place ID:" still stuck on the front.

So the parser accepts all of those:

var WR = 'https://search.google.com/local/writereview?placeid=';

function parse(raw) {
  var s = String(raw || '').trim().replace(/^[\s"'<(]+|[\s"'>)]+$/g, '');
  if (!s) return { ok: false, empty: true };
  var d = s; try { d = decodeURIComponent(s); } catch (e) {}

  // Business Profile short link: already a review link, use as-is
  var m = d.match(/^(?:https?:\/\/)?(?:www\.)?g\.page\/r\/([A-Za-z0-9_-]+)(?:\/review)?\/?(?:[?#].*)?$/i);
  if (m) return { ok: true, kind: 'gpage', link: 'https://g.page/r/' + m[1] + '/review' };

  var id;
  m = d.match(/(?:query_place_id|place_id|placeid)\s*[=:]\s*([A-Za-z0-9_-]+)/i);
  if (m) id = m[1];
  else if (/^(?:https?:\/\/|www\.)|^[a-z0-9-]+(?:\.[a-z0-9-]+)+\//i.test(d)) return { ok: false, msg: 'nolink' };
  else {
    d = d.replace(/^place\s*id\s*[:=]?\s*/i, '');
    if (/\s/.test(d)) {
      var t = d.match(/[A-Za-z0-9_-]{20,}/g);
      if (t && t.length === 1) id = t[0]; else return { ok: false, msg: 'chars' };
    } else id = d;
  }
  if (!/^[A-Za-z0-9_-]+$/.test(id)) return { ok: false, msg: 'chars' };
  if (id.length < 20) return { ok: false, msg: 'short' };
  return { ok: true, kind: 'id', id: id, odd: !/^ChIJ/.test(id), link: WR + id };
}

A few things I learned writing this:

• Run decodeURIComponent before matching. Links copied out of some apps come URL-encoded and the = turns into %3D.
• If it's a URL with no Place ID in it, say so. Don't try to guess. A plain Maps share link doesn't carry the ID and guessing gives you a link to the wrong business.
• Most business Place IDs start with ChIJ. I don't reject ones that don't, I just show a warning telling them to test the link first.
• Every error message tells them what to paste instead. "Invalid input" helps nobody.

2. The QR code as an SVG path

For the QR math I use Kazuhiko Arase's qrcode-generator (MIT, one file, no dependencies). I only use it to get the grid of dark and light modules, then draw it myself:

function qrMatrix(text) {
  var q = qrcode(0, 'M');      // 0 = pick the smallest version that fits, M = ~15% error correction
  q.addData(text, 'Byte');
  q.make();
  var n = q.getModuleCount(), rows = [];
  for (var r = 0; r < n; r++) {
    var row = [];
    for (var c = 0; c < n; c++) row.push(q.isDark(r, c));
    rows.push(row);
  }
  return rows;
}

The SVG is one <path> with a 1x1 square per dark module, plus a 4-module white border (the QR spec asks for that blank margin and some readers fail without it):

function qrSVG(text) {
  var M = qrMatrix(text), n = M.length, pad = 4, W = n + pad * 2, d = '';
  for (var r = 0; r < n; r++)
    for (var c = 0; c < n; c++)
      if (M[r][c]) d += 'M' + (c + pad) + ',' + (r + pad) + 'h1v1h-1z';
  return '<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 ' + W + ' ' + W + '"' +
    ' shape-rendering="crispEdges"><rect width="' + W + '" height="' + W + '" fill="#fff"/>' +
    '<path d="' + d + '" fill="#000"/></svg>';
}

Two details matter here. The viewBox is in module units, so the code scales to any size with no math. And shape-rendering="crispEdges" stops the browser from anti-aliasing the edges between squares. Without it you can get faint lines between modules, which look bad on a print.

The SVG download is just that string in a Blob. SVG is the one to use for truck magnets and yard signs because it stays sharp at any size.

3. PNG from a canvas

Print shops and text messages want a PNG, so the same matrix gets drawn to a canvas at roughly 1200px wide, with whole-pixel modules so nothing gets blurry:

var s = Math.max(8, Math.floor(1200 / (n + pad * 2)));  // pixels per module
var W = (n + pad * 2) * s;
cv.width = W; cv.height = W;
x.fillStyle = '#fff'; x.fillRect(0, 0, W, W);
x.fillStyle = '#000';
for (var r = 0; r < n; r++)
  for (var c = 0; c < n; c++)
    if (M[r][c]) x.fillRect((c + pad) * s, (r + pad) * s, s, s);
cv.toBlob(function (b) { download(b, 'google-review-qr.png'); }, 'image/png');

download() is the usual object URL plus a temporary <a download>. Revoke the URL a few seconds later, not right away, or some browsers cancel the download.

4. Printable counter cards with print CSS

The card is regular HTML (business name, the QR SVG, one line of text). When they hit Print, I copy 1 or 4 cards into a #print-sheet div and call window.print(). The print stylesheet hides everything else:

@media print {
  @page { margin: .4in }
  body > *:not(#print-sheet) { display: none !important }
  #print-sheet { display: block !important }
  #print-sheet .rcard { break-inside: avoid; page-break-inside: avoid }
  #print-sheet.one .rc-qr svg { width: 3.1in }
  #print-sheet.four { display: grid !important; grid-template-columns: 1fr 1fr; gap: .25in }
  #print-sheet.four .rc-qr svg { width: 2.25in }
}

Sizing the QR in inches is the reason this works on paper. A 2.25in code scans fine from a counter. Anything under about 1in gets iffy on older phones.

5. Remembering things with localStorage

The Place ID, business name and card text get saved to localStorage on every input, so if they come back next week it's all still filled in. Nothing gets sent anywhere. Wrap the calls in try/catch because Safari private mode and some locked-down browsers throw on setItem:

function put(k, v) { try { localStorage.setItem(k, v); } catch (e) {} }

What I'd tell anyone building something like this

Test the generated link on a real phone before printing anything. The link format has worked the whole time I've used it, but Google owns that URL and could change it.

If you want to try it, the tool is free at copypastepaid.com/review-link-generator. No signup. View source works if you want the full thing.

Four decisions made it work. Here they are with the code.

1. Do all money math in integer cents

Say a contractor bills 1.5 hours of labor at $19.95. The right line total is $29.925, which rounds to $29.93. In JavaScript:

1.5 * 19.95 * 100              // 2992.4999999999995
Math.round(1.5 * 19.95 * 100)  // 2992  -> $29.92, one cent short

One cent sounds like nothing. Then the customer adds up the lines on a calculator and gets a different total than your invoice. So every amount gets turned into an integer number of cents as soon as it's read, and it stays that way until it's printed.

The fix for the rounding error itself is to trim the float noise before rounding. toPrecision(12) keeps 12 significant digits, which drops the trailing ...4999999 and keeps any real fraction:

function rc(x) { return Math.round(Number(x.toPrecision(12))); }

rc(1.5 * 19.95 * 100)   // 2993 -> $29.93
rc(0.5 * 64.35 * 100)   // 3218 (Math.round alone gives 3217)

Line totals, discounts, tax and deposits all go through rc():

function lineCents(item) {
  const price = toNumber(item.price);
  if (price === null) return 0;
  const qty = toNumber(item.qty) ?? 1;   // blank qty = flat-price line, like a trip charge
  return rc(qty * price * 100);
}

function totals(items, taxRate, discountPct, paid) {
  const sub = items.reduce((s, it) => s + lineCents(it), 0);
  const disc = rc(sub * Math.min(discountPct, 100) / 100);
  const after = sub - disc;
  const tax = after > 0 ? rc(after * taxRate / 100) : 0;
  const total = after + tax;
  const paidC = Math.min(rc(paid * 100), Math.max(total, 0));
  return { sub, disc, tax, total, balance: total - paidC };
}

Formatting only happens at the very end, with integer division, so a float never reaches the screen:

function money(c) {
  const neg = c < 0; c = Math.abs(c);
  const dollars = Math.floor(c / 100), cents = c % 100;
  return (neg ? '-' : '') + '$' +
    String(dollars).replace(/\B(?=(\d{3})+(?!\d))/g, ',') +
    '.' + String(cents).padStart(2, '0');
}

Tax gets figured once on the discounted subtotal, never per line. If you round tax per line and add it up you can end up a cent or two off the rounded total, and customers notice that.

To test it I recompute every sample invoice's total from its line items, separately, and compare it to what the page shows.

2. localStorage as the database, with keys shared across tools

The site has a few tools: an estimate maker, an invoice maker, a change order maker and a payment reminder maker. A contractor should only have to type their business name, phone and license number once.

So there are two kinds of keys:

• Shared keys for the business: cpp-business, cpp-phone, cpp-license, and so on. Every tool reads them on load and writes them on change.
• One key per document: cpp-estimate-v1, cpp-invoice-v1, cpp-change-order-v1. Each one holds that tool's whole state as JSON.

Wrap storage access. Safari private mode and some locked-down browsers throw:

function get(k) { try { return localStorage.getItem(k); } catch (e) { return null; } }
function put(k, v) { try { localStorage.setItem(k, v); return true; } catch (e) { return false; } }

Since every tool can read the other tools' keys, hand-offs are easy. The invoice maker has a "Start from my last estimate" button that reads cpp-estimate-v1 and copies over the customer, line items, discount, tax and deposit. The payment reminder maker has "Start from my last invoice". No sync code and no API.

Invoice numbers work the same way. cpp-inv-last holds the last number printed, and the next invoice suggests that number plus one, keeping the prefix and zero padding:

function bump(s) {
  const m = /^(.*?)(\d+)(\D*)$/.exec(String(s || '').trim());
  if (!m) return '';
  let n = String(Number(m[2]) + 1);
  while (n.length < m[2].length) n = '0' + n;
  return m[1] + n + m[3];
}
bump('INV-1001')  // 'INV-1002'
bump('2026-009')  // '2026-010'

Version the document keys (-v1). When the shape changes you can read the old key, migrate it and write a new one, and nobody loses a saved invoice.

One thing I got wrong at first. The trade pages (plumbing, HVAC, electrical and so on) open with a sample job filled in. If a sample saved its customer name and job title into the shared keys, every other tool would greet the visitor with a made-up customer. Now a page that's still showing its untouched sample skips the hand-off writes, and the first real edit clears the sample flag.

3. Print CSS instead of a PDF library

The "Save as PDF" button just calls window.print(). Every desktop and phone browser already has "Save as PDF" in the print dialog, so there's nothing to bundle.

The print stylesheet hides everything except the invoice and sets the page size:

@media print {
  @page { size: letter; margin: .5in; }
  body { background: #fff; }
  body > *:not(main) { display: none !important; }
  main > *:not(#inv-wrap) { display: none !important; }
  #inv-wrap > *:not(.est-docwrap) { display: none !important; }
  main.wrap { max-width: none; padding: 0; margin: 0; }
  .est-docwrap { overflow: visible; }
}

Two things to check:

• Make sure a full invoice fits on one page. I print each sample to PDF in headless Chrome and count pages in the test suite.
• overflow-x: auto on a wrapper is handy on a phone screen but it clips the document when printing. Reset it to visible in print.

There's also a "Download as HTML file" button. It builds a standalone HTML document with the invoice markup and its CSS inlined, so a contractor can email or archive the exact invoice without any app:

const doc = '<!doctype html><html lang="en"><head><meta charset="utf-8">' +
  '<title>' + esc(title) + '</title><style>' + DOC_CSS + '</style></head>' +
  '<body><div id="inv-doc">' + invoiceHTML() + '</div></body></html>';
const a = document.createElement('a');
a.href = URL.createObjectURL(new Blob([doc], { type: 'text/html' }));
a.download = 'invoice-' + slug(number) + '.html';
a.click();

4. Logos stay local too

Contractors want their logo on the invoice. Uploading it would mean a server. So the file input reads the image, scales it down on a canvas (600 x 240 max) and stores the data URL in localStorage. Shrink it first. localStorage is usually capped around 5 MB per origin and a phone photo can be bigger than that.

What this buys you

• No hosting cost beyond static files. The whole site is static HTML on Netlify.
• No privacy headaches about customer data, because none of it leaves the browser.
• Once the page has loaded it works on a phone in a truck with a bad signal.

The downside is the data lives in one browser. If someone clears site data their saved invoice is gone. The page says so, and the HTML download is the backup. Honestly that's a trade I'm realy fine with for a free tool.

If you want to see it working, the invoice maker is free with no signup, and there are versions with a sample job filled in for six trades at /invoice-templates/. View source is the documentation.

I'd like to hear how other people handle money rounding in front-end tools, especially sales tax rounding rules that differ by state.