Ring-shaped parts (a plate with a large center hole) were left unlabeled:
the material at their pole is too narrow for the ID, and the label was
never tried anywhere else. Group IDs were likewise only ever placed beside
the dotted outline, so a cramped cluster lost its ID or straddled the
sheet edge.
A part whose pole spot is too tight now takes the roomiest clear spot
within its own extents, such as its empty hole. A group ID takes the
roomiest spot inside its outline or beside it; with none clear it may
cover the group's own parts near the center, since operators read part
detail from the parts list. No ID sits across the sheet outline.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Each dotted group outline was padded 1 pt beyond its parts. At overview scale
a 0.25 in part spacing is only ~1.3 pt, so the outlines of two adjacent
clusters (e.g. the six small bars and the two holed plates on N26-27Y plate 1)
overlapped, and the later group - with its ID - was silently dropped.
Pad outlines by under half the part spacing instead, so neighboring clusters
both get their outline and ID.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Nest reports showed "-" for every part weight on N26-295 because the nest and
its drawings store Stainless Steel 310 with density 0: materials are picked by
name and grade, and nothing copies a density onto them. The densities live in
the machine material defaults, and for this nest not even on its own machine
(CL-980 lists only 304; 310 is on CI FIBER 4020).
The desktop now resolves a catalog density before capturing the report: the
nest machine's exact name and grade, any machine's exact name and grade, then
the same material name. A density stored on the nest still wins, and the
drawing's own material stays the last fallback.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The summary's parts table squeezed each thumbnail into a 62 pt column and
had no room for the size and weight the shop asks for. Each drawing is now
a card, four to a row: ID, a larger thumbnail, name, bounding-box size,
weight each and for all nested copies, required/nested counts and plates.
A shortage or extra is a badge beside the ID (SHORT in red) so it stays
easy to spot without a column to scan.
Weight is net area x nest thickness x material density, read as lb/in^3
like the machine material defaults; millimeter jobs report kilograms. A
nest without thickness or density shows "-" and a note saying what is
missing, never a zero weight.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Group outlines and their shared ID were rejected whenever they touched
another part's bounding box. A large irregular part's box can cover most
of the sheet, so small repeated parts sitting in its notch or cutout
(e.g. test squares) were left with no ID at all. Test clearance against
real contours instead, as individual labels already do.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The nest report joined contour segments only within 1e-12, but converted
arcs rebuild their end from the start radius and end angle. Rounded or
incremental programs (end radius a few 1e-7 off the start radius, which
the report's own validator accepts up to Tolerance.Epsilon) left every
arc a hair short of the next move, so outlines split into open pieces
and N26-27K's parts printed unshaded as if they had tab gaps.
Join within Tolerance.Epsilon instead, still far below ShapeBuilder's
welding tolerance and real tab gaps.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Full circles now take InternalLeadIn/InternalLeadOut like every other
cutout; the ArcCircle lead settings and the cutting panel's Arc / Circle
tab are removed. Circle-specific geometry handling (radius clamp, angle
rounding, pierce zone) is unchanged.
Older nest files and desktop settings still load: their arcCircleLeadIn/
arcCircleLeadOut keys are ignored and no longer written, so re-planned
circles take the internal leads. Saved part programs are untouched.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The GitHub Linux runner has no poppler-utils, so ReportPdf throws
SkipException; as a plain [Fact] the test failed instead of skipping.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The nest report PDF gains an estimated cut time: the job total on the
summary, an Est. cut time column in the plates table, and per-plate and
all-copies times on each plate page. Times come from the cut simulation
with the settings last used in Calculate Cut Time, plus clamp removal.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Report, dialog and diagnostic text across post verification, cutoff
planning, alignment and cutting-plan review repeatedly told the user
what checks weren't (safety certifications, proof, guarantees) instead
of what to do. Reworded these to state the same caveats affirmatively
(inspect X, confirm Y, review Z) without changing the underlying
safety guidance, and updated the tests/docs that pinned the old wording.
The new windows-desktop CI job surfaced several tests that had never
actually run on Windows:
- SeparatorPenLifetimeTests expected Control.Disposed to fire only
once; current WinForms re-fires it on every Dispose() call.
- EditNestFocusTraversalTests assumed the Plates tab was selected by
default, which stopped being true once Drawings became the landing
tab; select it explicitly before asserting focus.
- NestReportExportTests asserted an exact plate count that ignored
PlateManager's trailing sentinel plate, and didn't expect the nest
name in the busy-export message.
- AtomicReportFileTests only expected IOException when replacing a
directory target; Windows raises UnauthorizedAccessException instead,
which callers already treat the same way.
Also register a ThreadException handler so an exception inside a
WndProc callback fails the test normally instead of popping a modal
dialog that blocks the desktop.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Slice 2 of the nest report plan: pagination, overflow and dense-label
coverage on top of the Slice 1 one-plate library.
- NestPdfWriter: general multi-plate pagination. Summary/plate tables
continue across pages with repeated (HeadingFormat) header rows; notes
flow as an ordinary paragraph instead of a bounded cell; page headers
are wrapped and sized into the top margin; drawing areas are located
per page via DocumentRenderer.GetRenderInfoFromPage.
- ReportText: lossless pre-wrapping (MigraDoc clips an over-tall row and
lets an unbroken token overflow a narrow cell without warning), capped
table-cell line counts, plate-range compression ("1-2, 4"), and
A/B/.../AA map-grid row names.
- NestReportDiagram: label placement centers each part ID on its
PolyLabel pole (matching PlateView's LayoutPart), computed on a
placement-independent quantized copy so identical parts share one
label position. Parts whose ID cannot fit legibly at overview scale
get a lettered/numbered map grid and a zoomed, framed detail page per
crowded cell; the writer fails with plate/part/ID when even that
cannot place a label, or a plate would need more than 24 detail views.
- Tests: NestPdfLayoutTests (multi-plate totals/ranges/same-named
references, table continuation with no lost rows, long name/notes
wrapping without column overflow, mm units in all four quadrants,
dense-label detail views with hole avoidance, save/reload of the
tabbed/lead-in fixture with stale tab flags, invalid later-plate data,
late write failures against an existing destination, source
unchanged on success/failure), ReportPdf test helper (page/word/
content-stream extraction).
- docs/nest-reports.md: replace the Slice 1 one-plate limits section
with the general pagination/dense-label contract and the process-wide
PDFsharp/MigraDoc render lock.
Verification: Reporting filter 70/70; full OpenNest.Tests 2524
passed/21 skipped/0 failed; Engine 351/351; IO 77/77;
EnableWindowsTargeting=true full-solution build 0 errors; scoped
dotnet format --verify-no-changes exit 0. Preview PDFs rendered and
visually inspected (evidence: /home/aj/extracted/2026-09-29/opennest-report-slice2/).
Windows runtime, the desktop adapter and packaged-app font deployment
remain unverified (Slice 3).
PDFsharp/MigraDoc layout and font state is process-wide. Parallel exports
of the same snapshot laid text out differently (for example merged words
like "Total physicalsheets" and shifted table columns). Serialize the
whole render-and-save in NestPdfWriter.Write; reports are rare.
Regression test exports one snapshot 128 times in parallel and compares
page content streams with a sequential export; it failed with dozens of
mismatches per run before the lock.
Add OpenNest.Reporting (net8.0, PDFsharp-MigraDoc 6.2.4) with a detached
report snapshot and a PDF writer for an empty/demand-only job or a single
plate layout: Letter portrait summary with vector part thumbnails and a
landscape plate page with a vector sheet diagram, both with Page X of Y.
- Snapshot uses reference identity for document-local R### IDs, recounts
nested quantities from placements x copies with checked wide integers,
excludes cutoffs from accounting, and retains no live domain objects.
- Geometry keeps Cut/Display material paths, drops rapid/scribe/lead paths,
preserves native arcs, holes and intentional tab gaps, and rejects
malformed programs with plate/part identification.
- Open contours and cutoffs are stroked per contour so PDFsharp cannot join
a tab gap to the next contour.
- Bundled DejaVu Sans via a custom resolver (including MigraDoc's error
font); unsupported text fails with the field and code point.
- Layouts beyond this slice (multiple plates, page overflow, labels that
do not fit) fail with NotSupportedException before the destination is
replaced; output is rendered to a temporary sibling and moved atomically.
ajandClaude Opus 5.5