eTransmit — Create eTransmit packages (zipped transmittal) for sharing

Historical Context & Motivation

Sharing CAD drawings has never been as simple as copying a single file. Unlike a self-contained document such as a PDF, an AutoCAD DWG file can reference dozens of external resources — fonts, images, externally referenced drawings (xrefs), plot style tables, and custom line-type definitions — all of which reside in separate locations on the originator's machine. When a recipient opens a DWG without these dependencies, the drawing renders incorrectly: hatches disappear, fonts substitute to defaults, and xref paths resolve to nothing. The problem is analogous to shipping a compiled binary without its shared libraries; the executable is present, but it cannot run.

Throughout the 1990s, firms manually assembled transmittal packages by hunting down every referenced file, copying them into a directory, and compressing the result. This was error-prone and time-consuming, particularly on large projects with nested xrefs three or four levels deep. Autodesk recognized this workflow bottleneck and introduced eTransmit as a built-in utility to automate dependency resolution, path remapping, and archive creation in a single operation.

The central question eTransmit addresses is fundamentally one of dependency resolution and path portability — how do you guarantee that every resource a drawing needs is present and correctly referenced when it lands on a different file system? This is the same class of problem that package managers solve in software engineering, and understanding eTransmit through that lens will deepen your appreciation of its design.

Core Principles & Definitions

Before diving into the mechanics of eTransmit, it is important to establish the foundational concepts that govern how AutoCAD drawings reference external resources and how eTransmit resolves those references into a portable archive. The utility operates on a dependency graph rooted at the DWG file you choose to transmit, recursively traversing every external reference until the full closure of required files is identified. Think of it as a depth-first search on a file-dependency DAG (directed acyclic graph) — a concept familiar from build systems like Make or package managers like npm.

Visual Explanation — eTransmit Workflow

As the diagram illustrates, the eTransmit engine operates as a pipeline. It begins by parsing the dependency graph rooted at the selected DWG file. Each node in the graph — whether an xref, a raster image attachment, a shape font, or a plot configuration table — is resolved to its absolute path on disk, verified for existence, and queued for inclusion. Nested xrefs trigger recursive traversal, ensuring that even deeply nested references (an xref within an xref within an xref) are captured. After dependency collection, the engine performs path remapping — rewriting saved paths inside each DWG so they reference the flattened or reorganized directory structure within the archive rather than the originator's file system. Finally, the collected files and the auto-generated transmittal report are compressed into the configured output format.

How eTransmit Works — Internal Mechanism

Understanding eTransmit's internals is best framed in terms of graph theory and file-system operations, concepts that map directly to your computer science coursework. The mechanism comprises four discrete phases: graph construction, closure computation, path normalization, and archive serialization.

Phase 1 — Dependency Graph Construction

AutoCAD stores references to external files in specific database objects within the DWG: the XREF table, IMAGE dictionary, STYLE table (for fonts), and PLOTSETTINGS objects. eTransmit reads these tables and constructs a directed graph G = (V, E), where each vertex v ∈ V represents a file and each directed edge (u, v) indicates that file u depends on file v. Because circular xrefs are not permitted in AutoCAD, this graph is guaranteed to be a directed acyclic graph (DAG), which means standard topological traversal algorithms apply.

Phase 2 — Transitive Closure

The set of files to include is the transitive closure of the root drawing's dependency set. Formally, if R(f) denotes the direct references of file f, then the transmittal set T is defined recursively as T = {root} ∪ ⋃_{f ∈ T} R(f). In practice, eTransmit performs a DFS or BFS traversal starting from the root node, marking each visited vertex. The traversal's time complexity is O(|V| + |E|), which is efficient even for large projects with hundreds of xrefs.

Phase 3 — Path Normalization

Once the file set is determined, eTransmit must rewrite the saved paths in each DWG so they resolve correctly within the archive. There are three path-organization strategies available in a transmittal setup. Use organized folder structure preserves the relative directory hierarchy as it exists on the source machine. Place all files in one folder flattens everything into a single directory, which simplifies extraction but can cause name collisions if two files in different directories share a name. Keep files and folders as is retains absolute paths — useful only when the recipient has an identical directory structure.

Phase 4 — Archive Serialization

Finally, the collected and path-remapped files are serialized into the chosen format (ZIP, self-extracting EXE, or folder). A transmittal report — either plain text or HTML — is generated to document the package contents, acting as the metadata layer. This report includes file names, sizes, originating paths, and any notes the sender appended, providing an audit trail that is invaluable in regulated industries such as architecture, engineering, and construction (AEC).

Detailed Breakdown — Included File Types & Options

eTransmit does not blindly package every file on disk; it selectively includes files based on the dependency analysis and user-configurable options. Understanding which file types are captured and how the transmittal setup options modify that behavior is critical for producing lean, correct packages. The table below categorizes every file type eTransmit can detect and whether its inclusion is automatic or opt-in.

Worked Example — Packaging a Multi-Discipline Project

Consider a scenario where you are a CAD manager responsible for delivering a complete set of construction documents to a client. The project consists of a main architectural drawing that xrefs a structural framing plan, which in turn xrefs a foundation detail. The architectural drawing also attaches a company logo as a raster image and uses a custom SHX font for the title block. All layouts reference a color-dependent plot style table (CTB). Your goal is to create a ZIP archive that the client can extract and open without any missing references.

eTransmit vs. Alternative Sharing Methods

eTransmit is not the only way to share AutoCAD drawings. Understanding when to use it versus alternatives such as manual packaging, Publish to DWF/PDF, or cloud-based collaboration platforms is essential for choosing the right tool for a given context. The comparison below evaluates each method across key criteria relevant to professional workflows.

Connection to Advanced Workflows

eTransmit represents one node in a broader ecosystem of output and collaboration workflows in AutoCAD. As projects grow in complexity — particularly in BIM-adjacent environments where AutoCAD drawings feed into Revit models or Navisworks coordination sets — the principles underlying eTransmit extend into more sophisticated systems. Understanding these connections prepares you for enterprise-level CAD management.

For those interested in automation, the ETRANSMIT command can be invoked from within AutoLISP scripts or command-line script files (.scr), enabling batch processing of multiple drawings. In enterprise environments, CAD managers often write Python scripts leveraging the Autodesk Platform Services (formerly Forge) Design Automation API to run eTransmit headlessly in the cloud, packaging drawings as part of a CI/CD pipeline — a concept that should resonate strongly with your software engineering background. The underlying principle remains the same: resolve dependencies, remap paths, and produce a portable artifact.

Practice Problems

Lesson Summary