HATCH entities: missing elevation X/Y codes (10/20) and pixel_size (47) cause AutoCAD to discard the drawing

[OndrejJanota91]

HATCH entities: missing elevation point X/Y codes (10/20), and pixel_size (47) causes AutoCAD to discard the drawing

*** Report generated by AI after few hours of solving issue.

Summary

Documents containing Hatch entities exported via DxfWriter produce DXF files that real AutoCAD (and DWG TrueView, which shares the same core engine) refuse to load — the drawing is discarded with an explicit error. Files without Hatch entities, generated with the same code path, open correctly. Two independent, confirmed issues in the Hatch DXF writer were found.

---

1. Hatch.elevation metadata is missing group codes 10 and 20

Root cause

src/Metadata/LookupTables/Entities.ts, in the Hatch type definition:

{
  "propertyName": "elevation",
  "valueCodes": [30],
  "referenceType": 0
}

Per the DXF reference, HATCH's elevation point is a fixed 10/20/30 (X/Y/Z) triplet, where X and Y are always written as 0 and Z carries the actual elevation:

10 — Elevation point (in OCS). DXF: X value = 0
20, 30 — DXF: Y and Z values of elevation point (in OCS); Y value = 0, Z represents the elevation

The current mapping only ever emits group code 30. Codes 10 and 20 are never written, for any Hatch instance, regardless of what the entity's other properties are set to.

Minimal reproduction

import {
  DxfWriter, CadDocument, XY, XYZ,
  Hatch, HatchBoundaryPath, HatchBoundaryPathPolyline,
  BoundaryPathFlags, HatchStyleType
} from '@node-projects/acad-ts';

const doc = new CadDocument();
doc.header.codePage = 'ANSI_1252';

const exteriorPath = new HatchBoundaryPathPolyline();
exteriorPath.isClosed = true;
exteriorPath.vertices = [
  new XY(0, 0), new XY(10, 0), new XY(10, 10), new XY(0, 10)
].map(p => new XYZ(p.x, p.y, 0));

const outerPath = new HatchBoundaryPath([exteriorPath]);
outerPath.flags = BoundaryPathFlags.External | BoundaryPathFlags.Outermost;

const hatch = new Hatch();
hatch.paths = [outerPath];
hatch.style = HatchStyleType.Normal;
hatch.isSolid = true;

doc.modelSpace.entities.add(hatch);
doc.restoreHandles();

const output = new Uint8Array(1024 * 1024);
const writer = new DxfWriter(output, doc);
writer.write();

Actual output (excerpt, around the AcDbHatch subclass marker)

100
AcDbHatch
30
0.0
210
0.0
220
0.0
230
1.0
2
SOLID
...

Expected output

100
AcDbHatch
10
0.0
20
0.0
30
0.0
210
0.0
220
0.0
230
1.0
2
SOLID
...

Suggested fix

{
  "propertyName": "elevation",
  "valueCodes": [10, 20, 30],
  "referenceType": 0
}

with the writer emitting 0.0 for codes 10 and 20 unconditionally (X and Y of this point are always 0 per spec) and the actual elevation value for code 30.

---

2. Hatch.pixelSize (group code 47) is always written, even at its default value, and causes AutoCAD compatibility issues

When a document produced with the fix of first issue. Autocad raises the following error:

The following error was encountered while reading in HATCH starting at line 2248:
Error: expected group code 98
Invalid or incomplete DXF input -- drawing discarded.

Group code 98 ("Number of seed points") is the last field in the top-level HATCH group code sequence and follows group code 47 .

Root cause

src/Entities/Hatch.ts:

pixelSize: number = 0;

This is a plain required property with a default value, always mapped to group code 47 in the writer metadata. There is no way to omit the field from the output — every Hatch entity gets 47 written, even when the value is the default 0.0.

Impact

This matches a documented, independently-observed AutoCAD compatibility issue. From the ezdxf project's own HATCH documentation:

"If there are troubles with AutoCAD, maybe the hatch entity has the Hatch.dxf.pixel_size attribute set — delete it (del hatch.dxf.pixel_size) and maybe the problem is solved. Ezdxf does not use the Hatch.dxf.pixel_size attribute, but it can occur in DXF files created by other applications."
— https://ezdxf.readthedocs.io/en/stable/dxfentities/hatch.html

In our own testing, after fixing issue #1 above (elevation point codes), AutoCAD was still unable to correctly load/display the resulting hatches until group code 47 was stripped entirely from the HATCH entities. With both issue #1 and this one fixed, the file opens and displays correctly in AutoCAD.

Suggested fix

Either:

• Omit group code 47 from the writer output entirely when pixelSize is at its default/unset value, or
• Make pixelSize an optional/nullable property (e.g. pixelSize: number | null = null) so consumers can explicitly opt out of writing this field, consistent with how other optional HATCH fields are handled.

---

Environment

• @node-projects/acad-ts v2.4.0 (also reproduced on the master branch as of writing)
• Node.js, ESM
• Target DXF version: AC1032
• Tested against: AutoCAD (full desktop), DWG TrueView — both exhibit the same failure behavior on files affected by these issues

Happy to provide the full minimal reproduction project (package.json + script) if useful.