DXF import and export
"DXF" in QET means two unrelated features that happen to share a file format:
| Direction | Where | How | |
|---|---|---|---|
| Export | folio → .dxf |
File → Export, alongside PDF/PNG/SVG | in-process, QET's own code |
| Import | .dxf → element geometry |
the element editor's Import a DXF file | shells out to a separate third-party program |
They don't round-trip each other and aren't part of the same code path. If you're looking for "import a DXF drawing as a folio", that isn't what either of these does — see §3.
Source: sources/createdxf.{cpp,h}, sources/dxfpaintdevice.{cpp,h},
sources/dxf/dxftoelmt.{cpp,h}.
1. Exporting a folio to DXF
File → Export, same dialog as PDF/PNG/SVG, one .dxf file per folio. The
border, title block and every diagram item on that folio are included.
There is no CLI verb for it. --export-pdf, --export-png and
--export-svg exist; DXF export is GUI-only today.
How it's rendered
Rather than a separate DXF-specific drawing pass, QET reuses the exact same
paint() code every element and shape already has for screen/PDF/PNG
rendering. A custom QPaintEngine (DxfPaintEngine) sits behind a
QPainter, intercepts the small set of drawing calls those paint()
methods actually make, and translates each into a DXF entity instead of
pixels. That's a deliberate design choice: an item's rendering code is
"already correct" for every other export, so DXF export can't drift out of
sync with what you see on screen — it draws the same calls, just recorded
differently.
What that costs — real fidelity limits
The DXF dialect targeted (AC1006) and the deliberately narrow set of translated calls mean some things don't come across:
| QET drawing call | DXF result |
|---|---|
| Lines | LINE |
| Rectangles | LWPOLYLINE outline — no fill, even if the rectangle is filled on screen (this DXF dialect has no filled-rectangle primitive) |
| Ellipses/circles | CIRCLE or a full-sweep arc |
| Arcs | a sequence of straight LINE chords, not a true DXF arc entity |
| Polygons | LWPOLYLINE |
| Text | TEXT |
| Filled paths | outline only, same as rectangles — no HATCH |
| Images / pixmaps | not exported. DXF has no raster-image entity in this dialect; a placeholder rectangle is drawn in the image's position, size and rotation instead, so layout is preserved but the picture itself is not |
Anything outside this list (gradients and similar) is not silently dropped — it logs a warning, on the principle that a caller should find out immediately that something wasn't exportable rather than get a DXF file quietly missing content.
If your drawing relies on filled shapes, hatching, or embedded images surviving into DXF, they won't — plan around outlines and text.
2. Importing a DXF into an element
This is a symbol-authoring tool, found in the element editor
(File → Import a DXF file), not the diagram/folio editor. It reads
geometry out of a .dxf and adds it as drawing primitives to the element you
currently have open — a way to trace or reuse CAD line art when drawing a new
symbol, not a way to bring a DXF schematic into a project.
It needs a separate program
Unlike export, import is not built into QET. It shells out to
dxf2elmt, a third-party console tool
(Vadoola/dxf2elmt) that QET
looks for next to itself (<data dir>/binary/dxf2elmt, or .exe on Windows).
If it isn't found, QET shows a dialog with the download link and the folder
to unzip it into, rather than failing silently — the same pattern as
qet_tb_generator for terminal block generation (see
Automating QElectroTech).
QET runs it as dxf2elmt <file> -v, reads its stdout as the resulting
.elmt XML, and pushes it onto the element editor's undo stack as one
operation. On a large DXF, a warning dialog tells you the import may take a
while before it starts.
Since dxf2elmt is a separate project, its own interpretation of DXF
entities — what maps to what, and its own limitations — lives with that
project, not with QET.
3. What neither of these is
- Not a way to place a DXF drawing on a folio as-is. Import only feeds the element editor.
- Not round-trip safe. Export's outline-only, no-image limitations (§1)
mean a
.dxfwritten by QET is not a faithful source to import back, even setting aside that import and export use entirely different code. - Not a general CAD interchange path, in the sense of preserving layers, blocks, or DXF metadata beyond raw geometry — both directions work at the level of individual drawing primitives.
See also: Automating QElectroTech · Linking elements
Getting Started
🌐 Languages — English · Français · Deutsch
Guides
Conductors — wire properties, what feeds which export, and cables
Wire & cable catalogue — cable types, IEC 60757 core colours, assigning a core to a conductor
Printing and exporting — paper, PDF, images, and what each path does differently
Linking elements — master, slave, terminal
PLC modules — I/O tables and linking a wire to a specific point
Using the element editor — drawing tools, saving, checks
Preferences reference — what each settings page does
Keyboard-only control — mouseless QET, and the one real gap
Mouse modifiers — what Shift, Ctrl and Alt change while you drag
Managing collections — folders, writability, building your own shortlist
Templates — reusable multi-element blocks, and why clicking one does nothing
Search & Replace — bulk property changes
Building a nomenclature query — the BOM/summary table builder
Linking wires across pages — folio reports
Variables & formulas — %f, %{label}, sequences
Auto-numbering — schemes, sequences, freezing
Terminal strips — strips, levels, bridges
Title block templates — the .titleblock format
Importing EPLAN parts (.edz) — EPLAN Data Portal
DXF import & export — two unrelated features, one format
The project database — the in-memory SQLite cache
Development
Automating QET — CLI, XML formats, external tools
CLI Reference — command line usage
JavaScript Scripting — --run, geometry editing, undo
Vision — proposal, under discussion
