PROOF

You already printed it. That's when you find out.

PROOF is the print dialog, reinvented. Instead of a stamp-sized thumbnail and a leap of faith, it shows you every page of the job at readable size, measures how much ink each page actually costs from the document's real, rendered layout, and flags the sheets that are waste before you burn paper on them — then it prints what you meant, not what your last edit left behind.

Built for the Cursor Calgary hackathon (Aug 2026), whose brief was to take a boring, everyday application format and make it dramatically better — visually, functionally, or both. The print dialog hasn't meaningfully changed since 1995. This is what it looks like if someone finally touched it.

The problem, concretely

The print dialog most operating systems ship today gives you a preview pane roughly the size of a postage stamp. That is the entire visibility you're given into a document that might run to a dozen-plus pages. At that size you cannot tell that one page is a single orphaned "Terms and conditions apply." line left behind by a page break, that another is nothing but a "— continued —" marker that overflowed onto its own sheet, or that a third says "This page intentionally left blank" in eleven-point serif type. You click Print. Every page comes out. Several of them are furniture, not content — and you paid for the paper and the toner on all of them before you ever saw it happen.

That's the failure mode PROOF exists to close: the dialog you already trust doesn't show you enough to make the decision it's asking you to make.

PROOF ships with a realistic demo document — a 20-odd-paragraph quarterly business report, "Q3_Operating_Review_FINAL_v4.docx," with a table of contents, an executive summary, a real financial table, a supply-chain section, headcount figures, and an outlook section, plus five deliberately inserted junk pages of exactly the kind real documents accumulate: an orphaned "Terms and conditions" footer, a "— continued —" break artefact, a stray copyright line, an "intentionally left blank" notice, and a lone page number. Loaded and paginated for real, this document runs to 15 pages, and PROOF's own live measurement — not a hand-typed figure — flags 5 of them as waste, printing 10. Open proof/index.html yourself and the rail shows the exact same numbers, because they're computed fresh every time the page loads, not memorized here.

Related MCP server: MCP Mortgage Server

How the numbers are actually produced

This is the part worth being precise about, because it's also the part that makes the whole idea work: every figure PROOF shows you is computed from the document as loaded, not typed in by hand or dressed up to look plausible — and this holds for the bundled demo document and for any file you drop onto it (see below).

1. Pagination is measured, not assumed. The document's HTML is laid out in a real, hidden DOM element at real content width, and PROOF walks its block-level children (headings, paragraphs, tables, blockquotes) accumulating each one's actual rendered height (getBoundingClientRect()), breaking to a new page whenever the next block would overflow a 816×1056px page box — 8.5"×11" letter paper at 96dpi, with roughly 1in margins. An explicit page-break marker in the source forces a break early. The page count is therefore an output of layout, not a number anyone chose.

2. Ink coverage is measured from real text geometry. For each finished page, PROOF walks every text node and asks the browser's own layout engine for the exact rectangles its glyphs occupy (Range.getClientRects()) — not a pixel-by-pixel canvas scan, but the same idea applied to real geometry the browser already computed. Each rectangle's area is weighted by a stated glyph-density constant (GLYPH_DENSITY = 0.16, i.e. roughly 16% of a line box is actual ink for normal text, rising with font weight), and table/blockquote border strokes are added on top since they carry ink too. The total, divided by the page's content area, is the page's ink coverage percentage.

3. A canvas-rasterization path exists too, but isn't the headline number. PROOF also ships a second, independent method (inkOf()): serialize the page to an SVG, rasterise it to an offscreen canvas, and count non-white pixels weighted by luminance-darkness. The code keeps this explicitly labeled "a second opinion, not used for the headline number" — worth knowing if you read the source, since it's the more intuitive of the two methods but isn't the one driving what's on screen.

4. Low ink alone is not waste. Below 2.0% ink coverage (WASTE_THRESHOLD) is necessary but not sufficient. A page is only flagged when it's also either a recognized piece of pagination furniture (an "intentionally left blank" notice, a "— continued —" marker, a copyright line, a lone page number) or has no structural element at all (h1,h2,h3,table,ul,ol,svg,img,blockquote) and under 120 characters of text. This is what keeps a title page or a table of contents from being wrongly flagged just for being sparse — in the bundled demo, the title page measures 2.06% ink and the table of contents measures 1.0%, both technically thin, and both print anyway because each one has a heading.

5. The reason, not just the flag. A flagged page's actual text is pattern-matched against the kinds of furniture real documents accumulate — "intentionally left blank" notices, "— continued —" markers, copyright lines, lone page numbers, or a short trailing line with no clear category — so the reason shown for each waste page is derived from what that page actually says, not a caption written for a specific demo.

