Diskussion:DXF/Archiv

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:DXF/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:DXF/Archiv#Thema_1

DXF

Nanu. DXF steht nicht für Data Exchange Format sondern für Data Interchange Format? Warum ist Data Exchange Format falsch? Wofür steht das Kürzel X? --1-1111 11:19, 23. Aug 2005 (CEST)

Das Zitat des Firmengründers habe ich wörtlich aus dem Buch abgeschrieben, war mir bis dato auch neu - Ralf 11:44, 23. Aug 2005 (CEST)

Kofferecken ?

Hi allerseits,

das man mit dxf erst mal keine Kofferecken darstellen kann, ok, aber ist das ein Geometrieelement, afaik ist hier auch Grafisches Primitiv gemeint, oder? greetz vanGore 00:11, 7. Mär. 2007 (CET)

Die "Kofferecke" ist eine Fläche mit besonderen Randbedingungen.

Für dise Randbedingungen müssen vom CAD-System bzw. vom DXF geeignete Randkurven und Flächendefinitionen zur Verfügung gestellt werden. -- 90.186.42.114 05:06, 21. Mär. 2010 (CET)

Die "Kofferecke" ist eine Flächeform mit besonderen Randbedingungen. Es ist eine Ecke, in der 3 unterschiedlichgroße Radien "einlaufen"; bzw. in einander übergehen. Flächen mit diesen Randbedingungen kann zur Zeit AutoCAD nicht selbst erzeugen. --90.186.174.121 22:54, 20. Okt. 2010 (CEST)

Natürlich kann AutoCAD das erzeugen, nur eben nicht mit Hausmitteln. Als Block kann sowas auch in DXF eingebunden sein. Da es keine Definition von Kofferecken gibt, gibt es auch kein Element dafür. --Marcela 22:58, 20. Okt. 2010 (CEST)

Also mit den DXF-Dateiformat kann man meines Wissens keine beliebigen Flächen wie z.B. Kofferecken übertragen bzw. speichern, (nachzulesen im "Der DXF-Standard") deshalb wird in der Fahrzeugindustrie das IGES Dateiformat für Flächenmodelle verwendet. Hast Du schon Programme geschreiben, die DXF-Files erzeugen? ---90.187.123.18 20:54, 21. Okt. 2010 (CEST)

Allerdings, ich bin seit 1998 im Autodesk Developer Network. Man kann alles Mögliche finden, was DXF nicht nativ unterstützt, das ist allerdings irrelevant. DXF ist ein Industriestandard, an dem sich Programme orientieren, nicht umgekehrt. Wenn bestimmte Elemente nicht unterstützt werden, dann hat das auch immer einen Grund. Kofferecken sind 2½D und das wird bewußt konsequent ignoriert wie alle anderen derartigen Elemente. Die Erwähnung von Kofferecken oder was auch immer wäre so, als wenn man bei MS Windows erwähnt, daß es klingonisch nicht unterstützt. Richtig, aber irrelevant. --Marcela 21:24, 21. Okt. 2010 (CEST)

Hallo und guten Abend

• Es geht mir hier nicht um alles Mögliche beim DXF
• Das Feature Kofferecke ist nur ein Beispiel was DXF nicht leisten kann, von den fehlenden Definitionen für einige Formen von Kurven reden wir ja noch garnicht...
• DXF ist meines Wissens nur ein Firmenstandard von AutoDesk und keine IndustrieNorm oder Standard ala DIN oder die VDA oder IGES
• Wenn bestimmte Elemente nicht unterstützt werden, dann hat das auch immer einen Grund. Kannst Du hierzu die Gründe nennen? Was wurde dazu in der Autodesk Developer Network veröffentlicht?
• Kofferecken sind 2½D und das wird bewußt konsequent ignoriert wie alle anderen derartigen Elemente. Es wäre nett wenn Du hier etwas genauer wirst.

nichtunterstützte Geometrieelemente wie z.B. Kofferecken hinzu

