Copyright © 2000-2008
Autodesk, Inc.



DWF 6 Specification

 

 

Introduction

This specification outlines the basic structure for version 6 of the DWF (Deisgn Web Format) publishing format.  Autodesk, Inc. has made it a priority to rationalize our viewing and “Published File Formats” technologies.  Thus, due to the wide variety of design data produced by Autodesk software, the DWF format is being targeted as the publishing format that will hold all published image data, 2D vector data, 3D vector data, animations, metadata, etc.  To realize the single format, starting with a generic base container or package format is the most ideal approach.

 


Purpose

The DWF 6 format is essentially an enhancement of the Autodesk Streamline DDP file format, thus leveraging proven in-house technology in an effort to reach this corporate goal. A file implementing the DWF 6 format may be referred to hereafter as a “DWF package”.

 


Users

The users of this document are internal Autodesk development temas as well as third party developers interested in creating applications which read and write DWF packages.

 

Design

Overview

The ZIP file format was chosen as the backing store mechanism for the DWF package for the following reasons:

·        It allows packing many files into one.

·        It can be organized into logical paths.

·        It preserves file attribute information.

·        It is compressed.

·        It is supported by all platforms.

·        ZIP implementation libraries for C/C++ and Java are freely available.

·        With some additional supporting code for reading and optimization during publishing, it can be streamable.

 

The DWF package will contain many kinds of design data such as 2D graphics, 3D graphics, package and section metadata, and other resource files. The content can be roughly divided into:

·        DWF metadata files – XML files that contain information pertaining to metadata and structure (author, title, creation time, section dependencies, section ordering, resource file descriptions, roles, mimetypes, etc.) and pertaining to the section (page information, design metadata, etc.).  The structural metadata is used to create logical objects (collections of files to represent a part or page, etc.).

·        Resource files – media or other content files that are referenced from the package/section metadata and are usually presentations of design data in various formats (ZGL, W2D, JPG, PNG, AVI, XML, TXT, DOC, etc.)


Minimum DWF requirements

A DWF package must meet the following requirements:

·        The first 12 bytes of the physical package file must contain the DWF version header (see below).

·        A manifest.xml file (herafter “the manifest”) at the root of the zip archive that complies to the manifest.xsd schema

·        File contents logically organized into sections, one for each component of the composite design, described by the manifest.

·        At least one resource file.

·        The manifest must contain an <Interfaces> element containing at least one <Interface> subelement that indicates a document interface supported by the DWF package.  An example would be the ‘ePlot’ document interface, which implies that the DWF contains at least one valid ePlot page. 


For example, the following files might be the only contents in a legal DWF package:

·        Manifest.xml

·        Section1\CostingEstimation.xls

 

Note: The CostingEstimation.xls file is simply an example and represents any type of resource file, and thus need not actually be an XLS file nor have any specific filename.

 


Document Interfaces

DWF packages provide a way to accumulate all the relevant publishing information for a design (or a collection of designs) into a single file that can be efficiently transported. DWF packages will be created either by design authoring tools and design file translators, or “plug-in” extensions to design applications. These tools might serve as translating exporters, augmenting the  “File Save As…” type of functionality.   DWF consumers can unpack the file and process or present the design data.

 

But how do we use these DWF packages once they have been published?  How do we recognize, in an extensible and generic fashion, what’s inside them?  We do so by implementing document interfaces.

 

In our context, the term document interface should not be confused with runtime interfaces as exposed by Java, C++ or COM objects.  It may be helpful to think of a document interface using a software analogy.  Whereas a Java, C++ class or COM object may implement several object interfaces, a DWF package may comply to several document interfaces such as ePlot, Streamline Part, Streamline Drawing, etc.  A C++ class that implements many interfaces may appear to be many different types of objects simultaneously; likewise, a package which implements several document interfaces may be read by many different types of clients and may contain many different “views” of the data.  The fact that a DWF 6 package may contain ePlot information does not preclude it from containing Streamline Drawing data as well. 

 

A DWF package is only interesting when it complies with one or more document interfaces that require specific information for document readers.  Document interfaces allow DWF consumers to identify the nature of the data at a very high level; and can be used to determine whether the data within is of value to the consumer.

 

