14f. What our DXF reader actually sees — and what it silently does not

kerfmaster pin list · Preflight — how files come in

rulingmixeddeferred d14A decision by Aristide or Jordan. True because it was decided; it can be superseded, but it cannot be stale.

Content last changed 2026-08-14 — computed from the item itself, not typed.

Contract — Intake stage

This contract states a decision, not an implementation.

takes customer-file

makes raw-geometry

fails if An entity type dropped without a word to anyone.

Contract last changed 2026-08-06 — computed, not typed. Dated separately from the text above, so neither date can speak for the other.

⚠ Known defects

This item's subject has a known defect in the code. Source: cadmaster/defects.json → cadmaster/KNOWN_DEFECTS.md, not this page — the text below is generated from the register so the two can never disagree.

D14 — The DXF parser reads BLOCK-definition geometry at block-local coordinates, ignores the INSERT that places it, and reports nothing skipped (DEFERRED)
dxf_io.parse walks the whole group-code stream and dispatches on six entity types -- POLYLINE, LWPOLYLINE, LINE, ARC, CIRCLE, SPLINE (dxf_io.py:113-244). It does not track SECTION, so a LINE sitting in the BLOCKS section is picked up exactly as if it were in ENTITIES, at its block-local coordinates. The INSERT that positions, scales and rotates that block is not an entity it knows, so it falls through the loop's trailing `i += 1` and is discarded. Every other entity type does the same: ELLIPSE, HATCH, SOLID, TEXT, MTEXT, DIMENSION, LEADER, 3DFACE, POINT, ATTRIB. There is no count of what was skipped and no warning.
Cost today: None measurable on any file cut so far -- every DXF we hold uses LWPOLYLINE only. The exposure is entirely on files we have not yet been given, which is precisely what the input survey exists to find out.
Verified: 2026-08-04. Probe written and run (cadmaster/probe_entities.py). CONTROL: the novi customer file parses unchanged at 91 polylines / 0 lines / 0 arcs / 0 circles / 0 splines, so this is a gap in coverage, not a regression. Entity list read off the code's own branches, not assumed. NOT YET RAISED WITH ARISTIDE OR JORDAN, and no fix attempted -- the phase rule says define first, and the first question is which of these entity types actually arrive from their customers, which only they can answer. DEFERRED by Jordan 2026-08-04, in his words: "Write it down as out of scope for now, but let's revisit this as part of our beta testing once the interface has been written." So this is closed to work and open on the record -- nobody should now go and fix it, and it must not be re-raised from the numbers. The revisit trigger is beta testing with real customer files arriving through an interface, which is also the only way to learn which of these entity types actually turn up. Written up for a reader on pin 14f, including a plainer explanation of the block/INSERT example, which Jordan reported was not clear the first time.

The input survey's first question is the one CLAUDE.md puts squarely in phase: what we can read, and prove we read correctly. For DXF the answer was assumed rather than tested, because every customer file we hold uses one entity type.

Measured, 2026-08-04

dxf_io.parse dispatches on exactly six entity types: POLYLINE, LWPOLYLINE, LINE, ARC, CIRCLE, SPLINE (dxf_io.py:113-244). Anything else falls through the loop's trailing i += 1 and is discarded — ELLIPSE, INSERT, HATCH, SOLID, TEXT, MTEXT, DIMENSION, LEADER, 3DFACE, POINT, ATTRIB. There is no count of what was skipped and no warning.

The parser also does not track which section of the file it is in, so geometry belonging to a block definition is read as though it were drawn on the sheet.

The example, said plainly — Jordan asked and it was badly explained the first time

A DXF block is a stamp. You draw a shape once, off to the side, and then place copies of it wherever you want them; each placement is an INSERT, which carries the position, the scale and the rotation. The drawing on the sheet is the stamps, not the original.

Our reader picks up the original, at wherever it happens to sit in the file, and throws away every stamp. So a sheet with six copies of a bracket comes back as one bracket in the wrong place. The probe: one line drawn inside a block, stamped down at (100,100), plus an ellipse elsewhere — parsed to a single line at (0,0)–(2,0). The stamp position gone, the ellipse gone, nothing reported. Reproduce with python3 probe_entities.py.

Why it was written up rather than fixed