siehe die Diskusion oben... ;(--2.201.137.138 17:48, 23. Apr. 2011 (CEST)

Interchange Format

Kein Mensch spricht von Drawing Interchange Format - Auch wenn es "früher" vielleicht mal so hieß. Die Überschrift sollte wie allgemein und international üblich Drawing Exchange Format lauten. Diese Deutung ist keineswegs "falsch" (siehe englische Wikipedia)

Es ist einfach falsch, siehe Drawing_Interchange_Format#Begriff - wenn es auf .en anders steht, dann haben die dort einen Fehler. --Marcela 16:49, 31. Jan. 2011 (CET)

Irreführend??? warum ???

Die Entwicklung des DXF-Formats wird von Autodesk als Entwickler des CAD-Programms AutoCAD bestimmt. Die DXF-Versionen werden umgangssprachlich den entsprechenden AutoCAD-Versionen zugeordnet, haben aber eigene Versionsnummern. Das DXF-Format wird von AutoDesk beschrieben und dokumentiert, während das DWG-Format als proprietäres Format behandelt und nicht dokumentiert wird. Durch die mögliche Verwendung von CAD-applikationsspezifischen Elementen, ab der mit AutoCAD Release 13 veröffentlichten DXF-Version AC1012, innerhalb von DXF haben auch dort proprietäre Erweiterungen Einzug gehalten. --109.43.35.182 21:43, 11. Sep. 2011 (CEST)

Man kann auch in ein quelloffenes OpenOffice-Dokument ein geschütztes Foto einbinden, dadurch ändert sich aber nichts am Status des Formats. Das ist irreführtung und suggeriert, daß das Format unfrei wäre. Sowas gehört hier nicht rein. --Marcela 05:39, 12. Sep. 2011 (CEST)

Aber man kann vielleicht in ein quelloffenes OpenOffice-Dokument, meines Wisses z.B. ein eigenes USERObjekt Rohrleitung aus MannesmannSTRohrleitungtool mit einer Eigenschaft BSRQ intgrieren. Das ist in AutoCAD und DXF möglich. Wo ist diese Dokumentation zu dem Objekt ausser beim Hersteller von MannesmannSTRohrleitungtool noch zu finden? Dieses DXF-Objekt ist nun mal leider nicht zwingend öffentlich dokumentiert... Nachzulesen als ein anderes Beispiel auf der Webseite von www.crlf.de...

Das was Du schreibst ist wirklich irreführtung und suggeriert, daß das Format vollständig beschrieben ist, dem ist nun mal beim Beispiel UserObjekt Rohrleitung aus MannesmannSTRohrleitungtool nicht so. Sowas gehört hier auch als Vergleich nicht rein. --2.205.251.26 19:18, 13. Sep. 2011 (CEST)

Wenn es keine UserObjects geben würde, hätte es wahrscheinlich niemals Aufsätze für Acad oder beliebige andere Cad- Programme gegeben. Das Format DXF ist vollständig beschrieben, dazu gibts das 1000seitige Handbuch. Wenn sich nun jemend ein eigenes Objekt basteln will, dann kann er. Man kann in jedes halbwegs vernünftige Dateiformat eigene (fremde, geschützte, propietäre) Inhalte einbinden. Das ach so hochgelobte SVG ist da nicht anders, nur benutzt das in der Praxis niemand. Linux wird doch nicht unfrei, nur weil man geschützte Inhalte einbinden kann, das ist dort auch keine negative Erwähnung wert, wie es hier geschehen soll. --Marcela 20:32, 13. Sep. 2011 (CEST)

Sorry aber Die meisten AutoCAD Aufsätze kamen früher auch ohne eigene (selbsdefinierte) CAD-Objekte aus. Genau diese Elemnte machen große Probleme beim Datenaustausch mit DXF, da sie nicht in geometische Objekte des alten DXF zerlegt werden, außer man zerstört vor den Export diese Objekte..

Genau so ist es. Solcher Schrott wie Kofferecken, die nicht definiert sind, wird eben nicht unterstützt oder vorher gesprengt. Es geht um den kleinsten gemeinsamen Nenner. Und der ist nunmal DXF. --Marcela 21:42, 13. Sep. 2011 (CEST)

Also da fällt mir noch XML ein, das ja auch öffentlich beschrieben ist. Als Mirosoft sein XML-Format seiner Office-Dateien vorstellt hat, trat genau das gleiche Problem auf, dass von Mirosoft selbstdefinierte Elemente Officce-Objekte in XML als properotäre Erweiterungen wargenommen wurden...

--77.25.44.148 21:36, 13. Sep. 2011 (CEST)

Wir reden hier von DXF und nicht von XML, DXF war schon Norm,da gab es MS-Office noch nicht, geschweige denn Windows. --Marcela 21:40, 13. Sep. 2011 (CEST)

Sorry Der Vergleich von DXF und XML ist schon angebracht.

Wenn halt Kofferecken nicht vernüftig in AutoCAD oder DXF erzeugt und transportiert werden, weil einfach das DXF keine passenden Definitionen dafür bereitstellt, dann ist das schon ein Thema für einen CATIA USER der via DXF seine Kofferecken austauschen will...

--77.25.44.148 21:50, 13. Sep. 2011 (CEST)

Das Gejammer hören wir im ADN seit Jahren. Das Problem liegt nicht bei Autodesk oder DXF sondern bei CATIA, dort sollen sie sich einfach mal an Standards halten, dann klappt auch der Datenaustausch. Wenn CATIA neue Sachen erfindet, dann sollen die das auch ausbaden. Also gehört dort in den Artikel, daß Katia Elemente beinhaltet, die von anderen Programmen nicht unterstützt werden und daß CATIA deshalb Kompatibilitätsprobleme bereitet. --Marcela 21:58, 13. Sep. 2011 (CEST) --Marcela 21:58, 13. Sep. 2011 (CEST)

Also der DXF-Export 2D aus CATIA IV klappte zu AutoCAD recht gut...

Naja, die Kofferecken in 2D waren Splines, die AutoCAD wirklich konnte... Ich glaube langsam verstehst Du warum die User mekerten: Sie wusten nicht, das Sie gerade das DXF-Format überforderten... Würde zufälliger Weise der gleiche Transfer aus CATIA in IGES zu NX erfolgen dann wären die Klagen nicht so laut, weil IGES geometrisch korrekt mehr als DXF übertragen kann... Bei der Übertragung von 2D Geometrie ist DXF häufig besser und der einfache sowie billigerer Weg. Er stellt häufig sehr pragmatisch den kleinsten gemeisammen Nenner dar bei der Datenübertragung dar... Bei 3D-Geometrie sollte es doch besser IGES sein...

Bei AutoCAD ist aber der interne IGES-Konverter auch in 3D dummerweise fast den gleichen softwaretechnischen Beschänkungen des DXF unterworfen, da AutoCAD intern ohne Parametrdarstellungen der Kurven, also anders (einfacher) als NX und Catia arbeitet...

Ps: Du solltest in Catia und NX problemlos 3D-Spiralen anhand von einigen Parametern erzeugen können. AutoCAD kann diese 3D-Spiralen meines Wissens nur über den Kunstgiff Spline (Polylinie) angenähert darstellen... Den Quellcode von 3DPoly.lsp ? hab ich nicht im Kopf... (nicht signierter Beitrag von 77.25.44.148 (Diskussion) 22:27, 13. Sep. 2011 (CEST))

Der Artikel wurde überarbeitet bitte Komentare und Ergänzungen hier zentral diskutieren

--77.25.106.72 05:38, 12. Sep. 2011 (CEST)

Sperrung des Artikel DXF

Hallo und guten Morgen Benutzer:Kuebi, Du sperrtest den Artikel DXF, und folgtes der Begründung vom Marcela...

Seit einiger Zeit versuchen verschiedene IPs, ständig irrelevante Inhalte einzubringen, die den Industriestandard ins negative Licht rücken sollen. Argumente wurden reichlichst auf der Disk. genannt.

Es mag ja sein, das Du Ruhe in den Artikel DXF hineinbringen woltest, aber das ist wohl der falsche Weg.

• Der USER Marcela konnte und wollte nicht zur Sache diskutieren

brachte immerwieder unrelevante Dinge in die Diskusion negierte Argumente

• Genau dieser USER entzieht sich der von Dir geforderten Belegpflicht...
• Er behauptet das jemand anaonymes eine Industriestandard ins negative Licht rücken will...
• Er behauptete noch vor kurzen dass DXF jede Geometrie übertragen kann...
• Er führte din der Diskusion grafische Primitive an, die dann im Artikel nicht erwähnt wurden...

Wenn dem so einfach wäre dann würde jetzt mindestens noch in der Vandalismusdiskusion zum Artikel und dem USER Marcela vom 18.08.2011 eine vollständige Begründung und nicht in der Historie zufinden sein... oder sollte hier was vertuscht werden?

Sorry ist dieses Vorgehen korrekt und wirklich mit den WP-Grundsätzen vereinbar?

Fakt ist, daß leider DXF aus mathematischer Sicht einige Schwächen hat. So kann man z.B. leider nicht beliebige Kurven in Parameterform korrekt in DXF abbilden... Hier zu einen Beleg für ein Fehlen im DXF einzufordern ist nicht so einfach möglich, da genau dieser Fakt in der DXF-Referenz von AutoDESK nicht explizit erwähnt wird! Aber wer Mathematik im Studium hatte, der kann es wissen wenn man alle Beschreibungen der geometrischen Elemente ansieht... Das ist aber mit Sicherheit keine Herabwürdigung von DXF sondern ein Umstand, den man beim Datenaustausch mit DXF berücksichtigen muß, wenn dieser vollständig und korrekt erfolgen muß...

Wenn dann andere USER den Artikel DXF mit der Abschnitt "Nicht unterstützte Geometrieelemente" sichteten, dann hat das sicherlich nichts mit einen irrelevante Inhalt zu tun, sondern ich gehe davon aus, das auch diese USER ähnliche Erfahrungen gemacht haben. Auch das hat dann genau nichts mehr mit der Behauptung zu tun "den Industriestandard ins negative Licht rücken"...

Ihr könnt euch gern mal beim nächsten WP-Admintreffem mal in Ruhe über meine Argumente unterhalten...

Übrigens wenn Ihr in der WP Probleme habt Editoren und qualifizierte Sichter zufinden, dann könnten diese unnötigen Diskusionen das ein Grund dafür sein...

--109.43.175.44 04:55, 19. Sep. 2011 (CEST)

Diese unnötige Diskussion geht seit über einem Jahr von dir aus, da du immer wieder irrelevante Inhalte in den Artikel einbauen willst. Es gibt 2 Fakten:

1. DXF kann jedes Geometrieelement darstellen
2. DXF hat nur für sehr wenige Elemente eigene Namen, nämlich für die geometrischen Primitive

Du versuchst ständig, aus 2. etwas Negatives zu konstruieren, ist es aber nicht, das ist ja gerade die Stärke des Standards. Wenn sich andere Programme nicht dran halten und ihre eigenen Definitionen erfinden (nichts anderes sind die sogenannten "Kofferecken"), dann ist das in der Verantwortung dieser Programme und nicht Aufgabe des Standards. Es ist nicht Aufgabe eines Industriestandard, sich neu zu definieren, nur weil ein Anwender etwas Neues erfindet. Und dies ist kein Mankop des Standard, es ist seine Stärke - und ein Manko der Anwendersoftware.

Also versuche nicht ständig, einen Negativaspekt in den Artikel zu bugsieren, nur weil DXF diese bescheuerten Kofferecken nicht unterstützt, für die es nichtmal eine echte Definition gibt. Es unterstützt ja auch keine Klothoiden, für die gibts ja immerhin eine Definition. Trotzdem sind sie darstellbar.

Höre auf, deinen POV in den Artikel zu verfrachten, daß andere, fast unbenutzte und unbeachtete Austauschformate Kofferecken unterstützen. Kannst du in deren Artikeln gerne schreiben, hier gehört es nicht rein und ist ist nicht neutral. DXF ist seit fast 30 Jahren weltweiter Standard und diese Tatsache ist völlig unumstritten. Programme haben sich am Standard zu orientieren und nicht andersrum. --Marcela 05:35, 19. Sep. 2011 (CEST)

Sorry aber nun erkläremal den geneigten USER was Deine Diskusion eigentlich bringen soll...

Also wenn Du behauptest, das hier ein Negativaspekt in den Artikel bugsiert wird, nur weil DXF diese bescheuerten Kofferecken in 3D im AutoCAD nicht gehen, dann ist das nun wirklich eine persönliche Wertung!

Neutral ist das man technisch mathematische Grenzen auf von DXF in den Artikel benennt. Das hat wirklich nichts mit einer persönliche Meinung zutun, eher mit der Qualität eines Beitrages zum Artikel.

Aber läuft das immer so hier? (Zitat+Antwort beim Admin)

• Zerstückelung der Disk... Ja, diese ist wirklich nicht mehr zu erkennen
• Habe auf Artikel geantwortet... Das ist leider unzureichend geschehen
• 3M eingeholt... Von einen DXF-Experten?
• Sachliches Diskutieren ist leider unmöglich... Auf Rückfragen selbst "klingonisch" geantwortet...

Leicht jetzt schon mit den Kopf geschüttelt... --2.205.129.78 06:34, 19. Sep. 2011 (CEST)

Ubrigens was sagt eigentlich AutoDesk zu diesen Artikel?

--2.205.129.78 06:56, 19. Sep. 2011 (CEST)

Dritte Meinung zu einigen Themen die WP in Englisch

As AutoCAD has become more powerful, supporting more complex object types, DXF has become less useful. Certain object types, including ACIS solids and regions, are not documented. Other object types, including AutoCAD 2006's dynamic blocks, and all of the objects specific to the vertical-market versions of AutoCAD, are partially documented, but not well enough to allow other developers to support them. For these reasons many CAD applications use the DWG format which can be licensed from AutoDesk or non-natively from the Open Design Alliance.--2.205.123.86 19:17, 19. Sep. 2011 (CEST)

Was in anderssprachigen Wikipedias geschieht, ist für uns irrelevant. Im üebrigen sind die angesprochenen Elemente sehr wohl dokumentiert, im ADN sind sie offengelegt. --Marcela 19:27, 19. Sep. 2011 (CEST)

Hallo Marcela wo muß ich genau in ADN nachlesen? Kannst Du bitte entsprechende detailierte Belege bringen?--77.24.124.232 06:50, 19. Okt. 2011 (CEST)

ernstgemeinter Vorschlag

Wie wäre es damit, erstmal einen Artikel Kofferecken zu erstellen? Auf WP:3M findet sich offenbar niemand, der eine Meinung abgeben möchte, das Thema scheint zu speziell zu sein. Anhand des zu erstellenden Artikels könnten dann Andere vielleicht einschätzen, wie die Sachlage hier ist? Da es recht schwierig ist, neue Artikel zu erstellen, ohne daß gleich ein Löschantrag kommt, kann dazu vorerst mein Benutzernamensraum genommen werden: Benutzer:Ralf Roletschek/Kofferecken, jedermann kann dort ungestört editieren und ich werde das nach Kräften unterstützen. Wenn das Artikelchen dann steht, wird es verschoben und wir diskutieren hier weiter? --Marcela 20:16, 19. Sep. 2011 (CEST)

Kein Thema also es gibt mehrere Varianten von einer Kofferecke ;)

