.DXF File Format – Objects

Common object group codes

These codes apply to almost every object and can appear with any object below. Some are written only when the object has a value other than the default. A dictionary’s record, including the named object dictionary’s, is just pairs of entry names and pointers to the entry objects. Developers should prefix their entry names with their registered developer prefix to avoid clashes.

ACAD_PROXY_OBJECT

A stand-in for an object whose application is not present. All codes are DXF codes. Code 92 is not used, and these objects never have graphics.

ACDBDICTIONARYWDFLT

A dictionary with a default entry.

ACDBPLACEHOLDER

DATATABLE

After the header, each column gives its type and name, and one value is written for every row in each column, using the code that fits the value.

DICTIONARY

AutoCAD keeps items such as multiline styles and group definitions as objects in dictionaries. Other applications may create and use their own dictionaries. The prefix ACAD_ is reserved for AutoCAD.

DICTIONARYVAR

AutoCAD uses DICTIONARYVAR objects to store named values for setvar and getvar without adding entries to the HEADER section. The system variables stored this way are DEFAULTVIEWCATEGORY, DIMADEC, DIMASSOC, DIMDSEP, DRAWORDERCTL, FIELDEVAL, HALOGAP, HIDETEXT, INDEXCTL, INTERSECTIONCOLOR, INTERSECTIONDISPLAY, MSOLESCALE, OBSCOLOR, OBSLTYPE, OLEFRAME, PROJECTNAME, SORTENTS, UPDATETHUMBNAIL and XCLIPFRAME.

DIMASSOC

A DIMASSOC object links a dimension to drawing geometry, so the dimension updates when the geometry changes (an associative dimension).

FIELD

GEODATA

Geographic location data for a drawing. Unit scales convert design coordinates to metres by multiplication.

GROUP

IDBUFFER

A utility object that is just a list of references to objects.

IMAGEDEF

IMAGEDEF_REACTOR

LAYER_FILTER

LAYER_INDEX

LAYOUT

A layout is a set of plot settings (the AcDbPlotSettings codes, listed under PLOTSETTINGS) followed by its own codes. Limits, insertion base and extents are those defined by LIMMIN, LIMMAX, INSBASE, EXTMIN and EXTMAX while the layout is current.

LIGHTLIST

MATERIAL

Colour values are unsigned 32-bit integers holding an AcCmEntityColor. Each map (diffuse, specular, reflection, opacity, bump, refraction) has the same set of settings: blend factor, source, file name, projection, tiling, auto transform and a transform matrix. The values the reference gives for them, written once here and used in the table below:

• Colour method (default 0): 0 use current colour; 1 override current colour.
• Map source (default 1): 0 use current scene; 1 use image file (named by the file name; an empty file name means no map).
• Projection method of the mapper (default 1): 1 planar; 2 box; 3 cylinder; 4 sphere.
• Tiling method of the mapper (default 1): 1 tile; 2 crop; 3 clamp.
• Auto transform method of the mapper (bit set, default 1): 1 no auto transform; 2 scale mapper to current entity extents and translate it to the entity origin; 4 include current block transform in mapper transform.
• Transform matrix: 16 reals in row-major order, default the identity matrix.

The reference lists the codes from 460 on by name only, with no values or defaults; several reuse codes from the first part of the object.

MLINESTYLE

Code 2 in MLINE entities and MLINESTYLE objects is a redundant copy of the style name. It is safe to read but should never be changed. To change the style, change the MLINE’s 340 group, which points to the right MLINESTYLE object, or the 3 group in the MLINESTYLE dictionary that comes before the 350 group holding the style’s handle.

OBJECT_PTR

PLOTSETTINGS

A named page setup. The same codes follow the AcDbPlotSettings marker in each LAYOUT. Margins, paper size and plot origin are in millimetres.

RASTERVARIABLES

RENDER

Three objects hold render settings.

MENTALRAYRENDERSETTINGS

RENDERENVIRONMENT

RENDERGLOBAL

SECTION objects

A section manager lists the section entities. Section settings hold, for each section type, nested type settings, which in turn hold geometry settings; string markers in groups 1, 2 and 3 open and close each part.

SECTIONMANAGER

SECTIONSETTINGS

Section type settings

Section geometry settings

SORTENTSTABLE

The DRAWORDER command attaches a SORTENTSTABLE to the extension dictionary of the *Model_Space or *Paper_Space block, under the name ACAD_SORTENTS. It gives each entity a different sort handle, which sets the order in which entities are regenerated. If the SORTENTS regen bit (16) is set, AutoCAD regenerates entities in ascending handle order.

SPATIAL_FILTER

SPATIAL_INDEX

SPATIAL_INDEX is always written empty to a DXF file and can be ignored.

SUNSTUDY

TABLESTYLE

Repeated for every cell

UNDERLAYDEFINITION

VBA_PROJECT

VISUALSTYLE

WIPEOUTVARIABLES

XRECORD

