 |
|
|
Abstract
WebCGM™ is the choice for implementers looking for interoperability and longevity of their web graphics. However, the standard alone does not give you an electronic parts catalog or interactive manual. This presentation will provide details on how to use WebCGM in real-world applications. This includes developing a concept for graphic navigation and how to implement it using WebCGM navigation. The presentation will also discuss the pros and cons of inline and out-of-line links. It will then provide an outlook over the latest developments around WebCGM, including stylable WebCGM and the WebCGM DOM. Lastly it will offer help for those who need to decide between SVG and WebCGM for their projects.
Keywords
Table of Contents
Building on the strong support of the large established CGM community, WebCGM has rapidly become the format of choice for web delivery. In addition, a lot of web users have started using WebCGM for the delivery of interactive vector graphics.
This paper discusses the usage of WebCGM in various environments. It will also provide an overview over the latest developments around WebCGM that will lead to enhanced functionality in the future.
SVG for creative graphics and WebCGM for technical graphics represent two choices for web users and programmers that seem to compete at first glance. In practice, however, there are significant differences that strongly influence the decision about the format for web delivery. This paper will detail some of the important differences around object linking and navigation as well as provide a generic comparison.
Both SVG and WebCGM have been released as Recommendations of W3C for scalable vector graphics on the web. WebCGM is based on existing, well supported ISO Standards and industry profiles, whereas SVG is a new start from scratch.
The domain of SVG is clearly the area of high quality, creative graphics. It should be used if there are high requirements with regard to color, text, or filter effects on raster portions. It can also be used for animation purposes, although most users would certainly prefer the Flash format here, though not standardized.
WebCGM is perfectly capable of dealing with high quality vector graphics, though not to the same point as SVG. However, the emphasis here is on interoperability and longevity of the graphics files. Typically, this is needed in the area of technical graphics that have a long life cycle. It should be used if the graphics are complex or large in size, if revisions will have to be performed on the files, or if the graphics will be exchanged between different programs. Of course, WebCGM should be the choice if compliancy with industry standards like ATA or CALS is needed.
One very important aspect is interoperability. The history of CGM shows that every chance was used to store private data in a standard file, thus leading to files that could not be read by other programs without problems. This was done to accomplish additional functionality, or for competitive reasons. When WebCGM was defined, we made the conscious and tough decision to ban all private content from WebCGM files to avoid such problems. SVG is wide open to private extensions, and in the opinion of CGM Open and leading CGM people, it will experience the same problems in the future. This can be observed already now by looking at files generated by certain vendors that contain lots of private tags that nobody else understands.
It is important to note that common navigation concepts used in technical graphics cannot or not easily be implemented in SVG. This is described further below.
A very common requirement for intelligent graphics is the usage of hotspots. One or more areas of the illustration needs to respond to mouse moves and/or clicks. In WebCGM, this is accomplished by defining grobjects (graphical objects), which can carry attributes to define the hotspot region and the link.
A link can be attached to a grobject using the linkURI attribute. Any valid URL can be used here together with a target.
Simple examples are:
http://www.cgmopen.org - a link to a web site or page
../images/sample.cgm – a link to another cgm file
sample.cgm#name(myObj1,highlight) – a link to a grobject in this or another cgm file
This way of linking is called inline linking, where the explicit links reside inside the graphics file. It is recommended for simple cases, e.g. a few hyperlinks on a CGM that doesn’t change often to targets that don’t change often.
Very often it is desirable to keep the links outside the graphics file for easier maintenance, for example if either the graphics or the link destinations change frequently. This is the case with most technical illustrations used in spare parts catalogs or manuals.
Graphical objects in WebCGM files can still be used as hotspots, even if no link is stored inside the cgm file. If an out of line link is to be used, an empty linkURI will be attached to the grobject to tell the viewer to report any click on this object to the outside.
Thus it becomes possible to maintain all links on the outside of the illustration, e.g. in an XML companion file. This file then contains entries like the following:
<grobject id=’myID1’>
<link1>…</link1>
<link2>…</link2>
</grobject>
At runtime, the viewer will report the mouse event to the runtime environment using the ID of the grobject. A simple lookup suffices to find the right link for this object, if necessary, even context-dependant.
This technique can also be used for dynamic link building. The ID reported by the viewer can be used to build a temporary URL to a location in a parts list, for example:
ID reported by the viewer: part12
URL of parts list in second frame: partslist.htm
Dynamic Link to anchor in list:
In JavaScript: window.parent.frame2.location.href=”partslist.htm#" + strID;
Actual URL: partslist.htm#part12
This is a very nice way to define all links for an entire catalog in a couple of JavaScript lines.
The way how the viewer reports the click event to the outside has not been standardized yet, however, this will be part of the WebCGM DOM that is under development.
In SVG, only the object itself can become clickable, and only, if a link has been attached to it. In WebCGM, the object itself or a click region can become clickable, if the object has a linkURI attribute attached to it. However, WebCGM does not require explicit links in the file, the linkURI attribute may be empty, thus pointing to out of line resolution of the link at runtime.
The lack of a region attribute in SVG requires explicit definition of filled areas to create hotspots.
Graphical objects in WebCGM files can be the targets of navigation. The navigation can be initiated from within a WebCGM file, or – much more frequently – from the outside, e.g. an HTML page.
This can be used in a lot of areas; here are some examples:
A click on a text portion highlights a callout number on the illustration.
A click on a text portion navigates to a specific area of a wiring diagram to show the target.
It is essential that WebCGM allows for easy navigation to an object and its highlighting. An object can be addressed by using its ID or name:
Sample.cgm#id(myID1,highlight)
Sample.cgm#name(myName1,view_context)
It is also possible to address all objects with the same name with one single URL:
Sample.cgm#name(myName,highlight_all)
The usage of the WebCGM fragment allows for fully dynamic link building as well. If the ID of the object is used as an ID on the XML/HTML side as well, it can be used to concat it with the cgm file name to a fragment URL, which then is sent to the viewer.
The fragment syntax of WebCGM allows for navigation to an object inside a CGM file. It also allows for highlighting of this object. Although SVG supports at least some part of the navigation concept, it has not been implemented so far by leading viewers, so it cannot be used. Highlighting of objects is not defined in SVG neither is the concept of highlighting all objects with the same name. Both navigation and highlighting can be accomplished by writing rather complex JavaScripts using the SVG DOM.
An overview over the latest developments around WebCGM will be given at the conference. Because a lot of the work is done in the areas of stylable WebCGM and the WebCGM DOM during the last months of 2002, it is too early for this paper to describe the results.
The usage of the WebCGM linking and navigation capabilities has proven to be simple and efficient. This is especially true in the area of technical graphics, where graphics and related text change frequently, and the storage of links inside graphic files is self-prohibitive.
The decision between SVG and WebCGM really depends on the environment. For typical cases in technical publishing with long living graphics undergoing regular revisions, CGM has proven to be the better choice. The most used ways to interact between text and technical graphics are not or not fully supported by SVG, which makes an implementation time and cost intensive.
  |
Design & Development by deepX Ltd. 2002 |