http://ww3.cad.de/foren/ubb/Forum68/HTML/000110.shtml

Die aufwendigste ist, wenn an einer Ecke 3 oder mehr unterschiedliche Radien sich treffen müssen... Sowas kommt im Formenbau öfters vor. Leider hat AutoCAD ein Problem mit 3 unterschiedlichen Radien... Die 3D-Kofferecke mit mindestens 3 unterschiedlichen Radien ist der "Elchtest" für einfache 3D CAD-Systeme. Ein guter Rohbaukonstrukteur wird Dir gern seine Kofferecken im Blech und CAD zeigen... Das wird schon mit uns...--77.25.82.140 20:51, 19. Sep. 2011 (CEST)

Ich weiß doch, was Kofferecken sind ;) Es geht darum, daß hier sonst niemand mitdiskutieren will bzw. kann. Das Ganze ist auch vielmehr ein geometrisches Problem, weniger eins von Autocad oder DXF. Schon 1992 gab es dafür eine Lösung von Accugraph MountainTOP, parametrische Objekte, die mittels künstlicher Intelligenz Näherungslösungen schafften, die je nach Parameter genau genug für alle Lösungen waren, das Ganze war nur extrem rechenaufwendig. Das Problem ist der Anschluß der "Stummel", das wurde mittels Spline gelöst und erinnerte etwas an Klothoiden, war aber doch komplizierter. Das mathematische Modell war quasi im Ergebnis nicht mehr nachvollziehbar, Flächenfüllungen im Raum verlangen aber exakte Schließungen und deshalb muß immer gerundet werden. Die Ecken sind immer ungenau, nur eben nnn Stellen nach dem Komma. Nun hat aber DXF systembedingt nicht unendlich Nachkommastellen, das würde dem Prinzip widersprechen, auch wenn man da etwas tricksen kann. Würde DXF die erforderliche Genauigkeit unterstützen, wäre es nicht mehr kompatibel - und genau das ist die Aufgabe des Austauschformats. DXF hat nicht die Aufgabe, möglichst vieles zu unterstützen, es soll der kleinste gemeinsame Nenner sein. Also los, erklären wir der Welt, was Kofferecken sind? Klothoide gibt es schon, das könnte als Beispiel dienen, auch wenn das 2D ist. --Marcela 21:28, 19. Sep. 2011 (CEST)

