Keywords: APPLICATION STRUCTURE, CALS, ATA profile, ATA GREXCHANGE, WebCGM, CGM, SVG, Graphics
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 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.
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 "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 few months between the previous draft of this paper and the present version, a second SVG plug-in implementation has joined the long-time single one, and a WebCGM interoperability and product directory has been initiated.
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.
|Introduction, Overview, & Requirements
In this section we will address the following topics:
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.
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 the drawing me 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 to produce 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 graphic 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.
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 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 with losses, because most high-level primitives like circles or similar get converted 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.
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
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.
|links to one or several objects supported using ID or name
|simple links to one object supported
|explicit support for navigation to single or multiple object(s) and highlighting
|limited support for highlighting and navigation
|not supported, possible with limitations by using event handlers
|explicitly, directly supported
|explicitly, directly supported
|explicitly, directly supported
|Document Object Model (DOM)
|none (limited DOM/API in development)
|full XML DOM plus SVG extensions
|full-functioned declarative & DOM animation
|none (ad hoc for link activation, object selection)
|full-functioned event model (based on DOM3 events) [LH verify this]
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.
|Non-scaling linewidth modes
|Engineering line types
|specific inking, offset controls for tech drawing
|offset control,but no vertex inking or adaptive controls
|no (but in ISO/CGM)
|Embedded raster images
|raster stored in CGM file, efficient compression methods
|raster in external file, or embedded without compression
|none (but limited CSS-like in development)
|full CSS & XSL support
|binary (but XML is planned)
|text (but binary is planned)
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.
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".
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 ).
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.
These links both point to an object inside the the same or another graphics file:
|Example for WebCGM:
|object resides in the same file
|object resides in a different file
|Example for SVG:
|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 ).
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
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.
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.
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.
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. Thus the entire concept of out-of-line links is not possible with SVG.
It would be impractical to write an explicit event handler for each object in a parts catalog, that would result in thousands of handlers. So perhaps it is possible to write one single event handler that uses the DOM to find an element under the mouse and then handles accordingly. All this is cumbersome and not very practical.
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 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.
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 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...".
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.
WebCGM has no DOM functionality. Several implementers have put proprietary DOMs on their viewers, and a standardized WebCGM DOM of limited functionality is currently under development.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.
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. There is some preliminary study for defining a simple but more comprehensive event model for WebCGM.
SVG supports a fully-functioned event model based on DOM3 events. With scripting, event handlers of various kinds can be attached to any identifiable graphical objects.
There is an interesting issue associated with events, related to some identified technical document requirements, which suggest an out-of-line-link solution. Out-of-line-links are supplied in the runtime environment, and the communication takes place using events. Using the DOM it is possible to establish an event listener for mouse events on a single object, however, we did not find an immediate way to establish one single event listener for a class of objects, i.e. one event listener for all hotspots on an illustration. This is an issue that is being discussed by WebCGM, with some initial proposals for a solution that might be simple enough for a WebCGM 1.1. There does not appear (to the authors) to be an obvious solution using DOM events, but we are investigating further. To illustrate the point, it is not acceptable to establish an event listener for each object/hotspot in a parts catalog, just think about the typical quantities.
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 does not support the functionality of non-scalable line width.
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.
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.)
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. 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. [LH to rsch whether this is in the SVG 1.2 requirements list.]
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.
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]). However, whereas in WebCGM the raster content is stored completely inside the WebCGM file, SVG references external files in JPEG, PNG, or other raster formats. The inclusion of raster data within the SVG file is possible by encoding the pixels as base64 characters inside the xlink:href attribute. This is done by several applications on the market.
This leads to significant differences between the formats when using raster portions as a part of the illustration. With SVG, either two files need to be handled, or the file size is significantly larger than the one of the WebCGM file.
An example will illustrate the point. Include a bitonal PNG file of approx. 150 KB size in an illustration. Save the illustration as a WebCGM with G4 compression. Save the illustration as SVG with external storage of images, then as SVG with embedded images. Table 3 shows the results:
|Group 4 compression
|SVG with ref
|SVG with ref
All SVG files have been created using Adobe Illustrator 9.0. The WebCGM file has been created using ITEDO IsoDraw 5.1. These products are listed as a reference only. Other products supporting WebCGM and/or SVG may be used.
The main reason for the file sizes is that the black and white file gets converted into an RGBA image. Then thereafter it will be base64-encoded. The consequence for technical graphics is enormous. A substantial legacy exists in a variety of raster formats. This legacy data will continue to be used for a long time, especially in the defense and aerospace industries. Thus it is of vital importance to have small file sizes and one single file.
WebCGM does not support attribute styling of the CSS and XSL kind. A design project has been completed for a limited "Stylable CGM" capability (see other paper at this conference), 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.
|Specific interoperability considerations
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 still under investigation, and will continue to be investigated until presentation of the paper. Such aspects are identified as provisional conclusions, with more work to be done.
|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
|uses CSS text properties and font resolution rules
|no styling (limited styling in planning)
|full CSS styling support
|Language flavors & strict profiles
|loose conformance, flavors developing
|Implementation of object linking
|several correct implementations (unconfirmed)
|no implementations known (unconfirmed) [LH verify]
|Viewer software availability & completeness
|a few plugins relatively complete (unconfirmed)
|two plugins, apparently incomplete (unconfirmed) [LH verify]
|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) [LH Verify]
|Test suites & validator
|comprehensive breadth-first plus some detailed tests; validator available
|comprehensive breadth-first plus some detailed tests; validator being built (unconfirmed)
|Maturity & stability
|very mature, changes and errata are rare
|fairly young, numerous errata and clarifications/interpretations
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.
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 [LH verify]. 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.
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 embedding the whole font definition in the picture file, and this is the only way to do so.
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.
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 proper functional subsets, not strictness constraints. In the opinion of the authors, the implementation landscape of SVG is fragmenting into numerous language "flavors", characterized by:
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 expected to be available by May, 2003, 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 a second plug-in is available, and is not yet tested. These tests will be repeated for both plug-in implementations in the immediate 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.
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. By May 2003, the products will be linked from the viewer-product page at [WebCGM Viewers] to completed Implementation Conformance Statements (ICS).
SVG. There are two 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.
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.
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 currently, however one is allegedly under construction.
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.
|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.
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 http://www.adobe.com/svg/indepth/pdfs/CurrentSupport.pdf
ATA GREXCHANGE profile at http://www.airlines.org/public/publications/display1.asp?nid=901
CALS profile at http://navycals.dt.navy.mil/cals/calsstds.html
CGM Open Website at http://www.cgmopen.org
[CGM Open BHO Project]
CGM Open BHO Project at http://www.cgmopen.org/technical/bho/index.html
SVG 1.1 at http://www.w3.org/TR/SVG11/
[SVG 1.0 Recommendation Errata]
SVG 1.0 Recommendation Errata at http://www.w3.org/2001/09/REC-SVG-20010904-errata
[SVG 1.0 Implementations]
(Old) SVG 1.0 implementation/interop status http://www.w3.org/Graphics/SVG/Test/BE-ImpStatus-20011026.html
[SVG 1.1 Implementations Status Matrix]
(New) SVG 1.1 implementation status matrix at http://www.w3.org/Graphics/SVG/Test/20021115/matrix.html
[SVG 1.0 Test Suite]
(Old) SVG 1.0 Test Suite http://www.w3.org/Graphics/SVG/Test/Overview-10.html
[SVG 1.1 Test Suite]
(New) SVG 1.1 Test Suite at http://www.w3.org/Graphics/SVG/Test/
[SVG Fragment Identifiers]
SVG Fragment Identifiers at http://www.w3.org/TR/SVG11/linking.html#SVGFragmentIdentifiers
[SVG Image Element]
The 'image' element at http://www.w3.org/TR/SVG11/struct.html#ImageElement
SVG Mobile at http://www.w3.org/TR/SVGMobile/
SVG Implementations & and product table at http://www.w3.org/Graphics/SVG/SVG-Implementations.htm8
[SVG View Element]
Predefined views: the 'view' element at http://www.w3.org/TR/SVG11/linking.html#ViewElement
SVG Viewers at http://www.w3.org/Graphics/SVG/SVG-Implementations.htm8#viewer
[WebCGM] WebCGM 1.0 Second Release at http://www.w3.org/TR/REC-WebCGM/
[WebCGM Addressing Pictures and Objects]
Addressing Pictures and Objects at http://www.w3.org/TR/REC-WebCGM/REC-03-CGM-IC.html#webcgm_3_1
[WebCGM and SVG]
WebCGM and SVG - A comparison at http://www.cgmopen.org/technical/webcgmandsvg.ppt
[WebCGM bibliography pages]
WebCGM product/interoperability pages at http://www.cgmopen.org/webcgm/products.html
Products supporting WebCGM at http://www.cgmopen.org/webcgm/products.html
WebCGM Proforma at http://www.w3.org/TR/REC-WebCGM/REC-04-CGM-Profile.html
[WebCGM product/interoperability pages]
WebCGM product/interoperability pages at http://www.cgmopen.org/webcgm/products.html
[WebCGM Test Suite]
WebCGM Test Suite, release 1.0 at http://www.cgmopen.org/resources/test/index.html
Viewers and Printers at http://www.cgmopen.org/webcgm/viewers.html
[W3C Graphics Activity Statement]
W3C Graphics Activity Statement at http://www.w3.org/Graphics/Activity
[W3C Scalable Graphics Requirements]
W3C Scalable Graphics Requirements at http://www.w3.org/Graphics/ScalableReq.html