Applicability of CGM versus SVG for technical graphics

Revision Date:
15 April 2004
Previous Major Version:
Updates information in Previous Major Version;
Clarifies information in Previous Major Version.


Lofton Henderson
Lofton Henderson Consulting


Lofton Henderson is an independent contractor with long experience in computer graphics, and especially in Web graphics technologies - WebCGM and SVG. He co-authored the "The CGM Handbook", Henderson and Mumford, Academic Press, 1993, 450 pp. He has long experience on the ANSI and ISO graphics standards committees, and has had a role with several industry consortia defining CGM profiles: ATA, PIP, J2008, and RIF. Currently, he is co-chair of W3C's QA Working Group, Program Director and past chair of the CGM Open Consortium, a member of W3C's SVG Working Group, and a member of two OASIS technical committees, Conformance, and XSLT conformance.

Dieter Weidenbrueck
ITEDO Software



Dieter Weidenbrueck is the founder and President of ITEDO Software, the manufacturer of the Technical Illustration package IsoDraw and of IsoView, the viewer for intelligent graphics. He is the primary architect of the IsoDraw software program. Dieter Weidenbrueck has developed a considerable experience in the field of documentation standards and is actively participating in standardization efforts concerning technical illustration. He is one of the authors of the WebCGM Recommendation. He serves as the current Chairman of the CGM Open Consortium.



As certain traditional technical and engineering applications become established on the Web, they bring with them information resources that mix text and data with significant technical graphics components. Technical graphics for such applications as aircraft maintenance manuals are characterized by high volume and complexity, stringent fidelity and interoperability constraints, and long life cycle. W3C has two standards for Web based graphics, WebCGM and SVG. WebCGM was specifically standardized for technical applications. SVG has much broader applicability. In a nutshell, the usual formula is "WebCGM for Web-based technical graphics, SVG for graphic arts and creative graphics." Still, the questions continue to arise. why there are two formats, and isn't it possible to use the one for the other application? When one takes a careful and detailed look at the two formats, in the context of the particular requirements of technical illustration, then specific differences emerge. This session will present such a comparison, from both the theoretical, functional perspective, as well a practical real-world (implemenations and interoperability) perspective. The comparison is based on an ongoing study that has been conducted within the CGM Open consortium and the Graphics Working Group of the Air Transport Association.


Table of Contents


Introduction, Overview, & Requirements
Technical graphics requirements
CGM and WebCGM target scenarios
SVG target scenarios
The positioning of WebCGM and SVG
Specific comparative technical details
Topics to cover
Dynamic functionality -- navigation, structure, and animation
Static graphics -- drawing
Object linking
From the outside (e.g. HTML) to a graphic object
From a graphic object to the outside (e.g. HTML)
From one graphic object to another
Object behaviors
Out-of-line links
Link titles
Document Object Model (DOM)
Event model
Non-scaling linewidth modes
Engineering line types
Linestyle definition
File Size
Embedded raster images
Specific interoperability considerations
Topics to cover
Resource limits and specific requirements
Extensions, optionality, implementation dependencies
Predictability of text model
Styling and altering of author's intent
Language flavors & strict profiles
Implementation of object linking
Viewer software availability & completeness
Generator software availability & completeness
Test suites & validators
Maturity & stability

WebCGM is a Web graphical format that is specifically designed to the requirements of technical graphics. The SVG graphical format is generating lots of interest, compelling demos, and questions. In particular, the question has come up, "Why not SVG for technical graphics?" So far, there has been a lot of buzz but not much hard data or objective assessment.

This paper is a look at the requirements of technical graphics that have come from some technical application communities -- especially aerospace, transportation, and defense -- and how the two formats measure up, from both technical and interoperability perspectives.

The authors confess a bias towards WebCGM as currently "the right tool for the job." But we have tried to be objective and measure the two formats against objective requirements and criteria.

Caveat. Some of the information in here, particularly regarding implementations and interoperability, is volatile and subject to rapid change. For example, in the time between the previous draft of this paper and the present version, the number of SVG plug-ins implementation has increased from two to four, and a WebCGM interoperability and product directory has been established.

Future versions and expansions of this study are expected. Please consult the bibliography section at [WebCGM bibliography pages] of the CGM Open Web site [CGM Open].

A word about specification versions. When we refer to WebCGM, we are referring to WebCGM 1.0 Second Release [WebCGM] (December 2001). When we refer to SVG, we are referring to SVG 1.1 [SVG 1.1] (January 2003). This is the same as SVG 1.0 (September 2001), except that errata have been applied, and it has been modularized, to support the specification of the SVG Mobile Profiles [SVG Mobile] (January 2003), Tiny and Basic. Alternately, we might sometimes refer to explicitly to [SVG 1.2]. Presently at the stage of Working Draft in W3C, new versions are being published every 1-2 months, and it is expected to stabilize (Candidate Recommendation) in late 2004 or early 2005. The in-progress SVG 1.2 contains a few new features relevant to technical graphics.

In this section we will address the following topics:

  1. Technical graphics requirements
  2. CGM and WebCGM target scenarios
  3. SVG target scenarios
  4. The positioning of WebCGM and SVG

Technical graphics requirements

Important note: The conclusions of this study depend critically on their evaluation within the context of the following requirements. The authors are fully aware that there are other use cases outside of technical graphics with different requirements, which may lead to different conclusions. The authors are also aware that missing functionality or features very often can be achieved by using scripts in SVG, however, scripting in files has proven to be a nightmare for the maintenance of huge technical graphics archives.

As we are going to measure the useability of the formats for technical graphics it is helpful to describe the main requirements first. These requirements are based on the authors' experiences in this field and do not claim to be complete. However, they are representative for a variety of industries.

W3C Requirements - The World Wide Web Consortium published a note [W3C Scalable Graphics Requirements] in 1996 detailing the requirements for scalable vector graphics used on web pages. A couple of years later two Recommendations have been released, one for WebCGM and the other one for SVG.

Graphical primitives - Technical graphics require a wide range of graphical primitives. Most of these graphics have to live for years and decades and will be revised numerous times. Thus it makes a huge difference in editing whether a circle is a circle with a radius or diameter, or just a Bezier spline or polyline.

Geometrical complexity - Technical graphics can become very complex depending on the content. The number of graphical primitives may easily exceed a couple of ten thousands. The dimensions of a drawing may be challenging as well. One of the authors recently had to deal with wiring diagrams that were over 60 inches long. At the same time there are stringent requirements for accuracy and precision.

