SVG Scenarios using Microsoft Office Visio 2003

Richard See holds a Master of Architecture degree from the University of Washington in Seattle. Mr. See is a licensed Architect in the state of Washington, and practiced architecture with some of the leading design firms in the Pacific Northwest region of the US. He has also contributed to the development of 3 CAD systems and led design and/or development for a number of AEC applications at industry leading companies including Autodesk, Visio and Microsoft. During the past 9 years, Mr. See has been responsible for managing the development of technology and methodologies for enabling interoperability between applications in the AEC/FM industries. In the role of International Technical Director for the International Alliance for Interoperability (IAI), a 650 member organization of global building industry leaders, Mr. See led the development of 3 releases of the Industry Foundation Classes, a software object model representation for the building industry projects that has emerged as the basis for software interoperability in that industry and a recognized industry standard. Currently, Mr. See is Lead Program Manager for the Advanced Technology Teams in the Microsoft Visio Product Group. In this role, he leads the design and implementation of advanced software technologies and next generation products for this Microsoft Division.

Self running the demonstrations described in this paper require the following software applications:

Microsoft Office Visio 2003

Adobe Illustrator 10

CorelDraw 11

SVG Viewer of your choice

For the convenience of conference attendees, we have installed these applications on computers in the Schema Software booth on the exhibition floor. We invite you to visit this booth to try the
demonstrations yourself.

Most people have at least heard of Visio, but the following are some facts that are generally less known. Visio version 1.0 was introduced by Shapeware in October1992 as an easy to use drawing tool for Windows. What
drew attention from the start, when compared to other drawing apps was its new UI paradigm; drag-and-drop drawing creation using pre-created shapes with smart behaviors like context specific graphics, shape specific editing behavior, and shape interaction like connectivity. These were called "SmartShapes".

Visio was positioned in the market as the drawing tool for people who don't know how to draw; a notable positioning, as most people feel they don't know how to draw. A central design goal of the product was to enable
anyone to create great looking, easy to read drawings and diagrams. Another goal was to become the graphics standard for users of Microsoft Windows and Office.

The corporate name changed to Visio Corporation in the spring of 1995, after the release of Visio 3.0 and before going public later that year. Through the late 1990's, multiple 'editions' of Visio were created, each containing shape sets (Stencils) tailored to drawing types (templates) used in targeted industries. These evolved into 4 product offerings: Visio Standard for general business and cross-industry drawing types; Visio Technical for engineering drawing types; Visio Professional for IT and software engineering drawing types; and Visio Enterprise, which extended Pro with network discovery and the Visio Network Equipment library (VNE).

In late 1999, Visio announced it had reached an agreement to be acquired by Microsoft Corporation. The acquisition was completed in early 2000. Since that time, the Technical and Professional products have been combined under the 'Professional' moniker. Key features of the Enterprise edition were migrated to the Windows Network Management division and products, so the Enterprise SKU was discontinued. Similarly, the software engineering and database drawing types were naturally migrated into the Visio Studio product line.

11 years after initial introduction, Visio is the most used graphics application in the world, with an installed base of 8 million users globally. Visio is used in most fortune 500 companies and is the graphics standard in many of these.

The forthcoming Visio 2003 will be distributed in 17 languages. It will be the best and will become the most used version of Visio ever. One of its notable new features will be support for import and export of Scalable Vector Graphics (SVG). The rest of this document is focused on the SVG related features in Visio 2003, and on end user scenarios in which we expect these features to be leveraged by our customers.

Originally, Visio was very focused on creating drawings and diagrams to be printed or embedded into other documents using OLE. After all, the Web did not really emerge until about the time of Visio 4. In the last 3 releases of Visio, we have added more and more features to support use of Visio graphics in web pages, creation of graphics for the web and storing/retrieving Visio graphics on Web based collaboration servers like SharePoint. SVG has emerged as the new high fidelity vector graphic standard for the Web. Dozens of applications have developed or announced their intent to support the SVG format. This made SVG a natural candidate as the Visio team evaluated alternatives for exchange of Vector graphics with other applications going forward.

Another significant factor in the decision to support SVG came out of an effort to rationalize the Visio foreign data format strategy and feature set. Over many releases, the Visio team had built or acquired import and export 'filters' for a large array of foreign graphic formats. Many of these were proprietary formats of competing products. In Visio 2002 release, the number of formats supported for import, export or both had reached 27 formats, 12 of which were proprietary formats of other products --- some of which had already announced they would be supporting SVG. The Visio team decided to deprecate support for a number of older formats and to add a single new format that would be supported by a wide array of other products --- SVG.

End User Scenario: Joe wants to modify an SVG file from an existing company Web site. He starts Visio 2003, selects FILE and then OPEN and is presented with the standard File open dialog. He selects SVG in the FILE TYPE dropdown list, browses to the SVG file and clicks OPEN. A progress dialog displays a progress bar and provides info about the import process. After several seconds, the progress bar is complete and disappears. A new Visio drawing is displayed. SVG elements are now editable as Visio Shapes. Joe begins to modify the graphics as if they were originally created in Visio.