Document interfaces defined by Xml schemas should employ a mechanism which places Xml schema versioning information in the document-level Xml object of each of the descriptor files which comprise the document interface. As a rule, a reader application must not attempt to continue processing a section with a major schema revision value higher than what it was coded to understand. However, if the minor revision value is higher, this indicates that the file may contain information unknown to the reader that can and should be skipped. It is the responsibility of the viewer or reader application to notify the user when either of these conditions occurs.

 


DWF version header

Since the beginning of the DWF format, the first 12 bytes of any valid DWF file have always contained the DWF file revision or version.  This continues with DWF 6.  By doing so, we leverage the requirement for DWF viewers to implement version checking and prompt the user when a file contains a version that is unsupported by the viewer.

 

The application generating a DWF file should specify the lowest possible revision that an application reading the file would need to support in order to properly use the data. As a rule, a reader application must not attempt to read a file with a major revision value higher than what it was coded to understand. However, if the minor revision value is higher, this indicates that the file may contain information unknown to the reader that can and should be skipped.  In both cases, it is the responsibility of the viewer or reader application to notify the user when either of these conditions occurs.

 

Minor revision updates would be justified when new sections or data stream types are added to the file yet older consuming applications can safely ignore the new data.  Another cause for a minor revision update would be if XML property metadata is extended that could also be safely ignored. However, if the data or file format is changed significantly enough to justify breaking backward compatibility, then the major revision value should be increased.

 

As an interesting note, DWF 6.0 is the very first revision of the DWF format that introduces a major revision change (the format version of DWF 5.5 was actually 00.55, whereas DWF 6.0 is 06.00.).  The major revision change is due to the fact that the underlying data transport has changed to a ZIP file format, and it is not possible for older readers to read DWF 6 files without modification.

 

Table 1 – File version header

Byte

1

2

3

4

5

6

7

8

9

10

11

12

Character

(

D

W

F

 

V

0

6

.

0

0

)

ASCII (Hex)

28

44

57

46

20

56

30

36

2E

30

30

29

 

Byte one is a left parenthesis.  Bytes 2-4 bytes are the characters "DWF" which identify this as a valid DWF file note that these characters are in upper case. Byte 5 is a space.  Byte 6 is the uppercase character ‘V’.  This constant is followed by a 5-byte revision number in the format shown in Table 2.


 

Table 2 - The 5-byte revision number

Byte

Value

Description

7 & 8

<00 .. 99>

ASCII integer; The major revision value of the format used.

9

.(period)

ASCII decimal point

10 & 11

<0 .. 99>

ASCII integer; minor revision value of the format used


Note, following the 12-byte header, the remaining bytes comprising the DWF package are those which makeup a standard zip file.

 


Resource Versioning

The DWF package serves as a transport for resources contained within. No provision is made in the DWF specification to honor resource versioning. It is entirely possible and likely that resource versions (e.g. WHIP! data) may change without affecting the DWF version. Developers of DWF consuming applications are responsible for implementing a versioning strategy that respects the versioning of resources which their applications are coded to understand. Such a strategy may be specified by the document interface which describes specific resource usage; however it is also entirely possible that the document interface version may not change while the version of a resource format contained within the document interfaces does change. It is the responsibility of the viewer or reader application to notify the user when action has been taken regarding resource version differences.


Manifest.xml

The manifest.xml file contains information describing the supported document interfaces, DWF package/file properties, sections and their contents, and section dependencies.  The manifest must describe at least one section, and a section must contain at least one resource file.

 

For convenience, resources within sections may be organized in ZIP subdirectories.  However, there is no requirement for adhering to a hierarchical directory structure as long as filenames within the ZIP archive remain unique.

 

A manifest is an ordered list of sections, each of which represents a logical component being published within the DWF package, perhaps representing an ePlot page, a mechanical part, an assembly, or a model. A section has a local name (in practice this is typically the same as the root of local filepaths within the ZIP directory structure), a user-friendly title for display, and a reference back to the original native data which was used when publishing the section.

 

There are a number of resources associated with a DWF package section. These may include XML descriptor files for describing domain-specific section information, .ZGL files for streaming 3D graphics, .W2D files for 2D graphics, presentation files, bitmap graphics, and more. Resources are collected into a table of contents for each section.

 

