In this issue, we present reaction from our readers to the OpenDWG Alliance. As you read the letters, you'll see that three camps are emerging: (1) those who favor the actions of OpenDWG; (2) those who don't; and (3) those who don't think DWG is the answer, whether coming from Autodesk or OpenDWG. Some letters have been edited for brevity and clarity.
Our first letter is from independent DXF expert, Dietmar Rudolph, who explodes some of the myths surrounding the content of DWG and DXF files. Dietmar <dietmar_rudolph@compuserve.com> is a CAD consultant and co- author of "DXF Standard," a 500+ page book about DXF.
In the meantime, we are waiting to hear back from the OpenDWG
Alliance as to what is happening with AutoDirect 3, the read/write/display
DWG API (the OpenDWG Toolkit is based on AutoDirect 2, the read/write API).
-- Editor
In DWG, floating point numbers are stored as 64-bit values. In DXF the user can select the precision necessary for a specific task (I don't know of any CAD drawing with more than 6 digits of _precise_ data). With the binary option, the DXF file is exactly as precise as the DWG. If someone says differently, this only shows how little they know about data exchange.
About the encryption of ACIS _data_ in a DXF file, there are two things to talk about: which data, and how is it stored. (1) Which data: AutoCAD uses the ACIS library from Spatial Technology, which uses and manipulates its own data. The internal format and meaning of this data is separate from AutoCAD. The ACIS library itself has a data exchange function that creates SAT format files (now published by Spatial). Since AutoCAD drawings contain ACIS- specific objects, the DWG must be a container for the internal ACIS data. We may argue whether it's Autodesk's task to document this ACIS-internal data or to provide an API to use it.
(2) How the data is stored: Luckily for the developer of data exchange programs, all three files [DWG, DXF, SAT] contain the same information formatted almost the same. Neither of the three formats is plain English and of course you need to know where to find which information. In SAT, you'll find keywords and numbers; in DXF, you'll find the same data bit-shifted and chunked to fit to the DXF line limit; in DWG, you'll find the same data with another modification, probably.
DXF and DWG do _not_ necessarily contain the same level of information about custom objects, however. This is a serious limitation and defect of DXF, which could be easily solved by Autodesk. Application programs running inside of AutoCAD are allowed to extend the DWG file with client- specific information. It's up to the developer to: (1) decide what to store in the DWG; (2) to document what and how it is stored; and (3) -- and here's the problem -- to decide if and how to expose the information to AutoCAD APIs and DXF. This means that an application developer is allowed to store data in DWG but not export it as DXF. Of course this only solves the DWG<->DXF differences. It does not solve the general problem inherited in application-defined data: format and meaning. Even if the application data is available to external programs, it is still useless. DWG and DXF are only containers for undocumented data that AutoCAD or other programs know nothing about. This is true for ACIS data; it is true for OLE data (which _is_ in both DWG and DXF); and it is true for application-defined data. (When you paste an Excel spreadsheet into an AutoCAD drawing, the Excel data is in DWG and DXF. But you cannot use it until you know how _Excel_ stores its data.)
The main problem of data exchange has absolutely nothing to do
with DXF versus DWG or with DWG being documented or not. The main problem
is how to exchange different descriptions of CAD objects from one product
to another. Today, most DXF filters are extremely bad, because their developers
either did not understand the DXF specs or they were unable to translate
foreign data structures to DXF objects. This may become better if more
companies use a common toolkit to read/write AutoCAD data, may it be the
OpenDWG toolkit or Autodesk's DWG unplugged. However, this has nothing
to do with DWG and/or DXF, since both toolkits accept either format just
fine.
-- Dietmar Rudolph
DWG sans ARx is a Autodesk's method of representing dumb drawing data. DWG with ARX is Autodesk's method of representing intelligent model data.
To my mind, these are two distinct standards, and lumping them together does nothing to clarify the issues. There may be minor aspects of DWG sans ARX which are proprietary, but for the most part it is a de facto industry standard, supported by many other vendors. DWG with ARX, however, is not a standard -- it is a proprietary format, and is arguably the intellectual property of Autodesk.
Users are unlikely to particularly care whether they have "100% Pure Autodesk DWG" or OpenDWG. They tend to care more about having tools to get their jobs done better, faster, and at a lower cost.
That being the case, this whole OpenDWG debate is just a red herring.
The *real* issue is AutoCAD R14 versus IntelliCAD 98. And that debate will
be played out in the marketplace.
-- Evan Yares
One of the problems with the OpenDWG toolkit is that its API is very raw with a steep learning curve to produce a valid DWG file. It requires the programmer to have an extensive knowledge of DWG -- it does very little validation, making it easy to produce a drawing AutoCAD won’t like. Our fear is that the number of corrupted drawing files may increase.
A better solution would be to create DWG files through an API, such as [SoftSource] Vdraft or AutoCAD. They automatically validate the data, require much less knowledge of DWG to produce results, display drawings (a notable omission in the OpenDWG toolkit), and can manipulate the data in more complex ways. And using an object-oriented API, such as VDraft’s, makes the code much easier to write and maintain (see http://www.vdraft.com/vdev/sample.html for an example.)
It’s one thing to read and write a file format, but it’s quite
another to manipulate it correctly.
-- Scott Sherman
OpenDWG may be a great marketing tactic, and there's for sure some pretty close thinking behind the Alliance, but for sure it is a _serious_ attempt to solve real _customer_ problems. Otherwise there wouldn't be a free subscription.
What is the most praised R14.1 update feature? The Content Explorer. Users have wanted this for ever, seeing blocks in other drawings: "Where the h*** have I defined this block?" The OpenDWG Toolkit allows you to do just this.
Well, it's just a C-library and not in a customer-level language. But the Autodesk API is only for C++ programmers too. (For example, accessing thumbnails in DWGs or AcDb, which is not available in AutoLISP or VBA.) With this free toolkit (free for non-commercial use) users could easily compile an ARX and export the needed functions to AutoLISP.
I need it for setting handles back, extracting attributes, and
getting block names. Other features would include external purging and
conversion to DXF. Teachers need it for checking cheaters.
-- Reini Urban
Why don't you ask Carl Bass to stop evading the real issue for Autodesk customers, which is not why the data is encrypted, but why there is no API within plain vanilla AutoCAD, to allow the customer to get at the data. You and he, and I all know d*** well that this is what APIs are for, and that an API to ACIS entities would ensure compatibility regardless of what happens to the underlying format, or even the kernel in use.
We also know for a fact that when R13 was released, Spatial Technology had such an API ready to go, that would have given AutoLISP and ARX programmers full access to ACIS- based AutoCAD entities.
We also know for a fact that Autodesk didn't want this API, or any other ACIS API to be available in vanilla AutoCAD, because Autodesk deliberately wants to impede and restrict all AutoCAD-based competition to Autodesk Mechanical Desktop (there is no need to debate Autodesk's anti competitive tendencies).
There is little hope for a company that has so many conflicting
interests with its own customers, as does Autodesk.
-- Tony Tanzillo
[Autodesk replies: I was not a part of the Release 13 cycle, so I was not privy to the decisions and trade-offs made bringing that product to market. You may have a point in the lack of a straightforward API via AutoLISP and ObjectARX to the ACIS objects, and this is an issue that I will look into the R13 history to educate myself. I don't think this was an attempt for us to keep ACIS to ourselves (to begin with it belongs to STI!).
As always, I politely disagree with the conclusion that you draw that this is somehow "anti-competitive" or "anti- customer" because: (1) there were ACISOUT commands present in R13 to get the data out; (2) there is an API (the MAI) to access B-REP data; and (3) any true competitor can easily license ACIS from Spatial and have full API access.
Also, I've since found out that the bit-swapping was mainly to
represent SAT in ASCII format to make the DXF data portable, not for encryption.
-- Amar Hanspal]
I think more attention should be focused on use of the more compact
and accurate Binary variant of the DXF format. Rather than opening-up AutoCAD's
own local storage format, I'm more inclined to support expansion of the
DXF format into a true inter-system exchange medium, with all CAD makers
contributing to its evolution. It wouldn't be too hard for a committee
to regulate its details and publication, and for CAD producer's to add
new Group-Codes as needed to suit new objects.
-- Geoff Harrod
Visio is trying to get people to pay $5,000 up front plus $2,500/year for something (AutoDirect 2) that MarComp charged a one-time fee of less than $1,000. So rather than "opening up" the DWG format, it seems to be a way to charge far more for the same product.You will notice that there is no mention of MarComp's more extensive AutoDirect 3 product (AD2 was read and write, AD3 added display capability. AD3 required royalties while AD2 did not).
The second point is that by joining the Alliance at _any_ level,
you are REQUIRED to provide the Alliance with _everything_ you know or
learn about DWG. Yeah, right. I am just sure that is going to happen. Since
each of the founding members get source code, are expected to make changes,
and then provide those changes back to everyone else, can you imagine the
configuration control problem involved to make that actually work? I fail
to see any realistic scenario that will make this work.
-- Scott Taylor
Never mind what Amar or Carl have to say about DWG, one fact undermines their stance: Autodesk is -- and has been for awhile now -- advertising on the back-end of 100% DWG compatible. Why advertise that the file format is 100% compatible? I would suggest it's because users are scared of loosing the integrity of their data; Autodesk is playing to the strength that they 'own' DWG and can guarantee its readability and writability.
Where's the added value in attempting to correct an error? DWG was compressed to its current extent out of necessity. R13's DWG file format swelled by at least 40% and had to be compacted.
On the other side, there's no doubt in my mind that the customer's
advantage in all this is a minimum. The main element here is the attempt
to remove one of Autodesk's "competitive advantages" with the OpenDWG Alliance.
Visio and partners are trying to use the weight of its opponent to win
-- it's a Judo move. I guess Autodesk feels picked on -- this is what happens
in a highly competitive business ecosystem.
-- Martyn Day
Is it not obvious that their [members of the OpenDWG Alliance] file
formats cannot compare to DWG. Otherwise, why would they bother trying
to open up DWG if they had a superior product? They are just re-affirming
everyone's decision to use Autodesk products since they are superior.
-- Richard Boothman
Well now, regarding the movement afoot by 15 or so of the CAD software
venders to impose the Autodesk drawing format upon all of us. Some of us
may not be so eager to give up the line widths, quality text, color as
color rather than pen numbers, and many other superior drawing entity properties
that have never been included in the AutoCAD drawing file format.
-- Noel Browning
About the Autodesk statements: Their positive attitude towards exchange
standards and DXF would be a little bit easier to believe if they did not
make a marketing point out of "AutoCAD LT) being the only product fully
compatible with AutoCAD (drawing files). They're essentially selling on
other's incompatibility, while doing very little make it possible to become
compatible. Their DXF docs is some of the most incomplete and inaccurate
documentation I've ever seen.
-- Name withheld by request
In response to the OpenDWG guys: All you are putting forth is a way
to have DWGs without paying for them. Users and developers are always looking
for the free stuff. Here is a way to dig into Autodesk's toy box without
having to pay for the key. Autodesk is on my doodoo list but I firmly support
them in their stance that reverse-engineering their product is nothing
more than a way to make bucks from their efforts without paying them royalties
(which, if available, would probably be cheaper than development costs
associated with reverse-engineering). In short: if you want something badly
enough, pay for it. If not, then do without. Either way, don't steal it.
-- Cliff W. Estes
Even if it should fail, I admire this open DWG foundation attempt. What
I entertain in my mind is that if, in the spirit of pollution "credits,"
Microsoft and Autodesk might actually pay out their cash to hard working,
faster- thinking, more creative, small companies for their own solutions
to Word macro viruses, bloated file size, and stability issues that these
two behemoths have spewed into the world.
-- Ben Logan
Whatever the reason for switching [to another CAD package], the user wants to take all of his data with him. And, in the vast majority of cases, that data DOES translate into the new package 100% intact using available third-party DWG or DXF translation technology. Any details that are missing can usually be restored by recreating them in the new system. In many cases, the legacy data is used to produce more valuable, higher order data, such as parametric solid models from 2D legacy drawings.
This is why AutoCAD or any incumbent will use any means available
to protect its domain. From feigned indifference and scorn, to an aggressive
legal defense of its "intellectual property" to the removal from the market
of any company that threatens to open the floodgates to making arbitrary
changes to the format. This is natural. It is also natural that the OpenDWG
alliance must exist as well...
-- Jeffrey Hall
It seems possible to me that AutoCAD could do one (or both) of the following:
(1) scramble /encode DWG files so that they are extremely difficult to
decode; (2) add a copyrighted string somewhere in the file. If AutoCAD
fails to find the string, it doesn't open the file. No other vender can
create such a string because it is copyright protected.
-- Dave Greenbaum
What frustrates me is that this new "cartel" has been established with
the apparent purpose of instigating a fight with Autodesk. If I want to
continue to use this DWG product, I have to join the cartel as well.
I presume Autodesk would like to see this illustrious group spend as much
money as possible on projects such as this, keeping the funds away from
various other research and development.
-- Name withheld by request
I liked your analysis of the DWG issue in your latest eZine. Looks to
me like the founding of the Royal Society for the Preservation of the Steam
Engine -- at the dawn of the nuclear age.
-- Kenneth Shain