.DWG File Format – Objects and entities

Reading objects

Not every object in a file is used. Every used object can be reached by following handle references from the header variables, so the specification recommends reading the header and then following every reference. Files occasionally hold two APPID objects with the same name, only one of them used, and some files hold table records with duplicate names, which a reader should rename. One way to load objects is through the object map, which loads each object exactly once; the ODA’s toolkit loads the control objects first and then the objects they contain.

Every object starts on a byte boundary with its size as a modular short, and ends with a 2-byte CRC on a byte boundary; between them the data is a bit stream. The CRC covers the size bytes.

Common object format

Non-entity objects have this general layout:

String stream (R2007 and later)

All Unicode strings of an object are kept together in a string stream at the end of its data, though the field tables list them among the other fields. To find it:

1. Read the bit at endbit − 1 (the last bit before the handles). If it is 0, there is no string stream.
2. If it is 1, move endbit back 16 bytes and read a short at endbit − 128 bits: strDataSize.
3. If strDataSize has 0x8000 set, move endbit back another 16 bytes, clear 0x8000, read the short at the new position as hiSize, and set strDataSize to strDataSize | (hiSize << 15).
4. Move endbit back by strDataSize; that bit position is the start of the string stream.

The header variables and classes sections use the same arrangement from R2007.

Common entity format

Entities have the same layout as objects with some standard items added:

R13 and R14 entity flags

The six flag bits, FEDCBA, say which handle references are present:

The six common parameter bits, CCSSII, are the colour (a bitshort), the linetype scale (a bitdouble) and the invisibility (a bitshort, bit 0 set when invisible). Some entity parameters are always raw even where a bit code could be used, such as the 10 and 11 points of TEXT.

Object type numbers

These types have fixed numbers:

Other types have numbers that vary by drawing. Subtract 500 from the type to get an index into the class list: type 501 is the second class, and its DXF name says what the object is. The specification lists these as variable: ACAD_TABLE, CELLSTYLEMAP, DBCOLOR, DICTIONARYVAR, DICTIONARYWDFLT, FIELD, GROUP, HATCH, IDBUFFER, IMAGE, IMAGEDEF, IMAGEDEFREACTOR, LAYER_INDEX, LAYOUT, LWPLINE, MATERIAL, MLEADER, MLEADERSTYLE, OLE2FRAME, PLACEHOLDER, PLOTSETTINGS, RASTERVARIABLES, SCALE, SORTENTSTABLE, SPATIAL_FILTER, SPATIAL_INDEX, TABLEGEOMETRY, TABLESTYLES, VBA_PROJECT, VISUALSTYLE, WIPEOUTVARIABLE and XRECORD. Some of these (GROUP, HATCH, LAYOUT, LWPLINE, OLE2FRAME, VBA_PROJECT, XRECORD) also appear with fixed numbers above.

Common entity data

Every entity starts with this data, written “Common Entity Data” in the field tables below:

Common entity handle data

In the handle stream of every entity (“Common Entity Handle Data”):

Worked example: an R14 ENDBLK

The specification prints this ENDBLK object, handle 1B, from an R14 file. The decoding below follows the bits through the R13–R14 common entity data.

0F 00                                       size 15
41 40 46 E2 48 00 00 05 5B 18 28 87 A0 20 20  data and handles
2E 8B                                       CRC

01000001 01000000 01000110 11100010 01001000 00000000 00000000 00000101
01011011 00011000 00101000 10000111 10100000 00100000 00100000

Entities

Each entity begins with the common entity data and its handle stream begins with the common entity handle data; every entity ends with the CRC. The tables list only what comes after the common data.

TEXT (1)

ATTRIB (2)

The TEXT fields, then:

ATTDEF (3)

The ATTRIB fields, then a version RC (R2010+) and the prompt (TV, DXF 3).

BLOCK (4), ENDBLK (5) and SEQEND (6)

BLOCK has one field after the common data: the block name (TV, DXF 2). ENDBLK and SEQEND have none. The specification notes that the BLOCK HEADER object holds the block’s real data, and the BLOCK entity is almost a dummy.

INSERT (7)

MINSERT (8)

As INSERT up to the owned object count, then column count (BS, 70), row count (BS, 71), column spacing (BD, 44) and row spacing (BD, 45). The handles are as INSERT’s, except that the R2004+ ATTRIB handles are listed as soft pointers.