While sections can be self-contained and independent of one another, it is possible for there to be inter-section dependencies. We say that section S1 is dependent on section S2 if the logical structure of S1 contains a reference to S2. Dependencies should be maintained in the Manifest separate from the sections themselves.

 

The DWF-Manifest Xml namespace must define a document-level element to represent the Manifest (see below):

 

The <Manifest> XML element contains all <Interfaces>, <Properties>, <Sections>, and <Dependencies> elements for the DWF package. A <Section> identifies its <Source> and gives its <Toc> (table of contents, listing <Resource> files).  The next section describes these elements in greater detail.

 

Manifest.xsd (see the referenced files section above, and hereafter called "the Schema") defines the following elements and attributes:

Table 3 - Manifest Elements and Attributes

Elements

AnyProperty (abstract element)

 

Dependencies (collection of Dependency elements)

 

Dependency

 

Interface

 

Interfaces (collection of Interface elements)

 

Manifest (document object)

 

Properties (collection of AnyProperty elements)

 

Property (substitution group for AnyProperty)

 

Resource

 

Section (contains a Source and a Toc)

 

Sections (collection of Section elements)

 

Source

 

Toc (collection of Resource elements)

Complex Types

AllPropertyContent 

 

SimplePropertyContent (derived from AllPropertyContent) 

Global Attributes

sectionIndex

index

 

Href

string

 

Role

string

 

mime

string

DataType definitions

index

restriction 

integer 

 

SimplePropertyType

restriction (enum)

string

 

uniqueId (a UUID)

restriction (format)

string 

 

 


Elements

<Manifest> (Document Element)

 

<xsd:element name = "Manifest">

    <xsd:complexType>

        <xsd:sequence>

            <xsd:element ref = "Interfaces" minOccurs = "0" maxOccurs = "1"/>

            <xsd:element ref = "Properties" minOccurs = "0" maxOccurs = "1"/>

            <xsd:element ref = "Sections" minOccurs = "1" maxOccurs = "unbounded"/>

            <xsd:element ref = "Dependencies" minOccurs = "0" maxOccurs = "unbounded"/>

        </xsd:sequence>

        <xsd:attribute name = "version" default = "1.0">

            <xsd:simpleType>

                <xsd:restriction base = "xsd:string">

                    <xsd:enumeration value = "1.0"/>

                </xsd:restriction>

            </xsd:simpleType>

        </xsd:attribute>

        <xsd:attribute name = "objectId" type = "uniqueId"/>

    </xsd:complexType>

</xsd:element>

 

<Manifest> begins with optional <Properties>  Note: these properties are DWF-wide properties and are independent of the properties of any particular component, page or drawing published with the DWF package. <Sections>, <Dependencies>, and  <Interfaces> follow the Properties.

 

Being a document-level element, <Manifest> has a 'version' attribute. Derived from xsd:string, its content is constrained to a set of enumerated values representing released versions of the manifest schema. If not specified, the version information can be coded in a standard XML namespace prefix declaration, i.e. xmlns:dwf="DWF-Manifest:6.0". Note, the namespace declaration is automatically added by the DWF Toolkit, if it is used to create DWF packages. Developers not using the DWF Toolkit are responsible for adding the version information themselves (either through the 'version' attribute or a namespace prefix declaration.)

 

Also, <Manifest> has an 'objectId' attribute.  This is a unique UUID representing the package which can be used by automation systems to refer to this package in a database (i.e. if the filename itself changes, the UUID will remain the same.) 

 


<Properties>

 

 

<xsd:complexType name = "AllPropertyContent">

    <xsd:attribute name = "name" use = "required" type = "xsd:string"/>

    <xsd:attribute name = "category" type = "xsd:string"/>

</xsd:complexType>

   

<xsd:element name = "AnyProperty" type = "AllPropertyContent" abstract = "true"/>

 

<xsd:complexType name = "SimplePropertyContent">

    <xsd:complexContent>

        <xsd:extension base = "AllPropertyContent">

            <xsd:attribute name = "type" default = "string" type = "SimplePropertyType"/>

            <xsd:attribute name = "units" type = "xsd:string"/>

  <xsd:attribute name = "value" use = "required" type = "xsd:string"/>

        </xsd:extension>

    </xsd:complexContent>

</xsd:complexType>

 

<xsd:element name = "Property" type = "SimplePropertyContent" substitutionGroup = "AnyProperty">

