Fix DXF export rejected by eDrawings/AutoCAD viewers

[YurMil]

Exported DXF files failed to open in strict viewers (eDrawings, AutoCAD viewer) with "Error reading file".

Cause: the header declared $ACADVER = AC1015 (AutoCAD 2000) while the file body was a minimal HEADER/TABLES/ENTITIES structure. AC1015 makes CLASSES, BLOCKS and OBJECTS sections, the full table set (VPORT/LTYPE/STYLE/APPID/DIMSTYLE/BLOCK_RECORD), and per-entity handles mandatory — strict parsers validate that and reject the file. Permissive viewers ignored it, which is why the bug went unnoticed.

Fix:

• Declare DXF R12 (AC1009) — no such requirements, universally readable, fully sufficient for CIRCLE/LINE geometry
• Define the CONTINUOUS linetype in an LTYPE table before the layers that reference it
• $MEASUREMENT = 1 marks the drawing as metric (replaces the AC1015-only $INSUNITS)
• 5 regression tests: version declaration, linetype-before-layers ordering, layer declarations, balanced SECTION/ENDSEC + EOF, entity counts

Verified: 63 tests pass (58 existing + 5 new), build green. Merging deploys the fixed bundle to cadautoscript.com.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request updates the DXF exporter to target DXF R12 (AC1009) instead of AC1015, which improves compatibility with strict CAD viewers, and ensures the CONTINUOUS linetype is defined before layers reference it. It also introduces a new test suite for the exporter. The review feedback suggests two important improvements to the test file: avoiding unsafe type assertions (using 'as unknown as') to maintain TypeScript's type safety, and moving the DXF generation logic from the root of the 'describe' block into a 'beforeAll' hook to prevent potential failures during the test registration phase.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Using as unknown as GeneratorParams bypasses TypeScript's type safety guarantees. If buildTubeSheetDxf or other helper functions are updated in the future to require additional properties from GeneratorParams, this test will compile successfully but fail at runtime with NaN or undefined errors.

Instead, define a complete, type-safe GeneratorParams object with default values for the missing properties.

const params: GeneratorParams = {
  boardDiameter: 150,
  thickness: 10,
  tubeDiameter: 25,
  tubeLength: 1000,
  tubeLayout: 'square',
  tubePitch: 30,
  edgeMargin: 10,
  topCutoffChord: 0,
  bottomCutoffChord: 0,
  partitionWidth: 10,
  partitionOrientation: 'horizontal',
  passCount: 2,
};

[gemini-code-assist]

Executing code directly inside the describe block (outside of it, beforeEach, or beforeAll) runs during the test suite registration phase rather than the execution phase. If buildTubeSheetDxf throws an error, the entire test suite will fail to load, which can break test runners and produce confusing stack traces.

Move the DXF generation logic into a beforeAll block. Remember to also import beforeAll from 'vitest' on line 1.

describe('buildTubeSheetDxf', () => {
  let dxf: string;
  let lines: string[];

  beforeAll(() => {
    dxf = buildTubeSheetDxf(params, coords);
    lines = dxf.split('\n');
  });

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 427c9ca232

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Preserve explicit millimeter units

When a user imports the exported DXF into a CAD/CAM workflow that infers scale from header units, this swaps the previous $INSUNITS=4 millimeter declaration for $MEASUREMENT=1; $MEASUREMENT only selects metric-vs-imperial linetype/hatch defaults and is independent of the modelspace unit, while $INSUNITS is what identifies millimeters (see https://ezdxf.readthedocs.io/en/stable/concepts/units.html). Because all UI inputs and filenames are in mm, these R12 files now become unitless/ambiguous and can be interpreted at the host drawing's default scale; if AC1009 is required for compatibility, we need another explicit unit strategy or a valid newer DXF path rather than dropping the millimeter declaration.

Useful? React with 👍 / 👎.