# SUBSYSTEM OVERVIEW

DXF Interface (DXFI) Subsystem

The DXFI subsystem is the top level subsystem in the DXF interface. The DXFI subsystem provides DXF schema dependent functions for accessing DXF data stored in a file or in a model. The reader should be familiar with the mda and ddf subsystems (see mda_intro and ddf_intro) before reading this manual page.

# GENERAL CONCEPTS

The DXF interface consists of the DXFI DDF and several subsystems. Each subsystem has four characters, the first of which is "d". The function dxfi_Initialize must be called once, before any other DXF interface function. The call to dxfi_Initialize must follow the pdx_Initialize call. Once processing is complete, the function dxfi_Terminate should be called prior to calling pdx_Terminate.

# CREATING A DXF MODEL

To create a DXF model, the following code sequence is used:

    #include "ddf_Interface.h"
    #include "mda_Interface.h"
    #include "dxfi_Interface.h"
    MDA_MODEL_INFO mod_info;
    int model;
          .
    pdx_Initialize( PDX_NOOPT );
    dxfi_Initialize( DXFI_NOOPT );
          .
    mda_GetModelDefaults( MDA_NOOPT, &mod_info );
    dxfi_InitModelInfo( DXFI_NOOPT, &mod_info );
          .
    /* Other mod_info fields set  */
          .
    mda_AllocateModel( MDA_NOOPT, &mod_info, &model );

The model is now ready to receive DXF entities. The model can be populated with the contents of an ASCII DXF file by calling mda_ParseFile. The contents of a model can be written with a call to mda_FormatFile. The mda_intro pages describe how additional entities are added to a model.

For options specific to parsing and formatting, see dxfi_ParseFile and dxfi_FormatFile.

# DXF VERSIONS

Support exists for DXF versions ten through fourteen. Parsing of different versions of these files is automatically determined by the parser. The formatter, however, will always format DXF models compliant to the revision fourteen rules unless dxfi_SetFileVersion is called to alter the version of the current DXF model. See the dxfi_SetFileVersion manual page for additional information.

By calling dxfi_SetFileVersion, it is easy to convert between differing DXF file revisions. Because the different revisions vary in their entity support capabilities, data may be lost when formatting a DXF file with a lower revision number than that of an existing model. Differences between revisions 10-12 are minute and should not cause problems when exchanging versions. Changes between versions 12 and 13, however, are more substantial. Consequently, if a version thirteen model is formatted as a version twelve file, entities not supported by version twelve will be omitted and a warning message will be issued. Conversion from version twelve to version thirteen will result in the additional creation of handles and default instances of all tables (as necessary) required of a version thirteen file.

# EXTENDED ENTITY DATA

Extended entity data is supported through the subentity, dxfxed (see dxfi.ddf). This subentity is included in all type-forms within the ddf except for the 1:0 (System Variables) and 700:0 (View Port entity).

The fields within dxfxed are organized so that collections of data are stored with their respective group codes for each application.

Since DXF tables may have extended data on each entry as well as the table as a whole, the table_entry field can be used to associate specific extended data to the corresponding table entry. For example, if table_entry is set to two, the extended entity data will be associated with the second entry within the corresponding table. If extended entity data exists for the table as a whole, table_entry should be zero.

The table_entry field should be set to zero if the corresponding entity is not a table.

# ENTITY HEADER DATA

A dxfhdr sub_entity structure is defined in the dxfi.ddf and included in most DXF entities with the purpose of defining attributes that are common to most entity types. The fields within this structure are as follows:

line_type

A fixed length character string representing the name of a linetype associated with an entity. This could be set to BYLAYER or BYBLOCK indicating that the entity's line_type is determined by its layer or by its block.

lay_name

A fixed length character string representing the name of a layer that is associated with an entity.

elevation

Elevation or magnitude of translation along the extrusion vector.

thickness

Entity thickness or magnitude of extrusion along the extrusion vector.

ltype_scale

The linetype scale.

color

A color number. If the value is zero, it indicates that the entity color is determined BYBLOCK. If the value is 256, it indicates that the color is determined BYLAYER.

space

A flag indicating whether the entity is in model space or paper space. 0 indicates model space. 1 indicates paper space.

visibility

A flag indicating whether the entity is visible. 0 indicates that the object is visible. 1 indicates that the object is invisible.

extrusion

A unitized extrusion direction vector.

block_flag

Flag indicating whether or not the entity is constituent to a block. 0 indicates independence. 1 indicates dependence to a block. NOTE: This field is not part of the definition of DXF. It is a PDElib internal field.

# ENTITY SUBHEADER DATA

A dxfsubhdr sub_entity structure is also defined in the dxfi.ddf and included in ALL DXF entities with the purpose of defining attributes that are common to all entity types. The fields within this structure are as follows:

handle

The handle field is a character string hexadecimal representation of the entity's handle. This field will be set from dxfi_ParseFile only if handles exist in the input file. It will otherwise be initialized to a null string.

line_num

The line number from the file (after parsing a DXF model) at which the entity begins. NOTE: This field is not part of the definition of DXF. It is a PDElib field.

# DXF POLYLINE TYPEFORMS

DXF polylines can represent many different geometric curves and surfaces with the same generic structural definition. In order to ease entity mapping processes involving polyline geometries, the dxfi.ddf has defined several separate polyline typeforms. The DXF parser transparently maps a polyline within a DXF file into the appropriate typeform. The DXF formatter automatically performs the converse operation. When creating new polyline entities, it is important to select the typeform that best suits the surface or curve's geometric purpose. Please see the dxfi.ddf for information on how the typeforms are broken down and how the parser and formatter determine the typeform mappings.

# PARSING AND FORMATTING OF DWG FILES

PDElib supports parsing and formatting of DWG files as an optional library package. DWG files are treated for the most part the same as ASCII DXF files and utilize the same dxfi.ddf. dxfi_ParseFile automatically detects whether a specified file is DWG or DXF ASCII and populates the specified DXF model with the data parsed from that file. dxfi_FormatFile will format the DXF model as a DWG file only if dxfi_SetFileType is called to change the model's preferred file type to PDX_DWG. The DWG parser supports DWG versions ten through fourteen. The parser automatically reads any supported version. The version to be formatted can be specified by calling dxfi_SetFileVersion.

The line_num field is initialized to zero for entities parsed from a DWG model.

# LIMITATIONS

The following restrictions apply to the DXFI and related subsystems:

•

Entity definitions for the 3Dsolid, Body, and Region entities exist within the dxfi.ddf, but contain no usable data.

•

The DXFI_ORIGHANDLES option's intended use is only that of debugging. It should not be used for routine formatting of DXF models. It may not set the handseed with correct values. No checks are made for handle accuracy or uniqeness when this option is used.