Graphical requirements - Most technical graphics can be categorized as containing complex geometry with modest graphical requirements. A significant percentage of technical illustrations and schematics is done as black and white lineart drawings. The focus is on conveying the technical message, not on producing a nice looking image.

Precision - Technical graphics show a lot of details, thus they need to be accurate and precise. It is a usual routine to zoom far into the graphics to see the detail of interest. Precision is equally important for printing.

Text requirements - It is not exaggerated to say that probably more than 90 percent of all technical graphics use Helvetica or one of its variants as their font. This indicates that the typographical requirements are typically low, however, support for text in all languages and encodings is strongly required. A second requirement is that it must be possible to constrain text to certain areas to ensure proper data exchange with other programs. For example, a text element between two lines on a wiring diagram must not move or change its size, it needs to be restricted to a certain bounding box.

Metadata requirements - The requirements for metadata inside technical graphics files are modest but very specific. Due to the fact that these graphics appear in huge quantities (did you know that approximately 70,000 illustrations are needed to document a Boeing 747 (Source: The Boeing Company)?) nobody wants to store more metadata inside the graphic files than absolutely necessary. Typically a simple ID and a hotspot region are associated with a group of primitives, the rest is done in SGML/XML companion files or databases.

Reliability - Wherever and whenever a technical illustration or schematic drawing is used by a mechanic or engineer it is essential that he can look at the authentic information in a reliable way. Time, money, and even security issues are at stake if the information is incorrect or not understandable. Therefore it is hardly imagineable that a user himself will get control over the styling, i.e. the outer appearance of the illustration. Styling may be applied by an application under the control of the illustration's author though.

Reusability and longevity - Most technical graphics live for a long time. Ten years are normal for parts catalog illustrations, very often 20 or 30 years. Think of a Boeing 747 that has been developed and illustrated in the late 60s and early 70s. The illustrations are still in use and being modified every day. If an illustration can not be reused the work is lost.

Interoperability - Probably the biggest requirement for technical graphics is their interoperability. This means it must be possible to exchange data back and forth between different programs from different vendors without losses or changes. If graphics in the defense or aerospace industry need to be maintained for 25 years or longer, it is inevitable that a whole range of products is going to work on them. The lack of interoperability leads to significant additional cost and even to total loss of data.


CGM and WebCGM target scenarios

The base standard for CGM is ISO/IEC 8632:1999. This standard was first published in 1987 based on work done in more than a decade before. As a consequence, CGM is a mature and well established standard that has gone through several iterations and improvements. In fact, the functionality of CGM:1999 (especially version 3 and version 4) is aimed exactly at the requirements from technical documents.

For certain industries, specific profiles of CGM have been issued to match the requirements in great detail. The most prominent of these profiles is the ATA GREXCHANGE profile [ATA GREXCHANGE]. It is aimed at the requirements in the air transport industry. Other industries reference the ATA profile for their needs, like the automotive, the telecommunications, and the defense industries [CALS Profile]. WebCGM is aimed at these requirements for general technical graphics on the Web.

It's worth spending a couple of lines on the history of CGM and its profiles, because we can see quite some similarities to the current situation. CGM started as a strong and rich standard supported widely by the software industry. Actually, today exist more than 250 software products on the market supporting CGM. However, one of the challenges of a rich standard is that software products rarely do a full implementation, and this is what happened to CGM. When CGM was published, there was a lot of hype, and lots of products implemented support for version 1. Unfortunately many dropped the ball thereafter. The biggest sins were:

In practice, the incomplete implementations led to huge interoperability problems for users, because the implemented subsets did not necessarily overlap completely. More than that, products tried to push the extremes, like using huge raster images in one chunk or similar. Then there were lots of details where implementations did not meet the standard.

Very popular was also the technique to hide private application-related data inside APPDATA or APPLICATION STRUCTURE elements. But the real problem was the attempt to extend CGM by creating private graphical primitives (GDP, General Drawing Primitives, and Escape elements) that nobody else understood.

The richness of the standard and some "looseness" was recognized and fixed by introducing the concept of strict profiles. A profile defines rules for each aspect of using a CGM from limiting the size of pixels in a raster portion to the exclusion of unwanted elements, from allowed fonts to semantics of application structures. These profiles led to greatly improved interoperability, and also to testability of software implementations and files.

The most recent profile is WebCGM. It comprises the experiences made with profiles, real-world software implementations, and new interactive techniques. The result is a profile that explicitely prohibits any and all private data in a WebCGM. It forces both vendors and users to stay with a rich but strictly limited set of functionality and features to achieve the common goal: interoperability. It is important to notice that the work around WebCGM is heavily influenced by CGM users, especially from the aerospace and defense industries. The clear goal is to maintain the value of the technical data, not to show the greatest and the latest in graphics techniques.


SVG target scenarios

SVG came into life as the result of the efforts of the W3C SVG Working Group. Various vendors had submitted notes proposing vector graphics formats, among those were Adobe with PGML and Microsoft with VML. All this input was used to define an XML-based standard vector graphics format.

The clear focus of SVG has always been the world of high-quality web graphics with lots of graphical effects and animation. So it was not only the improvement to use vectors instead of pixels to display a graphic, it was rather an attempt to achieve print-like quality on web pages. A lot of attention has been paid to color, colour models, typographical effects, filter effects on raster, transparency, and other features influencing the graphic arts quality.

SVG is a rapidly evolving and moving standard. Within a short period of time several variants and version have been developed, and more is to come shortly. It is amazing to see the functionality and richness of this standard. A closer look at SVG also shows that there is a clear relationship to PostScript and even PDF. This ensures that a proven rendering model is used, and also the printing quality.

So far, there has been little focus on re-authoring and re-use of SVG files. SVG files are created, used, and deleted. In today's world an illustrator would almost always retain a copy of the illustration in a proprietary format for further editing. The authors are aware of the fact that some products perform a native editing in SVG, however, the bulk is converted from other formats. Unfortunately, there are applications that convert high-level primitives like circles or similar into Bezier paths. There are products on the market that seem to include a copy of the entire content in their proprietary format inside the SVG.

While the SVG working group has done a good job of cataloging the capabilities of the principal implementations (see references), it is apparent from the SVG specification that strict conformance and interoperability requirements are lacking. So far the SVG working group has focussed mostly on designing features and functionality. The future will show whether users will demand more interoperability and reliability when exchanging data.

The authors of this papers are both impressed by the capabilities of SVG for creative graphics.


