DXF-CSV v1.0 Reference

The normative core of the format: what every column means, how coordinates and blocks are encoded, and the design principle behind what DXF-CSV keeps and strips. For entity-by-entity column usage, see Entities. For the raw source, see spec.md.

Design principle

DXF-CSV applies a consistent filter to all DXF input regardless of source version.

Keep -- drafting semantics: geometry, layer, linetype, color, block structure, text content, dimension definition points, entity type.

Strip -- AutoCAD bookkeeping: handles (group 5), owner chains (330/360), group 100 subclass markers, CLASSES section, OBJECTS section, extension dictionaries, reactors, XDATA.

Rationale: Group 100 subclass markers are redundant with the type column. Handles and owner chains serve AutoCAD's internal object graph for reactor/notification dispatch -- they have no drafting meaning. The CLASSES and OBJECTS sections register custom object types and non-graphical persistent objects (plot settings, material references, etc.) that are not part of drawing geometry.

Post-R12 entities (LWPOLYLINE, SPLINE, MTEXT, etc.) are included where present, treated as if they were added to R12's orthogonal data model -- each entity's properties are independent, with no side-effect dependencies on other objects. This means no observers or reactors are needed to interpret the data.

Uniform export environment

CSVOUT runs AutoCAD with object enablers deliberately disabled. Object enablers are .dbx modules that load custom object types into the drawing database -- Civil 3D, Architecture, MEP, and other vertical products each ship their own. When enablers are active, custom objects may serialize geometry in undocumented, enabler-dependent formats or refuse to serialize at all. Disabling enablers produces a uniform environment across all drawing types. Every drawing -- plain AutoCAD, Civil 3D, Architecture -- exports through the same code path. Entities whose geometry requires an enabler appear as zombie entities: the type name and non-geometric properties (layer, color, linetype, style, paper space) are preserved, but all geometry columns are absent.

Zombies are placeholders, not errors. The entity exists in the drawing with its correct layer and properties. On round-trip import, nothing is lost -- the original DWG (identified by source: and sha1:) holds the complete object, and the importer restores it from there rather than from the CSV geometry.

The zombie list reflects which enablers were absent in the specific export session, not which objects are "third-party." Any entity type -- including plain AutoCAD entities -- can appear as a zombie when its handler is absent from the running AutoCAD session.

Single-entity-type column suppression: columns that would be populated by only one entity type and carry no cross-entity semantic value are suppressed -- the column is not added to the header even if the group code is present in the source DXF. Example: char[281] (PDFUNDERLAY contrast) and char[282] (PDFUNDERLAY fade) are suppressed when PDFUNDERLAY is the only entity that would populate them. The entity is still exported -- only the single-entity-type columns are dropped.

Implication for import: CSVIN operates in two modes depending on the target drawing:

• Modify mode -- the target is the original source drawing identified by source: and sha1:. CSVIN verifies the hash matches the open drawing and updates changed entities in place via acdbEntMake / acdbEntMod. No DXF is generated or consumed.
• Create mode -- the target is a known published template (e.g. sha1:781e2fb2654f, new.dxf). CSVIN merges the CSV into the template to produce a new DXF or DWG. The sha1 is a public constant -- any AI generating for this sha1 knows exactly what tables and handles are present. The resulting DXF from Drawing Sync's own writer contains only drafting content -- the OBJECTS section remains minimal, unlike AutoCAD-written DXF which appends thousands of lines of plot settings and render data.

In both modes the CSV carries geometry and drafting intent; bookkeeping is never round-tripped.

Derived counts are absent: counts that are fully redundant with their data columns are omitted from the CSV. CSVIN derives them by counting fields -- the count column would add no information. This applies to:

• SPLINE: int[72] (knot count derived from real[40]), int[73] (control point count from pt[10]), int[74] (fit point count from pt[11])
• MESH: int[92] (vertex count from pt[10]), int[95] (crease count, always equal to int[94])

AI generators must not emit these columns. A consumer reading a DXF-CSV file should not expect them. This is a design rule, not a per-entity exception.

sha1 as drawing state contract: the sha1: clause is not just documentation -- it is a contract between the CSV and the drawing state. CSVIN verifies the hash before importing; if the open drawing doesn't match, import is rejected. This mechanism supports a library of known starting points. An AI generating content for sha1:396cb2c5a30e (empty AutoCAD 2018 template) makes no assumptions about pre-existing blocks, layers, or styles -- it must define everything it uses. An AI generating content for a domain-specific template sha1 can reference blocks, layers, dimstyles, and text styles that already exist in that drawing without redefining them, keeping the generated CSV lean and focused on design intent rather than infrastructure. The sha1 is the key; the drawing is the state. One exception to strict matching: an all-zero sha1 (000000000000) is treated as equivalent to 396cb2c5a30e -- AI consumers generating from scratch with no real source drawing commonly emit this placeholder rather than looking up the real hash, and CSVIN accepts it with the same "no pre-existing references" assumption.

