Zurück zur HomepageZurück zu DokumenteZurück zum TextanfangHier sind Sie gerade
Elementeigenschaften


Hinweis: Zum Buch "Der DXF-Standard" haben wir, die Autoren, eine überarbeitete Neuauflage veröffentlicht. Diese trägt den Titel "DXF intern" und enthält neben Fehlerkorrekturen auch einen Anhang über neuere DXF-Versionen (eine überarbeitete Fassung dieses Texts). Wenn Sie sich für neuere DXF-Versionen im Detail interessieren, so sei Ihnen außerdem das Buch "AutoCAD-Objekte" von Dietmar Rudolph empfohlen. Dieses beschreibt die Elemente der AutoCAD-Versionen 13, 14, 2000 und 2000i in allen Details sowie ihre Speicherung in DXF, AutoLISP, ActiveX und ObjectDBX.

VG-Wort Access-ZählmarkeDie Eigenschaften grafischer und nicht-grafischer Objekte werden in DXF durch Gruppencodes gekennzeichnet. Der Gruppencode beschreibt zum einen die Bedeutung der jeweiligen Information, zum anderen aber auch ihr Datenformat. Im Kapitel 2.2.3 finden Sie eine Liste der in AC1009 möglichen Gruppencodes und ihrer zugeordneten Datentypen. Für AC1012 erweitert sich diese Aufstellung wie folgt (neue Gruppencodes sind kursiv dargestellt):

8-Bit-Ganzzahl: 280, 281, 282, 283, 284, 285, 286, 287, 288, 289
16-Bit-Ganzzahl: 60, 62, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 170, 171, 172, 173, 174, 175, 176, 177, 178, 1070
32-Bit-Ganzzahl: 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 1071
64-Bit-Gleitkommazahl: 10, 11, 12, 13, 14, 15, 16, 17, 20, 21, 22, 23, 24, 25, 26, 27, 30, 31, 32, 33, 34, 35, 36, 37, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 140, 141, 142, 143, 144, 145, 146, 147, 210, 211, 220, 221, 230, 231, 1010, 1011, 1012, 1013, 1020, 1021, 1022, 1023, 1030, 1031, 1032, 1033, 1040, 1041, 1042
Folge von Binärdaten: 310, 311, 312, 313, 314, 315, 316, 317, 318, 319, 1004
Zeichenfolge: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 100, 102, 105, 300, 301, 302, 303, 304, 305, 306, 307, 308, 309, 320, 321, 322, 323, 324, 325, 326, 327, 328, 329, 330, 331, 332, 333, 334, 335, 336, 337, 338, 339, 340, 341, 342, 343, 344, 345, 346, 347, 348, 349, 350, 351, 352, 353, 354, 355, 356, 357, 358, 359, 360, 361, 362, 363, 364, 365, 366, 367, 368, 369, 1000, 1001, 1002, 1003, 1005

AC1012 weist einige grundlegende Veränderungen in der Gruppenstruktur auf. Zum einen besitzen die neuen Objekte neue Gruppencodes, das ist verständlich. Aber auch die bekannten Elemente aus AC1009 weisen neue Gruppencodes auf. Zudem sind Gruppencodes nicht mehr eindeutig, einige andere sind nicht mehr optional.

Zweideutige Gruppencodes

Bisher war die Reihenfolge der Gruppen in einem Objekt zwar fest vorgegeben, AutoCAD und die meisten anderen DXF-Programme akzeptierten Gruppen jedoch in jeder sinnvollen Reihenfolge. Lediglich in den Erweiterten Elementdaten konnten Gruppencodes innerhalb eines Objekts mehrfach auftreten, dort, z.B. beim Element VIEWPORT, ist die Reihenfolge der Gruppen wesentlich (vgl. Kapitel 3.9.3).

In AC1012 gibt es auch innerhalb der „normalen“ Gruppencodes solche, die in einem Objekt mehrfach auftauchen. Beispielsweise wird ein langer Text beim Objekt MTEXT in viele einzelne Gruppen 3 aufgespalten. Auch hier ist die Reihenfolge der Gruppen in der DXF-Datei wesentlich (sonst interpretieren Sie den Text in der falschen Reihenfolge).

Elementbenennung und Verweise