The positioning of WebCGM and SVG

To help everybody understand the differences between WebCGM and SVG, several presentations have been given at past XML Conferences. The following paragraphs represent the bottom line of the comparison as presented by Chris Lilley, Graphics Activity Lead of W3C, and the authors [WebCGM and SVG].

SVG is suitable for high quality, creative graphics with strong requirements for color, text and font features, animation, and filter effects on raster portions.

WebCGM is suitable for technical graphics with long life cycles with strong or stringent requirements for complex and large (file size) illustrations, re-authoring capabilities, interoperability (lots of data exchange), and compliance with industry standards like ATA or CALS.

This is also expressed in the official W3C positioning available at [W3C Graphics Activity Statement]:

It became apparent that there were two different markets for vector graphics.

In one, technical documentation for industry, there was no desire for restylable graphics or for graduated fills, but precise specification of line and hatch styles and use of Computer Graphics Metafile (CGM) was an important requirement. This market had already standardized on CGM, but lacked a vendor-neutral and interoperable hyperlinking mechanism. To satisfy the needs of this market, which covers the aerospace, defense, automotive and electronics industries, the WebCGM profile was developed in collaboration with CGM Open. CGM is an ISO standard for vector graphics. The WebCGM profile adds additional constraints to improve interoperability, defines how hyperlinking works, and defines mechanisms for use in HTML.

The other market, graphic design for advertising, clip art, business presentations and general Web use, needs complex fills, restyling, image clipping and manipulation, and re-usable components. For this market, use of CGM was regarded as less important than good integration with XML and other W3C specifications.

W3C therefore developed a new standard format for vector graphics, Scalable Vector Graphics (SVG), written in XML and usable as an XML namespace, that matches the needs of content providers and browser vendors alike. It is designed to be stylable, and to work well across platforms, output resolutions, color spaces, and a range of available bandwidths.

The expectation is that both formats will coexist and complement each other

 Specific comparative technical details

Topics to cover


Dynamic functionality -- navigation, structure, and animation

Much of the requirements work for technical graphics has focused on the static graphics functionality. However, in a Web environment even traditional "static" technical illustration uses the dynamic functionality of hyperlinking, graphic-to-graphic, graphic-to-text, and text-to-graphic. The other major category of dynamic functionality concerns animation, which is starting to generate some interest for training and other applications.

The following table Table 1 provides an index and summary assessment of several key dynamic functionality areas that are relevant to technical graphics, where there are differences between WebCGM and SVG. Each topic is linked to a more detailed discussion, in the subsections that follow.

Functionality WebCGM Assessment SVG Assessment
Table 1
Object linking links to one or several objects supported using ID or name simple links to one object supported
Object behaviors explicit support for navigation to single or multiple object(s) and highlighting limited support for highlighting and navigation
Out-of-line Links possible but not fully standardized yet possible using event handlers
Multi-links explicitly, directly supported via xlink extended links in 1.2
Link titles explicitly, directly supported supported directly in 1.2
Screentip explicitly, directly supported supported directly in 1.2
Document Object Model (DOM) draft IDL definition exists now, for a very limited DOM full XML DOM plus SVG extensions
Animation none full-functioned declarative & DOM animation
Event model proposed improvements for out-of-line linking, object selection, etc full-functioned event model (based on DOM2 and HTML events)

Note. Green-shaded items indicate changes since May 2003.

Static graphics -- drawing

The following table Table 2 provides an index and summary assessment of several key static graphics functionality areas that are relevant to technical graphics, where there are differences between WebCGM and SVG. Each topic is linked to a more detailed discussion, in the subsections that follow.

NOTE: There are, of course, many other static graphics functional differences. These are a handful that focus on features or requirements in the technical graphics arena, and where there are WebCGM-SVG differences.
Functionality WebCGM Assessment SVG Assessment
Table 2
Non-scaling linewidth modes yes special case of 1.2 Vector Effects
Engineering line types yes limited
Linestyle definition specific inking, offset controls for tech drawing offset control,but no vertex inking or adaptive controls
NURBS no (but see detailed comments) no
File Size compact binary compactable text
Embedded raster images raster stored in CGM file, efficient compression methods raster in external file, or compressed file embedded via data: URL scheme
Styling none (but limited CSS-like under discussion) full CSS & XSL support
Encoding binary (but XML is discussed) text (but binary is discussed)

Note. Green-shaded items indicate changes since May 2003.


Object linking

The term "object linking" refers to links that use an object inside a graphics file as the source or the destination for a link. We distinguish between three different types of links:

The second question is what behavior can be triggered by executing a link. This is called Object behaviors.


From the outside (e.g. HTML) to a graphic object

Both formats allow for links to objects inside the graphics file. These could be used when placing an <a>-Tag on a text string of an HTML page.

Example for WebCGM:

Example for SVG:

These links both point to an object inside the respective graphics file with the ID "myID5". In the WebCGM case, the default behavior is to highlight the object. The behavior on the SVG side is undefined unless the target is a <view> element.

WebCGM can link to objects in a variety of ways:

The name attributes in WebCGM may contain spaces and other special characters.

SVG can link to

SVG fragments must not contain any spaces (see [SVG Fragment Identifiers] ).

NOTE: For obvious reasons, the usage of object linking depends heavily on the support by the viewers. This support has not been fully implemented yet in the one mature SVG plug-in that the authors have examined (refer to Implementation of object linking ).

From a graphic object to the outside (e.g. HTML)

Both formats allow for links from objects inside the graphics file to the outside.


This link points to a paragraph on an HTML page. Both WebCGM and SVG support this type of link.


From one graphic object to another

These links both point to an object inside the the same or another graphics file:

Example for WebCGM:
#myID5 object resides in the same file object resides in a different file

Example for SVG:
  #myID5 object resides in the same file object resides in a different file

This is comparable to the first link type. Objects can be addressed in several ways in CGM and by their ID in SVG. The same limitations for SVG linking apply here.

NOTE: For obvious reasons, the usage of object linking depends heavily on the support by the viewers. Support for linking between objects in different files has not been fully implemented yet in the one mature SVG plug-in that the authors have examined (refer to Implementation of object linking ).

Object behaviors

If a link is executed the usual expectation is that the browser/viewer navigates to the target of the link and displays it. In technical graphics, this is a required functionality. Additionally, the highlighting of the object is required. Both the navigation and the highlighting are used to quickly find the point of interest on a complex illustration, for example a specific component on a wiring diagram.

