Mathematical Terminology

---

SVG Code Template for This Chapter

The examples in this chapter have at least two ECMAScript functions: an init() function that is executed immediately after the SVG document is loaded into memory, and a drawSpiral() function that is invoked from the init() function. Structurally the SVG documents have a format that is similar to the one listed below:

 <?xml version="1.0" standalone="no"?>  <!DOCTYPE ....> <svg onload="init(evt)" ...>   <script type="text/ecmascript">    <![CDATA[    // global variables here    function init(event)    {       target = event.getTarget();       svgDocument = target.getOwnerDocument();       gcNode = svgDocument.getElementById("gc");       drawSpiral();    }    function drawSpiral(event)    {       for(angle=0; angle<maxAngle; angle+=angleDelta)       {          // do something here       }    }  ]]> </script>  <g  transform="translate(10,10)">    <rect x="0" y="0"          width="800" height="500"          fill="none" stroke="none"/>  </g> </svg>

The preceding fragment contains the following line in order to invoke the function init() immediately after the SVG document is loaded into memory:

<svg onload="init(evt)" ...>

The init() function performs some initialization and then invokes another function, often called drawSpiral(), that dynamically creates SVG elements. The other detail to notice is the following line:

<g  transform="translate(10,10)">

This particular SVG g element is used very extensively in the examples for the remainder of this book and also the examples on the CD-ROM. Please note that the presence of this element is not mandatory; you can dynamically create this element and then add additional SVG elements as children of this element. The rationale for this construct is that it enables you to add other elements inside the SVG g element easily and quickly, and you can leverage those new elements with a minimum amount of code modification to the ECMAScript contained in the SVG document. For example, suppose you have already created another animation effect and you want to test the effect of combining both of them with a particular SVG document. You can do something like the following:

<g  transform="translate(10,10)">   <rect x="0" y="0"         width="800" height="500"         fill="none" stroke="none"/>    <!-- some fancy graphics here -->    ...    <!-- more fancy graphics here -->    ... </g>

The preceding fragment will cause your 'fancy graphics' to appear prior to anything that is dynamically created in an ECMAScript function. Indeed, this technique enables you to add some very large code fragments very easily and without having to write any of the corresponding ECMAScript code. This approach allows you to quickly 'mix and match' in order to test many different combinations of graphics objects and color-related effects. After you have decided which block of code to include in your SVG document, you can refactor the document, whereby the hard-coded block of code is replaced by an ECMAScript function that dynamically creates the necessary SVG elements.

Incidentally, this approach is also a prime example of leveraging both 'native' SVG code and ECMAScript functions in a manner that exploits what each of them does best. The proportion of ECMAScript code versus SVG code in your SVG documents will depend on various factors, such as the type of available code, your needs, and your proficiency in writing ECMAScript functions.

Another (slightly different) situation can arise where you have a sophisticated gradient shading pattern that you want to incorporate in order to alter the appearance of some existing SVG elements in your code. You can easily incorporate the existing SVG code in the following manner:

<defs>   <!-- dazzling gradient shading definition --> </defs> <g  transform="translate(10,10)">   <rect x="0" y="0"         width="800" height="500"         fill="none" stroke="none"/> </g>

In the preceding code fragment, you would also specify an id attribute for the gradient that you've defined in the SVG defs element so that you can reference that definition as part of the style attribute for an SVG element that you've created inside an ECMAScript function. Again, after having decided which code you want to include in your SVG document, you can perform the appropriate refactoring of the code. In case you're not quite sure how this is done, you'll see subsequent examples that will make this point clear.

What about performance? The insertion of dynamically created SVG elements to the SVG DOM is a time-consuming process. An alternative to this technique of using a hard-coded SVG g element involves dynamically constructing an SVG g element without adding this element to the SVG DOM. First create the dynamic elements, adding them to the new SVG g element in order to create a hierarchical structure of new elements, and then-as a final step-add the top-level dynamic SVG g element to the SVG DOM. You can experiment with this technique on several SVG documents and see if there is an appreciable difference in rendering time.

---