Visio Processing: Visio loads the source data into an SVG DOM, then iterates over that DOM, translating the supported SVG elements into Visio Masters, SmartShapes, Style definitions, etc. In each case, the SVG
element is mapped to the equivalent (or nearly equivalent) element type in Visio's import/export object model. The resulting (transformed) data is added to the current document in Visio's data translation framework (known as "Bridger"). After all the SVG data has been processed, Bridger streams the document to Visio in Visio's native XML format (VDX). Visio loads the VDX stream as a new Visio document that contains a single drawing page with the same name as the source SVG file. The resulting Visio graphics have very high visual fidelity when compared to the source SVG graphics, though there are some import limitations (Section 3.3.1 ), as outlined below.

End User Scenario: Mary is an avid Visio user who makes extensive use of the INSERT tool to integrate graphics from various sources. A large part of her job is creating technical documentation for the components manufactured by her company. She uses many tools to create such documentation, depending upon the source data and required final format. In one case, she was tasked with documenting a new solenoid assembly and was given an SVG exploded isometric diagram created for the company web site, plus a printout of the diagram annotated by hand. The SVG format drawing led Mary immediately to Visio 2003 in which she could add annotation and the standard company formatting to the solenoid assembly drawing.

Mary first opens her documentation template file containing standard formatting, page layout, fonts, styles, etc. She then selects INSERT, then PICTURE, thenFrom File and is presented with an
OPEN file dialog. She browses to the SVG file, selects it and clicks OPEN. The SVG graphics is added to the Visio page as the current selection. Mary moves the graphics to the desired location and clicks to place it. Mary then adds annotation keys and annotations according to the printout she had been given. She was even able to edit the SVG graphics just as if it had been created in Visio originally. When finished, Mary simply saves the Visio drawing, which now includes the converted SVG graphics, combined with annotation and other graphics created in Visio.

Visio Processing: Processing and results for this scenario are nearly identical to that described for scenario 1 (Section 3.1.1 ) . The difference is that the single page VDX document stream is loaded by Visio as a single group element. This group is merged into the active drawing page as the current selection set, initially located at the center of the current viewport. The user positions this group relative to other
graphics on the page, and sets its location just as if dragging and dropping from the Visio stencil (left mouse click).

End User Scenario: David leads a research lab in a high tech company in Silicon Valley. After taking a management course recently, he decided to create a new team web site on the company intranet. The purpose would be to create a site for intra-team collaboration and for outbound communication about the mission of his group and the projects on which each team member is currently working. One part of the site would show the team structure. He decided to pull this diagram from company organization charts. David loaded the company org charts into Visio and selected the R&D division page. He then created hyperlinks from each person in the team to the project page he had created for each. He was ready to
save the diagram & links for his team site, but decided he wanted to use SVG graphics as many people in the company did not have Visio. After selecting his team only, he selects FILE and then SAVE AS. He selects SVG as the file type and then SAVE.

Visio Processing: Visio streams the selected shapes and all objects referenced by those shapes as a VDX document to the Bridger data translation framework (see processing description in scenario 1(Section 3.1.1 ) ). Bridger loads the VDX stream as the export document, then iterates over each element in the document, translating each into equivalent (or nearly equivalent) SVG elements to construct a new SVG DOM. The resulting SVG document contains symbols, uses, styles, etc. nearly equivalent to the selected shape set in Visio. The resulting SVG graphics have very high visual fidelity when compared to the source Visio graphics, though there are some export limitations(Section 3.3.2 ), as outlined below.

End User Scenario: Ken is an executive assistant in the same company as David, but in a different division. Ken's boss was inspired by the new team web site created by David, and asked Ken to develop something similar for the Sales & Marketing team. Ken used the same steps as David, but working from the Sales & Marketing page in the company org charts. Since he wanted to include everyone on the Sales & Marketing page, he did not select a subset.
As a result, all graphics on the page were exported, including the background graphics from a Visio 'background page'.

Visio Processing: Visio streams the active page, including all shapes and all objects referenced by those shapes, visible and non-visible, as a VDX document to the Bridger data translation framework (see processing description in scenario 1 (Section 3.1.1 ) ). As in scenario 3 (Section 3.1.3 ), Bridger loads the VDX stream as the export document, then iterates over
each element in the document, translating each into equivalent (or nearly equivalent) SVG elements to construct a new SVG DOM. The resulting SVG document contains symbols, uses, styles, etc. nearly equivalent to the active page in Visio. Also as in scenario 3 (Section 3.1.3 ), the resulting SVG graphics have very high visual fidelity when compared to the source Visio graphics, though there are some export limitations (Section 3.3.2 ) , as outlined below.

End User Scenario: Inspired by the web sites of David and Ken, Yoko, the group admin in the company's HR department decides she should publish all the company's published org charts in SVG format. She opens
the source Visio drawing set and selects FILE, then SAVE AS WEB PAGE. This invokes the Visio Save As Web (SAW) solution. In the SAW dialog, Yoko selects PUBLISH and confirms that ALL pages will be exported.

She then clicks the ADVANCED tab, selects SVG as the primary "output format" and JPG as the secondary. Finally, she then clicks OK to begin creating the Web pages. Finally, she integrates the new pages containing SVG graphics into the corporate intranet Web. The resulting graphics are higher quality (on screen and in print) and users can now pan and zoom and link to sub-organizations.