WebCGM supports the following object behaviors (see [WebCGM Adressing Pictures and Objects] ):

Thus WebCGM is capable of zooming to an object or highlighting it. Future versions of WebCGM are expected to also allow for combinations of these behaviors, e.g. zoom to an object and highlight it.

SVG can navigate to a view element only (see [SVG View Element] ). This is comparable to an explicitely specified view_context in WebCGM.

If the target of an SVG object link is not a view but an element, the navigation is restricted to the view parameters of the next higher svg element:

If the SVG fragment identifier addresses any element other than a 'view' element, then the document defined by the closest ancestor 'svg' element is displayed in the viewport using the view specification attributes on that 'svg' element (see [SVG Fragment Identifiers] ).

It does not appear to the authors that it is easily possible to zoom in on a particular object in SVG unless a view element has been specified. This is a caveat for technical graphics, because it is impractical to specify explicit views for each element of interest given the quantity of objects. It is certainly possible to handle navigation using a fragment like #svgview(200,0,400,100). However, this requires knowledge about the coordinates of the target outside of the SVG file. Using coordinates outside of the SVG file then leads to additional maintenance as soon as the illustration changes. This is comparable to the problems that companies ran into when using SGML overlays with hotspot coordinates. The authors believe that SVG should be enhanced to support navigation to an element identified by its ID.

The second important behavior is highlighting. It is not easy to spot the target of a link on a complex illustration. Look at a wiring diagram and try to locate a specific component quickly. Even if you zoomed into a closer area around the object you will still see quite a number of objects. To help the user to find the object of interest as quickly as possible, highlighting is a stringent requirement in technical graphics.

SVG offers highlighting using the viewTarget element, however, so far this is not supported by the one mature plug-in that the authors have tested (other plug-ins have not been tested yet).

SVG does not offer a way to address multiple objects in one link. Think of a link that should highlight all five wheel nuts of a car's wheel at once. WebCGM uses a non-unique name on each nut in addition to the unique ID. Thus it becomes possible to address all objects that have the same name. The <g> element can not be used for this purpose because it requires that the objects all be consecutive in the file. This is not always possible due to constraints of display order.


Out-of-line links

In technical graphics exists a requirement to store links outside of the graphics file to be able to manage all links without having to open the graphics file itself. These links are called out-of-line links. The basic principle is that a mouse-click on an object of the illustration is reported to the outside of the viewer by means of an event. An event listener may then look up the link on the outside and execute it.

To accomplish this, an object needs to be clickable, and the viewer needs to know how to report the event to the outside.

In WebCGM, this has not been standardized completely, though the functionality is supported by all viewers in some way. In this scenario, an object may be clickable even if no explicit link is attached to it. The viewer generates one event for any and all object clicks on the illustration. Only one event handler is needed to handle all events related to mouse events. This event will be standardized as a part of the WebCGM Event Model.

In SVG, an object is clickable only if a link is attached to it. This is comparable to text on an HTML page that becomes clickable only if a link has been specified for it. A click on such an object results in a visual feedback to the user, for example a temporary highlighting, and the navigation to the target of the link.

An alternative is to add an event listener for mouse-clicks. This requires to perform the following steps from within a JavaScript or similar:

The event handler might look like this:

function myClick(evt)
var elem =;
var myID;
if( elem.hasAttribute("id") )
myID = elem.getAttribute("id");
... (do whatever you want to do with myID)

The event handler for WebCGM will be a bit simpler, because events will occur for objects only that have an ID.

The challenge is the visual feedback to the user though. It is difficult to achieve the same effect that is used if a click occurs on an object that has a link attached to it. Simply changing a color or stroke-width is not sufficient, one would have to remember all relevant graphical attributes to be able to restore the previous condition. The authors believe it would be benefitial to enhance SVG in one of the following ways:

There may be other solutions to this problem.

The authors see major challenges with regard to object navigation if SVG is used for technical graphics. WebCGM offers a simple URL fragment syntax to handle most aspects of object navigation and highlighting directly. SVG requires complex scripting to achieve at least a part of this functionality.



WebCGM directly supports the ability to add more than one link to any particular object. The semantics of activating a multi-link are well defined -- a choice mechanism, utilizing additional link description metadata.

SVG 1.1 does not have multi-link functionality. It could perhaps be imitated somehow with a nesting of groups, but obvious SVG semantics for nested 'a' tags are very different than the required functionality -- the choice mechanism would be difficult or impossible to support in any simple manner.

Explicit multi-link capability has been approved for addition to SVG 1.2 (currently at stage of Working Draft), by application of the Xlink extended link capability.


Link titles

WebCGM has 'linktitle' as a piece of metadata associated with the 'linkuri' APS attribute. The principal purpose is to provide descriptive metadata in support of multi-links.

SVG 1.1 allows the 'title' element within an 'a' element, which could perhaps be used for the purpose of providing descriptive metadata for a single link. SVG does not unambiguously define the semantics or require any particular viewer behavior (or for that matter, require that the viewer do anything): "User agents may, however, for example, display the 'title' element as a tooltip...".

Explicit link title support has been approved for addition to SVG 1.2 (currently at stage of Working Draft).


WebCGM explicitly defines the 'screentip' APS attribute. WebCGM content generators can rely on specific behaviors by conforming WebCGM viewers.

SVG defines a 'title' element that can serve the role of a screentip. In SVG, the expected user agent response to a 'title' is suggested, but not required: "User agents may [...] display the 'title' element as a tooltip...". The suggested uses of 'title' are quite flexible, and presentation (e.g., on aural media, for accessibility purposes) can be controlled by CSS stylesheets.

Explicit screentip support has been approved for addition to SVG 1.2 (currently at stage of Working Draft).

Document Object Model (DOM)

WebCGM has no DOM functionality. Several implementors have put proprietary DOMs on their viewers, and a standardized WebCGM DOM of limited functionality is currently under development. The WebCGM DOM is expected to be finalized within 2004.

SVG supports full XML DOM, plus SVG-specific extensions.


WebCGM has no animation capability. Some very limited animation would in principle be possible with the in-development DOM, but it is not yet clear whether positional animation will be supportable in that DOM.

SVG has full-featured DOM as well as declarative animation functionality that is based on a subset of the SMIL language. Animation -- both declarative and DOM -- is one of SVG's most powerful features. If standards-based animation is required, SVG is currently the clear choice.


Event model

