mirror of
https://github.com/qelectrotech/qelectrotech-source-mirror.git
synced 2026-09-20 15:24:14 +02:00
Document DXF: two unrelated features reduced to one bullet each
sources/createdxf.*, sources/dxfpaintdevice.*, sources/dxf/dxftoelmt.* total ~1,780 lines. The only wiki coverage was a single repeated bullet -- 'DXF -- CAD format for collaboration' -- across features, faq and user_manual, in all three languages, describing neither direction accurately: it reads as one feature, and it's actually two that share nothing but a file extension. Export (File -> Export, alongside PDF/PNG/SVG, in-process) reuses every item's existing paint() code through a custom QPaintEngine (DxfPaintEngine) rather than a separate DXF renderer -- documented from that class's own thorough header comment, including the real fidelity table it specifies: rectangles and filled paths lose their fill (no HATCH primitive in this DXF dialect), arcs become straight-line chords, and images become position-preserving placeholder rectangles since DXF has no raster entity here. No CLI verb exists for it, unlike PDF/PNG/SVG. Import (element editor only, not the diagram editor -- File -> Import a DXF file) is a symbol-authoring tool: it shells out to dxf2elmt, a separate third-party program QET does not bundle, the same external-tool pattern as qet_tb_generator already documented in api_reference. Traces the actual call: , stdout read as .elmt XML, pushed onto the element editor's undo stack as one operation. Makes explicit what neither direction is: not a way to place a DXF drawing on a folio, not round-trip safe (export's own limitations rule that out before even considering the code is entirely separate), and not a full CAD interchange path -- no layers, blocks or metadata, just primitives. Links the existing one-line mentions in features/faq/user_manual (all three languages) to the new page instead of rewriting them, since they are fine as list bullets. EN/FR/DE.
ispyisail
+2
@@ -34,6 +34,8 @@
|
||||
|
||||
**[Importing EPLAN parts (.edz)](edz_import)** — EPLAN Data Portal
|
||||
|
||||
**[DXF import & export](dxf)** — two unrelated features, one format
|
||||
|
||||
**[The project database](project_database)** — the in-memory SQLite cache
|
||||
|
||||
</details>
|
||||
|
||||
+115
@@ -0,0 +1,115 @@
|
||||
# DXF-Import und -Export
|
||||
|
||||
„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}`.
|
||||
|
||||
---
|
||||
|
||||
## 1. Ein Folio nach DXF exportieren
|
||||
|
||||
*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.
|
||||
|
||||
### Wie gerendert wird
|
||||
|
||||
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.
|
||||
|
||||
### Was das kostet — echte Grenzen der Genauigkeit
|
||||
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
## 2. Eine DXF-Datei in ein Element importieren
|
||||
|
||||
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.
|
||||
|
||||
### Dafür braucht es ein separates Programm
|
||||
|
||||
Anders als der Export ist der Import **nicht in QET eingebaut**. Er ruft
|
||||
**`dxf2elmt`** auf, ein Drittanbieter-Konsolenwerkzeug
|
||||
([Vadoola/dxf2elmt](https://github.com/Vadoola/dxf2elmt/releases)), 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](api_reference-DE)**).
|
||||
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
## 3. Was keins von beiden ist
|
||||
|
||||
- **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 `.dxf` zu 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](api_reference-DE)** ·
|
||||
**[Elemente verknüpfen](element_linking-DE)**
|
||||
+116
@@ -0,0 +1,116 @@
|
||||
# Import et export DXF
|
||||
|
||||
Le « DXF » de QET recouvre deux fonctions **sans rapport** qui partagent
|
||||
simplement un format de fichier :
|
||||
|
||||
| | Sens | Où | Comment |
|
||||
|---|---|---|---|
|
||||
| **Export** | folio → `.dxf` | *Fichier → Exporter*, aux côtés de PDF/PNG/SVG | en interne, code propre à QET |
|
||||
| **Import** | `.dxf` → géométrie d'élément | l'**éditeur d'élément**, *Importer un fichier DXF* | appelle un programme tiers séparé |
|
||||
|
||||
Elles ne font pas l'aller-retour l'une vers l'autre et ne partagent aucun code.
|
||||
Si vous cherchez « importer un dessin DXF comme folio », ce n'est ni l'une ni
|
||||
l'autre — voir §3.
|
||||
|
||||
Sources : `sources/createdxf.{cpp,h}`, `sources/dxfpaintdevice.{cpp,h}`,
|
||||
`sources/dxf/dxftoelmt.{cpp,h}`.
|
||||
|
||||
---
|
||||
|
||||
## 1. Exporter un folio en DXF
|
||||
|
||||
*Fichier → Exporter*, même dialogue que PDF/PNG/SVG, un fichier `.dxf` par
|
||||
folio. Le cadre, le cartouche et chaque objet du folio sont inclus.
|
||||
|
||||
**Il n'existe aucun verbe en ligne de commande pour cela.** `--export-pdf`,
|
||||
`--export-png` et `--export-svg` existent ; l'export DXF est aujourd'hui
|
||||
réservé à l'interface graphique.
|
||||
|
||||
### Comment c'est rendu
|
||||
|
||||
Plutôt qu'une passe de dessin spécifique au DXF, QET réutilise exactement le
|
||||
même code `paint()` que chaque élément et chaque forme possède déjà pour le
|
||||
rendu à l'écran, en PDF ou en PNG. Un `QPaintEngine` sur mesure
|
||||
(`DxfPaintEngine`) se place derrière un `QPainter`, intercepte le petit
|
||||
ensemble d'appels de dessin que ces méthodes `paint()` font réellement, et
|
||||
traduit chacun en une entité DXF au lieu de pixels. C'est un choix de
|
||||
conception délibéré : le code de rendu d'un objet est « déjà correct » pour
|
||||
tous les autres exports, l'export DXF ne peut donc pas diverger de ce que vous
|
||||
voyez à l'écran — il exécute les mêmes appels, simplement enregistrés
|
||||
autrement.
|
||||
|
||||
### Ce que cela coûte — de vraies limites de fidélité
|
||||
|
||||
Le dialecte DXF ciblé (AC1006) et l'ensemble volontairement restreint d'appels
|
||||
traduits font que certaines choses ne passent pas :
|
||||
|
||||
| Appel de dessin QET | Résultat DXF |
|
||||
|---|---|
|
||||
| Lignes | `LINE` |
|
||||
| Rectangles | contour `LWPOLYLINE` — **aucun remplissage**, même si le rectangle est rempli à l'écran (ce dialecte DXF n'a pas de primitive de rectangle rempli) |
|
||||
| Ellipses/cercles | `CIRCLE` ou un arc à balayage complet |
|
||||
| Arcs | une suite de cordes `LINE` droites, pas une véritable entité d'arc DXF |
|
||||
| Polygones | `LWPOLYLINE` |
|
||||
| Texte | `TEXT` |
|
||||
| Chemins remplis | contour seul, comme les rectangles — pas de `HATCH` |
|
||||
| **Images / pixmaps** | **non exportées.** Le DXF n'a pas d'entité d'image matricielle dans ce dialecte ; un rectangle de substitution est dessiné à la position, taille et rotation de l'image, la mise en page est donc préservée mais pas l'image elle-même |
|
||||
|
||||
Ce qui sort de cette liste (dégradés et similaires) **n'est pas
|
||||
silencieusement abandonné** — un avertissement est journalisé, selon le
|
||||
principe qu'un appelant doit savoir immédiatement que quelque chose n'était
|
||||
pas exportable plutôt que d'obtenir un fichier DXF amputé sans le savoir.
|
||||
|
||||
Si votre dessin repose sur des formes remplies, des hachures ou des images
|
||||
intégrées survivant dans le DXF, ce ne sera pas le cas — prévoyez plutôt des
|
||||
contours et du texte.
|
||||
|
||||
---
|
||||
|
||||
## 2. Importer un DXF dans un élément
|
||||
|
||||
C'est un outil de **création de symbole**, situé dans l'**éditeur
|
||||
d'élément** (*Fichier → Importer un fichier DXF*), pas dans l'éditeur de
|
||||
folio/schéma. Il lit la géométrie d'un `.dxf` et l'ajoute comme primitives de
|
||||
dessin à l'élément actuellement ouvert — une façon de calquer ou de réutiliser
|
||||
un tracé CAO en dessinant un nouveau symbole, pas un moyen d'introduire un
|
||||
schéma DXF dans un projet.
|
||||
|
||||
### Cela nécessite un programme séparé
|
||||
|
||||
Contrairement à l'export, l'import n'est **pas intégré à QET**. Il appelle
|
||||
**`dxf2elmt`**, un outil console tiers
|
||||
([Vadoola/dxf2elmt](https://github.com/Vadoola/dxf2elmt/releases)) que QET
|
||||
recherche à côté de lui-même (`<dossier de données>/binary/dxf2elmt`, ou
|
||||
`.exe` sous Windows). S'il est introuvable, QET affiche un dialogue avec le
|
||||
lien de téléchargement et le dossier où le dézipper, plutôt que d'échouer
|
||||
silencieusement — le même principe que `qet_tb_generator` pour la création de
|
||||
borniers (voir **[Automatiser QElectroTech](api_reference-FR)**).
|
||||
|
||||
QET le lance sous la forme `dxf2elmt <fichier> -v`, lit sa sortie standard
|
||||
comme le XML `.elmt` résultant, et l'empile sur la pile d'annulation de
|
||||
l'éditeur d'élément comme une seule opération. Sur un DXF volumineux, un
|
||||
dialogue d'avertissement prévient que l'import peut prendre du temps avant de
|
||||
démarrer.
|
||||
|
||||
`dxf2elmt` étant un projet séparé, sa propre interprétation des entités
|
||||
DXF — ce qui correspond à quoi, et ses propres limites — relève de ce projet,
|
||||
pas de QET.
|
||||
|
||||
---
|
||||
|
||||
## 3. Ce que ni l'un ni l'autre n'est
|
||||
|
||||
- **Pas un moyen de placer un dessin DXF sur un folio tel quel.** L'import
|
||||
n'alimente que l'éditeur d'élément.
|
||||
- **Pas garanti pour l'aller-retour.** Les limites de l'export — contours
|
||||
seuls, pas d'images (§1) — font qu'un `.dxf` écrit par QET n'est pas une
|
||||
source fidèle à réimporter, indépendamment même du fait que l'import et
|
||||
l'export utilisent des codes entièrement différents.
|
||||
- **Pas un chemin d'échange CAO général**, au sens de la préservation des
|
||||
calques, des blocs ou des métadonnées DXF au-delà de la géométrie brute :
|
||||
les deux sens travaillent au niveau des primitives de dessin individuelles.
|
||||
|
||||
---
|
||||
|
||||
Voir aussi : **[Automatiser QElectroTech](api_reference-FR)** ·
|
||||
**[Lier des éléments](element_linking-FR)**
|
||||
+110
@@ -0,0 +1,110 @@
|
||||
# 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](https://github.com/Vadoola/dxf2elmt/releases)) 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](api_reference)**).
|
||||
|
||||
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 `.dxf` written 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](api_reference)** ·
|
||||
**[Linking elements](element_linking)**
|
||||
+1
-1
@@ -135,7 +135,7 @@ See **[User Manual → Export & Printing](user_manual#export--printing)** for ex
|
||||
- **PDF** — Best for sharing/printing
|
||||
- **PNG** — Image format for web/documents
|
||||
- **SVG** — Vector format, editable
|
||||
- **DXF** — CAD format
|
||||
- **[DXF](dxf)** — CAD format (see the page for fidelity limits)
|
||||
3. Choose location and filename
|
||||
4. Click Export
|
||||
|
||||
|
||||
+1
-1
@@ -138,7 +138,7 @@ Alles, was Sie mit QElectroTech tun können — ein leistungsstarkes, kostenlose
|
||||
- **PDF** — Professionelle Dokumente zum Teilen, Archivieren, Drucken
|
||||
- **SVG** — Vektorformat, in anderen Designwerkzeugen editierbar
|
||||
- **PNG/JPG/BMP** — Rasterformate für Web und Dokumente
|
||||
- **DXF** — CAD-Format für Zusammenarbeit mit CAD-Tools
|
||||
- **[DXF](dxf-DE)** — CAD-Format für Zusammenarbeit mit CAD-Tools (Export, und separater DXF-zu-Symbol-Import)
|
||||
- **Mehrere gleichzeitige Projekte** — Mit mehreren Dateien gleichzeitig arbeiten
|
||||
|
||||
### Professioneller Druck
|
||||
|
||||
+1
-1
@@ -138,7 +138,7 @@ Au-delà des schémas électriques, QET gère :
|
||||
- **PDF** — Documents professionnels pour partager, archiver, imprimer
|
||||
- **SVG** — Format vectoriel, éditable dans d'autres outils de conception
|
||||
- **PNG/JPG/BMP** — Formats raster pour le web et les documents
|
||||
- **DXF** — Format CAO pour la collaboration avec les outils CAO
|
||||
- **[DXF](dxf-FR)** — Format CAO pour la collaboration avec les outils CAO (export, et import DXF vers symbole séparé)
|
||||
- **Projets multiples simultanés** — Travailler avec plusieurs fichiers à la fois
|
||||
|
||||
### Impression Professionnelle
|
||||
|
||||
+1
-1
@@ -138,7 +138,7 @@ Beyond electrical diagrams, QET handles:
|
||||
- **PDF** — Professional documents for sharing, archiving, printing
|
||||
- **SVG** — Vector format, editable in other design tools
|
||||
- **PNG/JPG/BMP** — Raster formats for web and documents
|
||||
- **DXF** — CAD format for collaboration with CAD tools
|
||||
- **[DXF](dxf)** — CAD format for collaboration with CAD tools (export, and separate DXF-to-symbol import)
|
||||
- **Multiple simultaneous projects** — Work with several files at once
|
||||
|
||||
### Professional Printing
|
||||
|
||||
+1
@@ -65,6 +65,7 @@ Beginnen Sie mit der deutschen Version dieses Wikis:
|
||||
| Title block templates | ✅ | ✅ | ✅ |
|
||||
| Linking wires across pages | ✅ | ✅ | ✅ |
|
||||
| Importing EPLAN parts (.edz) | ✅ | ✅ | ✅ |
|
||||
| DXF import & export | ✅ | ✅ | ✅ |
|
||||
|
||||
**Legend:** ✅ Translated | 📋 Planned | ❌ Not yet started
|
||||
|
||||
|
||||
+1
-1
@@ -510,7 +510,7 @@ Berichte erstellen automatisch Dokumentation aus Ihrem Schema:
|
||||
- **PDF** — Professionelle Dokumente, beste zum Teilen
|
||||
- **PNG** — Rasterbild, gut für Web
|
||||
- **SVG** — Vektorformat, editierbar in anderer Software
|
||||
- **DXF** — CAD-Format für Zusammenarbeit
|
||||
- **[DXF](dxf-DE)** — CAD-Format für Zusammenarbeit (nur Umrisse und Text, siehe Grenzen)
|
||||
|
||||
**Export-Prozess:**
|
||||
1. Wählen Sie Folio(s) zum Exportieren
|
||||
|
||||
+1
-1
@@ -512,7 +512,7 @@ Les rapports créent automatiquement une documentation à partir de votre schém
|
||||
- **PDF** — Documents professionnels, meilleur pour le partage
|
||||
- **PNG** — Image raster, bonne pour le web
|
||||
- **SVG** — Format vectoriel, éditable dans d'autres logiciels
|
||||
- **DXF** — Format CAO pour la collaboration
|
||||
- **[DXF](dxf-FR)** — Format CAO pour la collaboration (contours et texte uniquement, voir les limites)
|
||||
|
||||
**Processus d'Exportation :**
|
||||
1. Sélectionnez le ou les folios à exporter
|
||||
|
||||
+1
-1
@@ -510,7 +510,7 @@ Reports automatically create documentation from your schema:
|
||||
- **PDF** — Professional documents, best for sharing
|
||||
- **PNG** — Raster image, good for web
|
||||
- **SVG** — Vector format, editable in other software
|
||||
- **DXF** — CAD format for collaboration
|
||||
- **[DXF](dxf)** — CAD format for collaboration (outlines and text only, see limitations)
|
||||
|
||||
**Export Process:**
|
||||
1. Select folio(s) to export
|
||||
|
||||
Reference in New Issue
Block a user