Visio Processing: As SVG does not support the concept of multiple pages in a document, the SAW solution instructs Visio to process the graphics one page at a time. For each page, Visio completes export processing exactly as outlined in scenario 4 (Section 3.1.4 ) and SAW incorporates the resulting SVG graphics into HTML Web pages it creates. The resulting collection of Web pages will maintain any cross-page hyperlinks (e.g. the links from the executive org page to the sub-orgs in this example). As in the previous two scenarios, the resulting SVG graphics have very high visual fidelity when compared to the source Visio graphics, though there are some export limitations (Section 3.3.2 ), as outlined below.

Visio 2003 allows the user to open and edit an SVG document that was exported from Adobe Illustrator. The "2003 SVG Open Conference Bookmark" is an example. The graphics were originally created in Adobe Illustrator 10 and will be opened in Visio as the starting point for a new graphic composition.

Demo Script

Launch Adobe Illustrator 10

Select File, then Open; browse to "svgopenbookmark.ai"; click on Open.

Select File, then Save As; select SVG as the output format; use the default export options; confirm the name is "svgopenbookmark.svg"; click on Save.

No offense intended to the author of the bookmark graphics, but we would like to have a bit of fun with them. We found an SVG graphic published by Corel called 'funguys.cdr' which we believe is just the ticket.

Demo Script

Launch CorelDraw 11

Select File, then Open; browse to "funguys.cdr"; click on Open.

Select File, then Save As; select SVG as the output format; use the default export options; confirm the file name "funguys.svg"; click on Save.

Return to Visio 2003

Select Insert, then Picture, then From File; browse to "funguys.svg" from step (3); click Open.

Export multiple Visio drawings as a related set of SVG drawings, in the context of a cross-linked Web site. In this demonstration, we will save multiple building floor plan drawings that might be used on a company web page to
locate a person, a printer, the nearest kitchen or might be used as the corporate facilities management Web site.

Demo Script

Launch Visio 2003.

Select File, then Open; browse to "OfficeBuilding.vsd"; click on Open.

Click on the page tab that says "A-1". This is the first floor of the building.

Make sure no shapes are selected by clicking outside the drawing.

Select File, then Save As Web Page; enter a file name (e.g. "OfficeBuilding.htm"); Click on "Publish".

In the "General" tab, check to make sure that "All" pages are being published, and that all Publishing Options are checked. In the "Advanced" tab, check that the primary output format is set to "SVG" and the alternate (for older browsers) is "JPG".

Click "OK".
Progress dialogs inform the user of what is happening throughout the translation & export process. When the export is complete, the Web page is opened in Internet Explorer. The SVG graphics are rendered in the primary frame using your SVG Viewer. To examine these graphics:

Click on the "Go to Page" dropdown list to select the page you want to view. Click on the 'go to' arrow to the right of the page box to render the selected page.

As you can see, the graphics are nearly identical to the source drawing in Visio.

In general, import fidelity from SVG into Visio is quite good. However, there are some differences in graphic concepts and constructs between the SVG specifications and Visio 2003. Therefore, there are some limitations in
importing SVG and some SVG elements will be ignored. For example: Visio does not support animation; animation data will be ignored.

There is one limitation that should be discussed in some detail. In SVG, text contains limited semantic content and places the responsibility of laying out the text on the user / application that is generating the SVG. This allows for
great flexibility in the power of SVG, but makes it very difficult to retrieve the original intent of the end user

<text x="5.97" y="66.41" class="st2">

Textbox that contains

<tspan x="16.31" dy="1.2em" class="st3">

many lines of text

</tspan>

<tspan x="29.32" dy="1.2em" class="st3">

which will be

</tspan>

<tspan x="16.65" dy="1.2em" class="st3">

automatically text

</tspan>

<tspan x="38.32" dy="1.2em" class="st3">

wrapped

</tspan>

</text>

For example, if an application supports text box (as in Visio) and wraps the text flow according to the bounding box, the exported SVG may use <tspan>s to position each new line of text in order to provide visual fidelity.

In addition, <tspan>s may also be used to position text starting at the next line (from a carriage return) instead of an automatic text wrap. The example below illustrates this case.

<text x="4" y="672.02" class="st2">

List of &#60;svg&#62; elements

<tspan x="4" dy="1.2em" class="st3">

* Line

</tspan>

<tspan x="4" dy="1.2em" class="st3">

* Rect

</tspan>

<tspan> x="4" dy="1.2em" class="st3">

* Path

</tspan>

<tspan x="4" dy="1.2em" class="st3">

* Circle

</tspan>

</text>

The text and tspan elements in SVG 1.0 are insufficient to determining the original intent of the text creator; i.e. whether the y-position changes are due to carriage returns or due to normal text flow (wrapping) in the creating application. These observations led us to one of the key decisions in designing SVG import and export features for Visio. We needed to decide on the prioritization between text edit-ability and visual fidelity. While visual fidelity was the number one priority in virtually all other areas, we anticipated that users would need to be able to edit text after import from SVG. It was decided that edit-ability would be our first priority for text. All the <tspan>s are stored and concatenated into 1 text block, with no carriage returns introduced. This does result in text layout differences in many cases, but the user is able to use the full range of text editing and composition tools in Visio on the resulting text blocks and thus is able to quickly remedy these differences.