The event model of a Web graphics standard has a close relationship to the dynamic functionality of object selection and link activation, which are key requirements of Web technical graphics.

WebCGM has no event model per se. The specific rules of object selection for link activation are defined. The WebCGM DOM will have an event model for mouse events.

SVG supports a fully-functioned event model based on DOM2 and HTML events. With scripting, event handlers of various kinds can be attached to any identifiable graphical object.


Non-scaling linewidth modes

In engineering drawing and technical illustration, graphical attributes such as line width, marker size, etc are not affected by transforms that scale the geometry of a drawing. In a graphic arts drawing model, line width scales as does any other part of the geometry (as if it were a long thin polygon), including calligraphic effects when differential scaling is effect in the x and y directions.

WebCGM has linewidth specification mode (as well as modes for edge width, marker size, etc) that allow choice of scalable versus non-scalable drawing model for line width.

SVG 1.1 does not support the functionality of non-scalable line width.

Support for non-scaling line attributes is achievable by a special case of the vector effects functionality which has been approved for addition to SVG 1.2 (currently at stage of Working Draft).

Engineering line types

Engineering and technical applications have standardized (an ISO standard) a set of commonly used line types, such as phantom line, center line, single-arrow, double-arrow, break-style, etc., including precise specifications for their rendering criteria and tolerances.

WebCGM includes engineering line types as a registered extension to the ISO/IEC CGM:1999 standard. Each of the line types may be exactly selected by its registered index (6-14).

SVG does not support the engineering line types, and it does not appear that it would be trivial to build support using the existing capabilities of SVG 1.0/1.1. (I.e., something like a registered extension that allowed selection of a style from an enumerated list would have to be defined.) It would be possible to provide approximate support for a some of the linetypes using the normal SVG properties (attributes) for line stroking and markers.


Linestyle definition

Technical graphics (and especially engineering drawing) have particular requirements for how vertexes are handled (inked or not, adaptive adjustment of line type or not) for non-solid line types.

WebCGM includes attributes to select different vertex-inking rules and adaptive linetypes.

SVG does not support such engineering-specific linetype handling rules.



Non-uniform rational B-splines (NURBS) are commonly found in engineering and technical design. While Bezier curves are more commonly used in graphics formats, NURBS are allowed in some aviation graphics profiles and there are requests for the functionality in the Web graphics formats.

WebCGM 1.0 (profile of CGM:1999) does not allow inclusion of NURBS, although they are well defined in the ISO/IEC CGM:1999 base standard. I.e., it is a matter of selecting them for inclusion in the profile, rather than having to define complex NURBS requirements and functionality from scratch. NURBS are on the requirements list for WebCGM 2.0 (inclusion is a matter of unchecking the "Prohibited" box in the WebCGM profile pro-forma.)

SVG only supports Bezier curves (like WebCGM 1.0). There is no support for NURBS.


File Size

Given more or less equivalent graphical primitive functionality, a couple of factors affect file size of the graphics: binary versus text format; verbosity of the graphics language; and, whether the attribute models are modal (stream) or object oriented.

WebCGM a binary format and relatively compact to start with.

SVG (.svg) is clear text and can be as much as 8-10 times bigger. SVGZ (zipped SVG, .svgz) is about the same size as WebCGM.


Embedded raster images

Requirements review - A huge legacy of scanned raster images exists that continues to be used for technical illustration purposes. Very often, the content is combined with newly drawn vector graphics during revisions. Given the fact that not a single file but hundreds or thousands of files need to be managed, each one of them carrying possibly several raster portions on it, it becomes mandatory to embed all information belonging to one graphic into a single file. Externally referenced raster files are less practical because they lead to increased management work.

Format considerations - WebCGM supports embedding of raster images in various ways. Version 1 defines the CELL ARRAY element with limited compression capabilities. Version 3 defines the TILE ARRAY element with support for run-length, Group 3, Group 4, PNG, and JPEG compression schemes. Because the image can be tiled the storage of very large images is easily possible.

SVG supports embedding of raster images using the 'image' element (see [SVG Image Element]). There are two options:

Most of the legacy raster files is black and white, 1 pixel deep. Thus it is important that efficient compression schemes are available. It looks like the Group 4 compression used in WebCGM works best, followed by PNG, which is used by both WebCGM and SVG. A Group 4 compressed TIFF of approx. 65 KB stays about the same size when saved to WebCGM using the same compression. If saved using PNG compression the file size will be between 139 and 150 KB (stored as separate PNG file in the SVG case).

In theory, one could use a TIFF file in the SVG environment as well (with only the 35% penalty of base64 encoding), however, product support would likely to be problematic, becaues the SVG Recommendation only requires support for PNG and JPEG files.

If the PNG file is embedded inside the SVG file, it needs to be encoded in a way that only characters allowed in the encoding of the file will be used. This is done by using the base64 encoding. The base64 encoding needs 4 bytes to describe 3 binary bytes, so the overhead for encoding a binary PNG file into base64 is approx. 35% (4/3 ratio plus line end characters). If SVGZ is used, most of this overhead gets eliminated. Example: a 149 KB PNG file in base64 encoding is 204 KB large. If you zip this file it will be about 153 KB.

The SVG working group is discussing the multi-part MIME mechanism for SVG 1.2, which would allow for appending binary files to SVG content in one single file. The details of this still need to be defined, however, this would completely remove the encoding overhead.

There is a potential for problems when applications convert black and white (1 bit) raster images to RGBA (32 bit) images when using SVG. This may happen especially in authoring tools. We recommend that users test this behavior with their tool of choice. It is the opinion of the authors that the SVG specification is ambiguous in its definition of the 'image' element (see [SVG Image Element]):

The result of processing an 'image' is always a four-channel RGBA result. When an 'image' element references a raster image file such as PNG or JPEG files which only has three channels (RGB), then the effect is as if the object were converted into a 4-channel RGBA image with the alpha channel uniformly set to 1. For a single-channel raster image, the effect is as if the object were converted into a 4-channel RGBA image, where the single channel from the referenced object is used to compute the three color channels and the alpha channel is uniformly set to 1."

The usage of the word 'processing' is not completely clear. Processing could mean reading an image tag from an SVG file, rendering an image tag on screen, or saving an image tag into an SVG file. If a black and white image gets converted to RGBA the file size will be significantly higher of course. The authors have observed this conversion happening inside SVG authoring tools but can not state that this is the case for all applications.