VERTEX (10 to 14)

2D POLYLINE (15)

3D POLYLINE (16)

Two RC flag bytes, neither of them directly a DXF value. The first: bit 0 means splined with 75 = 5, bit 1 splined with 75 = 6 (set 70 bit 2 if either is set). The second: bit 0 closed (70 bit 0); set 70 bit 3 because this is a 3D polyline. Then the owned object count (BL, R2004+) and the same handles as the 2D POLYLINE.

ARC (17)

Centre (3BD, 10), radius (BD, 40), thickness (BT, 39), extrusion (BE, 210), start angle (BD, 50), end angle (BD, 51).

CIRCLE (18)

Centre (3BD, 10), radius (BD, 40), thickness (BT, 39), extrusion (BE, 210).

LINE (19)

DIMENSION (20 to 26)

All dimensions start with this common dimension data:

Then, by type; every dimension’s handles end with DIMSTYLE (DXF 3) and the anonymous block (DXF 2), both hard pointers:

POINT (27)

Point (3BD, 10), thickness (BT, 39), extrusion (BE, 210), X-axis angle (BD, 50).

3DFACE (28)

POLYLINE (PFACE) (29) and POLYLINE (MESH) (30)

PFACE: number of vertices (BS, 71), number of faces (BS, 72), owned object count (BL, R2004+). MESH: flags (BS, 70), curve type (BS, 75), M and N vertex counts (BS, 71, 72), M and N densities (BS, 73, 74), owned object count (BL, R2004+). Both have the first and last VERTEX handles (soft pointers) in R13 to R2000, or one VERTEX handle per owned object from R2004 (soft pointers), and then the SEQEND (hard owner).

SOLID (31) and TRACE (32)

Thickness (BT, 39), elevation (BD, the Z of points 10 to 13), four corners (2RD, 10, 11, 12, 13), extrusion (BE, 210).

SHAPE (33)

Insertion point (3BD, 10), scale (BD, 40, default 1), rotation (BD, 50, radians, default 0), width factor (BD, 41, default 1), oblique angle (BD, 51, radians, default 0), thickness (BD, 39), shape number (BS, 2: an index; DXF stores the name, found by searching the shapes of the text styles that hold shape files), extrusion (3BD, 210). Handle: the SHAPEFILE (STYLE) object, hard pointer.

VIEWPORT (34)

ELLIPSE (35)

Centre (3BD, 10) and semi-major axis vector (3BD, 11), both in world coordinates even though the ellipse has an extrusion; extrusion (3BD, 210); minor to major axis ratio (BD, 40); start and end angles (BD, 41, 42; eccentric anomaly, radians).

SPLINE (36)

REGION (37), 3DSOLID (38) and BODY (39)

These are ACIS entities, which the ODA can step through and write but has not fully decoded. After the common data: ACIS empty bit (B; 1 means no data follows), an unknown bit (B) and a version (BS, 1 or 2). In version 1, blocks of SAT data follow, each a BL size and that many bytes, until a size of 0; bytes from 0x20 to 0x7E are stored as 0x9F minus the character, and tabs become spaces. In version 2 an ACIS file follows directly: SAB if it starts with ACIS BinaryFile, otherwise SAT text that must be parsed to find its end. From R2013 the ACIS data may be in the data store instead. The specification continues with further fields (section 20.4.41) that this page does not reproduce.

RAY (40) and XLINE (41)

Point (3BD, 10) and vector (3BD, 11).

MTEXT (44)

TOLERANCE (46)

In R13 and R14: an unknown short, a height (BD) and the DIMGAP at creation times DIMSCALE (BD). Then: insertion point (3BD, 10), X direction (3BD, 11), extrusion (3BD, 210), text string (DXF 1; the specification gives its type as BS). Handle: DIMSTYLE, hard pointer.

MLINE (47)

LWPOLYLINE (LWPLINE)

Objects

Non-entity objects begin with the common object format: size, type, the object size in bits (R2000 and later), handle, extended data, the bit size (R13–R14), the number of reactors and the XDic missing flag (R2004+). Their handle streams begin with the owner or parent, the reactors and the extension dictionary. The tables list what follows.