Open library: anyone can define a template drawing, publish it, and document its sha1. No central registry or approval is required -- if the sha1 matches the open drawing, CSVIN imports cleanly and the expectations encoded in that template are guaranteed. Domain communities can maintain their own templates: architectural (standard layer names, door and window blocks, annotation styles), electrical (symbol libraries, IEC or NFPA layer conventions), civil (survey layers, coordinate systems), mechanical (ASME title blocks, GD&T styles). An AI targeting a known template sha1 can skip all table definitions and generate only entities -- the smallest possible CSV for the most complete result.

Currently published starting points:

Column headers

Headers follow the pattern semanticname[code] where code is the DXF group code number. All group codes are entity-scoped -- the same code number means different things on different entity types, exactly as in the DXF specification. When in doubt, look up the code against the type column value, not the column header.

The column set in any given file reflects only the group codes present in that export. Columns are added to the header when a group code appears in the data -- not when a section or table is included. A file with no arc entities will have no angle[51] column. A file exported without DIMSTYLE will have none of the dimvar columns. Always read the header row to determine the column set for that file.

name[2] is required in every valid DXF-CSV file. Every file contains SECTION, ENDSEC, LAYER, and LTYPE rows -- all of which use name[2]. Omitting name[2] from the header leaves these rows nameless and the file unimportable. When generating a DXF-CSV file, always include name[2] in the header regardless of what other columns are present.

Column prefix reference

Standard columns

All ~77 documented column headers, grouped below for scrolling -- expand any group to see its rows. Order matches spec.md; group titles describe what each covers rather than claiming a strict numeric range, since several codes (15, 93, 95) recur with different entity-scoped meanings.

DIMSTYLE group code range: DIMSTYLE rows use a wide and evolving range of group codes across real, int, char, and pt prefixes. The codes listed above cover the most common variables but AutoCAD adds dimension variables with each release. A DIMSTYLE row may contain additional valid codes (e.g. char[277] DIMUNIT, char[280] per-object linetype flag, pt[213] leader direction vector) not individually documented here. All are valid -- read the column header and treat any unknown DIMSTYLE code as a dimension variable to preserve round-trip.

Name-only table rows

Any table row (LAYER, LTYPE, STYLE, DIMSTYLE) may appear with only name[2] populated and all other columns absent. This is a valid reference -- it declares the name exists and CSVIN will create or verify the entry using AutoCAD defaults. This pattern is common in AI-generated CSV when the consumer wants to reference a standard AutoCAD resource (e.g. DIMSTYLE name[2]=ISO-25, LTYPE name[2]=CENTER) without specifying every parameter.

Coordinates

All coordinates are raw drawing units -- no conversion applied. The units: clause identifies the unit system.

Single-point entities (LINE, CIRCLE, ARC, INSERT, TEXT, POINT): pt[10] contains one coordinate as x,y or x,y,z.

Multi-point entities (3DFACE, SOLID, TRACE, DIMENSION): use pt[10] through pt[14], one coordinate per column.

LWPOLYLINE vertices: pt[10] contains all vertices space-delimited -- x1,y1 x2,y2 x3,y3. Z is absent for 2D polylines; elevation is in elev[38] (check file columns).

POLYLINE/VERTEX: vertices are on individual VERTEX rows following the POLYLINE row, terminated by SEQEND. Each VERTEX has one coordinate in pt[10]. The POLYLINE row itself carries only elevation in pt[10] -- X and Y are always zero and carry no meaning.

Z-absent rule: CSVOUT follows DXF conventions -- flat entity types (LWPOLYLINE, 2D ARC, etc.) do not include a Z component; 3D entity types (POLYLINE/VERTEX, INSERT, etc.) always include Z. A missing Z means the entity type is inherently flat. Z=0 means the entity type carries Z and it happens to be zero. Consumers should treat both as equivalent for flat geometry -- 5,15 and 5,15,0 mean the same thing in practice. The coords:xy vs coords:xyz metadata clause simply reflects which is present in this file.

Bulge

Bulge encodes arc segments within polylines. Formula: bulge = tan(included_angle / 4).

• 0 = straight segment
• 1 = quarter circle (included = 4×atan(1) = 180°)
• Positive = arc bows left of the direction of travel (CCW)
• Negative = arc bows right (CW)
• Very large absolute values (e.g. 437, 39073) indicate near-complete circles where the two endpoint vertices are very close together

