Round-tripping XML for Visio files

Round-tripping XML for Visio files

This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.

You can save Microsoft Visio drawings, stencils, and templates as XML (Extensible Markup Language) files and open them again in Visio without any loss of information. This is called round-tripping.

When Visio opens an XML for Visio file created by a third-party, and then resaves the document into another XML for Visio file, although there should be no loss of data the files are not guaranteed to be identical. The following cases illustrate some differences that occur when an XML for Visio file is round-tripped through Visio.

White space is not preserved in XML for Visio files except within the Text element. The user can create an XML for Visio file with any legal white space characters, but the Visio engine rewrites the XML for Visio file using minimal white space.

The following table shows four entity references are considered white space in XML.

Entity reference

Character

	

Tab




Linefeed



Carriage return

 

Space

Note To control whether Visio preserves white space or not, you can change the XMLEmitIndents value in the following registry key:

HKCU\Software\Microsoft\Visio\application

To enable white space, set XMLEmitIndents to a non-zero value. If no value is present or if the value is zero, space is not preserved.

Visio always emits local cell elements that have an explicit unit, value, and formula. A third party can omit portions of the element and Visio either picks default values or infers correct values for the missing components. Consider a possible fragment emitted from a third-party application:

  <PinX F='1'/>

Because only a formula was specified, Visio assigns the formula to the PinX element and then evaluates the formula to determine the value. Because the formula evaluates to a constant, Visio flags the element as a constant. A unit of measure was not specified, so Visio uses the default unit for the cell, which is inches (the default length unit or DL). When the file is resaved, the previous fragment appears like this:

  <PinX>1</PinX>

Note If the unit of measure is explicitly set in the ShapeSheet and is different from the default unit, Visio writes out the Unit attribute.

An XML for Visio file can contain a series of elements that represent indexed rows. Consider this file fragment:

  <Scratch IX='3'>
<X> 3 <X/>
</Scratch>
<Scratch IX='1'>
<X> 1 <X/>
</Scratch>

When Visio reads the file and resaves it, it appears as follows:

  <Scratch IX='0'>
<X F='No Formula'>0</X>
<Y F='No Formula'>0</Y>
...
</Scratch><Scratch IX='1'>
<X>1</X>
<Y F='No Formula'>0</Y>
...
</Scratch><Scratch IX='2'>
<X F='No Formula'>0</X>
<Y F='No Formula'>0</Y>
...
</Scratch><Scratch IX='3'>
<X>3</X>
<Y F='No Formula'>0</Y>
...
</Scratch>

Visio always writes indexed rows out in index order. If the original sequence of rows was indexed sparsely (there were gaps in the sequence), Visio implicitly creates the missing rows.

Note Text rows will not work as expected if the rows are not listed in ascending order.

Named rows have no specific order. If an XML for Visio file contains a series of named rows, when the file is round-tripped, their order is not guaranteed.

Geometry sections round-trip following the same rules as indexed rows. Indexed sections can appear in any order, but when round-tripped they are written out in index order and the sparse sections are implicitly created.

For more information about Geom elements, see Working with geometry in XML for Visio.

In the Visio engine, a block of text can contain ASCII control characters that represent tabs, line breaks, paragraph breaks, and field positions.

An ASCII 9, ASCII 10, or ASCII 13 character indicating a tab, paragraph break, or line break, respectively is emitted as a normal ASCII character into XML for Visio. These characters are considered legal Unicode characters by all XML parsers.

Any other ASCII control character between ASCII 0 and ASCII 31 (excluding ASCII 9, 10, and 13) is considered an illegal Unicode character by some XML parsers. As a result, these characters are translated into special character values in the Unicode Private Use Area. The Private Use Area begins at 0xE000. ASCII control characters are offset by the value 0xE000 when emitted to XML for Visio. Therefore, if a Visio shape's text contained the character ASCII 11 (Hex 0x0B), it is emitted as 0xE00B.

When Visio reads text elements, it translates Unicode characters in the range 0xE000 to 0xE01F by subtracting 0xE000.

For more information about working with text, see Working with a shape's text in XML for Visio.

A third party can omit a document-level element from an XML for Visio file, such as DocumentProperties, or any of the document level child elements, such as Author. However, when the XML for Visio file is round-tripped, Visio creates a document-level element for all non-empty document properties. For example, an XML for Visio file can omit the TimeSaved element, but the round-tripped XML for Visio file contains a TimeSaved element with an appropriate value.