In AC1009 darf jedes Objekt der DXF-Datei eine eindeutige Elementreferenz enthalten (Gruppe 5). In AC1012 dagegen muß jedes Objekt eine eindeutige Elementreferenz enthalten. Dies gilt nicht nur für die grafischen Elemente im Abschnitt ENTITIES und im Abschnitt BLOCKS, sondern nun auch für die nicht-grafischen Objekte in den Abschnitten TABLES, CLASSES und OBJECTS. Damit hat nun jedes Objekt einer DXF-Datei einen eindeutigen Namen.

Da unglücklicherweise im Tabelleneintrag DIMSTYLE die Gruppe 5 schon vergeben war, ergibt sich dort die Elementreferenz ausnahmsweise aus der Gruppe 105.

Aus AC1009 ist ebenfalls die Gruppe 1005 bekannt, die einen Verweis auf die Elementreferenz eines anderen Objekts enthalten darf. Wird das Objekt umbenannt (in AutoCAD geschieht dies beispielsweise beim Einfügen in eine andere Zeichnung), so wird der Verweis automatisch nachgeführt.

Diese Verweistechnik ist in AC1012 sehr wichtig und wird für verschiedene Situationen verwandt, in denen Assoziationen zwischen Objekten benötigt werden. Beispiele hierfür sind die bereits genannte Gruppierungsfunktion, aber auch assoziative Schraffuren, die Zuordnung von Textstil und Bemaßungsstil sowie die Verbindung von Multilinienobjekt und Multilinienstil. Aus Gründen der Kompatibilität (sofern das bei diesen Änderungen überhaupt noch ein Argument ist) wird diese Verweistechnik jedoch noch nicht an allen Stellen konsequent genutzt. Zwar zeigt ein DIMSTYLE mit einem Elementverweis auf den zugehörigen Textstil, ein TEXT-Objekt benutzt jedoch immer noch den Textstilnamen als Referenz. Eine MLINE zeigt via Verweis auf den zugehörigen Multilinienstil, eine LINE jedoch via Name auf die Linientyptabelle und die Layertabelle.

Da Querverweise innerhalb der Datenbank in AC1012 so wichtig sind, gibt es gleich fünf verschiedene Arten von Verweisen. Welcher Verweistyp gilt, wird durch die verwendete Gruppennummer bestimmt:

320-329: beliebige Verweise auf andere Objekte. Diese werden nicht nachgeführt oder überwacht.

330-339, 1005: (soft pointer) Verweis auf ein beliebiges Objekt der aktuellen Zeichnung. Wird das referenzierte Objekt umbenannt, wird der Verweis entsprechend nachgeführt.

340-349: (hard pointer) Verweis auf ein beliebiges Objekt der aktuellen Zeichnung. Wird das referenzierte Objekt umbenannt, wird der Verweis entsprechend nachgeführt. Zusätzlich wird das referenzierte Objekt überwacht, so daß es nicht aus der Datenbank entfernt werden kann, ohne daß das verweisende Objekt ebenfalls verschwindet. Beispiel: Der Verweis auf den Textstil des Maßtexts im Objekt DIMSTYLE.

350-359: (soft owner) Eigentümer des referenzierten Objekts. Wird das verweisende Objekt aus der Datenbank gelöscht, werden automatisch auch alle referenzierten Objekte gelöscht. Die Eigentümereigenschaft ist eindeutig, d.h. das referenzierte Objekt darf nicht noch einen zweiten Eigentümer besitzen. Beispiel: Die Multilinienstiltabelle ist Eigentümer jedes Multilinienstils.

360-369: (hard owner) Eigentümer des referenzierten Objekts. Wird das verweisende Objekt aus der Datenbank gelöscht, werden automatisch auch alle referenzierten Objekte gelöscht. Zusätzlich wird auch das referenzierte Objekt überwacht, so daß es nicht aus der Datenbank entfernt werden kann, ohne daß das verweisende Objekt ebenfalls verschwindet. Beispiel: Ein Polylinienelement ist hard owner aller untergeordneten VERTEX-Elemente. (Bei Polylinien ist dies eine implizite Eigenschaft, die aus historischen Gründen nicht gespeichert wird.)

Zwei spezielle Anwendungen dieser Verweistechniken stellen die "Extension Dictionaries" und die "Reactors" dar. Das Extension Dictionary ist eine Form erweiterter Erweiterter Elementdaten. Jene sind ja auf 16384 Bytes pro Objekt begrenzt und relativ schlecht strukturiert. Das Extension Dictionary eines Objekts darf dagegen beliebig groß sein und besitzt üblicherweise eine saubere Struktur ähnlich einem Satz einer relationalen Datenbank. Jedes grafische oder nicht-grafische Objekt darf beliebig viele Verweise auf das Extension Dictionary enthalten. Dazu enthält die Gruppenstruktur des Objekts beliebig viele Gruppen 330 mit Verweisen auf die entsprechenden Einträge im Abschnitt OBJECTS. Um diese Gruppen 330 von eventuellen anderen Gruppen 330 zu unterscheiden, wird die Gruppenfolge zwischen zwei Gruppen 102 eingeschlossen:

102
{ACAD_XDICTIONARY
330
<erster Verweis>
330
<zweiter Verweis>
...
102
}

Ein anderes Beispiel für diese Verweistechnik stellen die Reactors dar. Sie können dazu dienen, Assoziationen zwischen Objekten aufzubauen. AutoCAD benutzt diese Verweise, um bestimmte Objekte über Veränderungen zu informieren. Ein typisches Beispiel wäre eine assoziative Schraffur, in der die beteiligten Randobjekte das Schraffurobjekt davon informieren, das sie bewegt wurden. Das Schraffurobjekt kann dann darauf reagieren und sich neu berechnen. AutoCAD benutzt Reactors jedoch genau an dieser Stelle nicht, dafür aber innerhalb der hierarchischen Dictionaries des Abschnitts OBJECTS.

Hierarchiegruppen

CAD ist schon immer eine "objektorientierte" Anwendung gewesen. Auch in DXF arbeiten wir seit Jahren mit Linien und Kreisen, nicht mit Bits und Vektoren.

Das Modewort der 90er, die "Objektorientierung" hat jedoch auch in AutoCAD Release 13 und in der zugehörigen DXF-Version AC1012 ihre Spuren hinterlassen. Die wichitgsten Eigenschaften sind die Erweiterbarkeit und die Vererbung. Applikationsentwickler können beliebige eigene grafische oder nicht-grafische Objekte definieren. Das AutoCAD-Dateiformat und damit auch DXF wird so zum universellen Container beliebiger Strukturen. Allerdings umfaßt das Dateiformat lediglich die notwendigen Daten des Objekts, nicht auch die zur Anzeige und Manipulation nötigen Methoden.

Neue Objekte können komplett eigenständig definiert werden. Es ist aber im Normalfall besser und einfacher, neue Objekte aus bereits vorhandenen Strukturen abzuleiten. Eine solche vorhandene Struktur in AC1012 ist das universelle grafische Element (AcDbEntity). Jedes von AcDbEntity abgeleitete Objekt besitzt einen zugeordneten Bereich (Gruppe 67), einen Layer (Gruppe 8), einen Linientyp (Gruppe 6), eine Farbe (Gruppe 62), einen Linientypfaktor (Gruppe 48) und eine Sichtbarkeit (Gruppe 60). Alle aus AC1009 bekannten grafischen Objekte sind aus AcDbEntity abgeleitet.

Jeder Objekttyp ist dann zusätzlich durch eigene Datenstrukturen definiert. Ein Kreis (AcDbCircle) besitzt zusätzlich u.a. Mittelpunkt und Radius, eine 2D-Polylinie (AcDb2dPolyline, man achte auf die Unterscheidung) zusätzlich u.a. das Typkennzeichen.

Alle von AutoCAD erzeugten grafischen Elemente sind direkt aus AcDbEntity abgeleitet. Es gibt also nur die einstufige Hierarchie AcDbEntity -> AcDbLine. Dieses Konzept ist jedoch offen und kann in alle Richtungen beliebig erweitert werden. Ein sinnvolles Beispiel wäre ein Kabelobjekt, das sich aus AcDbLine ableitet, aber zusätzlich Informationen über Spannung, Widerstand und Aufbau trägt. Das Kabelobjekt ergäbe sich aus der Hierarchie AcDbEntity -> AcDbLine -> Kabel, wobei jede Ebene zusätzliche Informationen hinzufügt.

Diese Hierarchie ist in einer DXF-Datei der Version AC1012 deutlich sichtbar, da zu jedem Objekt nicht nur die Summe der definierenden Daten, sondern auch die Zuordnung zu den jeweiligen Hierarchiestufen gespeichert wird. Dieser Ausschnitt einer DXF-Datei macht dies deutlich:

  0              Jedes Objekt der DXF-Datei besitzt eine Gruppe 0
CIRCLE
  5              und einen eindeutigen Namen.
21
100              Grafische Objekte sind von AcDbEntity abgeleitet
AcDbEntity
  8              und besitzen deshalb u.a. eine Layerzuordnung
