Repository navigation
dxf DE
„DXF" bedeutet in QET zwei unabhängige Funktionen, die sich lediglich ein Dateiformat teilen:
| Richtung | Wo | Wie | |
|---|---|---|---|
| Export | Folio → .dxf
|
Datei → Export, neben PDF/PNG/SVG | intern, eigener QET-Code |
| Import |
.dxf → Elementgeometrie |
der Element-Editor, DXF-Datei importieren | ruft ein separates Drittprogramm auf |
Sie sind keine Umkehrung voneinander und teilen keinen Code. Wer „ein DXF-Zeichnung als Folio importieren" sucht, findet das in keinem von beiden — siehe §3.
Quellen: sources/createdxf.{cpp,h}, sources/dxfpaintdevice.{cpp,h},
sources/dxf/dxftoelmt.{cpp,h}.
Datei → Export, derselbe Dialog wie für PDF/PNG/SVG, eine .dxf-Datei je
Folio. Rahmen, Schriftfeld und jedes Objekt des Folios sind enthalten.
Dafür gibt es kein Kommandozeilen-Verb. --export-pdf, --export-png
und --export-svg existieren; der DXF-Export ist heute auf die Oberfläche
beschränkt.
Statt eines eigenen DXF-Zeichendurchlaufs nutzt QET genau denselben
paint()-Code, den jedes Element und jede Form bereits für die Darstellung
auf dem Bildschirm, in PDF oder PNG besitzt. Eine eigens gebaute
QPaintEngine (DxfPaintEngine) sitzt hinter einem QPainter, fängt den
kleinen Satz an Zeichenaufrufen ab, den diese paint()-Methoden tatsächlich
tätigen, und übersetzt jeden davon in eine DXF-Entität statt in Pixel. Das ist
eine bewusste Entwurfsentscheidung: Der Rendering-Code eines Objekts ist für
jeden anderen Export „bereits korrekt", der DXF-Export kann also nicht von dem
abweichen, was auf dem Bildschirm zu sehen ist — er führt dieselben Aufrufe
aus, nur anders protokolliert.
Der angesteuerte DXF-Dialekt (AC1006) und die bewusst schmale Menge übersetzter Aufrufe bedeuten, dass manches nicht ankommt:
| QET-Zeichenaufruf | DXF-Ergebnis |
|---|---|
| Linien | LINE |
| Rechtecke |
LWPOLYLINE-Umriss — keine Füllung, selbst wenn das Rechteck am Bildschirm gefüllt ist (dieser DXF-Dialekt kennt keine Primitive für gefüllte Rechtecke) |
| Ellipsen/Kreise |
CIRCLE oder ein Vollkreisbogen |
| Bögen | eine Folge gerader LINE-Sehnen, keine echte DXF-Bogenentität |
| Vielecke | LWPOLYLINE |
| Text | TEXT |
| Gefüllte Pfade | nur Umriss, wie bei Rechtecken — kein HATCH
|
| Bilder / Pixmaps | werden nicht exportiert. DXF kennt in diesem Dialekt keine Rasterbild-Entität; stattdessen wird ein Platzhalterrechteck an Position, Größe und Drehung des Bildes gezeichnet — das Layout bleibt erhalten, das Bild selbst aber nicht |
Was außerhalb dieser Liste liegt (Verläufe und Ähnliches) wird nicht stillschweigend verworfen — eine Warnung wird protokolliert, nach dem Grundsatz, dass ein Aufrufer sofort erfahren soll, dass etwas nicht exportierbar war, statt eine DXF-Datei zu erhalten, der still etwas fehlt.
Wer sich auf gefüllte Formen, Schraffuren oder eingebettete Bilder im DXF verlässt, wird enttäuscht — planen Sie mit Umrissen und Text.
Das ist ein Werkzeug zur Symbolerstellung, zu finden im
Element-Editor (Datei → DXF-Datei importieren), nicht im
Folio-/Schaltplan-Editor. Es liest Geometrie aus einer .dxf und fügt sie als
Zeichenprimitive dem gerade geöffneten Element hinzu — eine Möglichkeit,
CAD-Strichzeichnungen beim Entwurf eines neuen Symbols nachzuzeichnen oder
weiterzuverwenden, kein Weg, einen DXF-Schaltplan in ein Projekt zu holen.
Anders als der Export ist der Import nicht in QET eingebaut. Er ruft
dxf2elmt auf, ein Drittanbieter-Konsolenwerkzeug
(Vadoola/dxf2elmt), das QET
neben sich selbst sucht (<Datenverzeichnis>/binary/dxf2elmt, unter Windows
.exe). Wird es nicht gefunden, zeigt QET einen Dialog mit dem Download-Link
und dem Ordner, in den es entpackt werden soll, statt still zu scheitern —
dasselbe Muster wie bei qet_tb_generator für die Klemmenleistenerstellung
(siehe QElectroTech automatisieren).
QET startet es als dxf2elmt <Datei> -v, liest dessen Standardausgabe als das
resultierende .elmt-XML und legt es als eine Operation auf den
Rückgängig-Stapel des Element-Editors. Bei einer großen DXF-Datei weist ein
Warndialog darauf hin, dass der Import eine Weile dauern kann, bevor er
beginnt.
Da dxf2elmt ein eigenständiges Projekt ist, liegt seine eigene Auslegung von
DXF-Entitäten — was worauf abgebildet wird, und seine eigenen Grenzen — bei
diesem Projekt, nicht bei QET.
- Kein Weg, eine DXF-Zeichnung unverändert auf einem Folio zu platzieren. Der Import speist nur den Element-Editor.
-
Nicht rundreisesicher. Die Grenzen des Exports — nur Umrisse, keine
Bilder (§1) — machen ein von QET geschriebenes
.dxfzu keiner verlässlichen Quelle für einen erneuten Import, unabhängig davon, dass Import und Export ohnehin völlig unterschiedlichen Code verwenden. - Kein allgemeiner CAD-Austauschweg im Sinne des Erhalts von Ebenen, Blöcken oder DXF-Metadaten über die reine Geometrie hinaus — beide Richtungen arbeiten auf der Ebene einzelner Zeichenprimitive.
Siehe auch: QElectroTech automatisieren · Elemente verknüpfen