Gradients – Visio gradients are more limited than those allowed in SVG. Parameterized linear gradients in SVG will be mapped to the nearest of 4 pre-defined linear gradients in Visio. Parameterized radial gradients in SVG will be mapped to the nearest of the 5 predefined radial gradients in Visio.

SVG pattern elements - will be mapped to custom fill or line patterns in Visio 2003.

Visio only supports the even-odd fill rule. SVG allows for both even-odd and non-zero. Paths with the non-zero fill rule applied to them may look different when imported into Visio.

Line pattern styles (defined through dash arrays) - will be mapped to pre-defined Visio line patterns.

SVG allows for anisotropic scaling (i.e. horizontal and vertical lines will have different thicknesses). Visio only supports uniform scaling.

SVG property: stroke-linecap="butt" will be mapped to square in Visio.

SVG property: stroke-linejoin is not supported.

In Visio, if the stroke color overlaps the fill color, the fill color's opacity and the stroke color's opacities are combined together. Thus, the user can see up to 3 different shades of colors: fill color, combined fill and stroke color and stroke color. In SVG, when the stroke color overlaps the fill color, the fill color and its opacity is ignored. Thus, the user will see only 2 shades of colors: fill and stroke color.

Opacities defined on groups in SVG are applied to sub-shapes, whereas in Visio, the opacity defined on the group is ignored.

Explicit placement of pattern tiles in SVG is ignored.

The SVG property: patternTransform will only affect the scale of the pattern tile.

In SVG, when an object with a pattern fill has a transform attribute applied, the pattern receives the same transformation. In Visio, only rotation and flipping of the patterns will be done.

Nested patterns in SVG will not be supported.

The typographical control available in SVG for placement of glyphs (and rotating of glyphs) will be ignored.

TRef elements – will be parsed and features that are supported by Visio will be mapped.

TextPath elements – the text will be imported and placed character by character, but the path definition will be discarded as 'text along a path' is not supported in Visio

Text is limited to solid colors in Visio. Text that refers to patterns or gradients in SVG will be mapped to a solid color.

Text that has different stroke and fill colors in SVG will be visually different also, as Visio does not support different stroke and fill colors for text. In addition, the text in SVG will look slightly larger as it adds the stroke width to the glyph.

Visio has a maximum font size of 1638 pts. SVG has no such maximum. If the font size specified is greater than 1638 pts, the font size will be set to 1638 pts.

SVG property: baseline-shift will be mapped to either superscript or subscript text in Visio.

The "blink" text feature is not available in Visio.

Kerning and word spacing is not available in Visio.

SVG allows a font definition to actually consist of multiple fonts, and the rule for selecting the actual font to render in is dependent on what the character is. Visio doesn't support this, meaning the first font in the definition will be selected as the font to use.

Font names for embedded fonts - will be imported. Font glyph information will not be imported, as Visio will retrieve glyphs from Windows for any fonts that exist on the system and use font substitution for fonts not present.

Filter effects will only be supported for raster image elements, and will be limited to the subset of SVG filter effects supported by Visio for raster elements. These filter effects are:

Brightness

Contrast

Gamma

Transparency

Blur

Sharpen

Filter effects in SVG can be applied to particular sub-regions. This will be ignored.

Interactivity will not be supported other than for hyperlinks

In SVG, when a symbol is drawn with a use element, the effect of the width and height attribute is as if a transformation has been applied to it. This affects all length-based attributes (such as font-size and stroke-width). In Visio, these attributes will not be adjusted and will appear different if the master shape's size is different than the local shape's size.

XSL styling is not supported.

Elements such as markers and patterns will not be clipped.

In Visio, clip-paths cannot contain text. SVG documents which contain text clip-paths will map the clip-path's text element directly, at the location at which the clip-path is referenced. The color of the text will be as defined in the clip-path's text element definition, as it is not possible to use the fill color of the object that is being clipped, as the object may be a complex object, consisting of multiple geometries.

If a clip-path has a line element in its definition, that portion of the clip-path will not be visible when imported into Visio.

In general, export fidelity to SVG from Visio is quite good; especially graphic fidelity. However, there are some differences in drawing concepts and constructs between Visio and the SVG standard. Therefore, there are some limitations in exporting to SVG and some Visio constructs will be lost. Please see the Limitations in SVG Round-Trip (Section 4.4 ) section for more detail.

These limitations can be summarized as follows:

The current version of the SVG Export does not support custom fill patterns, custom line patterns or custom line ends. Drawings which use these features will default to a fill pattern of None, a solid line pattern, and a simple arrowhead.

Font width scaling in Visio will be mapped to the font-stretch attribute in SVG. Since the font-stretch attribute in SVG takes discrete values, there may be some minor visual fidelity
differences there.

Visio allows text to be formatted with double-strikethrough. The resulting SVG will only contain a single strikethrough.

Visio allows text to be formatted with a double-underline. The resulting SVG will only contain a single underline.

Underlines will appear directly beneath superscripted text instead of remaining part of the original underline.

Visio allows a text scaling range of 33% to 200%. SVG has a text scaling range of 68% to 173%.

