A fabrication geometry core and six public tools, verified three ways

Problem

Every plate and sheet-metal shop redraws the same developments: a cone or frustum, the four panels of a hopper, an open profile with three bends, a flange bolt circle, a pipe saddle. Each is a few minutes of geometry and a few hours of consequence if it is wrong. Free calculators exist, but most hide their assumptions — which face the diameter was measured on, whether the K-factor is yours or theirs, how a cone is bump-formed — and none hand back a file a laser can cut.

The demonstration goal: prove that fabrication geometry can be written once, as tested software, with every assumption stated, and reused unchanged across six tools, a share image and a set of figures.

Constraints

• Geometry must be pure: no DOM, no framework, no file-format knowledge, runnable in plain Node, so the same maths can back a desktop add-in, a batch generator or an API.
• Everything runs in the visitor's browser. Dimensions never reach a server.
• DXF R12, the most universally readable flavour, written deterministically: fixed formatting, no timestamps, a generator-version tag in every file.
• Fixed layer convention across all tools: CUT, BEND, CENTER, CONSTRUCTION.
• Metric and imperial must produce identical millimetre geometry; the unit toggle converts values and never reinterprets them.
• Nothing that depends on shop tooling — springback, bend tables, seam design — is applied behind the user's back.

Engineering logic

One pipeline, one direction: input → validation → normalised millimetres → geometry engine → render geometry → SVG preview | DXF serializer. The preview and the exported file consume the same Drawing — a list of layered lines, arcs and circles with bounds — so they cannot disagree about what the part looks like.

Each tool is a short derivation with the identity that makes it correct written beside it. For a frustum with radii R₁ > R₂ and axial height H:

L  = √((R₁ − R₂)² + H²)          slant height
Ro = R₁ · L / (R₁ − R₂)          outer development radius
Ri = R₂ · L / (R₁ − R₂)          inner development radius   (Ro − Ri = L)
θ  = 2π (R₁ − R₂) / L            included angle             (θ · Ro = 2π R₁)

The identity θ · Ro = 2πR₁ — the developed arc equals the true circumference — is asserted directly in the tests. It is what separates a correct development from a plausible one. The cone tool also asks which face the diameters were measured on and offsets to the neutral layer by (t/2)·cos θ; the pipe tool solves the cylinder intersection analytically and then samples it to a stated maximum deviation (default 0.05 mm), which is why it is the only export described as approximate.

System

The core is a set of pure TypeScript modules; the six tools are small islands that bind inputs to it and drop the preview and the DXF into the page. Layering is strictly one-way — pages → scripts → lib → dxf | render → geometry — and a rule in the repository forbids the geometry layer from importing anything above it.

The same functions produce the share image for this site and every technical figure on it. A picture on a page here is never an illustration of the software; it is the software's output.

Validation

1. Hand-derived golden cases. Expected values are worked out on paper in the test comments, so the implementation cannot define its own expected answer. The 3-4-5 cone (600 mm diameter, 400 mm high) must give an outer radius of exactly 500 mm and an included angle of exactly 216°; an eight-hole bolt circle a pitch of exactly 45°.
2. Invariants. Developed arc equals true circumference; Ro − Ri equals the slant height; every hopper panel is exactly planar and its developed area equals its true 3D area, with every developed edge and diagonal equal to its 3D length; metric and imperial inputs produce identical millimetre geometry; a profile's flat length and leg lengths agree across the tangent, inside and outside flange datums over a grid of thicknesses, radii, angles and bend directions.
3. Independent read-back. Every golden DXF is parsed and audited by ezdxf — a Python library that had nothing to do with writing the files — for version, units, entity counts, layers, and the absence of zero-length or zero-radius entities. The full report is published: verify-dxf-2026-09-15.txt.
4. Renderer parity. Separate suites decode the SVG preview and the DXF for each tool and assert they carry the same geometry on the same layers.
5. Real CAD. A ten-file acceptance package — one or two files per tool family, with a manifest of expected dimensions read back out of the files by ezdxf rather than typed — was opened in Autodesk Inventor and AutoCAD on 2026-08-10 and checked for scale, units, layers, orientation, duplicated geometry and key dimensions.
6. Real browser. Playwright drives every tool in Chromium at 1440×900, 768×1024 and 390×844: change inputs, switch views, download a DXF, print a template — under the site's own content-security policy, with zero violations.

Verifying 37 DXF files with ezdxf 1.4.4

  PASS  cone-full-600-400-mm.dxf
        Full cone D1=600 H=400 (3-4-5), Ro=500, angle=216deg
          - parses cleanly (ezdxf audit: 0 errors)
          - DXF version AC1009 (R12)
          - $INSUNITS = 4
          - entities: 1 arc, 2 line, 0 circle
          - no zero-length / zero-radius / zero-sweep entities
          - layers: CUT
          - radii present: [500]

Regenerate everything: npx vitest run · npx vitest run tests/fixtures.test.ts && .verify-venv/bin/python scripts/verify-dxf.py · npx tsx scripts/build-cad-acceptance.ts.

Result

• 1,193 automated tests across 39 test files at the last release (the whole site repository, of which the geometry, DXF and parity suites are the larger part) (measured 2026-09-16).
• 37 DXF fixtures verified by ezdxf 1.4.4, zero audit errors.
• Ten-file acceptance package accepted in Autodesk Inventor and AutoCAD, 2026-08-10.
• Six tools live, on one core, with every assumption listed on the page that uses it.
• The same core reproduces the independent C# generator's published cone blanks to within its printed rounding — see the Fabrication Generator study.
• Defects caught by this discipline before anyone cut plate: an SVG arc drawn on the wrong circle while the DXF was right (caught by renderer parity); a unit toggle that reinterpreted numbers as 25.4× larger parts (caught by the round-trip test); a worked example on a page stating 91.85 mm where the file said 91.84.

What is not claimed: that a physical part has been made from any of these files. The tools are planning and fabrication aids; the shop verifies before cutting, and the disclaimer says so.