The perceived ambiguity combined with the behavior of tested applications led to some controversy about previous versions of this paper. Discussions with SVG Working Group members indicate that this ambiguity hadn't been seen before. The authors recommend revising this verbiage to define the desired behavior in an unambiguous way.

Conclusion - WebCGM offers a straightforward way to embed raster information within a file. SVG can almost do the same, but we recommend to thoroughly test whether your tools do what you expect or have hoped for. Apart from differences in file sizes there may be round-tripping issues if the raster content is converted to RGBA.



WebCGM does not support attribute styling of the CSS and XSL kind. A design project has been completed for a limited "Stylable CGM" capability, in support of the in-development limited WebCGM DOM/API.

SVG is fully integrated with CSS styling, and all applicable CSS features must be supported in any SVG user agent that has CSS2 support (styling is optional, presentation attributes are required.)



The relevance of encoding format -- binary versus human-friendly text -- in technical graphics is debatable. An XML text format allows human editing, and may be fully integrated in-line with other XML languages (e.g., XHTML). On the other hand, typical technical graphics are sufficiently large and complex that hand-coding and hand-editing are out of the question. The need for in-line integration is unclear, and in fact some requirements point to out-of-line integration as preferable. Furthermore, support in products for in-line integration is relatively rare now (especially in principal commercial browser/viewer tools).

WebCGM is a binary encoding. (CGM:1999 has a Clear Text encoding, but you must transform it to binary encoding for conforming WebCGM interchange.) Note that a more verbose XML encoding of WebCGM is under discussion and some prototypes have been offered for consideration.

SVG is a text-encoded XML language. Note that requirements for and inclusion of a binary encoding are under discussion. A gzip-compressed variant is defined (uses extension ".svgz").

 Specific interoperability considerations

Topics to cover

The following table Table 4 provides an index and summary assessment of several aspects of interoperability, where there are differences between WebCGM and SVG. Each topic is linked to a more detailed discussion, in the subsections that follow.

Caveat. Some of this information is potentially volatile, especially the parts that in some cases depend on the capabilities of certain software products. Products change and new releases have different characteristics, completeness, bug fixes, etc. In some cases the authors have also relied on test cases to probe the capabilities of the implementations. We welcome comments, discussion, and corrections.

Some of these implementation aspects are have been incompletely investigated. Such aspects are identified as provisional conclusions, with more work to be done. A careful look at implementations of both standards, in several environments, is warranted. But it is a substantial undertaking, and beyond the scope of this document.

Interoperability topic WebCGM Assessment SVG Assessment
Table 4
Resource limits and specific requirements all aspects constrained & limited few limits or constraints
Extensions, optionality, implementation dependencies none of these are allowed extensions unrestricted, optional features defined, some implementation dependencies allowed.
Predictability of text model completely constrained and predictable Predicability achievable using SVG Fonts, instead of CSS text properties and font selection.
no styling (limited styling in planning) full CSS styling support
Language flavors & strict profiles strict profile loose conformance, flavors developing
Implementation of object linking several correct implementations (unconfirmed) no implementations known (unconfirmed)
Viewer software availability & completeness a few (~5) plugins relatively complete (unconfirmed) four plugins, apparently incomplete (unconfirmed)
Generator software availability & completeness a few specialized high-quality; many generic low-quality some specialized as well as generic, of apparently good quality; many others (unconfirmed)
Test suites & validator comprehensive breadth-first plus some detailed tests; validator available comprehensive breadth-first plus some detailed tests; no validator
Maturity & stability very mature, changes and errata are rare fairly young, numerous errata and clarifications/interpretations; SVG1.2 activity

Note. Green-shaded items indicate changes since May 2003.


Resource limits and specific requirements

WebCGM spells out resource limits and specific requirements on all aspects of the profile, e.g., raster size, required raster formats, required font support, polybezier segment limit, etc. See for example the WebCGM Profile Pro-forma (PPF) at [WebCGM PPF]. For example, a short list of raster formats including JPEG, LZW, and PNG is required, and only those formats are allowed.

SVG places few constraints. Rasters can be arbitrarily large, filled polybeziers can have an unlimited number of segments, there are no constraints on the fonts used, etc. SVG requires PNG and JPEG raster formats, but also allows any other that anyone wants to use.


Extensions, optionality, implementation dependencies

WebCGM prohibits all forms of private extensions, contains no optional features, and allows no implementation dependent results of interpreting the graphical or metadata content. The base standard ISO/IEC CGM:1999 does have private extensions mechanisms, but WebCGM prohibits the use. CGM:1999 does have numerous implementation-dependent semantics, but WebCGM requires a single unambiguous interpretation.

SVG has private extensions mechanisms, allows inclusion of arbitrary foreign-namespace content, and places no constraints on their use. There are optional features, such as ICC color profile support. Graphical results that are dependent on viewer (user agent) capabilities -- i.e., implementation dependencies -- are allowed. Some of these mechanisms are in use by leading generators of SVG content, as can be see in the published current support matrix (see [Adobe SVG Support] ) of one (this is just one example). SVG has capabilities (e.g., 'switch') that can be used to mitigate the negative interoperability effects of private extensions in some (but not all) circumstances and use scenarios, but using them is not required, and they are seldom seen in "extended" SVG content in the field.


Predictability of text model

WebCGM has minimum set of required fonts that must be supported by all conforming viewers. The glyph metrics of these required fonts are published in WebCGM. It does not allow generators to use any other fonts, unless a Font Properties element with information sufficient for font matching is included. It defines stringent fidelity and accuracy requirements for rendering. It requires that only Restricted Text be used -- a boxed text model where the width and height are defined and must be precisely matched. (Note current extent of implementation support of Font Substitution is uncertain.)

SVG text and font properties derive from CSS, and its rules for font matching and text rendering are also CSS based. So for text elements referring to an external named font (the set of which is unrestricted), the results are implementation dependent. SVG has a 'textLength' attribute that constrains the length of the rendered string, but its use is optional (not required). In SVG you can get a guaranteed text rendering result by using the SVG 'font' element to embed the (graphical) definitions of the needed glyphs from the needed fonts into the picture file, and this is the only way to do so.

It appears, using SVG Fonts, that it should be possible to achieve results as predictable as WebCGM's Restricted Text. There is some small size overhead due to embedding glyph definitions in the SVG instance, but it should be minor compared to typical file size. There is some awkwardness for authoring tools because of the lack of vertical text alignment in SVG (there is talk of adding that to SVG 1.2). In summary, the achievable predictability of the two formats should in principle be the same, although WebCGM achieves it very directly and SVG involves more machinery.