To recover arc geometry from bulge b between points P1 and P2:

chord   = distance(P1, P2)
radius  = chord / (2 * sin(2 * atan(|b|)))
sagitta = chord/2 * |b|

In LWPOLYLINE: bulge values are comma-delimited in real[42], one per vertex, in the same order as the space-delimited vertices in pt[10].

In VERTEX rows: bulge is a single value in real[42] on the VERTEX row it applies to.

Block structure

Block definitions are inline in the CSV between BLOCK and ENDBLK sentinel rows. They are not separate files.

BLOCK   name[2]='WIDGET'   layer[8]='0'   pt[10]='0,0,0'    <- definition starts
LINE    ...                                                    <- block geometry
CIRCLE  ...
ENDBLK                                                        <- definition ends
...
INSERT  name[2]='WIDGET'   pt[10]='100,200,0'  angle[50]=45  <- placement in model space

To render a placed block: find the BLOCK definition matching name[2] on the INSERT row, transform its geometry by the INSERT's position (pt[10]), x/y/z scale (real[41]/real[42]/real[43], absent = 1.0), and rotation angle (angle[50], absent = 0).

Block strip rules

Two categories of blocks are stripped from the output and never appear as BLOCK/ENDBLK definitions:

Anonymous blocks -- any block whose name begins with *. These are AutoCAD-managed internal blocks. Examples: *Model_Space, *Paper_Space, *D12 (dimension rendered geometry), *U333 (utility blocks).

Empty blocks -- any block containing no geometry rows between BLOCK and ENDBLK, regardless of name. This includes user-defined blocks whose geometry has been deleted but whose definition was not cleaned up.

Anonymous block inclusion and -dxs interaction

By default, anonymous blocks are stripped. This includes *D## dimension geometry blocks, which AutoCAD maintains as a dependent cache of rendered dimension primitives. The DIMENSION entity referencing such a block remains in the export -- the name[2] field will reference a block definition that is not present. On import, the importer recreates the anonymous geometry from the dimension parameters rather than restoring the cached primitives.

The -dxs flag controls which sections are exported. If the user excludes the BLOCKS section entirely, or specifies named blocks only, no block definitions will be present regardless of the anonymous strip rule. In all cases, an INSERT or DIMENSION referencing an absent block definition is valid -- treat as a zero-geometry placement, not an error.

Anonymous block inclusion is available as an export option -- when included, anonymous blocks appear as BLOCK/ENDBLK pairs with *-prefixed names.

INSERT with no matching BLOCK definition

An INSERT or DIMENSION row whose name[2] has no matching BLOCK definition in the file is valid -- the referenced block was stripped (anonymous or empty) or excluded via -dxs. Treat it as a zero-geometry placement at the specified position, scale, and rotation. Do not treat it as an error.

BLOCKS section states

The presence or absence of the BLOCKS section in the file is meaningful:

• BLOCKS section absent -- the user excluded blocks from this export
• BLOCKS section present, empty (SECTION/ENDSEC with no BLOCK rows between) -- blocks were exported but no user-defined block definitions exist in the drawing
• BLOCKS section present, with BLOCK/ENDBLK pairs -- user-defined block definitions are included

Note: AutoCAD always maintains at least *Model_Space internally, so the BLOCKS section is never truly empty at the DWG level. An empty BLOCKS section in the CSV means all definitions were stripped (anonymous or empty).

Structural sentinel rows

SECTION, ENDSEC, BLOCK, ENDBLK, and SEQEND are structural sentinels. They carry no entity properties -- all columns are empty except type (and name[2] on SECTION rows). Any properties that may exist on these rows in the source DXF are bookkeeping artifacts and are stripped on export.

TABLE and ENDTAB are never emitted -- they exist in DXF to wrap individual table sections but carry no information beyond what the enclosing SECTION row already provides.

BLOCK and INSERT conventions