Because of the kind of failure it is. A missing feature announces itself; this returns a confident wrong answer. Geometry in the wrong place looks exactly like geometry in the right place, and a file we cannot read at all is indistinguishable from an empty file. Nothing downstream — heal, QC, the post — can tell that anything is absent. Recorded as defect D14.

OUT OF SCOPE — Jordan, 2026-08-04

Write it down as out of scope for now, but let's revisit this as part of our beta testing once the interface has been written.

So this is deferred by decision, not forgotten, and it is not a defect anybody should now go and fix. It has cost nothing on any file cut so far — the novi file parses unchanged at 91 polylines — and the whole exposure is on files we have not been given. The right time to find out which entity types real customers actually send is when real customer files are arriving through an interface, which is exactly what beta testing is. D14 stays on the record as deferred so the finding survives until then.

⚑ Revisit trigger: beta testing, once the interface exists. The question to answer then is which of these entity types actually turn up — and the ones that never do get written down as out of scope permanently rather than quietly half-supported.

Record — 2026-08-10, TL-1016 forced two of these gaps closed

Jordan's TL-1016-81/-82 kit arrived drawn with 188/197 ELLIPSE arcs and a full BLOCKS section (ANSI-B title block, dimension-symbol blocks). Two fixes, both in dxf_io.py, same day:

ELLIPSE is now parsed (center/major/ratio/t0/t1), sampled off the true curve (eval_ellipse, same contract as eval_spline) and fitted into tangent-continuous G2/G3 arcs in heal.py — the spline road. Unit conversion and sample_true_source include it, so fidelity is measured against the true ellipse.
The entity scan is scoped to the ENTITIES section. On TL-1016-81 the old whole-file scan read 525 of 1541 'polylines' out of block definitions — title-block frame and dimension furniture emitted as cut geometry. Files with no ENTITIES marker keep the old whole-file fallback.

Still true: INSERT placements are dropped (a multi-stamp sheet still comes back as nothing, since its geometry now sits in BLOCKS which we correctly skip) — unchanged, and still ruled out-of-scope until beta. TL-1016's one INSERT is its title block, which is furniture, not part.

Output coverage, same date (record): MetaCam mishandles standalone ARC entities (parses centre+radius, drops start/end angles, draws full circles) — first seen on Brazen 2026-08-07, confirmed again on Jordan's TL-1016 first-nest screenshot 2026-08-10. emit.write_dxf_metacam() now emits the shop's proven R12 profile (closed bulge POLYLINEs + true CIRCLEs, CRLF, no $ACADVER, no handles, zero ARC entities) directly from the pipeline's own ordered contours — unlike the dxf_compat.py retrofit, nothing is re-stitched by endpoint proximity, so its two failure modes (sub-gate joints left open, 4 distinct boundaries merged on TL-1016-82) cannot occur. split_parts.py writes both profiles for every part and nest sheet. Three findings forced alongside: (1) stitch_runs — heal appends spline/ellipse-fitted prims after the entity stitcher, so boundaries mixing lines with elliptical edges shattered into open fragments (one became a fake 'part'); open runs now rejoin at coincident ends, tol 0.020" = 2× heal gate, 2-way joins only. (2) Debris gate 0.05" min dimension — TL-1016-82 carries hairline slivers to 1.172×0.003"; reported and kept in a debris DXF, never nested as parts. (3) Contours that still do not close (real customer-side gaps 0.02–5.2") ride as OPEN polylines and are counted on the page — never silently closed.

Record — 2026-08-14, drawing-sheet prep is now a tool, not hand surgery: prep_drawing.py reproduces what was done by hand for TL-1016-73..85: clusters modelspace geometry into views by bbox adjacency (with a containment pass so interior holes far from their outline stay with their view — TL-1016-90's three central bolt holes), drops bare-line strips whose short side is ≤16 mm (edge views: 6.4/12.7/1.5 mm seen), prints every cluster and its verdict, and writes the filtered copy. Used on the 2026-08-14 17-file batch (TL-1016-86..97, CP-6004-97/98, CP-8005-22/23/24); the CP-8005 sheets (border + drawn table + logo art in modelspace) needed a manual crop region on top — auto-classifying a drawn title-block table is still out of scope.