In Visio, the direction of text scaling is different when applied to text rendered horizontally vs. vertically. SVG always scales text horizontally. In the case where the Visio drawing has
vertically rendered text which has a scale applied to it, the exported SVG will have the scale applied in the horizontal direction instead.

Fill patterns are implemented as rasterized 8x8 RGB PNGs, so that the foreground and background transparencies can be set appropriately. Because they are rasterized, the fill patterns will not scale when the drawing is scaled inside the SVG Viewer.

Any filter effect in Visio is applied to the original image first, and then scaling is performed on the rasterized image (if necessary). In SVG, the image is first scaled, and then the filter
effect is applied. For images that have been scaled, the user may see a difference between the images from Visio and the ones in SVG.

Visio has the filter effect: denoise. This is not supported in SVG. The denoise filter effect will be applied to the raster image before it is exported to SVG.

Exporting of markers to SVG has the same limitations as the Visio Viewer does.

Some WMFs contain a bunch of polygons beside each other to try and produce a gradient, and uses R2_XORPEN to combine the polygons with the background. GDI doesn't fill the rightmost pixel in each scan line of the polygon, whereas SVG does. This causes the polygon fills to overlap, producing strange colors at the intersections due to the XOR.

Users will also experience some fidelity differences due to known issues in Adobe's SVG Viewer (version 3).

If the SVG document references a shape within another SVG document through a hyperlink, Internet Explorer displays an error. Other browsers are able to support this. (Note: if the hyperlink is to another SVG file – not a specific shape – Internet Explorer can link to it.)

Some simple paths in Adobe's SVG Viewer do not get clipped properly if the viewing area is large. If you zoom out of the image, making the viewing area smaller, the clip gets applied
properly.

Paletted PNGs with transparencies in them are not rendered.

Gradients which have one of its stop colors set to 100% transparent renders slightly differently between Adobe's SVG Viewer and the Visio application.
SVGVisio

Symbol fonts are not displayed in Adobe's SVG Viewer.

The selection of the font to use is sometimes incorrect. For example, if an SVG file specifies "Arial Narrow" as its font family name, and has a font-weight of 700, the Adobe SVG Viewer will automatically select "Arial" instead of selecting "Arial Narrow" and then applying the font-weight of 700 to it.

Underline, Strikethrough & Overline
The following problems exist for Underline, Strikethrough and Overline. These are issues with the Adobe SVG Viewer and its ability to handle relative (x or y) vs. absolute (dx or dy) text
positions.
Underlines, strikethroughs or overlines with not appear on the second line of wrapped text. Any of these underlines, strikethroughs or overlines will appear on the first line.

Visio 2003

Adobe Viewer 3.0

Table 1

Underlines, strikethroughs or overlines on Justified or Force Justified text will appear "broken".

To better facilitate editing of an SVG document created in Visio 2003 and then round-tripped back into Visio and to include concepts that don't yet exist in SVG, we leveraged the XML extensibility in the SVG standard. The following sections describe some of these extensions. None of these extensions compromise the SVG in terms of visual fidelity or conformance to the standard.

Appendix A (Chapter 7 ) contains a summary of the Visio extensions that were added to the SVG DOM to improve edit-ability after round-trip through the SVG format.

Key concepts to be preserved through round-trip were shape, layer, and page. A shape, when exported to SVG, can be defined through multiple SVG elements. For example, the text in the shape would be separate from the shape geometry. The drawing of the shape's shadow would result in separate elements from those representing the shape itself. Drawing layers are effectively a specialization for grouping a collection of objects, but does not exist in the SVG standard. Similarly, SVG does not include the concept of page, and therefore cannot represent shapes on a background page versus those on a foreground page.

SVG really only has 1 element type for representing such structural concepts in a drawing: the group element. As defined in the standard, the group element is not sufficient to distinguish between page, layer and shape structures in Visio drawings. The "v:groupContext" attribute was added to the <group> element so that grouping of SVG elements into a shapes, background pages and foreground pages could be maintained.

However, this group extension was insufficient to capture the concept of drawing layers in Visio. To preserve layer definitions, the <v:layer> element was added which contains attributes defining the layer properties, including such things as the name, color and visibility. Since a Visio drawing can have many layers, there can be many <v:layer> elements. The ordering of the <v:layer> elements will match the order in which the layers are defined in the Visio document. To capture Visio shape membership in a layer, the attribute "v:layerMember" was added to the SVG group element. When the group corresponds to a shape, the "v:layerMember" attribute specifies the indices of the layers to which the shape belongs. Shapes can be members of zero to many layers.

Annotation is a new collaboration feature introduced in Visio 2003. As in other Microsoft Office applications, this feature allows reviewers to annotate a drawing to provide feedback to the original author. Users can control visibility of these annotations, setting visibility to individual reviewers, all reviewers or no reviewers.

A key visual feature in annotation is that each reviewer is assigned a reviewer's color. All comments, shapes, etc. that the reviewer adds to a Visio drawing are placed on their annotation overlay and are rendered using their reviewer's color. This can be thought of as an override color. The shapes placed by the reviewer still have color definitions. If/when these proposed revisions are accepted into the underlying drawing, they will be rendered with the colors defined in the shapes. The SVG extension for annotation preserves the native shape colors so they are available if the proposed revision is accepted after round-trip back into Visio.