</xsd:element>

 

<xsd:element name = "Properties">

    <xsd:complexType>

        <xsd:sequence>

            <xsd:element ref = "AnyProperty" minOccurs = "0" maxOccurs = "unbounded"/>

        </xsd:sequence>

    </xsd:complexType>

</xsd:element>

 

<Properties> is an unordered sequence of <AnyProperty> elements.

 

The AllPropertyContent complex type defines the attributes common to all properties: a required 'name' attribute and an optional 'category'.

 

By declaring the <AnyProperty> element to be abstract, we say that it establishes the head of a substitution group into which concrete elements and types can be added. A <Properties> element will not literally hold <AnyProperty> elements, but instead will hold elements from the Property substitution group: <Property>.  This allows for extensible property types which still can be managed using the common “AnyProperty” attributes.

 

A <Property> (a member of the AnyProperty substitution group) extends AllPropertyContent to represent a name + value pair. The 'value' is expressed as an attribute, rather than as free text, to simplify parsing.

 

Some DWF client code may want to treat properties as mere strings, especially clients dedicated to viewing or transforming XML documents. However, client code that might want to interpret property values or agents that might want to make queries against properties will have to have some type information about a property's value. Not surprisingly, type information is represented by the optional 'type' attribute of a <Property>.

 


<Sections>

 

<xsd:element name="Sections">

    <xsd:complexType>

        <xsd:sequence>

            <xsd:element ref="Section" minOccurs="1" maxOccurs="unbounded" />

        </xsd:sequence>

    </xsd:complexType>

</xsd:element>

 

<xsd:element name="Section">

    <xsd:complexType>

        <xsd:sequence>

            <xsd:element ref="Source" minOccurs="1" maxOccurs="1" />

            <xsd:element ref="Toc" minOccurs="1" maxOccurs="1" />

        </xsd:sequence>

        <xsd:attribute name="name" type="xsd:string" use="required" />

        <xsd:attribute name="type" type="xsd:string" use="optional" />

        <xsd:attribute name="title" type="xsd:string" use="optional" />

    </xsd:complexType>

</xsd:element>

 

Since it is assumed that we would not be publishing an empty DWF package, it is required that there be at least one <Section> element under <Sections>.

 

The first element to appear under a <Section> is the <Source> that identifies the provider application and the full path to the design source file on the design author's local machine. This is followed by the <Toc> (table of contents), identifying resources associated with the section.

 

The 'name' attribute of a <Section> is expected to match the name of the logical component being published therein. A user-friendly 'title' is optional. A 'type' attribute (e.g. "Component" or "ePlot") is optional for the DWF 6 files but is required for certain document interfaces (e.g. ‘ePlot’ sections require the type “com.autodesk.dwf.ePlot”.)

 


Section subelement: <Source>

 

<xsd:element name = "Source">

    <xsd:complexType>

            <xsd:attribute name = "provider" type = "xsd:string"/>

            <xsd:attribute ref = "href" use = "required"/>

            <xsd:attribute name = "objectId" type = "uniqueId"/>

    </xsd:complexType>

</xsd:element>

 

The <Source> element represents the provider application and source file of published data.

 

The element-specific 'provider' attribute should correspond to the authoring tool that created the DWF package, e.g. Inventor, AutoCAD, MDT, etc.

 

Whether the file reference can truly be an href (like a request to a file archive like Project Point) or just a file name on a user’s local disk remains an open issue. Some means of identifying the file via its filename should be used here.

 

The 'objectId' is provided by the authoring tool to indicate a unique id for a given document. If the authoring tool changes the document and re-publishes, the objectId should remain the same.

 


Section subelement: <Toc>

 

    <xsd:element name="Toc">

        <xsd:complexType>

            <xsd:sequence>

                <xsd:element ref="Resource" minOccurs="1" maxOccurs="unbounded" />

            </xsd:sequence>

        </xsd:complexType>

    </xsd:element>

    <xsd:element name="Resource">

        <xsd:complexType>

            <xsd:attribute ref="role" use="required" />

            <xsd:attribute ref="mime" use="required" />

            <xsd:attribute ref="href" use="required" />

        </xsd:complexType>

    </xsd:element>

 