Sorry für Kofferecken bin ich nicht der Spezialist, für DXF schon eher --2.200.49.141 13:49, 3. Okt. 2011 (CEST)

ernstgermeinte Meinung

So wie der Artikel jetzt da steht, ist er bis zum Abschnitt "Nicht unterstützte Geometrieobjekte" brauchbar. Dann geht es wieder am Thema vorbei. Dank Andminsperrung kann man sowas nicht eimal direkt auf die QS setzen.

Die Behauptung DXF unterstützt nur Grafische Primitive, da es als Austauschformat systemübergreifend funktioniert. Zeigt mir wider eimal das man etwas anders schreibt als man wohl meint?

Schriftarten werden nur bedingt unterstützt, ist irreführend, weil Schriftarten, einfach viele Aspekte haben z.B.:

• a) Zeichensatz und Mächtigkeit der extern verwendeten Schriftart an sich
• b) Anwendung von landestypischen Codetabellen, z.B. Codepages in MS-Dos
• c) Nutzung des Textes als (Info-)Text oder als reine grafische Information (z.B. bei Schmuckschriften zum Gravieren)

Zu Schraffuren und Bemaßungen möchte ich jetzt mal nicht viel sagen. Was irgendewie rein gebaut wurde, dass es ein Problem gibt, wenn das Zielsystem externe Referenzen wie Schriftarten, Symbole und Schraffurmuster nicht kennt, sowie nicht in der Lage ist Bemaßungsblöcke im DXF korrekt im Zielsystem darzustellen.

Technisch sauber wären Hinweise, das DXF externe Referenzen verwendet, die bei der Datenübertragung in andere Systeme (warum kein weiterer Abschnitt im Artikel?) separat eingefügt wird.

Wenn jemand komplexe geometrische Elemente (z.B. eine Kofferecke) in primitive Subobjekte verwandelt, und dann sich wundert, daß die ursprünlichen Eigenschaften im Zielsystem nicht mehr vorhanden sind, ist das auch kein reines DXF-Problem. DXF ist nie zu Übertragung von allen möglichen geometrieschen Objekten geschaffen worden.

Sorry mir ist's schon langweilig, und es schade um die Zeit... --2.200.49.141 13:49, 3. Okt. 2011 (CEST)

Belege fehlen: Die Behauptungen vom Marcela?

• Jedes heutige CAD- und CNC-Programm beherrscht den Import und Export von DXF, womit DXF als Industriestandard der kleinste gemeinsame Nenner aller CAD-Systeme bildet.

• DXF ist im Import voll abwärtskompatibel, im Export werden von älteren Programmversionen unbekannte Objekte ignoriert, was die prinzipielle Verwendung auch neuer Dateien in sehr alten Programmversionen ermöglicht.

• Die oben genannten Einschränkungen sind systembedingt und werden heute als weitgehend unlösbar angesehen. Der Datenaustausch unter CAD-Systemen ist auch mit anderen Austauschformaten für CAD oft nur in wenigen Fällen ohne Nachbesserungen möglich. (nicht signierter Beitrag von 2.205.12.121 (Diskussion) 03:30, 26. Okt. 2011 (CEST))

@Marcela

Bitte unterlasse Deine begründungslosen Reverts! Du hattest 4 Wochen Zeit gehabt den Artikel DXF sauber zu machen oder fachlich zu korregieren. Du hast kaum etwas zu Verbesserung beigetragen oder konktete Belege für Deine Behauptungen und Reverts angebracht! So kann eine WP nicht funktionieren! Ich finde Dein Verhalten beim Artikel DXF nicht i.O.

• wenn Du die Relevanz der Engliches WP nicht ohne eigene Belege nicht akzeptierst!

--90.186.48.35 17:03, 23. Okt. 2011 (CEST)

warum eine Auflistung von nicht unterstützten Geometrieelemente in DXF, in einen Datenformat das zum Austausch von Geometrieinformationen verwendet, wird nicht relevant??

Hallo Ralf Roletschek, kanst Du uns bitte erklären warum eine Auflistung von nicht unterstützten Geometrieelemente in DXF, in einen Datenformat das zum Austausch von Geometrieinformationen verwendet wird nicht relevant sein soll? Warum ist die Seite unbedingt zu sperren? --2.200.169.185 06:44, 6. Sep. 2011 (CEST)

Die Erwähnung von Kofferecken oder was auch immer wäre so, als wenn man bei MS Windows erwähnt, daß es klingonisch nicht unterstützt. Richtig, aber irrelevant. Aber es ist ja nichtmal richtig. DXF unterstützt auch keine Dreiecke. Aber solche Aussagen sind wertlos, denn man kann alles darstellen, nur gibt es nicht für jede geometrische Erfindung einen Namen. Irgendwelche Konstrukte wie Kofferecken kann man endlos erfinden und dann sagen, daß DXF sie nicht beherrscht. Braucht es auch nicht, denn sie sind ja trotzdem darstellbar. Geometrieobjekte sind Punkte, Linien, Bögen, Splines. Rechtecke sind schon keine mehr, das sind zusammenhängende Objekte. Kofferecken sind... - ja was sind sie denn? unbekannt, unwichtig, unnütz. Nur ein Block von mehreren Elementen. Und das beherrscht DXF. DXF kann jedes geometrische Objekt darstellen. Nicht mehr und nicht weniger. Es unterstützt nur eben nicht endlos erfundene Objekte, die aus irgendwas zusammengesetzt werden als eigenen Namen. Und deshalb ist es Industriestandard. Die Stärke liegt in der Einfachheit. Mit jedem zusätzlichen Element würden Kompatibilitätsprobleme entstehen, deshalb werden die nicht aufgenommen. Ein Rechteck ist definiert, deshalb ist es dabei. Kofferecken sind nicht definiert, deshalb gibt es dafür keinen Namen in DXF. Trotzdem werden sie unterstützt - wie alles. Wenn irgendein Programm nicht in der Lage ist, daraus sauberes DXF zu schreiben, dann ist das nicht der Fehler des Standards, dann ist das Programm Schrott. --Marcela 11:24, 6. Sep. 2011 (CEST)

Sorry für das tiefe Nivau. Aber (gefüllte) Dreiecke können aus den AutoCAD- und DXF-Element Shape (ein 4-Eck) hergeleitet werden! Also Dreiecke sind also definiert.

Solltest Du mal in AutoCAD eine Bemaßung mit Maßfeil zerlegen, Dann kannst Du das gern selbst nachprüfen. Es geht hier mir nicht um ein Rumnörgeln und Erfinden von Sonderfällen, die noch zusätzlich einzeln aufgelist werden sollen, um die Nennung von Standardelementen die man halt mit andern Fomaten wie IGES oder VDA abbilden kann. Das sind keine 'Irgendwelche Konstrukte wie Kofferecken kann man endlos erfinden' muss sondern Standardelemente in komplexeren Geometrieformaten. Das ist nix klingonisches oder?

Deine Aussage:  DXF kann jedes geometrische Objekt darstellen ist falsch und steht im Wiederspruch zur Literatur auch von Autdesk selbst den Erfinder der DXF-Datenformates...