0
 62              und eine Farbe.
     3
100              Dieses spezielle Objekt ist von AcDbCircle abgeleitet
AcDbCircle
 39              und besitzt deshalb u.a. eine Objekthöhe.
20.0
 10
8.669585
 20
4.846606
 30
10.0
 40
1.495836

Sie sehen, daß die aus AC1009 bekannte Liste der Objekteigenschaften mehrfach durch Hierarchiemarkierungen (Gruppe 100 mit zugehöriger Zeichenfolge) unterbrochen wird. Dies kann sich über viele Ebenen fortsetzen. Die in jeder Ebene verwendeten Gruppencodes müssen nicht eindeutig sein. So könnte ein aus AcDbCircle abgeleitetes Objekt in der nächsten Ebene wieder eine Gruppe 40 enthalten, die allerdings eine vollständig andere, hoffentlich dokumentierte Bedeutung besitzt.

Unverständlich ist eigentlich, warum diese Klassenhierarchie bei den fest in AutoCAD eingebundenen Standardobjekten (z.B. CIRCLE) ebenfalls in der DXF-Datei gespeichert werden muß. Auf diese Weise bläht sich jede DXF-Datei extrem auf, der Umfang einer Zeichnung kann allein durch diese Informationen auf das Doppelte anschwellen.

Elementabhängiger Linientypfaktor

In AC1009 wurde der Abstand der Striche in einer unterbrochenen Linie durch den globalen Linientypfaktor (Headervariable $LTSCALE) bestimmt, vgl. Kapitel 3.3 und 4.2.71. Da es nur einen einzigen Maßstabsfaktor gab, mußte, wenn mehrere Linien in unterschiedlichen Maßstäben gezeigt werden sollten, für jede Linie ein unterschiedlicher Linientyp definier werden.

In AC1012 besitzt jedes Objekt einen eigenen Linientypmaßstab. Dieser wird in der Gruppe 48 als 64-Bit-Gleitkommazahl gespeichert. Ist keine Gruppe 48 angegeben, wird der Wert 1.0 angenommen. Der aktuelle Linientypmaßstab des Objekts ergibt sich durch Multiplikation des elementabhängigen Linientypfaktors mit dem globalen Linientypfaktor. Bei Ansichten durch ein VIEWPORT-Element geht in Abhängigkeit von der Headervariablen $PSLTSCALE auch noch der jeweilige Anzeigemaßstab in die Berechnung der Strichabstände ein.

Elementsichtbarkeit

In AC1009 ist jedes grafische Element in der Zeichnung sichtbar, sofern es sich nicht auf einem ausgeblendeten oder gefrorenen Layer befindet. In AC1012 kann diese Sichtbarkeit objektabhängig festgelegt werden. Besitzt ein Objekt die Gruppe 60 und hat diese den Wert 1, so wird das Objekt unabhängig von allen Layereinstellungen nicht angezeigt.

Applikationsabhängige Elementdaten

Sobald Applikationsentwickler eigene Objekte definieren, benötigen diese frei vereinbare Datenstrukturen, um die jeweiligen Objekteigenschaften zu speichern. Nun könnte jeder Applikationsentwickler jeden beliebigen Gruppencode verwenden, um eigene Daten zu speichern. Dies würde aber jeden DXF-Konverter zum Absturz bringen, spätestens beim Lesen von Binärdateien. Es ist eine grundlegende Eigenschaft von DXF, daß ein Importprogramm aus der Gruppennummer den Datentyp der folgenden Information erkennen kann.

Aus diesem Grund wurden folgende Gruppennummern vereinbart, die Applikationsentwickler beliebig nutzen können:

8-Bit-Ganzzahl:   280-289
16-Bit-Ganzzahl:   70-78
32-Bit-Ganzzahl:   90-99
64-Bit-Gleitkommazahl: Skalar: 40-48
  Winkel: 50-59
  Koordinaten: 10-18, 20-28, 30-37
Folge von Binärdaten:   310-319
Zeichenfolge:   300-309
Elementreferenz:   320-369

Dies ist ein Shareware-Dokument. Was ist ein Shareware-Dokument? Hat Ihnen dieses Dokument etwas genutzt? Haben Sie damit Geld gespart? Dann revanchieren Sie sich bitte:


Kontakt CR/LF GmbH

© 1999-2011 by CR/LF GmbH, Essen/Germany. All rights reserved.
No part of this document may be reproduced or published without written consent by CR/LF GmbH.
Last modification: 01.04.2011