The <Toc> element identifies the ZIP location (filepath) of resources files associated with a particular section. For every section, there will be at least one resource file containing design graphics (e.g. a Descriptor containing domain-specific metadata, W2D files for 2D drawing pages, Raster images, ZGL files for 3D components, etc.).   For this reason the Schema mandates at least one <Resource> element in the <Toc>.

 

Most likely there will be a Descriptor XML resource (explained below), an XML file containing section-specific metadata.

 

The required 'href' attribute of a Resource identifies its location in the zip archive. The required 'mime' should indicate the MIME type of the resource file as specified by ftp://www.ietf.org/rfc/rfc2045.txt. The required 'role' can list what type of resource it is. There are no enforced role values for DWF resources, but document interfaces may require the use of predetermined role values. 

Table 4 - Roles

Role (string)

Interpretation

“2d streaming graphics”

.w2d

“descriptor”

Descriptor file, describes a section.

“2d vector overlay”

.w2d

“2d vector markup”

.w2d

“font”

Embedded font file

“thumbnail”

Raster Graphics (e.g. .jpeg, .png, .tiff)

“preview”

Raster Graphics (e.g. .jpeg, .png, .tiff)

“overlay preview”

Raster Graphics (e.g. .jpeg, .png, .tiff)

“markup preview”

Raster Graphics (e.g. .jpeg, .png, .tiff)

“raster overlay”

Raster Graphics (e.g. .jpeg, .png, .tiff)

“raster markup”

Raster Graphics (e.g. .jpeg, .png, .tiff)

 


<Dependencies>

 

    <xsd:element name="Dependencies">

        <xsd:complexType>

            <xsd:sequence>

                <xsd:element ref="Dependency" minOccurs="1" maxOccurs="unbounded" />

            </xsd:sequence>

            <xsd:attribute ref="sectionIndex" use="required" />

        </xsd:complexType>

    </xsd:element>

    <xsd:element name="Dependency">

        <xsd:complexType>

            <xsd:attribute ref="sectionIndex" use="required" />

        </xsd:complexType>

    </xsd:element>

 

There is at most one <Dependencies> element for each Section (identified by the 'sectionIndex', e.g. Sj.) A section with no dependencies has no corresponding <Dependencies> element. Each <Dependency> element within the collection identifies one predecessor section Section Si.

 

The 'sectionIndex' attribute used to identify a section is derived from the index type and is a 1-based index into the <Sections> element specifying a particular <Section>.

 


<Interfaces>

 

<xsd:element name = "Interface">

    <xsd:complexType>

        <xsd:attribute name = "objectId" use = "required" type = "uniqueId"/>

        <xsd:attribute name = "href" use = "required" type = "xsd:string"/>

        <xsd:attribute name = "name" use = "required" type = "xsd:string"/>

    </xsd:complexType>

</xsd:element>

 

<xsd:element name = "Interfaces">

    <xsd:complexType>

        <xsd:sequence>

            <xsd:element ref = "Interface" maxOccurs = "unbounded"/>

        </xsd:sequence>

    </xsd:complexType>

</xsd:element>

 

There must be one and only one <Interfaces> element for the Manifest.  Inside this element, each <Interface> element identifies a document interface supported by the package. 

 

The required 'objectId' attribute is a UUID identifying a specific document interface and should be used by supporting applications as a reference or registration key to help locate an installed control, component, or viewer that understands the interface.  For example, the ePlot document interface’s objectId corresponds to the viewer control which understands ePlot packages.

 

The required 'href' should contain a URL which will direct users to a website which will specify applications that can be used to read the package containing that particular document interface.

 

The required 'name' attribute is a descriptive user-friendly name of the interface, for example “ePlot”, which may be shown to the end user.

 


Data types

SimplePropertyType