Maintaining the structure of object membership in an annotation overlay is fairly straightforward, as annotation overlays are structured in Visio as hidden pages. This means the "v:groupContext" attribute can be used. The <v:reviewer> element was introduced to define the list of reviewers who have annotated the document. The challenge was to display the annotated shape in the correct reviewer's color while preserving the shape's color properties for use after round-trip back into Visio. This was handled through use of class selectors in Cascading Style Sheets (CSS). The ordering of the class selector enabled us to override the original shape's style with the reviewer's coloring, thus preserving visual fidelity. When round-tripped back into Visio, the shapes are mapped back to the reviewer's overlay and the shape color properties
are maintained.

Multiple hyperlinks are supported through the use of scripting in the SVG created on export. Since the SVG Import process does not support scripting, an extension v:hyperlinks has been added to the menu containing the list of hyperlinks. The list of hyperlinks is then associated back to the Visio shape onimport.

Many extensions were added to support the different types of formatting available in Visio.

For example, to maintain visual fidelity of fill patterns, an 8x8 PNG image is created that corresponds to the fill pattern. This results in correct visual fidelity but after round-trip, the 8x8 PNG image would be imported as a custom fill pattern, and the original fill pattern, its foreground and background colors and opacities would be lost. To maintain this information, various attributes were added to the <pattern> element, so that the original Visio fill pattern can be used on import of an SVG document containing these Visio extensions.

Similar extensions have been added to properly round-trip gradients, image filtering and line ends.

Text is one of the areas where a lot of semantic information is lost when exported to SVG. SVG does not have the concept of paragraphs, indentation, alignment, bullets, tabs, and all text is placed explicitly. To enable structured text editing after round-trip, this information is preserved through the addition of Visio extensions.

In Visio, text can exist without any geometry. The information on where the text should be displayed is stored in the TextTransform row of the associated ShapeSheet. When such 'text only' shapes are translated, there is no SVG geometry element associated with the text. Preserving the Visio textbox information required the addition of the <v:textRect> element, which contains attributes which define the location and size of the textbox.

The <v:textBlock> element and its associated attributes contain formatting information at the textBlock level. This includes information such as margins, vertical alignment, tab spacing and vertical text indicator.

The <v:paragraph> element and its associated attributes contain paragraph formatting information, including: indentations, spacing, horizontal alignment, and bullet formatting. Note: this bullet formatting information can include bullet font, size, etc., but the text may not be bulleted. To represent when text is bulleted, the attribute "v:isBullet" is added to the <tspan> element.

The <v:tabList> element and its associated attributes define the tab stops associated with a block of text.

Control characters are also used to structure text. Examples include newline, space, line feed, and tab. Since none of these control characters are visually rendered, they will be lost when exporting to SVG. To preserve this formatting, the <v:newLineChar>, <v:spaceChar>, <v:lf> and <v:tabChar> elements are introduced. These elements can be children of <text> or <tspan> elements.

There are 3 generic types of foreign objects supported by Visio. These are: raster images, graphic metafiles and OLE linked or embedded objects. Raster images are converted to either PNGs or JPGs, and are round-tripped without any information loss.

Metafiles are converted to SVG as part of the export process. When round-tripped the resulting SVG elements would be imported as rather dumb shapes. While the resulting graphics would have good visual fidelity, the structure and semantics of the drawing would thus be changed. To preserve the original structure and semantics, the metafile is also embedded in the exported SVG. On round-trip, the SVG representation of the metafile is ignored and the original metafile is inserted into the Visio drawing created during import.

OLE linked or embedded objects are also converted to SVG as part of the export process by converting the metafile representation included in the OLE object. As with metafiles, the OLE object is embedded in the SVG and used on import if the SVG is round-tripped back into Visio in order to preserve the drawing structure and the opportunity to use the OLE object after round-trip. The corresponding SVG elements are, of course, redundant and ignored.

Custom properties and 'User' data cells are critical to Visio shapes and solutions. These properties are used to store non-graphic data and to define semantics for Visio SmartShapes. In many cases, this data is as important as the drawing graphics. In some cases it is even more important as the graphics may only be a single representation of a multi-dimensional data set. Loss of this data through SVG round-trip would break most Visio solutions and greatly limit the scenarios in which SVG could be used by Visio customers. Therefore, custom properties and 'User' cell data are included (by default) with SVG
exported from Visio. They are also restored in the shapes created during import of that (round-tripped) SVG, preserving this important non-graphic data.

There are still other Visio extensions to improve drawing semantics and structure through SVG round-trip that will not be discussed here. These include document properties, page properties, titles, descriptions, and more. Please see Appendix A (Chapter 7 ) for a more complete list.

Preserving the annotation overlays in a Visio drawing was an interesting challenge in SVG. Take the following example:

This is the first floor plan for a summer cabin. In this Visio annotation scenario, a furniture salesman will propose furnishings for review and comment by the cabin owners. To do this, he uses the new markup features in Visio 2003. The proposed changes are colored using the 'reviewer's color' as shown below.