Was einen Anwender wichtig ist oder nicht das ist wohl Sache des Anwenders, nicht die Deinige. Aber Du scheinst ja wohl das nicht verstehen zu können oder warum ziehts Du diese Diskusion immer auf dieses Niveau?--2.200.199.232 19:11, 6. Sep. 2011 (CEST)

Mit den graphischen Primitiven nach ISO 19107 läßt sich alles darstellen, dazu sind sie ja da. Punkt, Linie, Bogen und Spline und ihre Verwandten sind vollkommen ausreichend, um alles abzubilden. Kofferecken können kein Standardelement sein, denn DXF ist der Standard. --Marcela 05:34, 7. Sep. 2011 (CEST)

Sorry aber nun wieder der Reihe nach

1. Also wenn Dir die Primitiven nach ISO 19107 im Artikel fehlen dann füge Sie doch ein... Das hat nichts mit Deiner falschen Aussage zutun DXF kann jedes geometrische Objekt darstellen

2. 'Irgendwelche Konstrukte wie Kofferecken kann man endlos erfinden' ist nie mein Thema hier gewesen, sondern nur ein Beispiel was DXF einfach selbst nicht kann...

3. Deine Aussage Mit den graphischen Primitiven nach ISO 19107 läßt sich alles darstellen, ist nun auch nicht zielführend, da eine Transformation in diese Subelemente letztlich oft auch nur eine Näherung darstellt, die man vielleicht schön anschauen kann, aber nicht eineindeutig rückführbar in das Orginal ist, und damit der Idee eines Austauschformates zuwiederläuft ... (nicht signierter Beitrag von 2.205.125.242 (Diskussion) 21:34, 8. Sep. 2011 (CEST))

Dann kommen wir zurück zu deiner Frage in der Überschrift. Kofferecken oder ähnliche Erfindungen sind deshalb irrelevant, weil sie kein Standard sind. Sie sind außerdem nicht definiert. Und die Aussage, daß sie nicht darstellbar sind, ist ebenfalls falsch. Wir sind wieder an dem Punkt oben: versuche mal bei Windows reinzuschreiben, daß es keine klingonische Version gibt. Diese Nullaussage ist irrelevant wie die Kofferecken für DXF. --Marcela 22:25, 8. Sep. 2011 (CEST)

Also warum nochals:

Warum ist eine beispielhafte Nennung von einigen nicht in DXF unterstützten Geometrieelementen, in einen Datenformat (DXF) das zum Austausch von Geometrieinformationen entwickelt und verwendet, wird nicht relevant???

Meine Antwort: Flächen und andere Konstrukte (z.B. Kofferecken) die auf Kurven mit besonderen Randbedingungen basieren sind StandartElemente in anderen Austauschformaten für geometrische Informationen. Sie sind dort z.B. im IGES Standard. Nur DXF kann mit diesen geometrischen StandardElementen aufgrund eigener (fehlender) Definitionen diese Informationen nicht korrekt umgehen. Diese Einschränkung ist nicht neu. Deshalb gehören diese Information mit in den Artikel hinein...

Oder warum gehören diese wichtigen Einschränkungen nicht in den Artikel "DXF Datenaustauschformat" hinein?

Weil es weder eine wichtige noch überhaupt eine Einschränkung ist. --Marcela 22:14, 11. Sep. 2011 (CEST)

Bitte hier zur Sache diskutieren und keine irreführenden Einzelmeinungen verkünden, zu mal es Einschränkungen sind, die eine Anwendung des DXF-Formates zum Datenaustausch in bestimmten Fällen verbieten.--77.25.106.72 05:43, 12. Sep. 2011 (CEST)

Es ist eben keine Einschränkung, wenn der weltweite Industriestandard fremde Definitionen ignoriert. ASCII ist auch dann Standard, wenn es UTF-8 ignoriert. --Marcela 06:13, 12. Sep. 2011 (CEST)

Übriges ist IGES richtiger US-Standard und kein sogenanter FirmenStandard von AutoDESK.

Also das ist alles nur eine persönliche und damit unrelevante Betrachtung eines einzelnen angemeldeten WP:USER, ohne enzyklopädieschen Wert, der wohl offentsichtlich nicht den Sinn eines geometrischen Datenaustauschformates nicht sorecht verstehen kann...--2.200.105.204 17:37, 21. Apr. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Marcela 13:29, 22. Apr. 2012 (CEST)

offene Punkte im Archiv, von der Disk wann werden diese abgearbeitet?

2 Kofferecken ?

3 nichtunterstützte Geometrieelemente wie z.B. Kofferecken hinzu
8 Dritte Meinung zu einigen Themen die WP in Englisch
13 warum eine Auflistung von nicht unterstützten Geometrieelemente in DXF, in einen Datenformat das zum Austausch von Geometrieinformationen verwendet, wird nicht relevant??

Wann werden diese Punkte endlich aus den Archiv mal abgearbeitet?
(nicht signierter Beitrag von 109.43.66.131 (Diskussion) 04:21, 10. Mai 2012 (CEST))

Die sogenannten Kofferecken sind nirgendwo definiert. Außerdem werden sie als Blöcke sehr wohl unterstützt. DXF kennt alle grafischen Primitive, das reicht aus, um jegliche geometrische Gebilde darzustellen. Es reicht offenbar aus, wenn alles dargestellt werden kann. Was die en.Wikipedia schreibt, interessiert uns nicht. --Marcela 09:39, 10. Mai 2012 (CEST)

Bitte WP:POV und WP:Belege beachten!--77.24.8.80 18:04, 17. Mai 2012 (CEST)

Zeichnungsautausch ein ein kleiner Teilbereich des CAD-Datenaustausch....

nur mal so
Denn Spezialisten nutzen STEP

Der Austauch von  2D-Projektionen (Zeichnungen) ist halt kein vollständiger CAD-Datenaustausch....

--109.43.180.170 19:10, 9. Mai 2012 (CEST)

Wer redet denn von 2D? --Marcela 09:42, 10. Mai 2012 (CEST)

Das folgende ist halt oft nur als Zeichnnungselement in 2D sinnvoll zugebrauchen:
Im geometrischen Teil werden Linien, Polygone, Kreise, Kreisbogen, Texte und alle anderen Grundelemente mit verschiedenen Attributen wie Ebenen, Farbe, Strichstärke oder Linientyp gespeichert.--109.43.236.35 18:10, 14. Mai 2012 (CEST)

Das behauptet wer außer dir? --Marcela 18:06, 17. Mai 2012 (CEST)

Belege fehlen die 2. DXF ist im Import voll abwärtskompatibel

DXF ist im Import voll abwärtskompatibel, im Export werden von älteren Programmversionen unbekannte Objekte ignoriert, was die prinzipielle Verwendung auch neuer Dateien in sehr alten Programmversionen ermöglicht. (nicht signierter Beitrag von 2.205.45.190 (Diskussion) 19:51, 11. Apr. 2012 (CEST))

Nachzulesen in der aufgeführten Quelle und in allen Programmierhandbüchern zu DXF. --Marcela 19:29, 16. Apr. 2012 (CEST)

Bitte hierzu Autor, Titel und Seitenangabe nachreichen!--77.24.92.158 16:55, 21. Apr. 2012 (CEST)

Ist jetzt referenziert. --Marcela 22:16, 10. Mai 2012 (CEST)

