Once the defect resolution is complete this should be supported even in WebCGM 2.0.
There is no specification work to do except design a test for the test suite.
Vendors will have to ensure their products support nested APS while text state is open.
Do you commit to update your viewer to allow nested APS in the text open state?
It would be possible to provide a DOM interface to perform a text search, but it would be limited to evaluating the content APS attribute and a simple subset of regexp. Further discussion indicated that we might, as an alternative, provide a sample in WebCGM of how a script writer might accomplish this without a new interface. A link would be provided in 3.2.2.8 in the discussion of the content attribute to Chapter 5 where an example of a test suite case that would do a search. Stuart provided a possible JavaScript example (note: this example has not been tested for correctness).
function SearchContent(myRegex) {
var allNodes = document.getElementsByTagName('*');
var results = [];
for( var n = 0; n< allNodes.length; n++) {
var node = allNodes[n];
var i = node.getAppStructureAttr("content");
if(i.match(myRegex)) {
results.push(node.apsId);
}
}
return results;
}
This solution would only require adding an example to Chapter 5.
A second option centered around putting in a DOM inteface for a general text search. This function would be unrelated to APS and would accept a subset of regexp search methods. The viewer would search restricted text (and append text) strings for a pattern match and highlight the resulting strings.
Would you provide support for the general text search functionality?
Three area were identified that would support limited animation capabilities.
This would satisfy most of the requirements identified during the discussions with Larry Baum and Molly Boose.
Would you implement the three methods to support animation?
A common method of specifying a font mapping table will not resolve this issue, but it will clear up some of the confusion faced by the users when using multiple applications. We proposed to create an XML specification for capturing font mapping that is used by all WebCGM vendors.
Would you support a standarization of the font mapping file?
It was proposed that a set of CGM control and attribute elements should be available for applying default values to. In particular when there are V1 and V2 files that do not have direct control over values (like restricted text type), or when a V3 file either doesn't explicitly set the value or sets it to the equivalent of a not specified value (like setting line cap to 0). A common way of specifying these defaults might be in a preferences file that could be combined with the font mapping file described above.
Would you support a comment method for accepting preferences in your viewer?
There seems to be the potential to gain significant compression using z-compression. This would require that the viewer know how to decompress z-compressed files. The indication of compression would be handled through the http packet through the server to the client. We would define an extension of cgmz to indicate to a file is compressed. It isn’t clear whether it is necessary to register a mime type for cgmz. It appears that is is possible to identify a z-compressed file by examining the header of the file. There is no effect to the processing of the WebCGM file except for dealing with the compression wrapper.
Would you provide support for z-compressed WebCGM files?