This SVG snippet demonstrates the definition of CSS styles to color annotated shapes with an assigned reviewer's color. As some SVG elements belonging to a shape on an annotation overlay are styled slightly differently, there are many different CSS styles defined for each reviewer. For example, in Visio, the shape's edges are colored using the reviewer's (line) color, but the fill is rendered in a lighter shade of that color (the fill color). In SVG, the fill for text elements is set to the reviewer's line color, as this is how text is rendered in Visio. Markers are also defined to use the reviewer's line color and, the <use> element has its own styling in which the fill has also been set to the reviewer's line color.

This list of CSS styles must be defined for each annotation overlay (reviewer) in the Visio drawing.

Note: the '>' means "child of" instead of "descendant of", which limits the styling to only apply to the 1st generation children of the descendant of "reviewedBy1 vShp". This is done so that SVG generated from metafiles do not get colored by the reviewer's color (to match rendering behavior in Visio).

Upon review of the SVG corresponding to the dining room table that was added to "SummerCabin" as annotation, we can see how the CSS style definitions reviewed above are applied. The other shapes on the reviewer's page have been removed in order to focus on the annotation shapes. As you can see, the <g> element defining the reviewer's page has an associated class. This identifies which set of CSS styles that will be used (as seen above). The path defining one of the chairs that belongs to the dining room table has class="st20 vShp". The "st20" class selector refers to the style definition which defined the oval dining table. The "vShp" class selector in combination with its parent selector "reviewedBy2" and the type of SVG element, tells the SVG Viewer which of the CSS styles to apply after the "st20" style has been applied. This overrides the "st20" style's fill and stroke coloring, thus causing the shape to display as a shade of blue.

The Summer Cabin drawing is a very good example of how Visio users add semantics and non-graphic data to Visio shapes using custom properties and 'User' data cells. This drawing includes custom properties and user-defined data at all 3 levels of the document: drawing, page, and shape.

At the drawing level, the custom properties and user-defined data is stored as a child of the <v:documentProperties> element which is a child of the root <svg> element.

This demonstration will exemplify the round trip priorities we put in place for this release. Although we are far from maintaining full fidelity of all concepts in Visio drawings, we have been successful in maintaining a high level of visual fidelity, shape properties, layer membership, layer properties, annotation overlays structures and background page structures.

Our highest priority when considering what information should be round-tripped through SVG and back into Visio was to ensure that visual fidelity and content fidelity was
preserved. To a large degree, this goal was achieved. However, there is much more to a Visio drawing in terms of structure and formula driven graphics/behavior (parametric graphics).

In hindsight, we may have aimed a bit too low in our round-trip goals as drawings round-tripped through SVG have limited edit-ability, relative to the original drawings. The extensions to SVG are minimal in this release, so there are many limitations in round-trip through SVG. The following section is not an exhaustive list, but does briefly discuss some of these limitations.

Shape Types & Relationships - We did not set "behavioral" fidelity as a goal. This has been costly, particularly in the areas of connector shapes, their routing and their 'glue' relationships with the shapes they connect. Even though SVG round-tripped back into Visio appears to be identical to the source, the shapes behave quite differently. This means the Visio user must manually re-create the connection relationships, which is a notable weakness in the round-trip performance of this release.

Formulas – Similarly, we decided early in the design process to round-trip the Last Valid Computed Value (LVCV) for any shape data being included in our extensions to SVG. As so much of Visio's shape behavior is dependent on formulas, this is a significant compromise as shapes do not behave the same after round-trip through SVG.

Multiple Geometry Sections – Though Shapes in Visio can have many geometry sections for various purposes, these are combined into a single SVG <path> statement and will not be restored after round-trip.

Multi-Group Membership – In Visio, a shape can be a member of any number of groups (e.g. multiple layer membership). SVG does not support this feature. Shapes belonging to multiple groups originally, will belong to a single group after round-trip through SVG

Concepts Lost - Although not an exhaustive list, the following Visio concepts are not included in the SVG we emit and are therefore lost in round-trip through SVG:

SVG import and export has been fully integrated into Visio. This means it can be used through Visio rich API. This programmatic access, combined with the SVG extensions described above will enable a number of new opportunities for solution developers in the Visio Partner program and within customer organizations. The next few sections discuss some of the opportunities and provide a demonstration for
one hypothetical partner solution leveraging SVG.

Visio drawings can be rich with property data collected from corporate databases and Line Of Business (LOB) applications. In extending SVG emitted by Visio to include shape properties, this rich data is available to other applications using SVG. Extracting the shape property data from an SVG 'shape group' is very straightforward and open to any and all application developers as the extension schema will be published by Microsoft.

XML support was introduced In the 2002 release of Visio. In that release, we introduced support for associating namespace qualified XML data with Visio drawing elements. This goes significantly beyond the simple property associations described in the section above. Entire XML data structures can be associated. SolutionsXML can be embedded in most element types in Visio, from individual shapes up to the Document. SolutionsXML associated as a property of elements exported to SVG will be included in that SVG as part of the Visio Extension data. Additionally, as this is XML data, we expand this SolutionsXML property data to inline, namespace qualified, embedded XML. SolutionsXML associated with a 'shape group' in SVG can be mined using any standard XML toolset.

We discussed the opportunity to include SolutionsXML in SVG above. This data could be mined and/or surfaced to the user in a number of ways. One method that would be broadly useful would be to inject script into the SVG (as a solution post-process) that would format and present the SolutionXML to the user in the browser, e.g. in response to a Right Mouse Action (RMA) or Mouse Over event. Some Microsoft Office Visio partners are already investigating this opportunity.