Implementation support for the necessary mechanisms should be carefully evaluated.

Note. There has been questions for how predictable the WebCGM text model would be, if text is not ISOLatin1. WebCGM does accommodate Unicode, and does allow for appropriate fonts via the Font Properties element. Implementations are known to exist.

Styling and altering of author's intent

We note a potential problem in technical graphics environments, associated with stylable graphics. Aviation and aerospace users are very stringent that rendering results are consistent and exactly predictable. Stylable graphics, especially external (user and UA default) stylesheets potentially compromise this requirement. We're not sure how to assess the nature of this problem.

WebCGM has no styling -- all graphical aspects are completely, unambiguosly, and unalterably defined. But WebCGM is designing a limited styling solution, for support of the WebCGM DOM. The downside and ways to limit it have not yet been explored or evaluated.

SVG is fully stylable with CSS or XSL. We're unsure how to evaluate this, vis a' vis fidelity and predictability requirements that exist in some technical graphics environments. Suffice it to note, for now, that application of User stylesheets and UA Default stylesheets (for example) is potentially problematic.


Language flavors & strict profiles

Overall, a policy of strict conformance has been mandated by some technical graphics constituencies -- Air Transport Association (ATA), defense, WebCGM, etc. Strict conformance is expressed in a strict profile, which minimally bans: private extensions, optional features, implementation dependent features and results. Anything that can lead to unpredictable or inconsistent results across implementations is prohibited. Strict profiles may further facilitate reproducible and consistent results by placing well-defined limits and constraints on all significant components of the format.

WebCGM is a strict profile of the base standard, CGM:1999. The conformance rules of CGM:1999 we loose in all of the ways that are proscribed for strict conformance, and the conformance rules of WebCGM addressed all of these deficiencies. The ATA profile of CGM is another example of a strict conformance profile. We note, for completeness, that there are private CGM language flavors that preceeded the WebCGM profile, and these can still be problematic. But they are at least easily distinguishable from WebCGM.

SVG 1.1 does not have strict conformance rules itself, and there are no strict profiles presently defined.. The companion SVG Mobile defines two profiles of SVG Full -- Tiny (think cell phones) and Basic (think hand-held computers) -- but these define proper functional subsets, and contain no strictness constraints. In the opinion of the authors, the implementation landscape of SVG is fragmenting into numerous language "flavors", characterized by:

This is similar to what happened with the ISO CGM standard in its early years, before the Rules for Profiles were added and the technical documentation community began making strict profiles. In its February 2004 draft, SVG 1.2 said: profiles for application sectors would be left to organizations in those sectors to write (similar to the CGM approach); and, rules for profiles would not be addressed in SVG 1.2, but possibly in a future 1.x or 2.x.

Implementation of object linking

As noted earlier, some of the most important of the dynamic technical graphics requirements relate to object linking specifications. These relate to:

Also noted was that the SVG specification defines a couple of capabilities that could satisfy some (but not all) of the requirements, and that WebCGM was specifically designed to satisfy all of the requirements. That addresses the specifications. What about the implementations?

WebCGM implementation. There are several WebCGM plug-ins that are alleged to support inter-content-type object linking, picture behaviors, and object behaviors. There are several that allegedly have resolved the "fragment bug". These claims have not been confirmed except in a few cases. The WebCGM interoperability data (including Implementation Conformance Statements, ICS) should answer these questions. The data is available at the WebCGM Product Directory [WebCGM Implementations].

SVG implementation. (Caveat. There was only one SVG plug-in at the time the authors first performed these diagnostic tests, and its version is still current. Now other plug-ins are available, and are not yet tested. These tests should be repeated for all plug-in implementations in the near future.) There are no SVG plug-ins that fully execute the SVG-to-SVG linking functionalities. Two SVG functionalities -- xlink:show and svgView 'target' -- potentially would handle a couple of the picture and object behaviors in the technical graphics requirements. Text-to-SVG links will be impacted by the apparent lack of BHO-like fixes for the fragment bug (in Internet Explorer and pre-7.0 Netscape browsers). SVG-to-text linking (e.g., to an XHTML anchor) have not been tested yet.


Viewer software availability & completeness

For the use scenarios of Web-based technical graphics, the most important sort of viewing (user agent) software is the browser plug-in. Of course there are needs for printers, static stand-alone viewers, etc, but typical multi-content technical manual users rely on Web browsers.

WebCGM. The WebCGM product pages [WebCGM Implementations] list viewer and printer software from CGM speciality companies. A handful of WebCGM plug-ins are known. The plug-ins are all commercially supported, some are freely available for some use, others licensed with purchaseable support. Several plug-ins are alleged to be substantially complete and correct, and one or two have apparently passed the WebCGM test suite, but the hard data to evaluate the claims are not yet available. The products are linked from the viewer-product page at [WebCGM Viewers] to completed Implementation Conformance Statements (ICS).

SVG. There are several known SVG plug-ins. At least one, the Adobe plug-in, is substantially (but not totally) complete -- its feature support matrix (see [Adobe SVG Support] ) documents the limitations. See the viewers product listing at [WebCGM Viewers] on the SVG web site, from which you can follow links to the implementors, and sometimes feature matrixes. There is an interesting view of the completeness of several implementations at the SVG Conformance Suite Implementation Status at [SVG 1.1 Implementations Status Matrix]. Note that the data in the matrix are over 4 months old, an update is pending that will show more progress towards completeness.

Implementations Footnote. There have been many CGM software implementations (someone once counted hundreds). Many came out in the early days of CGM. The majority are incomplete, or incorrect, or privately extended, or some combination thereof. Some implementations now are relatively complete and correct. There are a huge number of SVG implementations (see [SVG Implementations] ). A quick look at the product status matrix (see [SVG 1.1 Implementations Status Matrix] ), which focuses on the most serious contenders, shows considerable disparity in completeness and/or correctness (note -- the matrix shows Full SVG, as well as the Basic profile (small), as well as the Tiny profile (smallest)). It is the authors' opinion that this shared pattern of early CGM and early SVG -- high activity and many implementations of mostly questionable utility -- is a basic pattern in the life cycle of important new standards. It is probably especially likely for those that do not start life with strict conformance requirements.


Generator software availability & completeness

