The crate ends at numbers. An engineer then redraws the result by hand in CAD, which is repetitive, easy to mistranscribe, and the step where a correct calculation turns into a wrong drawing.
A beam check already knows everything a reinforcement detail needs: the section, the bar layout, the cover, the effective depth. It should be able to draw it.
Architecture: one drawing model, several renderers
Do not generate PDF from DXF, and do not write a separate drawing routine per format. Build a small internal representation, lines, arcs, circles, hatches, text, dimensions, layers, and render that.
calculation result -> Drawing (internal) -> DxfRenderer -> .dxf (opens in AutoCAD)
-> PdfRenderer -> .pdf (submission and print)
-> SvgRenderer -> .svg (web, and free with WASM)
SVG costs almost nothing once the model exists and pays for itself the first time this runs in a browser.
Keep the zero-dependency default
The crate advertises no dependencies beyond std, and that is worth protecting. Put drawing behind an optional feature:
[features]
default = []
dxf = ["dep:dxf"]
pdf = ["dep:printpdf"]
svg = [] # no dependency needed
cargo add sni-struct stays dependency free. Someone who wants drawings opts in.
The dxf crate (v0.6.1 at the time of writing) reads and writes DXF, so that half does not need writing from scratch. SVG needs nothing at all.
First drawing, and only this one
A reinforced concrete beam cross section. Outline, bars to scale at their real positions, cover dimension, effective depth, and a label block carrying the section size, fc', fy, As and the resulting phi.Mn.
That is enough to prove the whole pipeline end to end. Steel sections, elevations, bar schedules and a full sheet border all come after, and each is its own issue.
What it must not do
Draw something that does not match the numbers it came from. The label block and the geometry must both be derived from the same result struct, never passed in separately, so a drawing cannot disagree with its own calculation.
Testing
Rendering is hard to assert on. Suggested approach:
- Assert the model, not the pixels: entity counts, layer names, coordinates of known points, the text of the label block
- One golden-file test per renderer, with the file committed, so an unintended change shows up as a diff
- Open the output in a real CAD program once by hand before calling it done. A DXF that parses is not the same as a DXF that opens
The crate ends at numbers. An engineer then redraws the result by hand in CAD, which is repetitive, easy to mistranscribe, and the step where a correct calculation turns into a wrong drawing.
A beam check already knows everything a reinforcement detail needs: the section, the bar layout, the cover, the effective depth. It should be able to draw it.
Architecture: one drawing model, several renderers
Do not generate PDF from DXF, and do not write a separate drawing routine per format. Build a small internal representation, lines, arcs, circles, hatches, text, dimensions, layers, and render that.
SVG costs almost nothing once the model exists and pays for itself the first time this runs in a browser.
Keep the zero-dependency default
The crate advertises no dependencies beyond std, and that is worth protecting. Put drawing behind an optional feature:
cargo add sni-structstays dependency free. Someone who wants drawings opts in.The
dxfcrate (v0.6.1 at the time of writing) reads and writes DXF, so that half does not need writing from scratch. SVG needs nothing at all.First drawing, and only this one
A reinforced concrete beam cross section. Outline, bars to scale at their real positions, cover dimension, effective depth, and a label block carrying the section size,
fc',fy,Asand the resultingphi.Mn.That is enough to prove the whole pipeline end to end. Steel sections, elevations, bar schedules and a full sheet border all come after, and each is its own issue.
What it must not do
Draw something that does not match the numbers it came from. The label block and the geometry must both be derived from the same result struct, never passed in separately, so a drawing cannot disagree with its own calculation.
Testing
Rendering is hard to assert on. Suggested approach: