« March 2006 | Main | May 2006 »
Autodesk customers want to publish DWF files to share design data with other project members. They appreciate the benefits of: small file size, ability to measure accurately, no hassles with missing XREFs, multiple sheets in one file, single file for data from a variety of sources, and protection from sharing intellectual property in its original form; however, even though DWF files are print-ready, they are curious as to what will happen with their DWF files if they send them to commercial reprographers?
Commercial reprographers who provide "print for pay" services have a variety of options at their disposal.
makeldf "%f" /D=%d /DWFD=1
HKEY_CURRENT_USER\Software\Oce\ORT\Common\Process\
Process DWG\...
REG_DWORD: "Dont Show LDF Driver Warning" set to 1
These software packages are popular among commercial reprographers. Odds are that a reprographer has one of them. If an Autodesk customer or reprographer wants to print DWF files using a device's Windows System Printer driver, there are options available.
DWF does go beyond the paper in that it allows design data to be shared and managed as compared to plot files; however, DWF can also be put to paper via software used by commercial reprographers. The benefits that DWF provides make it the format of choice for many projects. This choice (see comparison of file formats) even applies when sending files to commercial reprographers for printing. Autodesk customers want to generate one file and use it for sharing, managing, and printing. Thanks to the efforts of our DWF Partners in the commercial reprographics industry, they can.
The traditional model for sharing design data through commercial reprography includes a print then distribute operation.
We have all used a process like this many times. How many times have you had something copied at the UPS Store or FedEx Kinko's? It works just like that but is larger in scale due to the higher volume needs of the construction industry.
With DWF we are attempting to move to a distribute then print operation.
In this process, the General/Sub Contractor has the option to print locally or continue to use a reprographic shop. The data has been distributed in digital form prior to printing. He is free to make use of solutions such as Autodesk Design Review or the free Autodesk DWF Viewer. DWF goes beyond the paper; however it also has implications for how project members actually get their paper.
The DWF Frequently Asked Questions (FAQ) document has moved. It will now be maintained at:
http://dwf.blogs.com/articles/DWF_FAQ.htm
In its previous form, the DWF FAQ was a 68 page Word document that was approximately 1MB in size. The HTML file that will now be maintained as part of this blog is an index that points to other locations. This allows the FAQ to always reference the latest and greatest information. Perhaps some of you liked being able to print out one 68 page document and have the encyclopedia of DWF all in one place? If so, please let me know. If I can develop a process to generate a single document from the various web location, I may do it; however, I must first know that there is a need before even considering it.
There is a list of SHORTCUTS in the left hand portion of this blog. It appears at the bottom of the left navigation panel. The DWF FAQ is a member of that list. The DWF FAQ image has also been added as a hyperlink in the top of the left hand portion of the blog. In the words of Sergeant Joe Friday from the Dragnet TV show: "Just the FAQs ma'am."
In an earlier article, I mentioned that the Autodesk DWF Writer is not for AutoCAD. I developed this article because through my contacts with users in the AutoCAD discussion groups, I encountered customers configuring their page setups to reference the DWF Writer for 2D instead of using the DWF6 ePlot PC3 file. Allow me to make a South Park reference and say:
GDI is Microsoft's Graphics Device Interface. "GDI is bad" is really an overstatement for comedic effect. It works quite well for interfacing with printers. It's just that when it comes to DWF generation, we can do better. This posting is intended to illustrate why - albeit in an overly technically simplified way.
All Autodesk products generate DWF files. Both the Autodesk DWF Viewer and Autodesk Design Review read DWF files. AutoCAD 2007 can read a DWF file as an underlay to a DWG. So we have various products that read and write DWF files. Rather than have each department within the company develop its own code for reading and writing DWF files, we centralize it into one set of code known as the DWF Toolkit. The DWF Toolkit handles both the reading and writing of DWF files. This includes all DWF files - those published by AutoCAD 2007 or even those as far back as AutoCAD R13. We make the DWF Toolkit available publicly on the Autodesk web site.
When an Autodesk design application such as AutoCAD or Inventor interfaces directly with the DWF Toolkit, it has a variety of operations it can perform. It can set colors, draw polylines, draw polygons, draw gradients, etc. Setting attributes and placing geometry in the DWF file accounts for what you see when you view the file; however, in addition to this, the design application can add other information like named views, layers, hyperlinks, or object properties.
This other information, i.e., extra data, is what separates DWF files from traditional plot files.
The Autodesk DWF Writer for 2D acts like a printer. To interface with software applications, it accepts the same standard commands that printers do. Autodesk applications have been specifically developed to interface with the DWF Toolkit. non-Autodesk applications have not. On the other hand, non-Autodesk applications do know how to interface with a printer. Any Windows program knows how to use the standard Windows print mechanism through GDI. The Autodesk DWF Writer for 2D takes advantage of this fact. It acts like a printer, accepts the commands, and instead of putting ink on paper, writes the commands to the DWF file.
Though this approach allows DWF files to be created from applications that have no knowledge of DWF, it does not provide a means of getting the extra data into the DWF file. There are no standard GDI provisions for sending non-drawable items such as hyperlinks or named views to a printer. (Special tricks are available, but both the application and the printer must implement them to make it possible.) Other factors such as gradients or transparency (only available in GDI plus) are not handled optimally as part of DWF publishing via standard GDI. For example, gradients are decomposed into many, many small images. As a result, it is common for a DWF file to be larger when generated from the Autodesk DWF Writer compared to its size when generated from the built-in process of Autodesk design applications. So although the DWF Writer for 2D is valuable in that it allows Autodesk customers to create DWF files from non-Autodesk applications, it is not a substitute for using the built-in DWF publishing capabilities of Autodesk design applications.
The Autodesk DWF Writer for 2D is best used in conjunction with Autodesk software.
This allows a project to share one repository of all of its information in one file - design data and other data. The Autodesk DWF Writer has its rightful place in the world of DWF - it's just better, due to technical limitations of any approach using GDI, to use the built-in publishing capabilities of Autodesk products when possible.
Vespa is amazing. Everyone's talking about it:
So I thought I would try it myself. I drew this in AutoCAD 2007:
I then generated a DWF file. I loaded the DWF into Vespa. I applied a visual style:
I must say this Vespa thing works pretty well. This DWF file looks good. (Yes I am kidding about the rendering shown here - but not about the application.) I don't know if I should say, "Vespa - software so good, it's turns your designs into works of art" or "Vespa - software so good, it's as if it was coded by Da Vinci."
Subscribe