Outside The Box blogs, Autodesk University anecdotes, articles, blog digests, and product news in chronological order. See Writing for the same material by subject.
No matter the communication protocol used to transmit it, most information gets packaged into a file format for consumption. File formats are like virtual checkpoints along the information superhighway, and we would do well to pay attention to who is manning the gates.
We’ve heard a lot of noise lately about the need for “open” file formats, but documenting a file format is not the same thing as relinquishing control of the format. The key consideration is who decides when and how the file format changes. This is a dirty little secret about file formats that you are not supposed to know. By controlling when and how a file format changes, an organization can maintain a mindshare monopoly over consumers of its file format – even when the format is “open”.
It may be that the relative anarchy of the internet has given us a false sense of security. We happily use “open” formats like PDF, DWF, DXF, HTM, and others with relatively little concern about who controls them, but all of those formats (HTM perhaps to a lesser degree) are controlled by corporations whose allegiance is first and foremost to their shareholders. For example, PDF is “open”, but did you know that third party developers need a digital ID signed by Adobe in order to create forms-enabled PDF files that can be opened in the free Acrobat Reader?
In April of 2006, Autodesk filed a trademark application for the word “DWG” when used to refer to DWG files. This may seem benign on the surface, but if successful it will give Autodesk more legal leverage in “defending” the file format. A few weeks ago, Autodesk filed a trademark infringement lawsuit (http://www.cadcourt.com/Docket/206cv01637AutodeskvODA.aspx) against the Open Design Alliance claiming that the ODA infringed their “AUTODESK” trademark by embedding the mark inside DWG files created with its DWGdirect libraries.
Much has been written by the pundits about the pros and cons of the ODA lawsuit, and the Electronic Frontier Foundation predictably suggests that Autodesk is using trademark claims to stymie interoperability, but the bottom line is that the contention centers around a file format – a file format that Autodesk considers valuable enough to wage war over.
If you’ve been programming with ObjectARX for a while, you already know that each version of the ObjectARX SDK only works with a specific version of Visual Studio. Mazhar Basa touches on the subject in his article Components of ObjectARX Applications (http://www.dailyautocad.com/objectarx/components-of-objectarx-applications/). My VCBuildHook utility makes it possible to build for multiple target AutoCAD versions from a single Visual Studio 2005 solution, but this utility still needs the older versions of Visual Studio to be installed on the same system in order to perform its magic.
The problem is, legitimate licenses of older versions of Visual Studio are hard to come by. Back in the Visual Studio .NET 2003 days, you could purchase a new license of VS 2003, then get a free license downgrade from Microsoft that allowed you to install Visual Studio 2002 side by side on the same system. That combination allowed you to target AutoCAD versions as far back as AutoCAD 2004. Unfortunately, Microsoft stopped offering the VS 2002 downgrade license when Visual Studio 2005 began shipping in November of 2006.
The end result is that new ObjectARX programmers are faced with a dilemma if they need to target anything older than AutoCAD 2007. One of the attendees at my “High-Octane ObjectARX” class at AU 2006 reminded me that MSDN (Microsoft Developer Network) members can download older versions of Visual Studio from the MSDN subscriber download center.
I have verified that Visual Studio .NET 2002 (VS 2002) is available for download to MSDN Professional subscribers, but I could not find Visual Studio 6.0, which is required to target AutoCAD 2000 - 2002. Visual Studio 4.2 (required for AutoCAD R14) is available though, so maybe I’m just not looking in the right place.
If you are a professional software developer, whether commercial or in-house, you should consider subscribing to MSDN for various reasons. If you’re an ObjectARX programmer and need to target older versions of AutoCAD, MSDN may be the only way to obtain the older Visual Studio build tools and libraries that you’ll need.
Not according to the press release (http://pressreleases.autodesk.com/index.php?s=118&item=161). Vista (and .NET 3.0) includes a built-in XPS Viewer (http://www.microsoft.com/whdc/xps/default.mspx) (also available for Windows XP SP2 and Windows Server 2003), which will view any XPS format (http://www.microsoft.com/whdc/xps/downloads.mspx) file. Apparently Autodesk plans to add support for output to XPS format in the future, and this output will be called DWFx – a new file format. It’s not clear what the difference will be between DWFx and the output produced using the Microsoft XPS Document Writer (http://www.microsoft.com/whdc/xps/viewxps.mspx) that is already available.
I installed the Microsoft XPS Document Writer and XPS Viewer on my Windows XP SP2 machine. Next, I started AutoCAD 2007 and opened “3D House.dwg” from the Sample folder. I then plotted this file to DWF, PDF, and XPS, with the following results:
PlotterPlot TimeFile SizeDWF6 ePlot.pc37 seconds139 kbDWG To PDF.pc35 seconds165 kb
Microsoft XPS Document Writer34 seconds829 kb
I’m not suggesting that these files all contain the same content, I’m merely suggesting that DWFx/XPS may have some undesirable tradeoffs in practice.
This whole issue about “native Vista support for DWF” may be nothing but smoke and mirrors. There is no guarantee that publishing CAD data in the XPS format will be efficient. So what will happen if users can choose between a compact DWF, a slightly less compact but ubiquitous PDF, or a very space-hungry DWFx? Time will tell, but I think this issue of DWF in Vista is getting way to much spin and not enough critical analysis.