Said plainly, because it matters for trust: if the layout-based measurement can't run for some reason, PROOF does not silently show you nothing or quietly make something up — it falls back to a disclosed, deterministic estimate (estimateInk(): a stated formula over character count, heading count, and table-cell count) documented in the code as exactly that, an estimate, not a measurement. The UI's status line tells you which one produced the numbers you're looking at — it reads either measured · N glyph runs across N pages or estimated · layout measurement unavailable, so you are never looking at a guess that was presented as a measurement. The per-sheet detail panel's own "method" readout agrees with it, reading measured · glyph-run geometry or estimated · block model for that specific sheet.

Everything downstream — which pages are flagged, the sheets-saved count, the mean ink percentage, the per-page reason shown when you open a sheet, and the cost figure — is derived from this pipeline running against whatever document is currently loaded. Nothing on screen is a hard-coded result dressed up as a computation.

What you actually see

• The verdict, first. Pages in, pages out, with the dropped-sheet count and the mean ink percentage stated as a headline stat in the rail — not buried in a settings panel.

• The sheet wall. Every page of the job as a live thumbnail — the actual rendered page, scaled down with CSS transform: scale(), not a placeholder graphic or a miniature redrawn from scratch — with waste pages visibly stamped and a per-page ink gauge.

• The nested reveal. Click any sheet and it opens into its own explanation: how it was classified, its measured ink coverage against the 2.0% threshold, and — for a flagged page — which specific kind of furniture it is and why dropping it changes nothing you meant to print. This is the design's spine: document → pages → one flagged sheet → the reason, each level revealing the next. From that same panel you can restore or drop that one sheet individually.

• Proof another file, for real. The rail has a genuine drop zone: drag in your own .html, .txt, or .md file (or click to pick one) and PROOF paginates and measures that document with the exact same pipeline described above — this isn't a second demo mode, it's the same load() function the bundled document runs through.

• A real Print button. "Print" calls the browser's real window.print() against a hidden print root that mirrors the on-screen job; dropped/waste pages carry display:none under @media print, so the sheets you decided not to print genuinely don't print. There's also an explicit "Print everything anyway" escape hatch, and print CSS hides the app chrome so only the document itself goes to the printer.

• Before / after. The 1995 dialog is rendered honestly on the presentation deck (proof/deck.html), side by side with what PROOF shows instead, so the contrast is stated explicitly rather than only implied.

Platforms

Desktop and mobile are both designed as first-class layouts, not one scaled down from the other — the sheet wall, the hero stat row, and the nested detail view all have dedicated breakpoints down to phone width.

The MCP server — proofing a document without a human in the loop

The web page is one surface on PROOF. Underneath, PROOF is meant to be usable by an AI agent directly: an MCP server exposes the same document model the web UI uses, so a coding agent, a document pipeline, or Claude itself can proof a job before a single sheet moves — no screenshot, no human reading a preview pane.

The server lives in proof/mcp/ and mirrors the exact same 15-page document the web app measures — same filename (Q3_Operating_Review_FINAL_v4.docx), same 5 waste pages (4, 6, 9, 11, 13) with the same reasons, and the same cost constants (cost_per_sheet_usd: 0.012, cost_per_ink_point_usd: 0.0009) index.html itself uses, so a call to ink_cost quotes the same money the UI shows on screen (mean ink 2.97% and $0.0603 saved here, "2.9%" and "$0.06" rounded in the UI). One thing stated plainly rather than hidden: the ink percentages in the server's document.js are captured values mirrored from a real browser measurement, not recomputed by the server itself — there's no portable Node equivalent of index.html's Range.getClientRects() glyph-geometry method, since that API only exists in a real layout engine, so the server discloses its numbers as "method": "measured_in_browser_layout" rather than pretending to re-derive them independently. Wiring the server to measure an arbitrary document handed to it — the same way the web UI's drop zone already does — is the natural next step.

The four tools it exposes, verified against a live smoke-test run (node proof/mcp/smoke_test.mjs):

To connect it to Claude Desktop, Claude Code, or any MCP-compatible client, point the client at the server directory:

cd proof/mcp
npm install

Then add it as an MCP server (stdio transport) in your client's config, e.g. for Claude Desktop's claude_desktop_config.json:

{
  "mcpServers": {
    "proof": {
      "command": "node",
      "args": ["/absolute/path/to/proof/mcp/server.js"]
    }
  }
}

There is no network hop and nothing to deploy: the server is a local stdio process, exactly like any other MCP server you'd run for local tools. This was a deliberate constraint on the whole project — see "No backend," below — extended to the agent layer: agentic capability without a hosting dependency that can fail during a demo.

