Takeoff Estimating

The bug this exists to prevent

Estimating software fails quietly, in arithmetic, and the output always looks like a bid.

A token that writes as text. The estimator's workbook has {{qty:Slab}} in a cell inside a SUM range. Write "1240" instead of 1240 and the cell displays correctly, the sheet opens fine, and the SUM ignores it. The bid is short by one line item and nothing anywhere is red. Whitespace-padded tokens are the common cause, and there is a test named for exactly that: a padded numeric token must still write a typed number.

Overhead and profit applied in the wrong order. Profit on cost, then overhead on the result, is a different number from overhead on cost and profit on the sum. Both are defensible in conversation; only one matches what the estimator intends. One function owns that formula here rather than the rule living in three places that drift.

An uncalibrated drawing. Dividing by a scale nobody set gives Infinity or NaN, which propagates into a total and renders as a blank or a nonsense figure. Every quantity path returns 0 on an uncalibrated or negative scale — a zero is obviously wrong to a human; NaN in one cell of forty is not.

The geometry is where the silent errors live

• Shoelace area is winding-order independent — a polygon drawn clockwise must not measure
• negative and cancel another region out of the total.
• Deducts are signed on purpose. A cut-out measures negative so it subtracts. That is the
• intended behaviour and the reason winding-order independence has to be handled deliberately
• rather than by taking an absolute value everywhere.
• Area scales by the square of the calibration, linear scales linearly, counts ignore scale
• entirely. Getting the exponent wrong is off by a factor of the scale — large, consistent, and
• invisible if every room is wrong together.
• Arcs use the bulge convention (tan θ/4), tested against a semicircle: bulge 1 on a 100px
• chord is exactly 50π.
• Degenerate inputs return 0 rather than throwing: fewer than three points, a single point, a
• zero-length segment.

Filling the estimator's own workbook

People reject estimating tools because they already have a macro workbook that took years to build. This fills theirs: tokens go in cells once, values are written back typed.

• Whole-cell tokens write typed numbers; embedded tokens substitute into surrounding text as
• strings.
• Tokens inside formula cells are skipped and reported — writing a value there would be
• discarded on the next recalculation, so a silent write is a value the estimator thinks they
• have and does not.
• Unmatched tokens are reported, trimmed, rather than left in the sheet as {{qty:Slab}} for
• someone to find in a PDF sent to a client.
• Name collisions resolve deliberately: when an alternate reuses a base line's name, both
• {{qty:X}} and {{cost:X}} resolve to the base line.

Exporting an annotated PDF

annotExport writes measurements back into the ORIGINAL plan bytes as standard ISO 32000 markup annotations — PolyLine with /IT PolyLineDimension for linear, Polygon for area.

That standard matters more than it sounds. A "marked-up PDF" produced by flattening shapes onto the page is an image of a measurement: the recipient cannot select it, edit it, or see what it measured. Real annotations survive into Bluebeam, Acrobat and every other reviewer, and the original page content is untouched underneath.

What this does NOT do

No PDF rendering, no drawing UI, no scale detection, no symbol recognition — see ink-bounded-floodfill and template-symbol-match for those. It takes measurements you already have.

No pricing database, no labour rates, no regional adjustment. You supply rates; this applies them consistently.

Verified

96 tests: shoelace area including non-convex and winding order, polyline length, arc bulge against an exact semicircle, quantity scaling by dimension, uncalibrated and negative scale guards, signed deducts, the overhead-then-profit formula, typed numeric writes including whitespace-padded tokens, formula-cell skipping with a report, unmatched-token reporting, base-versus-alternate name collisions, and annotation export against the original bytes.

Not covered: no test opens a real estimator's workbook, so exotic sheet features — merged cells, array formulas, protected ranges — are unexercised.

Note: this shares geometry.ts and types.ts with ink-bounded-floodfill. They are separate products for separate jobs, so the two files are vendored into both rather than creating a dependency between listings.