|
Copyright
© 2000-2008 |
|
DWF ePlot
Document Interface Specification
Version 1.2
AUTODESK, INC. MAKES NO WARRANTY, EITHER
EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, REGARDING THESE MATERIALS
AND MAKES SUCH MATERIALS AVAILABLE SOLELY ON AN "AS-IS" BASIS.
IN NO EVENT SHALL AUTODESK, INC. BE LIABLE TO ANYONE FOR SPECIAL, COLLATERAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES IN CONNECTION WITH OR ARISING OUT OF PURCHASE OR USE OF THESE MATERIALS. THE SOLE AND EXCLUSIVE LIABILITY TO AUTODESK, INC., REGARDLESS OF THE FORM OF ACTION, SHALL NOT EXCEED THE PURCHASE PRICE OF THE MATERIALS DESCRIBED HEREIN.
Autodesk, Inc. reserves the right to revise and improve its products as it sees fit. This publication describes the state of this product at the time of its publication, and may not reflect the product at all times in the future.
Autodesk Trademarks
The following are registered trademarks of Autodesk, Inc., in the USA and/or
other countries: 3D Studio MAX, 3D Studio VIZ, Actrix,
AutoCAD, AutoCAD LT, AutoCAD Map, Autodesk, Autodesk (logo), Autodesk Express
Viewer, Autodesk View, AutoVision, Design Web Format,
Drawing Web Format, DWF, Heidi, HOOPS, Kinetix,
Multimedia Explorer, ObjectARX, RadioRay,
WHIP!, WHIP! (logo).
The
following are trademarks of Autodesk, Inc., in the
Heidi, and WHIP! are registered trademarks of Autodesk, Inc.
Third-Party Trademarks
All other brand names, product names or trademarks belong to their respective
holders. Windows is a registered trademark of Microsoft Corporation.
Acknowledgements
Thanks to the following individuals for their contributions in designing, writing, editing, illustrating, and producing the DWF 6.0 specification, with special thanks to the Autodesk Streamline team for the original DDP format upon which DWF 6.0 is based:
Samir Bajaj, Michael Chase, Ben Cochran, Tom Dennehey, John Dunn, Subu Gupta, Damian Hallbauer, Peter Hodgman, Larry Horner, Peter Janson, Jeffrey Klug, Brian Mathews, Dennis Mulonas, Ram Mummidi, Brian Pene, Greg Remmert, Tim Scully, Rob Sinkler, Ken Vadella, and Xiong Wang.
Thanks to the following individuals for their contributions in designing, writing, editing, illustrating, and producing the original DWF specification (now the Whip 2D publishing channel specification), with special thanks to Brian Mathews who wrote the original DWF file format:
Vincent Abeyta, Heinz Baumann, Michael Butler, Alena Caldwell, Robert Covey, Damian Hallbauer, Tanvir Hassan, Larry Horner, Brad Howland, Ching-Chi Billy Hsu, John Lancaster, Raj Manathattai, Brian Mathews, Ram Mummidi, Joshua Natarajan, Kenneth Riley, Usha Sanagala, John Schmier, Tim Scully, Benjamin Sellers, Scott Sheppard, Robert Sinkler, Cicilie Ulrich, Richard Weiss, and Justin Zhou.
GOVERNMENT USE
Use, duplication, or disclosure by the U.S. Government is subject to
restrictions as set forth in FAR 12.212 (Commercial Computer
Software-Restricted Rights) and DFAR 227.7202 (Rights in Technical Data and
Computer Software), as applicable.
2.1 ePlot Document
Interface – Minimum Requirements
2.3 Global (‘ePlotGlobal’
sections)
3 Schema Elements and
Data Types
4.2 Example using Object Definitions
In the context of a DWF package, the term document interface should not be confused with runtime interfaces as exposed by Java, C++ or COM objects, however it may be helpful to think of a document interface using this software analogy.
Whereas a Java, C++ class or COM object may implement several object interfaces, a package may comply to several document interfaces such as ePlot, Streamline Assembly, Streamline Drawing, etc. A C++ class that implements many interfaces may appear to be many different types of objects simultaneously. Similarly, a DWF package which implements several document interfaces may be read by many different types of document clients. Just because a package document contains ePlot information, that does not preclude it from also containing Streamline Drawing information.
A DWF package is only interesting when it complies with one or more document interface that requires specific information for document readers. Document interfaces allow DWF readers to identify the nature of the DWF data at a very high level; and can be used to determine whether or not the data within the DWF is of value to the reader.
This document outlines the ePlot document interface of the DWF package. DWF packages are said to “conform to the ePlot document interface” if they meet a set of requirements specified herein and can thus be referred to as “DWF ePlot packages”. DWF ePlot packages will contain specific information applicable to the concept of electronic paper, to be read by applications (e.g. viewers) which are written to work specifically with the DWF ePlot document interface.
Since the ePlot document interface specified in this document works within the DWF framework, it is highly recommended that readers of this document familiarize themselves with the DWF 6 Specification document which is bundled with the DWF Toolkit documentation.
The ePlot document interface provides a mechanism for publishing multi-page design data using the compressed, secure, and streamable DWF 6 package format.
The ePlot document interface specifies how 2D vector graphics - created using the WHIP! toolkit - in W2D files (pronounced “wid”), preview and thumbnail rasters, published redline/markup files (held in other W2D streams), embedded font files, and application specific metadata will be organized within the package framework.
DWF ePlot package consumers can reliably examine the DWF manifest to discover which document interfaces the DWF package implements, as well as which package sections represent ePlot pages, and then examine those sections/pages for specific information such as plot order, page contents, and page metadata.
DWF ePlot packages will be created either by design authoring tools and design file translators, or “plug-in” extensions to design applications, perhaps functioning as translating exporters - augmenting the system’s “File Save As…” functionality.
The objective of this document is to detail the DWF ePlot document interface specification.
The users of this document are development and marketing teams associated with design data authoring tools that will publish ePlot-compliant DWF 6 files.
New elements:
· <ObjectDefinition> a document-level element contained in an ObjectsResource file/stream.
· <Objects>, contains new <Object> elements.
· <Instances>, contains new <Instance> elements.
Changed elements:
· <Global> can now contain an optional <Properties> element and/or an optional <Resources> element.
· <Properties> can now contain optional id and/or refs attributes.
· <Resource> can now specify a parentResourceId.
Deprecated/removed:
·
<Page> color
attribute. (Note, <Paper> color is still
available.)
To implement the ePlot document interface and thus be considered ePlot-compliant, a DWF package must meet the following minimum requirements:
· 2D graphics pages must be represented by W2D files/streams (See the WHIP! 2D Publishing Channel Specification included with the DWF Toolkit documentation.)
· Page sets must be organized into sections with type=com.autodesk.ePlot.
· Manifest must contain Interfaces/Interface element describing the ePlot interface.
· An optional ePlotGlobal section may be provided to contain metadata specific to all of the ePlot pages within the set. If an ePlotGlobal section is added (and only one is allowed), it must be placed in a section with type=com.autodesk.ePlotGlobal.
· In each ePlot section or in the ePlotGlobal section, one descriptor.xml file must exist and must conform to the ePlot.xsd schema (also included with the DWF Toolkit documentation.)
An ‘ePlot’ section as described in the package Manifest.xml file is analogous to a single paper page. An ePlot Descriptor XML file within each ePlot section/page will contain information regarding the page and its resources, including page plot order, paper description, and other page metadata. A DWF ePlot package may contain multiple ePlot sections, thus representing a set of pages.
Each ePlot section must contain one ePlot Descriptor XML file and may also contain additional resources. The ePlot Descriptor XML filename must be ‘descriptor.xml’ and its specified file resource role must be “descriptor” as indicated in the manifest.
The ePlot page descriptor contains a descriptive list of the resource files for the page. Standard resource roles must be used to describe page resource files (stored as EPlotResource elements as defined in the ePlot.xsd schema). Resource roles are described in the DWF 6 Specification document. Unrecognized resource role strings (i.e. those not listed in the standard roles) list may be used, however they can and will be ignored by ePlot viewers.
The ePlot page descriptor file contains information describing the page and its plot order with respect to other pages in the DWF ePlot package. The descriptor must describe one and only one page - a logical page component being published within the page set, perhaps representing a drawing layout, a raster image, or a view onto a mechanical part.
There are a number of resources associated with a page. 2D vector graphics are described using W2D files, created using WHIP! toolkit version 6.0 or greater. Page resources may include raster images for thumbnails, previews, as well as additional resources for application specific metadata and font files.
Pages are self-contained and independent of one another, and have no dependency upon one another except perhaps for plot ordering (which determines the virtual page “number”.) If a Global section exists, pages will depend on the Global section for data that applies to all pages.
The ePlot page descriptor file must define the document-level XML element <Page> to represent the collection of elements comprising the page.
While an ‘ePlot’ section as described in the package Manifest.xml file is analogous to a single paper page, the optional ‘ePlotGlobal’ section contains data corresponding to the entire collection of pages in a DWF ePlot package. There can be only one ePlotGlobal section in a Dwf document. Descriptor XML files within the ePlotGlobal section will contain metadata corresponding to all ePlot pages within a DWF document. The ePlotGlobal section may also contain resources used by all pages within a DWF document, however in order to be composited on a page, the global resource must be present in the page descriptor’s Resources collection.
The Descriptor XML filename must be ‘descriptor.xml’ and its specified file resource role must be “descriptor” as indicated in the Manifest.
The ePlotGlobal descriptor file must define a document-level element <Global> to represent the data relating to the page set.
ePlot.xsd (hereafter called "the Schema") defines the following elements and attributes as shown in the following table:
Table 1 - ePlot Elements, Types, and Attribute Groups
Elements |
Bookmark |
|
|
|
Global |
|
|
|
Page |
|
|
|
Properties |
|
|
|
Paper |
|
|
|
Resource |
|
|
|
GraphicResource |
|
|
|
ImageResource |
|
|
|
Instance |
|
|
|
Instances |
|
|
|
FontResource |
|
|
|
Object |
|
|
|
Objects |
|
|
|
ObjectDefinition |
|
|
|
ObjectResource |
|
|
|
Resources |
|
|
Complex Types |
ResourceContent |
|
|
|
GraphicResourceContent |
|
|
DataType
definitions |
rectangle |
|
|
|
transform4x4 |
|
|
The ePlot schema defines three document-level elements, <Page> identifying the contents of a page, <Global>, identifying global metadata across all pages in a DWF ePlot package, and <ObjectDefinition>, containing an object model representing objects on a page (or on all pages) which can be tied to graphics.
<xsd:element name = "Global">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref = "Properties" minOccurs = "0"/>
<xsd:element ref = "Bookmark" minOccurs = "0"/>
<xsd:element ref = "Resources" minOccurs = "0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
The ePlot <Global> element may contain zero or one <Properties>, <Bookmark>, and/or <Resources> elements. Global properties apply to all ePlot <Page> elements, meaning that page properties should consist of global properties plus local page properties.
<xsd:element name = "Properties">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref = "AnyProperty" minOccurs = "0" maxOccurs = "unbounded"/>
</xsd:sequence>
<xsd:attribute name = "id" type = "xsd:string"/>
<xsd:attribute name = "refs" type = "xsd:string"/>
</xsd:complexType>
</xsd:element>
<Properties> elements should be treated differently depending on their usage context. See the <Global>, <ObjectDefinition>, <Objects> and <Page> sections for further information.
Attributes:
id – (optional) a unique string identifier for this object. This identifier should be unique in the scope in which it is used. For example, Properties elements in ePlot and ePlotGlobal descriptor files should have unique id’s with respect to each other. Also, Properties elements in ePlot object definition resources should be unique with respect to Properties elements in ePlotGlobal object definition resources.
refs – (optional) a list of previously defined Properties id’s used to aggregate their contents into this element without having to respecify the contained property collection. For an example of this and the id attribute, see the Appendix section containing the object definition example.
<xsd:complexType name = "AllPropertyContent">
<xsd:attribute name = "name" use = "required" type = "xsd:string"/>
<xsd:attribute name = "category" type = "xsd:string"/>
</xsd:complexType>
<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 = "AnyProperty" type = "AllPropertyContent" abstract = "true"/>
<xsd:element name = "Property" type = "SimplePropertyContent" substitutionGroup = "AnyProperty" />
The property object represents, well, a property. It is arguable that since the attributes contained in SimplePropertyContent are useful enough to be applied to all future property objects, and that AllPropertyContent is too generic to be useful, then the two should be merged into one object. This is true for the vast majority of property applications; however, in the interest of keeping things obtuse and complicated, AllPropertyContent will remain intact.
Attributes:
name – (required) a user-friendly string containing the name of the property. Note, a naming convention where the first character is an underscore “_” indicates that this property should be hidden to users (i.e. not displayed in any viewing application.)
value – (required) a string containing the value of the property.
category – (optional) – reserved
type – (optional) – if given, this is one of the SimplePropertyType enumerations as specified in the ePlot Schema.
units – (optional) – Iindicates the units of the value.
<xsd:element name = "Bookmark">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref = "Bookmark" minOccurs = "0" maxOccurs = "unbounded"/>
</xsd:sequence>
<xsd:attribute name = "name" use = "required" type = "xsd:string"/>
<xsd:attribute ref = "href"/>
</xsd:complexType>
</xsd:element>
The <Bookmark> element represents a heirarchical tree of other <Bookmark> elements. Each node in the tree can be both a container and a “leaf node”, meaning that even a parent can have its own href (hyperlink) specified.
Attributes:
name – (required) a user-friendly string to be displayed as the tree node / link / folder text..
href – (optional) a standard hyperlink / URL.
<xsd:element name = "Page">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref = "Properties" minOccurs = "0"/>
<xsd:element ref = "Paper" minOccurs = "0"/>
<xsd:element ref = "Resources" minOccurs = "0"/>
</xsd:sequence>
<xsd:attribute name = "plotOrder" default = "1" type = "xsd:double"/>
<xsd:attribute name = "name" use = "required" type = "xsd:string"/>
<xsd:attribute name = "version" type = "xsd:string"/>
<xsd:attribute name = "objectId" type = "uniqueId"/>
</xsd:complexType>
</xsd:element>
When a reading application considers Page properties, the <Properties> element in the ePlot <Global> section should be aggregated together with the Page <Properties>. Care should be taken to examine the internal <Property> elements in order to determine if the Page contains properties which override Global properties.
The optional <Resources>
subelement is a container for one or more <Resource> elements (or valid substitution
elements) as described below. Note, if the Page contains any graphical (or
image) resources, it MUST specify a <Paper>
element.
Attributes:
plotOrder – (default) a double indicating the order in which this particular page should be plotted relative to the other pages in the plot set. Defaults to 1.
name – (optional) a string indicating the name of this page
version – (optional) used by the toolkit to indicate the schema version of this element (which may not change when the schema itself may – i.e. other items in the schema may change independent of the document element “Page”)
objectId – (optional) a uniqueId for this page. This is typically used in consumer-side post-processing (i.e. it's not generated by the authoring tool nor is it packager data). This could be used as a synchronization GUID by a hosting server. For example, a page may be stored in a database as a discrete element which might need to be synchronized with a page contained in a local DWF file – this synchronization GUID could be used as the common key.
<xsd:element name = "Paper">
<xsd:complexType>
<xsd:attribute name = "show" default = "true" type = "xsd:boolean"/>
<xsd:attribute name = "units" use = "required" type = "xsd:string"/>
<xsd:attribute name = "width" use = "required" type = "xsd:double"/>
<xsd:attribute name = "height" use = "required" type = "xsd:double"/>
<xsd:attribute name = "clip" type = "rectangle"/>
<xsd:attribute name = "color" default = "255 255 255" type = "rgbColor"/>
</xsd:complexType>
</xsd:element>
The <Paper> element describes the physical paper on which the page geometry is to be placed.
Attributes:
show – (optional) a boolean value (default “true”) whether viewers should show the physical page
units – (optional) string enumeration: “in” or “mm” (default “in”) indicating inches or millimeters, respectively
width – (required) a double value indicating the width in paper units (inches or millimeters as specified in units)
height – (required) a double value indicating the height in paper units (inches or millimeters)
clip – (required) a rectangle indicating a clipping rectangle (in paper units) to be applied to the paper. This indicates the printable area of the paper and will serve as a hard clip for all graphic elements on the paper with the exception of markups/redlines (which are specifically allowed to exist in the non-printable area of the page.) The values are four doubles in the order left, bottom, right, top, relative to the paper origin (bottom left corner of the paper), and have the same units as specified in the ‘units’ attribute.
color – (optional) a color for the paper. Defaults to white.
<xsd:complexType name = "ResourceContent">
<xsd:annotation>
<xsd:attribute ref = "role" use = "required"/>
<xsd:attribute ref = "mime" use = "required"/>
<xsd:attribute ref = "href" use = "required"/>
<xsd:attribute name = "title" type = "xsd:string"/>
<xsd:attribute name = "objectId" type = "uniqueId"/>
<xsd:attribute name = "size" type = "xsd:integer"/>
<xsd:attribute name = "parentObjectId" type = "uniqueId"/>
</xsd:complexType>
<xsd:element name = "Resource">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base = "ResourceContent"/>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
The <Resources> element contains one or more <Resource> elements. The <Resource> element describes a non-graphic resource associated with a page (such as a metadata file, etc.). <Resource> elements are contained by the <Resources> element (note the plural). <Resource> is derived from the ResourceContent complex type, which contains a standard set of attributes.
Valid substitution elements (such as <GraphicResource>, <ImageResource>, <FontResource>, and <ObjectsResource> - described below) are also derived directly or indirectly from ResourceContent and may also be added to the <Resources> collection to describe other specific types of resource data.
Attributes:
role – (required) a string indicating the resource role as described in the DWF 6 specification document
mime – (required) a string indicating the MIME type of this resource file
href – (required) a string indicating the package archive filepath for this resource
title – (optional) a string indicating the title of this resource
objectId – (optional) a uniqueId for this resource
parentObjectId – (optional) a uniqueId for the resource from which this data was generated or upon which it is dependent
size – (optional) the size (uncompressed bytes) of the resource file
See <Resource> above for the ResourceContent definition referenced below.
<xsd:complexType name = "GraphicResourceContent">
<xsd:complexContent>
<xsd:extension base = "ResourceContent">
<xsd:attribute name = "transform" use = "required" type = "transform4x4"/>
<xsd:attribute name = "extents" type = "rectangle"/>
<xsd:attribute name = "clip" type = "rectangle"/>
<xsd:attribute name = "author" type = "xsd:string"/>
<xsd:attribute name = "description" type = "xsd:string"/>
<xsd:attribute name = "creationTime" type = "xsd:dateTime"/>
<xsd:attribute name = "modificationTime" type = "xsd:dateTime"/>
<xsd:attribute name = "orientation" default = "alwaysInSync">
<xsd:simpleType>
<xsd:restriction base = "xsd:string">
<xsd:enumeration value = "alwaysInSync"/>
<xsd:enumeration value = "alwaysDifferent"/>
<xsd:enumeration value = "decoupled"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name = "effectiveResolution"
type = "xsd:integer"/>
<xsd:attribute name = "zOrder" type = "xsd:integer"/>
<xsd:attribute name = "show" default = "true" type = "xsd:boolean"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name = "GraphicResource" substitutionGroup = "Resource">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base = "GraphicResourceContent"/>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
The <GraphicResource> element is a generic element derived from the GraphicResourceContent type which derives from ResourceContent. This element is used to describe a non-image graphic file resource. Raster image file resources are described in better detail using the <ImageResource> element, described below. Resource files suitable for <GraphicResource> use are the primary W2D file, and other overlay graphics (W2D, redlines, etc.)
Attributes:
This element also
contains all attributes for the <Resource> element, see above.
transform – (required) a transform4x4 type used to position, scale and rotate the graphics onto the primary page. In the case of a preview or thumbnail (or other graphics not inserted into the primary page), this attribute will be ignored and can be set to the identity matrix (i.e. 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1). The transform4x4 data type is described below.
extents – (optional) a rectangle indicating a bounding rectangle (in paper units – i.e. inches or millimeters) of the graphic resource. While this information can be derived by [transforming and] rendering the graphic resource into the primary page, the information is useful to viewer applications and should be provided when possible. The rectangle data type is described below.
Note: For items that don’t transform onto paper (for
example, thumbnails and previews), the extents attribute should be in native
units (for example, pixels), since the transform would typically remain the
default identity transform. In
any case, the values are four doubles in the order left, bottom, right, top.
clip – (optional) a rectangle indicating a clipping rectangle in paper units to be applied to the graphic resource. The rectangle data type is described below.
Note: The printable area of the paper in the <Paper> element definition serves as an overriding hard clip for all page elements excepting markup/redline, which is specifically allowed to exist in the non-printable area of the page.
The values are four doubles in the order left, bottom, right, top, relative to the paper origin (bottom left corner of the paper).
author – (optional) a string containing the name or user name of the author of this graphic resource.
description – (optional) a string containing a description of this graphic resource.
creationTime – (optional) a dateTime type indicating the [file] creation time of this graphic resource.
modificationTime – (optional) a dateTime type indicating the [file] modification time of this graphic resource.
orientation– (optional) a string enumeration indicating how the graphics should track with the primary page’s landscape/portrait orientation. Legal values are ‘alwaysInSync’, ‘alwaysDifferent’, and ‘decoupled’.
effectiveResolution – (optional) an integer indicating the effective or desired resolution (DPI) of plotted graphics.
zorder– (optional) how this graphic should be rendered relative to other overlaid graphics on the page. A negative value indicates that this graphics resource should be rendered behind the primary page.
show – (optional) a boolean value (default “true”) whether viewers should actually show this component on the page.
See <GraphicResource> above for the GraphicResourceContent definition referenced below.
<xsd:element name = "ImageResource" substitutionGroup = "Resource">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base = "GraphicResourceContent">
<xsd:attribute name = "invertColors" default = "false" type = "xsd:boolean"/>
<xsd:attribute name = "scanned" default = "false" type = "xsd:boolean"/>
<xsd:attribute name = "originalExtents" type = "rectangle"/>
<xsd:attribute name = "colorDepth" type = "xsd:integer"/>
<xsd:attribute name = "scannedResolution" type = "xsd:integer"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
The <ImageResource> element is used to describe an image (raster) file resource and is derived from GraphicResourceContent. Possible resource files which may be suitable for <ImageResource> are previews, thumbnails, other overlay rasters, etc.
Attributes:
This element also
contains all attributes for both the <Resource> and <GraphicResource> elements, see above.
invertColors – (optional) a boolean indicating whether the colors of this image should be reversed (negative image).
scanned – (optional) a boolean indicating whether this image was originally scanned from paper.
originalExtents – (optional) a rectangle indicating, if known, the original extents of the image (in pixels) prior to any downsampling or transformations. The rectangle data type is described below. The values are four doubles in the order left, bottom, right, top.
colorDepth – (optional) an integer indicating the number of colors required for this image (for example, 2, 16, 256, 65536, etc.)
scannedResolution – (optional) an integer indicating the original scanned resolution of the image in DPI.
See <ResourceInfo> above for the ResourceContent definition referenced below.
The FontResource is used to describe an embedded font. The font data is as specified in the OpenType Font Embedding format available from Microsoft at http://www.microsoft.com/typography/embed/sdk.htm.
<xsd:element name = "FontResource" substitutionGroup = "Resource">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base = "ResourceContent">
<xsd:attribute name = "request" use = "required" type = "xsd:integer"/>
<xsd:attribute name = "privilege" use = "required">
<xsd:simpleType>
<xsd:restriction base = "xsd:string">
<xsd:enumeration value = "previewPrint"/>
<xsd:enumeration value = "editable"/>
<xsd:enumeration value = "installable"/>
<xsd:enumeration value = "noEmbedding"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name = "characterCode" use = "required">
<xsd:simpleType>
<xsd:restriction base = "xsd:string">
<xsd:enumeration value = "unicode"/>
<xsd:enumeration value = "symbol"/>
<xsd:enumeration value = "glyphIdx"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name = "canonicalName" use = "required" type = "xsd:string"/>
<xsd:attribute name = "logfontName" use = "required" type = "xsd:string"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
Attributes:
This element also
contains all attributes for the <Resource> element, see above.
request – (required) an integer bit-field of OR-able flags denoting the request by which the font information was embedded. This field could be one or more of the following Request values by which font information would have been embedded by Microsoft's Open Type Font Embedding SDK:
· 0x01 (Raw) — Returns a font structure containing the full character set, non-compressed. This is the default behavior of the function.
· 0x02 (Subset) — Returns a subsetted font containing only the glyphs indicated by pusCharCodeSet. These character codes must be denoted as 16-bit Unicode values.
· 0x04 (Compressed) — Returns a compressed font structure.
· 0x08 (Fail_If_Variations_Simulated) — In some cases, a client will want to avoid embedding simulated fonts, especially if the normal instance of the typeface is being embedded. If this flag is set and the font in the DC is simulated, TTEmbedFont( ) will fail, generating an error.
· 0x10 (Eudc) — Embed EUDC font. If there is typeface EUDC embed it; otherwise, embed system EUDC.
· 0x20 (Validation_Tests) — Confirms validity of the font file before embedding.
· 0x40 (Web_Object) — Clients embedding fonts for the web must use this flag to create valid web objects. Clients embedding fonts in their own document files do not use this flag.
· 0x80 (Encrypt_Data) — Causes font data in the embedded object to be additionally encrypted when compression is being performed.
Note: For more detailed information, please refer to the Microsoft Font Embedding SDK documentation.
privilege – (required) a string enumeration indicating the embedding privileges of the font. This flag can have one of the following values:
· ‘previewprint’ — preview and print embedding.
· ‘editable’ — editable embedding.
· ‘installable’ — installable embedding.
· ‘noembedding’ — restricted license embedding.
characterCode – (required) a string enumeration specifying the character set of the font to be embedded. This flag can have one of the following values:
· ‘unicode’ — a unicode character set, requiring 16-bit character encoding.
· ‘symbol’ — a symbol character set, requiring 16-bit character encoding.
· ‘glyphidx’ — indicates that subset values passed are to be interpreted as glyph id’s (rather than unicode values).
canonicalName – (required) a string containing the full descriptive font name.
logfontName – (required) a string containing a shorter logfont name (32 byte character length restriction applies).
Note: For more detailed information, please refer to the Microsoft OpenType Embedding SDK documentation.
<xsd:complexType name = "ObjectDefinitionContent">
<xsd:sequence>
<xsd:element ref = "Properties" minOccurs = "0" maxOccurs = "unbounded"/>
<xsd:element ref = "Objects" minOccurs = "0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name = "GlobalObjectDefinition">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base = "ObjectDefinitionContent"/>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name = "PageObjectDefinition">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base = "ObjectDefinitionContent">
<xsd:sequence>
<xsd:element ref = "Instances" minOccurs = "0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
High-level DWF ePlot objects are defined in an XML file associated with an ePlot or ePlotGlobal section. This “object definition” XML file is contained in the respective descriptor’s resources collection. This file will contain definitions that define objects. For a page, the file can contain not only definitions of objects, but also will contain definitions of instances of objects which tie the instance to low-level graphic elements (e.g. W2D WT_Object_Node numbers.) Note, WT_Object_Node is merely an example of a low-level graphic hook for instances. Other graphic formats might specify different hooks to be use with instances.
Objects can aggregate referenced properties and/or can specify unique properties. Instances likewise inherit the object properties, but can also specify new properties. Both Object and Instance elements can override properties that are aggregated or inherited. A property is overridden when a subsequent property has the same name as another property in the collection (last one in wins).
While the resource filename of the object definition can be anything other than ‘descriptor.xml’, the resource’s “role” as indicated in the Manifest and descriptor XML files must be “object definition”, this is true for both global and page object definitions.
The ePlot Resource element is used
to describe the file containing the object definition. When specified on a Page, the parentObjectID attribute
of the Resource will contain the objectID of the
resource which contains the source data to which the objects refer – the source
data will typically reside within a W2D GraphicResource,
(the corresponding object definition’s Resource would specify the GraphicResource objectID in its parentObjectID attribute.)
While an object definition can be applied to more than one parent resource (by adding additional Resource elements), a parent resource can have only one page-level object definition.
If the resource containing the source data is a W2D stream, then the W2D data contains geometry which has been decorated using WT_ObjectNode attributes, thereby uniquely identifying geometric items as discrete elements which can be referenced by external metadata. The use of WT_ObjectNodes must be as granular as is necessary to provide specific targeting for objects or components that receive their own properties, selection behaviors, etc.
The <GlobalObjectDefinition> document-level element will contain zero or more <Properties> elements, zero or one <Objects> element. A <PageObjectDefinition> document-level element will contain zero or more <Properties> elements, zero or one <Objects> element, and zero or one <Instances> element.
Note, resources containing the <GlobalObjectDefinition> XML model may be used in the <Global> Resource collection whereas resources containing the <PageObjectDefinition> may be used in the <Page> Resources collection.
<xsd:element name = "Object">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref = "Properties" minOccurs = "0"/>
</xsd:sequence>
<xsd:attribute name = "id" use = "required" type = "xsd:string"/>
<xsd:attribute name = "children" type = "xsd:string"/>
</xsd:complexType>
</xsd:element>
<xsd:element name = "Objects">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref = "Object" maxOccurs = "unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
The <Objects> element is a container for <Object> elements. <Object> elements describe a virtual object in the ePlot object definition model. An <Object> may contain zero or one <Properties> element.
If an <Object>’s child <Properties> element specifies one or more entries in its refs attribute, this indicates that the <Object> aggregates those <Property> elements defined in its child <Properties> element with all of the <Property> elements contained in the referenced <Properties> elements. These “free-floating” <Properties> elements are typically defined in the <ObjectDefinition> element in which the parent <Objects> element resides. Additionally, if the <Object> element is defined within a page object definition, its <Properties> element may reference <Properties> elements defined in a global object definition. For this reason, <Properties> id’s must be unique between global and page object definitions.
Attributes:
id– (required) a string containing a unique identifier. This identifier should be unique between global and page object definitions.
children - (optional) a list of unique identifiers from other <Object> elements indicating those other objects “contained” by this object. An <Object> may be defined to “contain” other <Object> elements through the children attribute. For example, a “door assembly” object may contain both a “door” object as well as a “knob” object. The identifiers for the “door” and “knob” should therefore be contained in the children attribute. Note, containment (or being contained) via the children attribute does not affect the object properties – i.e. contained objects’ properties are not aggregated.
<xsd:element name = "Instances">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref = "Instance" maxOccurs = "unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name = "Instance">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref = "Properties" minOccurs = "0" maxOccurs = "unbounded"/>
</xsd:sequence>
<xsd:attribute name = "id" type = "xsd:string"/>
<xsd:attribute name = "object" use = "required" type = "xsd:string"/>
<xsd:attribute name = "nodes" type = "xsd:string"/>
<xsd:attribute name = "children" type = "xsd:string"/>
</xsd:complexType>
</xsd:element>
The <Instances> element is a container for <Instance> elements. <Instance> elements describe an instance of a virtual object in the ePlot object definition model. An <Instance> may contain zero or one <Properties> element. An <Instance> element is used to tie a virtual object to real graphics.
If an <Instance>’s child <Properties> element specifies one or more entries in its refs attribute, this indicates that the <Instance> aggregates those <Property> elements defined in its child <Properties> element with all of the <Property> elements contained in the referenced <Properties> elements. These “free-floating” <Properties> elements are typically defined in the <ObjectDefinition> element in which the parent <Instance> element resides. Additionally, if the <Instance> element is defined within a page object definition, its <Properties> element may reference <Properties> elements defined in a global object definition. For this reason, <Properties> id’s must be unique between global and page object definitions.
Note, an <Instance> of an <Object> implies that the <Instance> also aggregates all the <Properties> aggregated by the parent <Object>.
Attributes:
id – (optional) is a unique identifier used for external instance referencing
object – (required) contains the identifier of the <Object> of which this element represents an instance
nodes – (required) is used to indicate which geometric elements (e.g. WT_ObjectNode numbers) correspond to the instance of the object being defined.. The children attribute may contain more than one graphic element identifiers (e.g. WT_ObjectNode).
children –
(optional) is used to indicate child instance id’s which are contained in this
instance. These should be instances of
child objects as defined in the parent object, um… object. For example, an instance to a “door assembly”
object may contain both a “door” instance as well as a “knob” instance. The identifiers for the “door” and “knob”
should therefore be contained in the children attribute.
<xsd:simpleType name = "rectangle">
<xsd:list>
<xsd:simpleType>
<xsd:restriction base = "xsd:double">
<xsd:length value = "4" fixed = "true"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:list>
</xsd:simpleType>
The ‘rectangle’ data type indicates a rectangle in either paper units or pixels (depending on the context in which it is used), consisting of a list of four whitespace-separated doubles in the following sequence: left, bottom, right, top.
<xsd:simpleType name = "transform4x4">
<xsd:list>
<xsd:simpleType>
<xsd:restriction base = "xsd:double">
<xsd:length value = "16" fixed = "true"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:list>
</xsd:simpleType>
The ‘transform4x4’ data type indicates a 4x4 matrix represnted by a list of sixteen whitespace-separated
doubles, in the following sequence: row1col1
row1col2 row1col3 row1co41 row2co1 …
<xsd:simpleType name = "rgbColor">
<xsd:list>
<xsd:simpleType>
<xsd:restriction base = "xsd:long">
<xsd:length value = "3" fixed = "true"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:list>
</xsd:simpleType>
This data type represents a simple rgb color as a list of three whitespace-separated longs, in the following sequence: red, green, blue.
o-+ Page
1 - Electrical contains hyperlink "?docType=ePlot&page=1"
| |
|
o-+ Breaker panel
| |
|
| |
o 15A breaker contains hyperlink "?docType=ePlot&page=1&view=Breaker_15A"
| |
|
| |
o 20A breaker contains hyperlink "?docType=ePlot&page=1&view=Breaker_20A"
| |
|
o-o Title block contains hyperlink "?docType=ePlot&page=1&view=Title"
|
o-o Page
2 – Plumbing contains hyperlink "?docType=ePlot&page=2"
|
o-+ Retrofit
Drawing contains hyperlink "Retrofit.dwf"
| |
|
o-o Structural detail contains hyperlink "Retrofit.dwf?docType=ePlot&page=1&view=structural"
| |
|
o-o Explanation video contains hyperlink "Retrofit.dwf?docType=ePlot&page=1&resource=explain.avi"
|
o-+ ElectroPlumbing, Inc. contains hyperlink
"http://electroplumbing.com"
Would be represented by the following XML:
<Global>
<Bookmark>
<Bookmark name="Page 1 –
Electrical" href="?docType=ePlot&page=1">
<Bookmark name="Breaker
panel" >
<Bookmark name="15A breaker"
href="?docType=ePlot&page=1&view=Breaker_15A" />
<Bookmark name="20A breaker"
href="?docType=ePlot&page=1&view=Breaker_20A" />
</Bookmark>
<Bookmark name="Title Block" href="?docType=ePlot&page=1&view=Title" />
</Bookmark>
<Bookmark name="Page 2 -
Plumbing" href="?docType=ePlot&page=2" />
<Bookmark name="Retrofit
Drawing" href="Retrofit.dwf">
<Bookmark name="Structural
detail"
href="Retrofit.dwf?docType=ePlot&page=1&view=structural" />
<Bookmark name="Explanation
video"
href="Retrofit.dwf?docType=ePlot&page=1&resource=explain.avi" />
</Bookmark>
<Bookmark name="http://electroplumbing.com" href="?docType=ePlot&page=1" />
</Bookmark>
</Global>
Publishers may deem it appropriate to define objects globally (across the entire document – shared by several pages). Unless low-level object ‘node’ identifiers are unique across the package (e.g. WT_ObjectNode elements within the W2D streams), any and all Instance declarations be done at the Page level, and shared Object definitions done at the Global level.
EXAMPLE:
Figure 1 – Two DWF EPlot
pages
We have a two simple pages containing doors consisting of the following W2D pseudo-data.
Page 1’s W2D data:
ObjectNode 1 door1rect
Polyline
ObjectNode 2 door1knob
Circle
Circle
Object Node 3 screw1
Circle
Line
Line
Object Node 4 screw2
Circle
Line
Line
ObjectNode 5 door2rect
Polyline
ObjectNode 6 door2knob
Circle
Circle
Object Node 7 screw3
Circle
Line
Line
Object Node 8 screw4
Circle
Line
Line
Object Node 0
Page 2’s W2D data:
ObjectNode 9 doorrect
Polyline
ObjectNode 10 doorknob
Circle
Circle
Object Node 11 screw
Circle
Line
Line
Object Node 12 screw
Circle
Line
Line
Object Node 0
Given the preceeding W2D data, we can define the object and instance graph, and attach meaningful object properties to the graphics, as in the following example ObjectDefinition.XML content.
Global Object definition:
<GlobalObjectDefinition>
<Properties id=100>
<Property name=”Preferred Supplier” value=”Diamond Building
Supply” />
</Properties>
<Properties id=101 refs=100>
<Property name=Manufacturer value=Schlage />
</Properties>
<Properties id=102 refs=100>
<Property name=Manufacturer value=Hunter />
</Properties>
<Objects>
<Object id=500>
<Properties refs=101>
<Property name=Name value=Knob />
<Property name=Material value=Brass />
</Properties>
</Object>
<Object id=501 children=500>
<Properties refs=102 >
<Property name=Name value=Door />
<Property name=Material value=Wood />
</Properties>
</Object>
</Objects>
</ObjectDefinition>
Page 1 Object Definition:
<PageObjectDefinition>
<Instances>
<Instance id=600 object=500 nodes="2 3 4" />
<Instance id=601 object=500 nodes="6 7 8" >
<Properties>
<Property name=Material value=Steel />
</Properties>
</Instance>
<Instance id=602 object=501 nodes="1" children="600" >
<Properties>
<Property name=Color value=Brown />
</Properties>
</Instance>
<Instance id=603 object=501 nodes="5" children="601" >
<Properties>
<Property name=Manufacturer value=Thompson />
<Property name=”Preferred Supplier” value=”Central Valley Supply” />
<Property name=Color value=White />
</Properties>
</Instance>
</Instances>
</ObjectDefinition>
Page 2 Object Definition:
<ObjectDefinition>
<Instances>
<Instance id=700 object=500 nodes="10 11 12" />
<Instance id=701 object=501 nodes="9" children="700" />
</Instances>
</ObjectDefinition>
Objects:
Objects 500 and 501 are defined globally and do not exist as
geometric data per se. They are object
definitions. Instances of these objects
do exist in the graphical data. Since
there are multiple instances of these objects in our “document”, the publisher
decided to define the object definitions globally so that they can be used
across multiple pages without having to define the objects more than once.
A property heirarchy can be
specified where properties are aggregated by their refs attributes. Properties
collections 101 and 102 therefore contains the property in collection 100. This is an optimization and is not
necessarily required.
Instances:
Instances are required to tie an object back to the graphical data. Unless WT_ObjectNode numbers on each page correspond to the same data, instances should typically be defined at the page level.
On Page 1, Instance 600 defines a doorknob consisting of W2D object nodes 2 (two circles) and 3 and 4 (“screws”). Instance 601 defines the other doorknob, but also overrides the material property from the doorknob object definition. Instance 602 defines a door consisting of W2D object node 1 (a rectangle), plus child instance 600, and defines instance property Color. Instance 603 defines another door, overrides two properties, and defines an instance property. On Page 2, Instance 700 defines a doorknob consisting of W2D object nodes 10, 11, and 12. Instance 701 defines a door consisting of W2D object node 9, plus child instance 700. Page 2’s instances do not override any properties and thus have the default properties as specified in their respective object definition.
Allowing instances to contain other instances (and objects to contain other objets) gives us a true graph. Publishers should be careful to not allow cyclic references. This would be very bad.