Xrecords store arbitrary data. They are made of ordinary object group codes (not extended data codes) from 1 to 369. They are like extended data but not limited in size or order. They do not disturb releases R13c0 to R13c3, but disappear if read into AutoCAD before R13c4.

  0
DICTIONARY
  5
2A
330
C
100
AcDbDictionary
280
0
281
1
  3
MYAPP_SETTINGS
350
2B
  0
XRECORD
  5
2B
102
{ACAD_REACTORS
330
2A
102
}
330
2A
100
AcDbXrecord
280
1
  1
Hello
 40
2.5

THUMBNAILIMAGE section

This section exists only if a preview image was saved with the DXF file.

Ownership and pointer references

Every database object has a handle that is unique in the drawing and constant for its lifetime (handles are always on since Release 13), and may have extended data, a persistent reactor table and an owner pointer to an extension dictionary. Symbol tables and their records are database objects too, so they have handles and can carry extended data and persistent reactors.

Objects refer to other objects in the same drawing through four kinds of reference handle, each with its own group code range:

• Pointer and owner handles are kept up to date in insert, xref and wblock: links between objects in the copied set are redirected to the copies, and links to other objects stay as they were.
• A pointer means the object uses another object and shares access to it, but does not possess it. An owner is responsible for the objects it has owner handles to, and ownership drives the writing of whole DWG and DXF files from a few root objects.
• An object can have any number of pointers to it but only one owner.
• Hard references, pointer or owner, protect an object from being purged; soft references do not. Choose the kind by whether the reference should protect the object from PURGE.
• In AutoCAD, block definitions and complex entities are hard owners of their elements; symbol tables and dictionaries are soft owners of theirs. Polylines hard-own their VERTEX and SEQEND entities; inserts hard-own their ATTRIB and SEQEND entities.
• Arbitrary handles are stored as handles, never turned into session identifiers or entity names, and are ignored when handles are translated in a merge. A common use is referring to objects in other DXF and DWG files. In every environment they can be exchanged for entity names of the current drawing with the handent functions.
• Extended data 1005 handles behave like soft pointers: they are translated when the host object is merged into another drawing, but stored as handles and not turned into entity names. In AutoLISP the other reference ranges appear as entity names, and in ObjectARX as ads_name values (APP only).

Subclass markers

An object may be filed by several class members, one for each level of inheritance that files data. Each class’s data starts with a subclass marker: group 100 followed by the class name. The marker does not change the object’s state; it lets a DXF parser route the groups that follow to the right software. Because each class has its own block, the same codes can mean different things in each. The reference’s example is an object FOOGRANDCHILD of class AcDbSonOfSonOfFoo, derived from AcDbSonOfFoo: after its handle come 100 AcDbFoo with a 10/20/30 point, 100 AcDbSonOfFoo with another 10/20/30 point for a different purpose, and 100 AcDbSonOfSonOfFoo with a third, then its extended data (1001 APP_1, 1070 45, 1001 APP_2, 1004 18A5B3EF2C199A).

Extension dictionaries and persistent reactors

Any object or entity may have either of these optional groups.

• The extension dictionary group (102 {ACAD_XDICTIONARY, a 360 hard owner handle, 102 }) stores the handle of a dictionary that belongs to the object. That dictionary may hold entries, so any database object can have other database objects attached to it.
• The persistent reactors group (102 {ACAD_REACTORS, 330 handles, 102 }) stores the handles of objects that have registered themselves as reactors on the object.

Extended data

Extended data (xdata) is created by AutoLISP or ObjectARX applications and follows an entity’s normal data. Unlike normal data, the same code may appear many times and order matters. It is grouped by registered application: each group starts with a 1001 group naming the application, which matches an APPID table entry. An application can use as many APPID names as it needs; they are permanent, but can be purged when unused. Each APPID can have at most one data group on each entity, and the application decides the order and meaning of the groups inside it. The reference’s example is an INSERT on layer TOP followed by 1001 AME_SOL data mixing 1002, 1070, 1071, 1010/1020/1030, 1005, 1040 and 1000 groups.

Not confirmed

The source text read cleanly. These values are not given in the reference and are left out:

• VISUALSTYLE code 70 (type): no values are listed.
• TABLESTYLE code 71 (flags), cell alignment (170), cell data type (90) and cell unit type (91): no bits or values are listed.
• SUNSTUDY code 70 (output type) and 74 (shade plot type): no values are listed.
• FIELD code 90 (data type of the field value): no values are listed.
• GEODATA codes 91 and 92: the UnitsValue enumeration is named but not listed.
• DIMASSOC codes 71, 73 and 74: only the meanings in brackets are given, not numbers.
• MATERIAL codes from 460 on, and the section objects’ type, flag and bit-flag codes: names only, with no values or defaults.
• PLOTSETTINGS codes 48 and 140 are both described as the X of the lower-left window corner, and 49 and 141 both as the Y of the upper-right corner; the reference does not say how the pairs differ.
• The reference’s common codes table says the {ACAD_XDICTIONARY group exists “only if persistent reactors have been attached”, repeating the reactors wording; this page gives it as optional.