Why: real CAD drawings (e.g. McMaster part DXFs) carry their dimensions as DIMENSION entities, not loose TEXT. SwiftDXF's DXF.Entity model has line/circle/arc/ellipse/point/text/polyline — no DIMENSION — so every dimension callout is silently dropped. A downstream drawing→3D pipeline needs the value and what it measures to bind dimensions to geometry.
Ask: add a DXF.Entity.dimension(...) case exposing, per DIMENSION entity:
- the measured value (group 42 actual measurement, or the group-1 text override when present),
- the definition points (the dim's defining points — e.g. the two witness origins for a linear dim; group 13/14 + 10),
- the text position (group 11) and the dimension type (group 70: linear / aligned / radial / diameter / angular),
- the layer.
The rendered arrow/text block geometry can be ignored — we need the semantic measurement, not its glyphs. Linear/aligned/radial/diameter cover the immediate need; angular/ordinate can follow. Validate against an ezdxf-read of the same files (as the existing reader is).
Why: real CAD drawings (e.g. McMaster part DXFs) carry their dimensions as
DIMENSIONentities, not looseTEXT. SwiftDXF'sDXF.Entitymodel has line/circle/arc/ellipse/point/text/polyline — noDIMENSION— so every dimension callout is silently dropped. A downstream drawing→3D pipeline needs the value and what it measures to bind dimensions to geometry.Ask: add a
DXF.Entity.dimension(...)case exposing, per DIMENSION entity:The rendered arrow/text block geometry can be ignored — we need the semantic measurement, not its glyphs. Linear/aligned/radial/diameter cover the immediate need; angular/ordinate can follow. Validate against an ezdxf-read of the same files (as the existing reader is).