We have discussed embedding data in drawings collected through Visio's ability to link to corporate databases. These scenarios are limited in that they are only as accurate as the last 'synch' to the source data done in Visio. A more ambitious strategy would be to add XML data that could be used to link directly to a LOB application, e.g. through a web service or ASP.NET HTTP Handler that exposes such data live. As in the case above, the solution could inject script in a post-processing of the SVG generated by Visio. The script would extract the SolutionsXML data and query the app, web service or HTTP Handler for the current data set associated with the element in the SVG graphics. In the example below, we took a different approach. In this example, the HTTP Handler modifies the SVG being returned to the client by adding a new CSS style as a highlight color and then modifies the appropriate SG element representing the process step that is currently active. In this case, no client side script is required.

This demonstration simulates a manufacturer's order status web site. The end user scenario is that a customer visits the Web site to query for the status of a purchase order. The customer enters a customer ID and an order number. These parameters are included in a query to an ASP.NET (ASPX) web page exposed by the manufacturer's order processing Web server. The response to the query is presented as SVG graphics, showing the order and shipment process and highlighting the current process step (status) for the order queried. The SVG includes property data on each of the process shapes including the products in the order, the warehouse from which they were shipped, the shipment tracking information, etc.

The SVG graphics will be different, depending on the order as the process is dependent on multiple parameters (e.g. parts orders, warehouse inventory, shipment destination, etc.). The associated data is obviously dependent on the customer and order. A library of SVG drawings created in Visio is the basis for responses from the server. Based on user input to the ASP.NET form in the Status
web page, the appropriate SVG document is selected, loaded into memory and modified to convey the appropriate information to the user. The resulting SVG stream is then returned to the client web page for display to the user.

In the 2003 release of Visio, we have introduced support for import and export of SVG as a new generation exchange standard increasingly supported by other graphic applications. It provides Visio users with support for a high fidelity efficient vector graphics format optimized for the Web. This was a logical 'next step' for the Visio product as importing graphics from other products and formats has always been a priority. As SVG will be supported in a number of other graphic apps, we were also able to deprecate support for older proprietary formats and recoup the associated maintenance resources.

Through a wide array of samples and examples, we have demonstrated that Visio 2003 is an excellent application for generating SVG graphics. Visio supports a rich array of 67 different drawing types in16 drawing categories. Each of these can be exported as SVG for ready use on the Web. These drawing categories (drawing type counts) are:

Block diagrams (3)

Brainstorming (1)

Building plan drawings (12)

Business process diagrams (9)

Charts & graphs (2)

Database diagrams (3)

Electrical engineering (4)

Flowcharting (5)

Maps (2)

Mechanical engineering (2)

Network diagrams (6)

Organization charts (2)

Process engineering (2)

Project scheduling (4)

Software diagrams (8)

Web diagrams (2)

We have achieved a high degree of graphic fidelity and even managed to make the SVG data richer and highly editable through a set of Visio extensions to the standard. As demonstrated, these
extensions allow us to maintain concepts and semantics that would otherwise be lost in the SVG format.

We have also demonstrated that Visio is a highly capable and easy to use SVG editor. When importing, the structure in SVG graphics is preserved and intelligently mapped to equivalent concepts in Visio. This results in highly editable Visio drawings. This combined with Visio ease of use and rich content libraries make Visio an excellent choice for editing SVG graphics.

Special attention was given to edit-ability of text, since the SVG 1.0 standard does not include support for text flow. In this case, visual fidelity is secondary to edit-ability. All <tspans> in a <text> element are concatenated and will flow within a single Visio text box element. Visual fidelity can be quickly re-established using Visio's rich text editing and composition features.

As with export, we have achieved a high degree of graphic fidelity with few exceptions. Additionally, we have enhanced the edit-ability of SVG originally generated by Visio through the Visio extensions discussed above. Examples of this improved edit-ability include: preservation of drawing layer definitions, shape membership in those layers and round-trip of embedded metafiles and OLE objects.

However, concepts not supported in Visio are not preserved in a round-trip through Visio. Animation and sound are two examples of SVG data that will be lost on import to Visio.

The release cycle for Visio over the past 3 releases has been approximately 2 years. Assuming the SVG feature set is well received by Visio customers and partners, we can reasonably anticipate many enhancement requests for SVG import/export in the next Visio release. While I certainly cannot commit to implementing any such requests at this time, it is useful to discuss some possible next steps in this area.

Microsoft is participating in the W3C's SVG 2.0 committee. Michael Stokes is Microsoft's representative on this committee. The Visio team will provide input to the next version of SVG based on our experiences in supporting SVG 1.0. One example of this is a request to support text flow. Extraordinary efforts were required to overcome this limitation in SVG 1.0 --- in our effort to maximize the edit-ability of text elements imported from SVG.

There are a number of things we have discussed for possible improvement in the next release of Visio, assuming this feature set is well received and used by customers. The following list of possibilities should be considered a brainstorming list with no level of commitment at this point.

Possible SVG import/export improvements

Improved gradient support

Export support for custom line styles, line end styles (markers) and fill patterns