DICTIONARY (42) and DICTIONARYWDFLT

DICTIONARYWDFLT (a dictionary with a default) adds the default entry handle (H, DXF 7, hard pointer).

Control objects

Each symbol table has a control object, owned by the root object (its owner handle is 0), with an entry count (BL, 70) and a list of entry handles after a null soft pointer and the extension dictionary:

The specification also describes the VIEW (60), UCS (62), VPORT (64), APPID (66), DIMSTYLE (68) and VIEWPORT ENTITY (70) control objects (sections 20.4.59 to 20.4.69).

Common table entry fields

Every symbol table entry starts with:

BLOCK HEADER (49)

LAYER (51)

STYLE (SHAPEFILE) (53)

A text style for TEXT and MTEXT:

Sometimes TrueType font information is kept in the entry’s extended data: 1001 the font file name, an optional 1002 {, a 1071 flags value (bold 0x02000000, italic 0x01000000, pitch mask 0x00000003, family mask 0x000000F0, character set mask 0x0000FF00) and an optional 1002 }.

LTYPE (57)

APPID (67)

The common table entry fields, then an unknown RC (DXF 71, not in DXF when 0). Handles: the APPID control (soft pointer), reactors, extension dictionary and the external reference block (hard pointer).

GROUP (72)

Name (TV), unnamed (BS, 1 if the group has no name), selectable (BS, 1 if selectable), number of handles (BL). Handles: parent (soft pointer), reactors, extension dictionary, then the group’s entries (hard pointers).

DICTIONARYVAR

An integer value (RC) and a string (the specification gives the type as BS). Handles: parent (soft pointer), reactors and extension dictionary.

XRECORD

Number of data bytes (BL), the data bytes, then a cloning flag (BS, 280, R2000+). The data is pairs of an RS group code and a value in the DXF convention: code 1 is a string (in R13 to R2004 a length RC, the code page RC and the bytes; from R2007 a short length and that many UTF-16 characters), 70 a 2-byte short, 10 three 8-byte doubles, 40 one double, and so on. Handles: parent (soft pointer), reactors, extension dictionary, then object handles until the data runs out.

Objects described in the specification but not here

Chapter 20 of the specification also gives the fields of these, which this page does not yet reproduce:

Extended entity data

Extended data (EED, DXF −3) follows the object’s handle. For each application: a BS length of the data (not counting itself or the application handle), the application’s handle (a table handle, 0101, a 4-bit length and the handle bytes), then the data items. This repeats until a length of 0. Each item is a 1-byte code, the DXF group code minus 1000, then the value, which is not bit coded:

Proxy entity graphics

Proxy entities (called zombies before R14) and a few others carry graphics, when the “graphic present” bit is 1. The data is padded to 4-byte boundaries, strings included. Besides the usual types it uses PS, a zero-terminated string in the file’s code page, and PUS, a UTF-16 string ended by two zero bytes. It is a series of chunks, each an RL size, an RL type and the type’s data:

The edge, face and vertex primitive flags of MESH and SHELL select per-item traits:

For a MESH there are (rows − 1) × columns + (columns − 1) × rows edges and (rows − 1) × (columns − 1) faces.

Not confirmed

• Type numbers 0x09, 0x36, 0x37, 0x3A and 0x3B have no name in the specification’s table, though its prescriptions call 52 (0x34) SHAPEFILE CONTROL and 53 (0x35) SHAPEFILE where the table says STYLE CONTROL OBJ and STYLE.
• Several types appear both with fixed numbers and in the list of variable ones; the specification does not say which applies when.
• Some types in the prescriptions look like slips: the TOLERANCE text and the DICTIONARYVAR string are given as BS, and the polyline-with-normal proxy chunk gives its normal as one RD. They are shown as printed.
• The ODA does not fully understand the ACIS data of REGION, 3DSOLID and BODY, or the fields marked unknown above. The type code EC (vertex flags, MLINE justification) is not defined in the specification.
• The material flag value 10 (“global material?”) is uncertain in the specification itself.

Sources

• Open Design Specification for .dwg files, version 5.4.1 – Open Design Alliance; chapter 20 (AcDb:AcDbObjects), including the ENDBLK example in section 20.4.7.1, chapter 28 (extended entity data) and chapter 29 (proxy entity graphics)