WebCGM. There are a handful of specialized products (especially technical illustration packages) that are good. Many of the generic products (e.g., in CAD and presentation graphics) have CGM exports with quality problems -- incorrect or private extensions. This is problematic for users of such generic illustration software that want to use WebCGM. It necessitates 3rd party filters and converters to get WebCGM from diverse sources. Both the specialty WebCGM generator products, and some of the available filtering software, can be see at the WebCGM product/interoperability pages at [WebCGM Implementations].

SVG. There are many products (see [SVG Implementations] ) capable of writing SVG. Some of the generic graphic arts and illustrator packages have apparently good quality SVG generation (note however some problems with private extensions and language flavors). The authors don't have much data or experience with the quality of the mass of these implementations. See our "Implementations Footnote" comments in the previous section.


Test suites & validators

WebCGM Test Suite (see [WebCGM Test Suite] ): about 230 Basic Effectivity (BE) plus Detailed test cases for Static graphics, and about 25 BE test cases for Dynamic functionality. A comprehensive breadth-first test suite with some detail. There is a WebCGM content validator.

SVG Test Suite (see [SVG 1.1 Test Suite] ): about 125 BE test cases, plus some detailed, spanning the entire standard (static graphics, dynamic/DOM, animation, etc). A comprehensive breadth-first test suite with some detail. There is no SVG content validator.


Maturity & stability

The stability and maturity of a standard is usually reflected directly in the interoperability of implementations. Or more accurately, instability is generally reflected in interoperability problems. For large complex standards such as SVG and CGM, numerous errata and questions of interpretation are typical for some period following publication of the standard.

WebCGM. The WebCGM profile is 4+ years old (in 2nd edition now), and the base CGM standard is another ten years older. The rate of errata reports on the CGM and WebCGM standards has decreased to almost zero. The standard is mature and stable, and ambiguity or misinterpretation of the standard, or conflicting and contradictory specifications, are no longer the major contributors to what interoperability problems still exist.

SVG. SVG 1.1 was published in January 2003, 2+ years after SVG1.0. Numerous 1.0 errata corrections (see [SVG 1.0 Recommendation Errata] ) were folded into 1.1. There are no published errata for 1.1 yet, but interpretation questions still continue at a fair pace on discussion lists. It is not difficult to find even fairly simple SVG files that display very differently in the major viewers. Much of SVG's power derives from leveraging of related XML-family standards such as CSS and DOM. But this also creates complexity. In the authors' view, complexity slows the achievement of stability and complicates interoperability. Since the publication of SVG 1.1, there has been a very large investment of work in SVG1.2. It is adding a very substantial collection of new functionality and new features to SVG 1.1. Completion is planned for late 2004/early 2005.

NOTE: This paper discusses the usage of SVG and WebCGM for technical graphics only, not the formats in general.

The power of SVG is impressive to say the least. However, most of this power is used to achieve the highest graphical quality possible and to script and animate it. SVG graphics are flashy and may event represent entire programs. This is "cool", but it is not a requirement in technical graphics.

There is no doubt that both SVG and WebCGM could store and display most types of technical graphics. It takes a second look to see the pitfalls.

Technical issues. There are significant technical issues that are show stoppers in the world of technical graphics. One example is the embedding of raster content. Any restriction like using a second file or living with huge files sizes is unacceptable in front of the situation that almost every company has a certain portion of its technical graphics in raster format. For practical use, it doesn't matter whether the problems are based on specific SVG deficiencies, or on implementation issues.

Linking and navigation issues. Technical graphics have the requirement for a relatively simple way to link graphical objects to the outside world. One example is a link between a callout number on a spare parts drawing and the corresponding entry in the parts list. However, this simple linking scheme is applied to thousands of objects in a parts catalog. There is no room for hand-coding, individual event handlers or similar. This needs to be automated as much as possible. This is especially important regarding the constant revision work on technical graphics.

Re-usability. As far as the authors are aware, so far SVG has been used on short-living graphics only. Most of the time the SVG was generated from some kind of proprietary source file. Any change was conducted on the source file, and then a new SVG was generated. In the world of technical graphics, any duplication of files leads to huge efforts to keep the archive in synch with the web format. It is mandatory that illustrations can be stored in one format that allows for revisions and web delivery at the same time.

Interoperability issues. Some people think the scope of SVG's interoperability issues is yet to be appreciated, because it hasn't yet been applied seriously in a rigorous, mission-critical technical environment.

WebCGM is tailored at exactly reproducible results across implementations, in all graphical and intelligent aspects. SVG will be problematical to get identical results across implementations.

The authors are convinced that SVG is a format with a great functionality and an even greater potential, and that it should be used for the purpose it has been developed for: creative graphics. When it comes to technical graphics, the authors clearly prefer WebCGM for its stability, maturity, and reliability.


[Adobe SVG Support]
Current Support for SVG at


[CALS Profile]
CALS profile at

[CGM Open]
CGM Open Website at

[CGM Open BHO Project]
CGM Open BHO Project at

[SVG 1.1]
SVG 1.1 (Recommendation) at

[SVG 1.2]
SVG 1.2 (Working Draft) at

[SVG 1.0 Recommendation Errata]
SVG 1.0 Recommendation Errata at

[SVG 1.0 Implementations]
(Old) SVG 1.0 implementation/interop status

[SVG 1.1 Implementations Status Matrix]
(New) SVG 1.1 implementation status matrix at

[SVG 1.0 Test Suite]
(Old) SVG 1.0 Test Suite

[SVG 1.1 Test Suite]
(New) SVG 1.1 Test Suite at

[SVG Fragment Identifiers]
SVG Fragment Identifiers at

[SVG Image Element]
The 'image' element at

[SVG Mobile]
SVG Mobile at

[SVG Implementations]
SVG Implementations & and product table at

[SVG View Element]
Predefined views: the 'view' element at

[SVG Viewers]
SVG Viewers at

[WebCGM] WebCGM 1.0 Second Release at

[WebCGM Addressing Pictures and Objects]
Addressing Pictures and Objects at

[WebCGM and SVG]
WebCGM and SVG - A comparison at

[WebCGM bibliography pages]
WebCGM product/interoperability pages at

[WebCGM Implementations]
Products supporting WebCGM at

WebCGM Proforma at

[WebCGM product/interoperability pages]
WebCGM product/interoperability pages at

[WebCGM Test Suite]
WebCGM Test Suite, release 1.0 at

[WebCGM Viewers]
Viewers and Printers at

[W3C Graphics Activity Statement]
W3C Graphics Activity Statement at

[W3C Scalable Graphics Requirements]
W3C Scalable Graphics Requirements at