Nö da steht und HIER stand was anderes, und noch nicheinmal in deutsch ;(--77.24.8.80 18:01, 17. Mai 2012 (CEST)

Einschränkungen zu früheren Versionen speichern Sprachtools können helfen....

http://translate.google.com/translate?langpair=auto%7Cde&u=http%3A%2F%2Fexchange.autodesk.com%2Fautocadarchitecture%2Fesp%2Fonline-help%2FARCHDESK%2F2012%2Fesp%2Fpages%2FWS1a9193826455f5ffa23ce210c4a30acaf-59da.htm

Einschränkungen zu früheren Versionen speichern:

Die Speichern von Zeichnungen in 2000/LT Version 2000 gelten die folgenden Einschränkungen:

Die Dateigröße kann ansteigen.

Verschlüsselung und digitale Signaturen werden nicht beibehalten.

Die Zeichnungen im Format der Versionen 14/LT 98/LT 97 gespeichert ist, unterliegt den folgenden Einschränkungen:

Hyperlinks verknüpft werden URL 14/LT 98/LT Version 97.

Die Links-Datenbank und Independent-Labels werden Links 14/LT 98/LT Version 97 und Attribute sichtbar.

Stichworte verknüpfte Datenbank mehrzeiligen Text und Objekte Leitlinie geworden, und die verlinkten Informationen nicht zur Verfügung steht. Linked-Tags werden wiederhergestellt, wenn Sie die Zeichnung in AutoCAD 2000 oder höher öffnen.

Sie können die Geometrie einer dynamischen Block unabhängig von den Elementen der es neu zu definieren, und die Geometrie des Referenz-Block wird nicht aktualisiert, wenn die Zeichnung in AutoCAD 2012 oder später geöffnet wird.

Es ist möglich, dass die Abmessungen der Befehle erstellt ACOARCO und ACORECODO nicht die Erhaltung der ursprünglichen Farbfassung 98/LT 14/LT 97.

Die Zeichnungen im Format 12/LT 2 DXF-Versionen gespeichert sind, unterliegen den folgenden Einschränkungen:

Schraffurmuster und optimierte Polylinien Polylinien und Schraffuren R12 geworden.

− Alle Festkörper, Regionen, Ellipsen, Richtlinien, mehrere Linien, Strahlen, Toleranzen und líneasX geworden Linien, Bögen und Kreise, soweit angemessen.

Gruppen, komplexe Linientypen, OLE-Objekte und Vorschau-Bilder werden nicht angezeigt.

Viele Objekte sind verloren, wenn die Zeichnung als Release 12 gespeichert wird und späteren Release 2000/LT Open im Jahr 2000 oder später.

Mehrere Präsentationen sind verloren und die Namen der Präsentationen. Nur dann gespeichert, auf die Registerkarte Modell und die Registerkarte für die aktuelle Präsentation.

Die Räume in den Namen der Schichten und andere Objekte in Unterstriche umgewandelt werden, ist die maximale Länge 32 Zeichen.

Die DWF-Unterlage Dateien oder Zeichnungen DWFx gebunden ist, kann nicht in dem Format für die Version 2 DXF 12/LT gespeichert werden.

Externe Verweise Heruntergeladene deren Status verloren diesen Zustand. (nicht signierter Beitrag von 109.43.180.170 (Diskussion) 19:20, 9. Mai 2012 (CEST)) --109.43.109.18 07:43, 18. Mai 2012 (CEST)

Wenn das Thema sauber erledigt werden sollte, dann fehlen diese Negativbelege im Artikel DXF das sich die Abwärtskompatibilität von DXF oft nur für den DXF-Import gilt, das Schreiben in alte Versionen sich jedoch als verlustbehaftet erweist... (nicht signierter Beitrag von 2.205.53.103 (Diskussion) 07:54, 18. Mai 2012 (CEST))

Neutrale deutsche oder übersetze Quellen erforderlich...

Sorry, Ralf,
Dein Rauswurf Deiner eigenen Quellen, die ich mal verständlicherweise neutral übersetzen lassen habe ist schon eine sehr eigenartige Sache.
Warum machst Du sowas?
Wass willst Du damit erreichen?
Entwerder Du schaffst es neutrale (einfache auch auf deutsch) überprüfbare Quellen in der deutschen WP zu benennen oder die Quelle ist in der in dieser deutschen WP nicht nutzbar! Oder gibt es neutrale deutschsprachigen Bezüge auf diese Quellen?--2.205.190.117 07:11, 17. Mai 2012 (CEST) --2.205.55.111 07:54, 17. Mai 2012 (CEST)

Das ist Quatsch. Quellen müssen nicht deutsch sein. --Marcela 18:02, 17. Mai 2012 (CEST)

Ja Belege müssen relevant, nachvollziebar und neutral sein, was wohl die engliche WP für dich offensichtlich auch nicht ist! Was soll hier das Theater? Verstecken spielen?--109.43.109.18 07:34, 18. Mai 2012 (CEST)

siehe auch IGES

Weitere Formate zum Austausch von CAD-Daten sind IFC, STEP und IGES, diese können sich am Markt jedoch nicht durchsetzen Das ist falsch eine Teilmenge von IGES wurde vom Verband der Automobilindustrie sogar zum Datenaustausch temporär genormt, bis es vollständige IGES -Konverter für deren CAD-Systeme gab...

Der Verband der Automobilindustrie hat mit dem Ziel der einfacheren Implementierung verschiedene Untermengen des IGES-Standards definiert und zusammen mit weiteren Anforderungen unter der Bezeichnung VDA-IS veröffentlicht:

--2.205.239.203 08:15, 18. Mai 2012 (CEST)

Das sich IGES und STEP (immerhin nach ANSI bzw. ISO genormt), nicht am Markt durchsetzen konnten, halte ich aus der täglichen Praxis heraus für ziemlichen Unsinn. Im Gegenteil spielt DXF bei den Datenaustausch mit unseren Zulieferern und Auftragsfertigern im Gegensatz zu IGES und STEP keinerlei Rolle. Bauteileanbieter wie Molex oder Tyco/AMP bieten in der Regel Modelldownloads ihrer Produkte an: Dort ist von DXF keine Spur, nur IGES oder STEP. 3dcontentcentral.com bietet Millionen von Modellen an: Catia, Parasolid, IGES und STEP sind die Formate der Wahl. Oder soll das nur für den 2d-Sektor gelten? Dann bitte auch so notieren. 178.200.111.41 10:18, 19. Mai 2012 (CEST)

Das sind reine Behauptungen, nichts weiter. --Marcela 21:32, 3. Jun. 2012 (CEST)

Achtung: Schwere POV's (Das sind reine Behauptungen, nichts weiter. --Marcela 21:32, 3. Jun. 2012 (CEST))von oben...

Gerade bei 3D-CAD Daten sind IGES und STEP (immerhin nach ANSI bzw. ISO genormt) im Maschinen und Fahrzeugbau die erste Wahl...

Wenn es nur um 2D und weniger um Zeichnungsaustauschtausch geht ist DXF noch das Mittel der Wahl...

2D und DXF werden auch gern zu Wahrung von Firmendaten verwendet, wenn man kein 3D-Modell freigeben will...

Für die Archivierung von Zeichnungen, geht wird in der Regel heute noch TIFF auch noch HPGL/2 und nun verstärkt das PDF-A verwendet. Du kenst Ja das Thema auch..

Das willts Marcela ja nicht glauben? Aber es ist die Wahrheit in der Industrie. In der BAUGRUBE mag man bescheidener leben, andere sind aus guten Gründen weiter...

Hör endlich auf M. "alte Weisheiten" in der WP zu verkaufen, das ging schon einmal bei speicherre... schief...--109.43.102.61 04:46, 4. Jun. 2012 (CEST)

Ja, reine Behauptungen. Zwar wurden IGES und STEP schon vor zehn Jahren signifikant verwendet, im Fahrzeugbau IGES schon häufiger als DXF, aber die Jungs von der FH Trier haben wahrscheinlich auch keine Ahnung. [1] 178.200.103.51 18:14, 5. Jun. 2012 (CEST)

Vorschlag: Ersatz des diese können sich am Markt jedoch nicht durchsetzen durch diese sind jedoch weniger weit verbreitet als DXF und das Einfügen der Studie der FH Trier als Beleg. Irgendwelche Einwände? Falls ja, dann hätte ich gerne eine sehr gute Begründung, warum eine Internetquelle der Studie einer Hochschule vorzuziehen ist... denn WP:Q sieht das etwas anders. --Jogy _{sprich mit mir} 18:23, 5. Jun. 2012 (CEST)

Nö, keinerlei Einwände meinerseits. --Marcela 00:02, 6. Jun. 2012 (CEST)

erledigt --Jogy _{sprich mit mir} 10:36, 6. Jun. 2012 (CEST)

....können sich am Markt jedoch nicht durchsetzen

die Russische Quelle Nr. 8 enthält korrekt folgendes, aber keine Wertung... 

Im Jahr 1979, bevor das technische Komitee, das von Boeing, General Electric Company und das US National Bureau of Standards (National Buerau of Standards, heute National Institute of Standards and Technology) bestand, wurde beauftragt, ein Verfahren für den Datenaustausch im Rahmen eines integrierten Computer-Aided Manufacturing entwickeln ( ICAM) für die US Air Force. Das Ergebnis dieser Bemühungen war die Beschreibung des Formats von IGES-Version 1.0, im Januar 1980 Im Jahr 1981 veröffentlichte er vom American National Standards Institute (ANSI) als Standard verabschiedet wurde.

IGES war die erste Standard-Format für den Datenaustausch, speziell auf die Bedürfnisse von Spezifikationen für die Datenübermittlung zwischen verschiedenen CAD-Systemen gerecht zu werden.

Frühe Versionen von IGES wurde implizit bei CAD / CAM-System der 1970er und frühen 1980er Jahre ab., Das heißt, vor allem über den Austausch von Zeichnungen. In späteren Versionen der Reihe von Datentypen ausgetauscht werden erweitert worden. Zum Beispiel unterstützt Version 2.0 der Austausch von Daten-Analyse von Finite-Elemente-Methode und die Daten der Leiterplatte, in der Version 3.0, die Kapazität von benutzerdefinierten Makros, die eine wichtige Rolle dabei spielen, den Austausch von Standard-Bibliotheken von Teilen, in der Version 4.0 die Unterstützung für einen Baum CSG eingeführt, in der Version 5.0 eingeführt Prozess Datenstruktur des B-Rep.

Format DXF (Drawing Interchange Format - Drawing Interchange Format) wurde entwickelt, um den Anwendern Flexibilität im Datenmanagement und Konvertierung von AutoCAD-Zeichnungen in den Dateiformaten, die lesen und anzuwenden, die von anderen CAD-Systemen können. Aufgrund der Beliebtheit von AutoCAD DXF-Format hat sich zum de facto Standard für File-Sharing-CAD-Zeichnungen für nahezu alle CAD-Systeme. In der Tat, in fast allen Schwellenländern CAD-Übersetzer zur Verfügung im DXF-Format und zurück.

DXF-Datei - eine textbasierte ASCII-Datei, die aus fünf Abschnitten besteht: Header (Titel), Tabelle (Tabelle), Block (Block), Entity (Element) und Beenden (Ende). In der Header-Abschnitt wird beschrieben, Mittwoch AutoCAD, die DXF-Datei erstellt wurde. In der Tabelle gibt Auskunft über die Arten von Linien, Ebenen, Text Stile und Typen, die in der Zeichnung identifiziert werden können. Im Block enthält eine Liste von grafischen Elementen, die als Gruppe definiert sind. Spezifische Daten für die einzelnen Elemente werden in dem entsprechenden Abschnitt des Entity, die unmittelbar auf die Abschnitt-Block gespeichert. § Entity - das ist der Hauptteil der DXF-Datei, die alle Elemente in der Zeichnung beschreibt.

IGES und DXF-Formate wurden entwickelt, um technische Anforderungen zu kommunizieren, anstatt Daten über das Produkt. Unter den Daten über das Produkt verstehen wir die Daten über den gesamten Produktlebenszyklus hinweg.

Obwohl die Spezifikation von IDES und DXF-Dateien erweitert worden sind, einige dieser Daten ™ enthalten, die Informationen in diesen Dateien enthalten sind, in der Tat nicht aus, um den gesamten Produkt-Lebenszyklus beschreiben. Infolgedessen begannen die Vereinigten Staaten im Jahr 1983 die Entwicklung einer neuen Standard namens die PDEs (Product Data Exchange Specification - eine Spezifikation für den Austausch von Produktdaten-Management).

Im Mittelpunkt der Entwicklung von STEP auf folgenden Grundsätzen basiert.

Design, Produktion, Qualitätskontrolle, Tests und Support: STEP Standard sollte auf Produkt-Daten, die Informationen über alle Produkt-Lebenszyklus umfassen konzentrieren. So sollten die Daten als Informationen über Toleranzen, technologische Merkmale der Form, Finite-Elemente-Modell, ein Modell für die kinematische Analyse, etc., sowie Daten-Spezifikationen vor allem auf die Form der Ware im Zusammenhang betrachtet werden. Im STEP Datenstruktur Informationen im Zusammenhang mit der Anwendung muss in den Modul-Level-Anwendungen gespeichert werden, abgesehen von allgemeinen Informationen über die Form. Mit diesem Ansatz kann die Datenstruktur einen weiten Bereich von Anwendungen, während Vermeidung von Redundanz in der gesamten Struktur der Daten. Um die Struktur der Daten zu bestimmen sollten formale Sprache verwendet werden. Specification IGES und DXF-Format beschriebenen physikalischen Datei, die alle geometrischen und anderen Daten enthält. Im STEP-Daten werden in der Sprache EXPRESS beschrieben, und dann wird das Ergebnis in einer physikalischen Datei umgewandelt. Auf diese Weise können die Mehrdeutigkeiten in der Interpretation von Daten über das Produkt, aus der Datei extrahiert vermeiden können. (nicht signierter Beitrag von 2.205.239.203 (Diskussion) 08:24, 18. Mai 2012 (CEST))

Das kann man kaum als Übersetzung gelten lassen, war wohl eine Maschine? --Marcela 21:38, 3. Jun. 2012 (CEST)

Dann gebe doch BITTE SELBST eine NEUTRALE deutsche Quelle an! Als hier selbst mit unverständlichen auch Russischen Quellen zuarbeiten!--2.200.168.7 04:02, 4. Jun. 2012 (CEST)

Ralf, einen Vorschlag zur Güte: Such die Stelle aus der russischen Übersetzung heraus, an der die Wertung steht und übersetz diese für uns. Quellen müssen nicht in deutscher Sprache verfasst sein, sollten aber nachvollziehbar sein. Und da die wenigsten hier russisch lesen können, ist das etwas schwer. Weiterhin wäre noch interessant zu erfahren, welche Expertise diese Seite aufweisen kann, um eine solche Aussage zu tätigen. Da ich des Russischen nicht mächtig bin, kann ich nicht beurteilen, ob das eine nach WP:Q valide Quelle ist.

Ich stehe gerade selbst vor dem Problem einer Softwareumstellung meiner Konstruktionsabteilungen und wenn ich die Softwarehersteller frage, wie man die 3D-Modelle am besten in die neue Software rettet, dann höre ich von allen: STEP. Von daher kann ich die Wertung im Artikel nicht so ganz nachvollziehen, beuge mich aber natürlich einer guten Quelle - ich habe auch nur die Binnensicht aus meinem Unternehmen und keinen Überblick über den Gesamtmarkt. --Jogy _{sprich mit mir} 18:09, 5. Jun. 2012 (CEST)

Es hat schon seinen Grund warum man Step und alternativ IGES bei 3D empfiehlt...

Besser sind direkte Konverter die die Ursprungsparametrik auch in das neue 3D-System übertra<gen könnnen sollen, das ist um Welten besser als DXF, STEP und IGES... --77.24.129.117 19:38, 11. Jun. 2012 (CEST)

Ok, werde ich machen, dauert aber etwas. Bin grad im Bildereinsatz in Österreich. Aber es ist schon komisch, englische Quellen werden immer und überall bedenkenlos durchgewunken, für russische muß eine Übersetzung her. Welches Format zur Datenrettung optimal ist, hängt von Quelle und Ziel ab. Da kann durchaus STEP erste Wahl sein. Wenn man aber das Ziel nicht kennt, möglichst weit kompatibel sein will oder an Langzeitarchivierung denkt, dann ist DXF dran. Es ist der kleinste gemeinsame Nenner, mit allen Fehlern und Problemen. --Marcela 00:08, 6. Jun. 2012 (CEST)

Schon wieder ein neues Thema hier: "Datenrettung" und das alte Märchen von der Langzeitarchivierung....

Naja DXF kann viel, aber ist nur bei einfachen 2D-Themen manchmal kleinste gemeinsame Nenner, wenn man bei der Übertragung auf eine Besonder Qualität von Kurven verzichten kann...--77.24.129.117 19:38, 11. Jun. 2012 (CEST)

Das ist einfach die Sprachbarriere, Englisch verstehen die meisten mehr oder weniger, bei Russisch sieht das ganz anders aus - und wenn dann der Inhalt der Quelle der eigenen Erfahrung widersprechen soll, will man es doch lieber genauer wissen. Dass DXF verbreiteter ist, stelle ich gar nicht in Frage, nur zwischen "eines ist verbreiteter als die anderen" und "die anderen konnten sich am Markt nicht durchsetzen" ist noch ein weiter Weg. Aber schon mal Danke im voraus, dass Du Dir die Mühe der Übersetzung machst. --Jogy _{sprich mit mir} 10:40, 6. Jun. 2012 (CEST)

Defekte Weblinks

• 1.1.1.5/bmi/www.dxfmagic.homepage.t-online.de/HomepageClassic01/dxfmagic/press3.jpg
• www.infograph.com/products/dwgviewer/ (Internet Archive)

– GiftBot (Diskussion) 04:09, 2. Sep. 2012 (CEST)

• http://1.1.1.5/bmi/www.dxfmagic.homepage.t-online.de/HomepageClassic01/dxfmagic/press3.jpg ist erreichbar, kann nicht kopiert werden, wäre URV
• Link ist geändert: infograph.com --> http://www.myriadviewer.com/download --Marcela 07:04, 2. Sep. 2012 (CEST)

Also der erste Link geht bei mir nicht. – Giftpflanze 21:19, 8. Okt. 2012 (CEST)

Bei mir geht er. Andere Erfahrungen? --Marcela ¿•Kãʄʄchen•? 10:53, 19. Nov. 2012 (CET)

Erledigt Frohes Schaffen, Boshomi ☕⌨☺ –  01:52, 16. Feb. 2013 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: 109.43.170.244 09:37, 10. Nov. 2013 (CET)

"Dimensionslos"

Es ist unglaublich, dass in einem aktuellen CAD-Austauschformat keine Informationen zur verwendeten Koordinaten-Einheit gibt: "DXF-Dateien sind grundsätzlich dimensionslos, so dass der Benutzer einer fremden DXF-Datei die in der Zeichnung verwendete Einheit kennen muss." Ein Mensch muss also entweder den Erzeuger der DXF-Datei nach der Einheit fragen oder er muss sie aus den textuellen Kommentaren in der Zeichnung heraussuchen. Ein Importfilter einer anderen Software kann die Einheit nur raten. Unglaublich... --93.230.97.220 09:25, 13. Jan. 2015 (CET)

Nicht unglaublich sondern gewollt. Nur so kann man weitestgehende Kompatibilität gewährleisten. Es ist auch kein Problem, im Ingenieurwesen wird ja prinzipiell im mm bemaßt. Wer sich nicht daran hält, arbeitet sowieso entgegen der Normen. --Pölkky 09:35, 13. Jan. 2015 (CET)

Mag für den Mechaniker in Deutschland stimmen. Im Chipdesign arbeitet man mit nm. Beim Hausbau in cm. Beim Leiterplattendesign in mil oder mm. Beim Rohrdesign (Spenglerei) in Zoll. In Amerika und im GB-Raum ist das metrische System gänzlich unbekannt. Es ist in Wirklichkeit ein schwerer Designfehler. Am Anfang wurde es versäumt und die Leute haben nach Herzenslust Maße an "ihre" Koordinaten geschrieben. Dann konnte man keine Maßeinheit mehr nachrüsten, weil alle alten Projekte dadurch zweideutig geworden wären. --93.230.97.220 16:50, 13. Jan. 2015 (CET)

Hausbau wird im mm bemaßt. daß deutsche Architekten da ein Extrasüppchen kochen wollen, tut nichts zur Sache. Es ist kein Fehler sondern absichtig so gewollt, weil man die Dimensionen auch nachher ändern kann. Der Maßstab des Ausdrucks ist bei Beginn der Arbeit unbekannt. Das ganze ist auch keine Eigenschaft von DXF sondern aller weitverbreiteten CAD-Programme. --Pölkky 16:58, 13. Jan. 2015 (CET)

Fehlerhafter Link

Der Hyperlink zu Quelle: 9. (Формат IGES Формат DXF Формат STEP Vergleich der Formate IGES, DXF und STEP (russ.)) funktioniert nicht mehr. Die Domain existiert nicht (mehr). -- 13:19, . 29. Apr. 2020 (CET) (nicht signierter Beitrag von 141.44.29.252 (Diskussion) 13:21, 29. Apr. 2020 (CEST))