VML and PGML: A Comparison

June 22, 1998

Lisa Rein

There are many ways in which PGML and VML are similar.

Both are text-based metamarkup languages, and are singing the same song about the advantages of text-based markup over a binary format. Both strive to be CSS2 compliant.

Both PGML and VML were inspired by their respective companies' software products' image and document formats. Both will enable applications like Word (for VML) and Illustrator (for PGML) to pump out XML versions of their files. This is good news for many that non-XML developers can start marking up their Web content despite themselves, which is something we have all been waiting on for quite some time.

The integration of XML into the core level of every end user product is a smart move for everyone concerned, but at present, there are a lot of legacy documents (.ps, .pdf, .doc, .rtf) that are not just going to disappear anytime soon. But remember, both the VML and PGML camps insist that their XML-based formats are much more than XML wrappers for their existing formats.

PGML and VML use different syntaxes for graphic objects, but the feature sets are basically the same.

Both specifications allow for:

• Paths
• Images
• Text (there might be some differences here)
• Predefined shape objects (e.g., rectangles, rounded rectangle, ellipse, circle)
• Prototype shape objects

The VML specification included a partial DTD, while the PGML specification included a complete and verified DTD. When a standard is adopted, surely a complete DTD will be provided.

Both specifications include features allowing applications to store higher-level application-specific private data within the graphics file. These features promote a higher-level interchange of graphics between applications. VML goes beyond PGML in this regard by providing additional features which are particularly valuable in exchanging higher-level graphics data, particularly between template-oriented graphic diagramming applications.

PGML allows the creation and editing of shapes via transformation matrix in a coordinate system. VML accomplishes this differently, through the use of shape types that can then combine semantically to form other shapes that in turn are scalable, etc. VML's coordinate space's shape and group define a CSS2 block level box.

The following two snippets illustrate how PGML and VML are equivalent in how they save/restore a graphics state.

Both snippets draw a rectangle rotated at 180 degrees and an oval/ellipse rotated at 90 degrees.

VML logic:

<v:group style="rot:90">       

<v:group style="rot:90">    

<v:rect ... />     <!-- rectangle rotated 180 degrees -->

</v:group>      

<v:oval ... />           <!-- oval rotated 90 degrees -->

</v:group>                 

PGML logic:

<p:group concat="0 1 -1 0 0 0"> 

<p:group concat="0 1 -1 0 0 0">   

<p:rectangle .../>  <!-- rectangle rotated 180 degrees -->

</p:group>                 

<p:ellipse ... />     <!-- ellipse rotated 90 degrees -->

</p:group>            

(Note: the concat="0 -1 -1 0 0 0" tells PGML to apply a 2x3 transformation matrix to the graphics, which in this case is a 90-degree rotation transformation.)

Applications needing either VML or PGML must identify links to external objects even though they may occur in extensions. The specifications adopted for identifying such links within XML will be used by VML. In addition, both will depend on a namespace mechanism to identify unknown XML tags and to reliably and safely add new XML tags.

PGML/VML Comparison Chart

PGML and VML and DOM

One of the advantages of vector graphics formats such as PGML and VML is that they provide new ways of combining scripting with the Document Object Model (DOM) API or the SAX API to control a Web page's graphical elements.

For a small PGML or VML graphic embedded in a larger document, the DOM is ideal. It provides an easy, standard way for a script writer to manipulate the graphic (by rotating it, say, 90 degrees), or allowing the ability to tweak a presentation without requiring the use of special software tools.

When dealing with larger files, however, the DOM might not always be the best choice for processing PGML or VML, or in accessing their potentially resource-intensive media types.

"Since building a DOM could have potentially terrifying resource requirements, a computer would need gigabytes of RAM just to represent all of the XML markup," explains David Megginson, creator of SAX, member of the XML working group, and author of the recently-published Structuring XML Documents.

"For these reasons it is far more likely that XML applications such as PGML will be developing their own specialized APIs and interfaces for processing the potentially demanding needs of their media-based formats," Megginson says proudly. "Just another great advantage of using XML."

Indeed, if PGML created and maintained DOM data structures for every point on every curve, it would use lots of memory. For this reason, PGML and VML processors will need to be implemented with DOM-related memory saving techniques. Sources at Adobe insist that this kind of memory savings (i.e., points on paths) will come very easily.

What conclusions can be drawn at this point?

It is highly unlikely that an XML-based vector graphics language is about to replace GIFs on the Web in the near future. Even after a standard is developed, a hybrid approach may still prove useful.

Whether PGML and/or VML rendering will utilize a plug-in or an embedded, "built-in" browser component is too early to predict. Nevertheless, one can be sure that one or the other will be required in order for the XML parser to process the markup correctly.

Adobe wants PGML to be viewed as more of a future-oriented submission, attempting to define a great standard for both rendering and printing in next year's browsers.

VML is more of a present-oriented submission, attempting to define a great standard built around the graphics capabilities built into this year's releases of Office and IE for the vast market of users who wish to publish Web pages directly from Microsoft Office.

Both camps praise the other's formats for presentation capabilities, but insist that their own syntax is superior for authoring and editing requirements.

The important thing to remember for both PGML and VML is that they are experiments that companies have contributed as starting points for discussion. By the end of the W3C process, not only will there be a single XML-based vector graphics format, but all the companies will be moving toward it.