To verify the server actually works end to end without wiring up a full client, run the included smoke test — it spawns server.js as a real child process over stdio, performs the MCP handshake, lists all four tools, and calls each one:

cd proof/mcp
node smoke_test.mjs

Fuller connection instructions (including a Cursor-specific config) live in proof/mcp/README.md.

How to run it

The product is static HTML/CSS/JS. There is no build step, no bundler, and no server.

open proof/index.html

or just double-click proof/index.html in Finder/Explorer. That's the entire installation procedure — no npm install, no dev server, no dependency on this repo's node_modules at all, and no external fonts, CDN scripts, or network images.

The page pairs with proof/sample-document.js, which supplies the full 15-page demo report (window.SAMPLE_DOC) — keep the two files together in proof/ and it loads automatically via a plain <script src> tag. If that file is ever missing, index.html doesn't break: it falls back to a smaller, self-contained demo document (FALLBACK) built into the page itself, so the app never shows a blank screen, just a shorter document. Either way, ink measurement works identically whether you open the file directly (file://) or serve it, because nothing in the pipeline depends on cross-origin network access.

If you'd rather serve it over HTTP for any reason (some browser extensions or stricter local security policies can interfere with file:// pages), any static file server works, e.g.:

npx serve proof

Screenshots and the capture harness

The _brainstorming/ directory holds this project's working notes, including capture.mjs, a small Playwright script used to take frame-exact screenshots of the page at specific scroll positions and viewport sizes (desktop and phone) for the hackathon submission. It requires the playwright devDependency declared in this repo's root package.json:

npm install
node _brainstorming/capture.mjs proof/index.html --out shots

This is a development tool, not part of the product — PROOF itself needs none of it to run.

No backend, on purpose

PROOF has no server, no database, and no deploy step for the product itself. Its bundled demo "data" is a hand-built, realistic quarterly report shipped as static content (sample-document.js, with a smaller built-in fallback if that file is absent) so that every number computed from it — page count, ink coverage, waste flags, cost — is real arithmetic over real content the moment the page loads, not a fetch to a backend that could be down, slow, or absent during a demo. It also genuinely accepts a file you drop on it, run through the identical pipeline. The MCP server is the one process that runs outside the browser, and it's a local stdio process rather than a hosted one, so it carries none of a web backend's deploy risk.

Why the print dialog

Roughly a dozen other "boring format" candidates were considered and rejected during design, for several distinct, individually stated reasons: a subscription manager, a package tracker, and a utility bill were dropped because reinventing them honestly would mean inventing data with no legitimate source (a bank balance, a carrier's real tracking state, a meter reading); a cancellation flow and a CAPTCHA were dropped for adding no real information; a browser-tab manager and an airline seat map were dropped as already well-served by existing products (OneTab/Arc, SeatGuru); a cookie banner was too small a canvas for the intended layered, scroll-driven reveal; and an earlier prescription-dosing concept was cut for failing an instant-comprehension test. The print dialog is the one candidate that cleared all of these bars at once: instantly recognizable, adds real information the current dialog hides, and every dramatic number on screen — pages, blank-page detection, ink coverage — is something a browser can actually compute from a real document, live, with nothing faked. The full decision record, including the rejected candidates and the reasoning at each step, is in _brainstorming/SPEC.md.

Repository layout

proof/
  index.html          the product — open this
  sample-document.js   the 15-page demo report loaded into the product
  deck.html            a short, seven-slide product presentation, same art direction
  docs.html             the full feature-by-feature reference, verified against live output
  mcp/
    server.js           the MCP server entrypoint (stdio transport)
    document.js          MCP server's document model — mirrors index.html's live document
    smoke_test.mjs        end-to-end check: spawns the server, calls all four tools
    package.json          MCP server package (@modelcontextprotocol/sdk, zod)
    README.md             MCP-specific install/connect instructions
_brainstorming/
  SPEC.md             the full design/decision record for this project
  capture.mjs          Playwright screenshot harness used for the submission
  ...                  earlier design drafts and research notes, kept for the record
shots/                desktop + mobile submission screenshots of proof/index.html
shots-deck/           submission screenshots of proof/deck.html

proof/deck.html is a short, standalone product-presentation page — open it the same way as index.html — walking through why the print dialog is broken, how PROOF measures ink coverage (measured vs. rasterised), and the classifier's kept-despite-low-ink logic, in seven slides in the same visual language as the product itself. proof/docs.html is the deeper, scrollable reference: every feature — including the MCP server — documented against the current code with real, live-verified numbers.

Built for the Cursor Calgary hackathon, August 2026.