BLOCK int[70] flags: 0 = regular block (or omit), 1 = anonymous (*-prefixed, AutoCAD-managed), 2 = has attributes (required when block contains ATTDEFs), 4 = xref block definition (external reference -- the block's geometry lives in the external DWG file; no entities will appear inside this BLOCK/ENDBLK pair in CSVOUT), 8 = xref overlaid. Must be set to 2 when the block contains ATTDEFs -- this signals AutoCAD to prompt for attribute values on INSERT. Omit or use 0 for blocks without ATTDEFs.

Color inside block definitions: entities inside a BLOCK should use color[62]=0 (BYBLOCK) so the INSERT's own layer color propagates into the block geometry at reference time. Entities with a specific ACI or true-color override inside a block will always display that color regardless of INSERT layer -- use BYBLOCK for reusable symbols and specific colors only when the block is intentionally hardcoded.

Nested blocks: a BLOCK definition may contain INSERT rows referencing other blocks -- nesting is supported. The nested INSERT appears as a normal INSERT row within the BLOCK/ENDBLK pair.

INSERT seq[66]: set to 1 when ATTRIB rows follow the INSERT before SEQEND. When absent or 0, no ATTRIB rows follow and no SEQEND is expected for that INSERT.

ATTDEF: defines an attribute template inside a BLOCK. text[1] = default value, name[2] = tag (matched against ATTRIB name[2] on INSERT), text[3] = prompt string. int[70] flags: 0=visible, 1=invisible, 2=constant, 4=verify, 8=preset.

ATTRIB: carries a live attribute value on a specific INSERT instance. Mirrors ATTDEF structure -- name[2] = tag, text[1] = actual value, real[40] = text height, pt[10] = text position. Must be followed by SEQEND (or another ATTRIB then SEQEND) when seq[66]=1 is set on the INSERT.

SECTION/ENDSEC for TABLES and BLOCKS appear only when the entire section is included via -dxs:

• -dxs=TABLES → SECTION name[2]=TABLES / ENDSEC wrap all table rows
• -dxs=TABLES(LAYER),TABLES(LTYPE) → no SECTION/ENDSEC; LAYER and LTYPE rows appear directly
• -dxs=BLOCKS → SECTION name[2]=BLOCKS / ENDSEC wrap all block definitions
• -dxs=BLOCKS('myblock') → no SECTION/ENDSEC; BLOCK/ENDBLK for that block appears directly

SEQEND terminates a POLYLINE/VERTEX sequence or an INSERT/ATTRIB sequence. Its presence is preserved for human readability -- a reader can always infer termination from context, but the explicit row is kept because people look for it.

ATTRIB / ATTDEF

ATTDEF defines an attribute template inside a block definition. ATTRIB is the filled-in instance attached to an INSERT in model space.

• name[2] = tag name (the attribute identifier, e.g. PART_NUMBER)
• text[1] = value on ATTRIB rows (the actual data, e.g. WD-4412)
• int[70] = attribute flags: 0=visible, 1=invisible, 2=constant, 4=verify, 8=preset
• int[72] = horizontal justification (same as TEXT)

ATTRIB rows immediately follow their parent INSERT row, before SEQEND. An INSERT and its following ATTRIB rows always share the same space -- both model or both paper. paper[67] will be consistent across the INSERT and all its ATTRIBs.

Paper space

When space:model-and-paper is in the metadata, the file contains both model-space and paper-space entities.

• paper[67]=1 on an entity means it lives in the default paper space layout (Layout1, *Paper_Space block record). paper[67]=2 = second layout (*Paper_Space0), paper[67]=3 = third (*Paper_Space1), and so on
• VIEWPORT entities define the viewports on the paper layout
• VIEWPORT real[40] and real[41] are viewport width and height in paper units
• VIEWPORT int[68] and int[69] are status flags and viewport ID
• VIEWPORT entities are always paper space entities -- paper[67]=1 is emitted on VIEWPORT rows.
• Viewport layer overrides (per-viewport layer freeze, color, linetype) are not exported -- these are stored as handle lists in extended data and do not survive round-trip. The user sets them manually after import.

VIEWPORT creation workflow: CSVIN cannot create VIEWPORT entities (acdbEntMake limitation -- permanent). For AI-assisted paper space layout, place a LWPOLYLINE rectangle in paper space (paper[67]=1) at the desired viewport position and size, with a TEXT entity on layer _ai describing the view you want (orientation, scale, layers to freeze). The user creates the actual viewport manually using the rectangle as a guide, then adjusts layer visibility to match the directive. Example:

LWPOLYLINE, _ai, "2.5,1.5 14.5,1.5 14.5,9.5 2.5,9.5", paper[67]=1  <- viewport boundary guide
TEXT, _ai, "Create viewport here: 3D isometric view, freeze layers: floorplan centerline labels", paper[67]=1, pt[10]="2.5,9.6"

Units reference

Less common DXF unit codes (uin, angstrom, nm, um, dm, dam, hm, Gm, AU, ly, pc, us-in, us-yd) are passed through using the same short-name pattern -- see the DXF specification for the full enumeration.

ACI color reference

AutoCAD Color Index (ACI) -- integer 1-255. Common values:

Negative ACI in the LAYER table means the layer is frozen or off. Use abs(value) for the display color.