<xsd:simpleType name = "SimplePropertyType">

    <xsd:restriction base = "xsd:string">

        <xsd:enumeration value = "string"/>

        <xsd:enumeration value = "boolean"/>

        <xsd:enumeration value = "uriReference"/>

        <xsd:enumeration value = "timeDuration"/>

        <xsd:enumeration value = "timeInstant€u47 ?>

        <xsd:enumeration value = "date"/>

        <xsd:enumeration value = "month"/>

        <xsd:enumeration value = "year"/>

        <xsd:enumeration value = "century"/>

        <xsd:enumeration value = "recurringDate"/>

        <xsd:enumeration value = "recurringDay"/>

        <xsd:enumeration value = "float"/>

        <xsd:enumeration value = "double"/>

        <xsd:enumeration value = "long"/>

        <xsd:enumeration value = "int"/>

        <xsd:enumeration value = "short"/>

        <xsd:enumeration value = "byte"/>

        <xsd:enumeration value = "unsignedLong"/>

        <xsd:enumeration value = "unsginedInt"/>

        <xsd:enumeration value = "unsignedShort"/>

        <xsd:enumeration value = "unsignedByte"/>

        <xsd:enumeration value = "stringList"/>

        <xsd:enumeration value = "doubleList"/>

        <xsd:enumeration value = "longList"/>

    </xsd:restriction>

</xsd:simpleType>

 

This type provides a means of specifying the type of data contained in the value attribute of a property.

 


index

<xsd:simpleType name = "index">

    <xsd:restriction base = "xsd:unsignedInt">

        <xsd:minInclusive value = "1"/>

    </xsd:restriction>

</xsd:simpleType>

 

This type is a 1-based indexer and serves as a base for various uses, such as the ‘sectionIndex’ attribute.

 


uniqueId

<xsd:simpleType name = "uniqueId">

    <xsd:restriction base = "xsd:string">

        <xsd:pattern value = "[0-9,A-F,a-f]{8}-[0-9,A-F,a-f]{4}-[0-9,A-F,a-f]{4}-[0-9,A-F,a-f]{4}-[0-9,A-F,a-f]{12}"/>

    </xsd:restriction>

</xsd:simpleType>

 

This type specifies a properly formed UUID.

 


Descriptor.xml

Although descriptor files are optional in a DWF, section specific metadata can (and likely should) reside in a descriptor XML file, one per section.  Document interface specifications will elaborate the requirements of the descriptor.xml file, but its use is important enough to at least mention in this document.

 

The descriptor is the place where domain-specific section information belongs.  This may include data such as graphical object relationships, domain-specific metadata, page ordering for plotting, assembly structure information, graph trees, display and selection trees, etc.  This information is entirely ignored during generic DWF package browsing operations, as it contains no information of impact to the overall package structure in general.

 


Resource Files - Naming Considerations

There are several goals and constraints that impact the choice of how to name the various resource files within a DWF package.

·        Items within the DWF package must have unique names (for example, the name for a particular resource is likely comprised of its section path and a resource filename.)

·        Items within a DWF package may reference other items in the same DWF package.  For example, elements in various descriptor.xml files may point to various media files (JPG, etc.) in other sections of the same DWF package.

·        Items within a section must be unique, but sections should be largely independent of each other (with the possible exception of ZGL – see below)

 

Most “hard-coded” intra-package references will likely be defined in XML. If a package user needs to rename a referenced resource file, the referencing XML file(s) could theoretically be updated with the renamed reference and thereby preserve package integrity.  However, renaming resources is discouraged due to potential conflicts arising when non-XML resource files contain references to other resource files (e.g. ZGL and potentially W2D files.)  As the DWF toolkit is unaware of resource format internals, changing the name of referenced resources is not possible since that would require internal knowledge of the various resource formats to be able to locate those references and rewrite the resource with updated references.

 

An example of where this can happen is with ZGL includes.  One of the goals for the naming model is to allow the use of <INCLUDE/> elements in the ZGL files. These elements allow ZGL files to share graphics information segregating the data into separate ZGL files, and then including those files in other ZGL files. The <INCLUDE/> element specifies the name of the file to be included, as either a path relative to the including file, as a server independent absolute path, or as a server specific absolute path.

 

In order to use ZGL includes, the names of ZGL files must be fixed at the time they are created and added to the DWF package. ZGL includes will also reference ZGL files that are in other sections of the DWF package, so the name chosen must indicate the section, and therefore section monikers must also remain static.

 

In light of this, it is highly recommended that resource file names remain static (and perhaps should be generated solely by the toolkit) within the DWF package.  In a UI implementation, applications could simply present user-friendly name, type and title for the sections, and role for the resources,  instead of allowing access to the actual filename or ZIP directory pathname.

 

Hyperlinks and DWF 6

