VML (Vector Markup Language) is a markup language based on existing HTML capabilities which allows vector graphical information to be integrated with the text and other data typically found in HTML pages. This document compares VML against the requirements given in W3C Scalable Graphics Requirements published by the W3C.
This is a discussion document which presents the views of the authors of VML. It should be evaluated within the context of the full VML submission.
The document uses the text of the scalable graphics requirement document as a basis for discussion, headings match those in the original content, text is quoted verbatim.
VML is offered for adoption as a W3C recommendation - the final form would be subject to the relevant review process within W3C.
The specification itself is readily available. The specification is intended to be complete and dependent only on existing public specifications, such as the CSS-P definitions in Cascading Style Sheets, Level 2, and precise mathematical definitions, such as the definition of cubic Bézier curves.
VML precisely defines the behavior of a user agent in the presence of unrecognized extensions. The extensibility built in to the current proposal for Namespaces in XML is further specified to allow any user agent to maintain the internal consistency and correctness of the markup. VML defines mechanisms to support older user agents which have no VML support - the user agents will automatically render (optional) bitmap representations of the graphical data.
It is Microsoft's intent to support VML in personal productivity applications. A complete implementation of a rendering tool (which can display the underlying graphical data but not parse the lexical form) is already available in Microsoft Office 97. The underlying graphical techniques used in VML are widely supported in operating system interfaces (Win32 GDI, Macintosh QuickDraw) and in existing printer languages (PostScript, PCL.)
Reference implementations of user agents and authoring tools will be available (as above.) Microsoft will provide a VML reference implementation that is based on transformations and path definitions which are routinely supported in operating system interfaces.
The ability to create a subset of VML is a key feature of the specification. The specification defines how an authoring agent and a viewing (user) agent must respond to VML which is not in the subset which they implement. This allows an authoring agent or a special purpose viewing agent to implement only the subset required to meet its own requirements while a general purpose viewing agent must implement the complete proposal.
Closed and open paths specified as sequences of straight lines and cubic Bézier curves may be filled and stroked (drawn with a pen of arbitrary size and fixed - circular - geometry.) This matches the capabilities found in most modern operating systems and printer driver languages.
Cubic Bézier curves are the fundamental curved representation used. Extensions to the path definition allow specification of circular arcs (these may be reduced to cubic Bézier curves by standard techniques.)
Text is represented within VML in exactly the same way as the representation within the containing HTML or XML, thus ISO 10646 is fully supported. VML uses the facilities of Cascading Style Sheets, level 1 and Cascading Style Sheets, Level 2 wherever reasonable and so the font specification mechanism is taken from Cascading Style Sheets, level 1.
VML follows Cascading Style Sheets, level 1 in using sRGB as the definition of RGB values which occur in VML - see IEC 61966-2. Cascading Style Sheets, level 1 defines the lexical form for the representation of colors. VML defines a representation for indexed colors in those cases where they are required (specifically in the case of an external indexed color bitmap where one palette entry is to be regarded as transparent.) VML defines the order of transformations applied to a color value to ensure that output gamma correction does not change the interpretation of color adjustments. (The final VML specification will contain reference source code to ensure that implementations are consistent and can be accomplished easily.)
VML requires user agents to support PNG bitmaps, which fully support both transparency and alpha without degradation of image quality.
VML includes support for specification of a chromakey on a legacy bitmap or image. VML allows specification of opacity on fill operations in such a way that efficient implementation is possible on all devices.
VML uses the CSS-P positioning support for z-index defined by the CSS2 Visual rendering model, indeed every aspect of VML layout is based on the CSS model. (VML provides minimal extensions to accommodate rotation of objects, these extensions are specified in such a way that an authoring tool concerned only with layout still has good behavior if it ignores the rotation.)
Stenciling and masking are accommodated by permitting a fill operation to be specified
as a bitmap (which may therefore be clipped to the fill path). It is possible to
extend VML to accommodate clipping of arbitrary drawing by specifying that drawing as the
fill which is to be clipped to the shape path. Compatibility with user agents which
do not support the extension is obtained using an intermediate bitmap (in the
element). User agents which do support the extension need not download the bitmap.
Line termination (end caps), line joins and miter control are expressed in the standard way. VML enhances the traditional end caps with the provision of arrowheads to simplify many diagramming operations.
The hierarchical structure of VML allows a user agent to perform decluttering of a diagram during layout, however this behavior is not specified or required by VML. The fact that VML encodes the structure of a diagram as well as the rendering details allows the data to be treated in an intelligent way which reduces the need for mechanistic level of detail transformations.
Bitmaps are an essential part of VML. Raster and vector data may be intermingled. Raster data may be combined with vector data by clipping the raster to a vector path. Limited transformations (chromakey, gamma, picture and black level adjustments) may be applied to raster data.
VML data is an integral part of the HTML page in which it occurs - VML is intended as a means of combining vector information with textual information. VML elements participate in the CSS2 rendering model, see Visual effects. Thus pan can be implemented by enclosing VML elements and other content in an element with the appropriate overflow property (scroll). Zoom and pan can also be achieved by adjustment of the internal VML coordinate space specification - this selects the area within the content of a group or shape which is mapped to the rectangle specified by CSS2 layout.
VML defines single elements as shapes and allows these to be collected as groups.
Each such element is individually identifiable via an
id attribute (as
defined in The global
structure of an HTML document.) In a conformant (integrated - not plug in) user
agent implementation the elements fully participate in the document object model and
associated event mechanisms.
By identifying the shape - the smallest element which can be independently rendered - VML provides a structure for user interaction. VML also allows sub-elements (such as fill specifications and image data) to be identified. This facilitates interaction with more complex scripting such as that defined by the eXtensible Style Language (XSL).
Layering and the control of layers operates at a higher level than VML - VML shapes and
groups act as elements of the document structure supporting vector information in exactly
the same way as
div acts as an element supporting (primarily) textual
content. VML elements may thus participate in any layering scheme which is
compatible with HTML. In addition CSS2 supports an object property,
which allows selection of the VML elements which are displayed.
VML defines a semantic structure which identifies the smallest self contained element (a shape) and allows it to be associated (in a group) with related elements. VML defines how an application may associate higher level semantic data with each element, in such a way that a VML conformant user agent knows that the data is purely semantic (it does not affect the rendering.) VML defines markup within the shape which exactly defines how the shape should be rendered.
VML does not define user interface behavior - this would be inappropriate as behavior in an application which generates VML will be very different to that in a user agent which just displays it. Because VML is integrated with HTML, standard HTML mechanisms can be used to control viewer behavior.
It is a fundamental requirement of VML that it allow an application to express the relationships between separate top-level VML elements. VML uses this mechanism to share shape definitions across a complete document. VML is designed to maintain complex interrelationships between shapes within a group by application specific extensions (for example, allowing two shapes to be connected by a third, without requiring explicit support from user agents).
VML shape elements support links using the
Because VML elements are simply part of the HTML, they may be enclosed with
tags. This allows the top level elements to be referenced from other media in a
backward compatible way. Within the VML elements, the
allows each sub-element to be referenced, however this will not be compatible with older
Desirable that the metadata be readily extractable by search and indexing engines, also by browsers (on-the-fly HTML generation).
VML is an application of XML. The current namespace proposal, Namespaces in XML, allows embedding of additional metadata within a different XML namespace. Great care has been taken in VML to specify the behavior of an authoring application when it encounters such XML. This ensures that the metadata is handled correctly in both the application which adds it and in a subsequent application which edits the VML.
VML is intended to be printed along with the document of which it is a component. Nevertheless any VML shape element can be independently rendered. VML groups allow composite scaling of the contained elements, but this is achieved without alteration of the contained element, and so any VML shape retains the information which defines its original aspect ratio. Physical size of an individual shape is not defined by VML. Physical size of embedded (raster) graphics is defined by the recommended formats (PNG, JFIF) and so may be used to render the graphic in isolation, if required.
VML is a generic format which can accommodate a wide range of data. Application-specific acquisition information can be added with complete compatibility with conformant implementations.
There should be wide cross-platform support in existing content creation tools which should be able to export the format; preferably, re-import it for additional editing.
VML is designed as a way of embedding vector data in HTML such that existing layout tools can manipulate the data with ease and such that content creation tools can embed content specific information losslessly. The use of CSS for layout ensures minimal support requirements in existing layout tools. Very precise specification of support for layout (CSS) and extension (via XML namespaces) is intended to ensure maximum compatibility between applications which are used to modify the same HTML page.
VML is intended to provide a lingua franca for applications which need to interchange vector data. By structuring VML from the point of view of the layout engine, the authors ensure that the minimal common requirements are met. The basic definition of a shape exactly matches the corresponding operating system and printer language facilities. All applications should be able to render to that form. Any VML-compliant application can perform editing of the VML elements, even if generated by another application.
The extensibility mechanisms allow the much richer requirements of non-layout content creation tools to be expressed. These mechanisms ensure that content creation tools may reliably store data in VML - users do not need to be persuaded to maintain an alternate form of the content. This capability is an essential requirement of VML - that it allows the content to be stored in just one place.
When VML data produced by one application is edited by another, it is necessary to ensure that additional semantic information added by the original application is maintained in a consistent fashion. VML meets this requirement by defining exactly how the second application must handle the unrecognized data and by allowing the first application to tag data appropriately to cause the correct editing behavior.
Additional tools for metadata and link editing are desirable
The VML format is designed to be compatible with existing search engine technology -
text is encoded using standard HTML forms. Care has been taken to ensure that the
link information is useable by site management tools. In addition the VML definition
ensures that those intra-document links which would appear broken, because they refer to
attributes the tools do not recognize, are not seen by such tools, while those which refer
to external objects associated with the document can easily be recognized. (This is
a serious compatibility issue which is not completely solved - the HTML+VML must be
compatible with existing user agents, yet it contains external links to raster data which
should be visible to site management tools. The VML authors have used standard HTML
attributes to represent these links to ensure minimal support requirements in site
It is intended that VML track the work described in XML Linking Language (XLink) and related documents to ensure that these issues are solved in the future (the backward compatibility issue will, however, remain for some time).
Desirable that the graphic can be displayed as it is streamed in from the network. Internal directories and offsets are thus undesirable.
VML supports links between shapes. However the specification mandates that the
element, used to provide a definition of a shape used in several places in the same
document, must appear before its first use. The format thus streams as well as HTML
Because the layout code is the likely bottleneck in display of a partially received
page, VML does not permit the size of an element to be implied by its content. Thus
the major problem with the
IMG tag is avoided, i.e. that, if not specified on
the tag, the image height and width can only be discovered by reading the referenced
Additional issues are raised by the need to be able to incorporate vector information in HTML pages. Some of these are mentioned below.
In many cases, the screen rendition of vector data intended for printing suffers from serious aliasing problems because of the screen pixel size. This can be avoided by anti-aliased line drawing. It is anticipated that high quality VML renderers will use anti-aliased display on screen. However VML allows user agents and authoring tools to choose the most appropriate rendering technique (for example trading quality for speed).
To ensure that anti-aliasing can be implemented without unexpected changes in the on-screen appearance, VML does not define precise pixelization rules (unlike, for example, the X Window System). At the same time, the mathematical foundations of the path model adopted by VML are sufficient to guarantee pixelization on any device where errors of one pixel or less are not noticeable - for example, any printer.
VML does not require implementation of a rasterizer. Existing operating system facilities as found in the Win32 GDI or Macintosh QuickDraw can be used. This has a particular benefit with regard to printing - vector information can be sent to the printer rather than a pre-rendered bitmap.
To achieve this aim it is necessary to restrict the facilities available within VML - for example arbitrary opacity need not be supported by a user agent (only 50% opacity need be supported). Experience has shown that it is possible to implement this with moderate efficiency on all printers.
In addition the specification does not mandate any algorithm for the scaling of raster graphics. This allows applications to trade off speed of rendering against quality.
VML does not contain any specification of animation behavior - however it has been designed to allow animation by a script-based mechanism. To achieve this it defines vector attributes where appropriate - these contain an (x,y) pair instead of specifying two separate attributes, one for x, one for y. This allows a script-based approach to atomically update such parameters.
VML uses the shape as the basic element of interaction. However it defines additional elements which may be mapped into a corresponding shape but which have a more convenient form for hand-authoring. These forms have the additional advantage of offering relatively compact representations of the most commonly found shapes - the rectangle and the circle.
A further advantage of the predefined shapes is that user agents can optimize the rendering of these elements very easily - experience in Microsoft Office 97 showed that rendering of rectangles was a significant performance bottleneck when a completely general representation was used.
VML uses a stateless model of graphic rendering. Every shape holds a complete
definition of the information necessary to achieve the visual effects. The group
and shape layout (as described in Visual
rendering model details in CSS2) can be done without access to the rendering
attributes of a shape. This has the important consequence for hand-authoring that
shapes can be moved within the document and between documents very easily - with the
shapetype it is not necessary to identify associated data
elsewhere on the page and copy that to the new document.
VML takes particular care to ensure that the path representation is compact. This allows a representation to be used which can be hand-edited while ensuring that most paths for "simple" shapes require fewer than 256 characters. VML follows a general philosophy of giving the commonly encountered attributes of a shape short names, but using longer, more explanatory, names for less frequently encountered attributes.
shapetype element supports reuse of shape definitions. This
leads to very efficient representations of complex diagrams where repeated elements need
only be specified once, even though size, location and other stylistic attributes such as
color may change between elements. It also enables the generation of shape
libraries which may be reused in many documents.
The path definition allows for precise parameterization of paths. This means, for example, that a shape such as a rounded corner rectangle may be specified just once, even though instances of that shape have corners of different radii.
The parameterization extends to mechanisms to transform paths - for example, a shadow may be specified as a transformation of the shape path and a color.