A native DXF can be correct and still make a poor browser preview.
That is not a contradiction. DXF is an interchange artifact; a browser needs a presentation policy.
The boundary
PRT
→ native DXF
→ normalized scene
→ optional mesh or GLB
→ browser previewThe native DXF remains the engineering ground truth. The normalized scene is derived, disposable, and regenerated from it.
Why direct rendering fails
CAD exports may contain:
- reusable
BLOCKdefinitions andINSERTinstances; - dimension and leader graphics;
- construction layers;
- layer inheritance and transforms;
- entities that are valid in CAD but unsupported by a small browser renderer.
Expanding everything into one flat canvas can make the part disappear under its own annotations and construction geometry. That is a renderer-policy problem, not evidence that the DXF is corrupt.
What normalization does
A deterministic normalizer should:
- expand block instances and apply transforms;
- preserve source layer and component metadata;
- filter dimensions by an explicit default policy;
- keep construction geometry separately controllable;
- emit only supported renderables;
- record skipped entities and counts.
The browser should receive a scene it can draw—not a second undocumented CAD database to interpret.
What the preview is—and is not
The preview helps a reviewer navigate a recovered artifact. It does not replace the native DXF, prove a watertight solid, or establish that an unresolved PRT field has been decoded.
The same rule applies to baked GLB or mesh output: it is a presentation derivative unless independently validated as an engineering deliverable.
The practical result
A recovery package can contain two cleanly separated artifacts:
- native DXF for CAD inspection;
- normalized scene data for browser review.
That separation prevents a polished preview from hiding uncertainty and prevents browser code from becoming the format parser.