The hyperlinking format used in DWF 6 files is essentially a contract between an authoring tool (e.g. AutoCAD, Inventor, etc.) and the consuming DWF reader (e.g. Autodesk Express Viewer, Volo View, etc.)  The DWF toolkit and DWF specification are merely a transport for the hyperlink string. However, to achieve interoperability, it is necessary to standardize on a specific hyperlinking protocol so that all parties can benefit. 

 

Hyperlinks can link to external documents (standard URLs), or to specific sections / resources / pages / views within a DWF package (or more particularly a DWF ePlot package.)

 


External links

A standard URL

·        “http://mydomain.com/mydrawingset.dwf”

·        “http://www.autodesk.com”

 


Arbitrary sections within a DWF package

A section name that was automatically generated by the toolkit.  It’s ugly, but guaranteed to be unique:

·        “http://mydomain.com/mydrawingset.dwf?doctype=eplot&section=com.autodesk.dwf.ePlot_87518391CFF9349A8FE4C81FABD23C07”


A section name that was generated by the authoring tool… much more readable, but we have to be careful when/if merging DWF packages so that section names don’t collide:

·        “http://mydomain.com/mydrawingset.dwf?doctype=mcs&section=section_1”

·        “http://mydomain.com/mydrawingset.dwf?doctype=eplot&section=HVAC_1”

 


Arbitrary resources within a DWF package (i.e. thumbnails, metadata)

·        “http://mydomain.com/mydrawingset.dwf?doctype=eplot&section=Building112_Floor2_HVAC&resource=thumbnail.jpg”

·        “http://mydomain.com/mydrawingset.dwf?doctype=mcs&section=section_1&resource=resource_1.zgl”

 


EPlot specific links:

Pages within a drawing set. (The page attribute is overloaded to handle pages specified via descriptor, page number, or page name.)

By descriptor (uses the section name described above, plus concatenates "\descriptor.xml" to the name.)

·        “http://mydomain.com/mydrawingset.dwf?doctype=eplot&page=com.autodesk.dwf.ePlot_87518391CFF9349A8FE4C81FABD23C07\descriptor.xml”

 

By page number

Note, page number is an abstract concept unknown to the viewer until the entire package has been loaded, so using page numbers can work, but performance may lag somewhat. This also risks incorrect or broken links if pages are inserted or deleted from the package without reevaluating the internal links (within resources.)

 

 

By page name

Note, page name is not the same as section name, though the authoring tool may override default section naming to keep the two the same.  The section name is typically never seen by the user.

 

 


Views within a section/resource.

Note, a view on an arbitrary type of section is arguably a domain-specific concept, and is illustrated here as a suggested convention, and only a requirement onto ‘ePlot’ pages / sections.

 

By named view

·        “http://mydomain.com/mydrawingset.dwf?doctype=eplot&section=com.autodesk.dwf.ePlot_87518391CFF9349A8FE4C81FABD23C07&view=DETAIL”

·        “http://mydomain.com/mydrawingset.dwf?doctype=eplot&section=HVAC_1&view=DUCT_2”

 

By paper coordinates (lower left x,y, upper right x,y)

·        “http://mydomain.com/mydrawingset.dwf?doctype=eplot&page=HVAC&view=0.25,0.25,4,4”


Internal links (i.e. within the same DWF package)

Links using a current file (no http header nor filename given – arguments begin with the question mark) indicates a path within the DWF package:

·        “?doctype=eplot&section=com.autodesk.dwf.ePlot_87518391CFF9349A8FE4C81FABD23C07”

·        “?doctype=mcs&section=section_1”

·        “?doctype=eplot&section=HVAC_1”

·        “?doctype=eplot&section=Building112_Floor2_HVAC&resource=thumbnail.jpg”

·        “?doctype=mcs&section=section_1&resource=resource_1.zgl”

·        “?doctype=eplot&section=com.autodesk.dwf.ePlot_87518391CFF9349A8FE4C81FABD23C07&view=DETAIL”

·        “?doctype=eplot&page=com.autodesk.dwf.ePlot_87518391CFF9349A8FE4C81FABD23C07&view=DETAIL”

·        “?doctype=eplot&page=1”

·        “?doctype=eplot&page=HVAC”

·        “?doctype=eplot&section=HVAC_1&view=DUCT_2”

·        “?doctype=eplot&pageName=HVAC&view=0.25,0.25,4,4”