Chapter 14. When Things Go Wrong
 | CONTENTS |  |
In this chapter:
- Minimizing Errors
- Avoiding Problems by Using Good Coding Practice
- Handling Common Error Symptoms
- Diagnosing and Solving Problems
Minimizing Errors
Inevitably, at some time during your use of SVG, things go wrong. Particularly during your first efforts to hand-code or to tweak by hand some code that was generated by a vector drawing package, you might find things going visibly awry. In this chapter, I describe an approach to keep serious errors to a minimum, discuss symptoms of commonly occurring errors, and show you an approach to diagnosing and solving problems that you might inadvertently create.
I hope that you don't get the wrong idea from this chapter and come away with the impression that SVG is impossibly complex. It isn't. However, things can go wrong in a number of ways, particularly in the learning phase. Being aware of them and of the solutions might save you time and increase the fun you have creating SVG images.
Avoiding Problems by Using Good Coding Practice
I suggest that you change, particularly during your early attempts at hand coding, only one thing at a time, whether that is adding an element, altering an attribute, or adding or refining some animation.
Let me repeat that: Change only one thing at a time when you are learning SVG coding. It helps your sanity!
If you change more than one thing at a time and you move from having an SVG image that is displayed correctly to one that isn't displayed as you want or, worse, isn't displayed at all, diagnosing and fixing can be quite a tussle. In the interest of sparing yourself avoidable frustration, change one thing at a time and view the result in an SVG viewer after each step.
This is good advice when you are working with the code for complex images too. You can make lots of potential tweaks that can cause problems. You might, in a flight of creative fancy, change five or ten things, one after the other, without checking the effect, and then find that the nice image is now broken and that you can remember only nine of the ten things you tweaked.
You get the idea. Work logically and systematically it saves time and frustration in the long run.
Use an XML-aware editor
One aid to avoiding problems when coding SVG is to use an XML-aware editor. You can craft, on Windows systems, SVG images in the simplest text editor, like Notepad. However, I suggest that you think seriously about obtaining an XML-aware text editor.
An XML-aware text editor provides two simple but important aids. You can typically check to see whether the SVG document is well formed. In other words, the XML-aware text editor identifies whether your code conforms to the XML rules, and, if it doesn't, the editor identifies the line on which your first syntax error exists.
Often in parallel with the ability to check for well-formedness, an XML-aware text editor also has a color-coding facility for your code. If you omit quotation marks on an attribute or forget the closing angled bracket on an element, you have some assistance by means of an unusual color pattern in identifying exactly where the problem is.
One XML-aware text editor I like is XML Writer. It is by no means the most sophisticated XML editor around, although it does the simple, basic things well and without fuss. My strongest recommendation is that, for a basic everyday tool, it doesn't get in the way. Further information on XML Writer is available from http://www.xmlwriter.com/. A 30-day free evaluation version is usually available.
Many other XML editors are available that also have evaluation downloads. For further options, take a look at http://www.xmlsoftware.com or a similar site, for a list of XML tools. Some HTML editors, such as Allaire Homesite, can provide color coding, but without the ability to check XML well-formedness, they are of limited help.
Of course, an XML-aware editor doesn't solve all your problems. For example, covering over your nice image with a plain rectangle is perfectly legal, although not sensible. The editor doesn't point out that if you intended for the rectangle to be the background, but forgot about the SVG painter's model and placed the rectangle late in the document, it covers up something else. Nor does the editor prevent you from trying to place white text on a white background.
Construct visual components
Just as making one change and testing the effect is sensible, constructing complex SVG images and documents as visual components is helpful. If you have created and tested an SVG visual component, you know that the component was working and, assuming that you pasted it into the correct part of the document, is unlikely to have caused the problem. Because you might have imported a text component with black text to display on your nice, new black background, however, it is always possible that the component is indeed the problem.
Handling Common Error Symptoms
First, deal with a couple of the most common symptoms you are likely to encounter when you first try to code SVG by hand. The first symptom is when nothing is displayed. The second is that only some of the parts of the image are displayed.
Nothing is displayed
Getting into this position is easy. Even minor syntax errors can cause an SVG document or element to fail to be displayed.
For example, if you make a simple mistake, like omitting a closing quotation mark in the following simple SVG, which ought to display a simple rectangle with a blue outline, the browser window is blank as in Figure 14.01.
Figure 14.01. The code in Listing 14.1 fails to display anything, but an error message appears in the browser status bar.
Listing 14.1 (FailToDisplay01.svg)
<?xml version="1.0" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/PR-SVG-20010719/ DTD/svg10.dtd"> <svg> <rect x="100" y="100" width="100" style="fill:none;stroke:#0000CC; stroke-width:2;/> </svg>
The error in this simple code that prevents anything from being displayed is that the closing quotation mark on the style attribute of the <rect> element has been omitted. If you add the closing quote, the rectangle is displayed, but not properly at least not until you specify a height attribute for the <rect> element.
Pause to consider why this failure to display anything happens. An SVG viewer is designed to render SVG elements from the beginning of the SVG document to the end. If the viewer processes an SVG element or group of elements without an error occurring, it renders that element or group and moves on to the next one. On the first occasion that the viewer encounters an error, it does not render that element or group.
Returning to the rectangle example, the viewer was unable to render the rectangle because its syntax was incorrect. No element appeared earlier in the document that can be rendered, so nothing could be rendered, and the SVG image was blank.
Another cause of a blank screen is when an error occurs in the syntax of the <svg> element that encloses the SVG document. For example, a missing quote on the x attribute of the document's <svg> element causes a blank screen:
Listing 14.2 (FailToDisplay02.svg)
<?xml version="1.0" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/PR-SVG-20010719/ DTD/svg10.dtd"> <svg x="400 y="300"> <rect x="100" y="100" width="100" style="fill:none;stroke:#0000CC; stroke-width:2;/> </svg>
The rationale is similar to that for the preceding example. The SVG viewer stops rendering when it encounters the first error in this case, on the <svg> element and it doesn't even attempt to render any other elements.
Here is a challenge for you. Can you spot in the following code why the image (a transparent rectangle with a blue outline) fails to be displayed?
Listing 14.3 (FailToDisplay03.svg)
<?xml version="1.0" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/PR-SVG-20010719/ DTD/svg10.dtd"> <svg x="400" y="300"> <rect x="100" y="100" width="100" height="100" style="fill:none;stroke:0000CC; stroke-width:2;"/> </svg>
The problem is in the stroke property of the style attribute. I have omitted the # that precedes the six-character definition of the color! The syntax of the rectangle is incorrect. Therefore, it is not rendered.
Another possible reason that an image, or part of it, might fail to be displayed is the introduction of a duplicate attribute. For example, if you mistakenly create two y2 attributes, as shown here:
<line x1="50" y2="50" x2="750" y2="50" style="stroke:white; fill:white;"/>
you can expect to get an error message that says something like duplicate attribute: line XX, column XX, which basically means that you have created two identically named attributes on an element, which is illegal in XML and therefore in SVG. Because the syntax is illegal, an SVG viewer ought not to display the <line> element.
Here is another, simplified example that tripped me up when I was trying to create a multiply-nested bunch of <svg> elements. Again, try to spot the problem before reading the explanation:
Listing 14.4 (FailToDisplay04.svg)
<?xml version="1.0" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/PR-SVG-20010719/ DTD/svg10.dtd"> <svg> <svg id="MeterHolder" x="0" y="0" width="200" height="200"> <rect id="MyMeter" x="0" y="0" width="20" height="40" style="fill:white; stroke:none;"> <rect x="2" y="2" width="6" height="4" style="fill:red; stroke:none"/> <rect x="2" y="10" width="6" height="4" style="fill:red; stroke:none"/> </rect> </svg> </svg>
The problem arises because the first <rect> element was split into its start and end tags (in preparation for adding an animation at a later stage), and the two other <rect> elements were inserted in the wrong place. The outer <rect> element has its end tag last and is therefore rendered last. As far as the user is concerned, nothing is rendered to the screen. What is happening is that the outer rectangle with the white fill is rendered last and therefore covers over the two other rectangles because of the way in which the SVG painter's model works. To fix the problem, simply move the end tag </rect>, as shown in the following code snippet:
<rect id="MyMeter" x="0" y="0" width="20" height="40" style="fill:white; stroke:none;"> </rect> <rect x="2" y="2" width="6" height="4" style="fill:red; stroke:none"/> <rect x="2" y="10" width="6" height="4" style="fill:red; stroke:none"/>
One practical tip is to avoid using white or whatever matches the background of your image, in the early stages of exploring a new idea. If you have something being visibly rendered, the use of another color helps you track down the problem more quickly.
You can cause a blank image in lots of other ways. If you get that problem, take a particularly careful look at the early part of the document. Check the spelling of the element name, and ensure that an opening quotation mark has a corresponding closing quotation mark. If the opening quotation mark is a double quote character, make sure that the closing one is too. If the opening quote is an apostrophe, make sure that the closing one is the same. Check the spelling of attribute names, and remember that SVG is case sensitive.
Only some parts of the image are displayed
This problem has lots of possible causes. A partial display arises in part from the way in which an SVG viewer is supposed to handle errors. It processes elements starting from the beginning and displays each element it views as having correct syntax. The first element the viewer encounters with a serious syntax error isn't displayed. Any elements after that one aren't displayed either.
The key to tracking down this kind of problem is to work out which elements are displayed. Work through the source code, in document order, and see what is displayed, it is likely (though not absolutely certain) that the first element you encounter that is not displayed is the one that contains the error.
The following code has syntax errors in all but the first <rect> element. Can you spot them and fix the code so that each rectangle is displayed? The answers are at the end of this chapter, but I encourage you to try to spot the problems yourself.
Listing 14.5 (PartDisplays01.svg)
<?xml version="1.0" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/PR-SVG-20010719/ DTD/svg10.dtd"> <svg> <rect x="20" y="20" width="100" height="50" /> <rect x="20" y=90" width="100" height="50" /> <rect x"20" y="160" width="100" height="50" /> <rect x="20" y="230" width="100" hieght="50" /> <rect x="20" y="300" width="100" height="50" style="fill;red; stroke:red;"/> </svg>
It was working earlier and doesn't work now
This type of problem is fairly common. Typically, the scenario is that you have a nice static SVG, you decide that you want to animate some part of the image, you introduce the necessary animation elements, you fail to get the animation you want, and part of the image that was previously displayed correctly disappears.
The cause is similar to what you saw earlier. When you introduce an animation element that contains an error, the element being animated isn't displayed because that element has an error and can't be rendered. At that point, the SVG viewer stops trying to render elements later in the document but displays any SVG elements that were processed without producing an error.
Look at the image and decide which elements have been rendered correctly. If you can remember the code clearly, decide which is the first element that ought to have been rendered but wasn't. The error is likely to be somewhere in the code of that element.
You might have made simple syntax errors in the animation element, like those shown in Listing 14.5. Or, you might have forgotten to indicate that the animation element is an empty element. For example, the <animate> element should look like this, with the /> at the end:
<animate ..... />
not like this:
<animate .... >
because the SVG processor expects an
</animate>
end tag somewhere later in the document and you almost certainly won't have provided one.
It doesn't animate
This problem has two likely causes.
The first is that a syntax error is somewhere in the animation element, whether that is an <animate> element, an <animateMotion> element, an <animateColor> element, an <animateTransform> element, or a <set> element. Did you include all the necessary attributes? If you omitted the attributeName attribute, for example, the SVG rendering engine doesn't know which attribute you want it to animate, so the animation fails. Similarly, if you omit the dur attribute, it doesn't know how long that color change, or whatever, is supposed to take, so it can't start it. Or, you might have forgotten to tell the SVG rendering engine when the animation was supposed to begin because you omitted the begin attribute.
Check carefully for missing quotation marks in attribute values. Check too for any misspelling of attribute names, and remember that SVG (because it is XML) is case sensitive.
You can happily animate a rectangle using this code:
<animate begin="5s" dur="5s" attributeName="x" from="100" to="200" fill="freeze"/>
but this code doesn't work:
<animate begin="5s" dur="5s" attributename="x" from="100" to="200" fill="freeze"/>
because the N of attributeName needs to be uppercase to be correctly recognized. Similar problems can occur if you misspell the element name. Remember that it is <animateColor> and <animateTransform>, and that case is important.
Now look at an example of inserting the animation element in the wrong place. You want to animate a rectangle, and you produce the code shown in Listing 14.6. You find that the rectangle is displayed okay, but it doesn't animate:
Listing 14.6 (WrongAnimation.svg)
<?xml version="1.0" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/PR-SVG-20010719/ DTD/svg10.dtd"> <svg x="400" y="300"> <animate begin="5s" dur="5s" attributeName="x" from="100" to="200" fill="freeze"/> <rect x="100" y="100" width="100" height="100" style="fill:none;stroke:#0000CC; stroke-width:2;"/> </svg>
The <animate> element is attempting to animate the x attribute of the outer <svg> element, which you can't do. The code shown in Listing 14.7 works because it is now animating the x attribute of the <rect> element.
Listing 14.7 (RightAnimation.svg)
<?xml version="1.0" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/PR-SVG-20010719/ DTD/svg10.dtd"> <svg x="400" y="300"> <rect x="100" y="100" width="100" height="100" style="fill:none;stroke:#0000CC; stroke-width:2;"> <animate begin="2s" dur="5s" attributeName="x" from="100" to="200" fill="freeze"/> </rect> </svg>
Killer white space appears
This potential pitfall belongs in one sense in the preceding section, but is so subtle and potentially frustrating if you are not aware of it that I have given it a section to itself. Worse, if you fall into this trap, the Adobe viewer gives you no hint that anything is wrong, simply saying Done, which usually indicates that everything is fine, although in this case it isn't. To illustrate the problem, go back and adapt one of the chained animation pieces of code so that it looks like this:
Listing 14.8 (WrongWhitespace.svg)
<?xml version="1.0" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/PR-SVG-20010719/ DTD/svg10.dtd"> <svg width="300" height="100"> <rect id="MaroonRect" x="10" y="15" width="10" height="10" style="fill:#990066;"> <animate begin="PinkAnim.begin+ 2s" dur="10s" attributeName="width" from="10" to="250"/> </rect> <rect id="PinkRect" x="10" y="45" width="10" height="10" style="fill:pink;"> <animate id="PinkAnim" begin="2s" dur="10s" attributeName="width" from="10" to="250"/> </rect> <rect id="YellowRect" x="10" y="75" width="10" height="10" style="fill:#FFFF00;"> <animate begin="PinkAnim.begin+4s " dur="10s" attributeName="width" from="10" to="250"/> </rect> </svg>
If you try this code, you find that the pink and maroon animations work exactly as you would expect but that the yellow animation doesn't work. The problem is buried in the syntax for the value of the begin attribute:
begin="PinkAnim.begin+4s "
No white space is allowed at the beginning or end of the syncbase value. If you remove the space character after 4s, the animation works correctly. Yet white space is allowed on either side of the + sign, as shown here:
begin="PinkAnim.begin+ 2s"
That is one example you might stumble across if you use syncbase values in your animations.
Also, be aware that the same problem can prevent event-based animations from working.
The weird trailing semicolon appears
Another subtle syntax sensitivity you should be aware of when you are creating animations is what I call the weird trailing-semicolon issue. Here is a piece of code, extracted from http://www.svgspider.com/Page02.svg, that illustrates the problem. If you want to test your diagnostic skills, read and test the following code, to see whether you can spot what is causing the animation problem. Figure 14.02 shows the position at the end of a fairly weird animation.
Figure 14.02. The odd position obtained at the end of a weird animation, caused by the trail-ing-semicolon issue.
Listing 14.9 (CurtainsSemicolon01.svg)
<?xml version="1.0" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/PR-SVG-20010719/ DTD/svg10.dtd"> <svg width="600" height="600"> <svg x="50" y="-200"> <rect style="fill:black" x="250" y="260" height="100" width="150"/> <rect style="fill:white" x="255" y="265" height="90" width="140"/> <text style="font-family:Arial; font-size:12; fill:red; stroke:red" x="275" y="280">SVGSpider.com</text> <text style="font-family:Arial; font-size:12; fill:red; stroke:red" x="260" y="310"> Do you like my curtains? </text> <rect style="fill:red" x="255" y="265" height="90" width="1" > <animate attributeName="width" values="1; 75; 1" dur="5s" begin="0s" /> <animate id="close3" attributeName="width" attributeType="XML" values="1; 75" dur="2.5s" begin="button2.click" fill="freeze"/> <animate id="open" attributeName="width" attributeType="XML" values="75; 1" dur="2.5s" begin="button1.click" fill="freeze"/> </rect> <rect style="fill:red" x="394" y="265" height="90" width="1"> <animate attributeName="width" values="1; 75; 1" dur="5s" begin="0s"/> <animate attributeName="x" values="394; 322; 394" attributeType="XML" dur="5s" begin="0s"/> <animate id="close1" attributeName="width" attributeType="XML" values="1; 75;" dur="2.5s" begin="button2.click" fill="freeze"/> <animate id="close2" attributeName="x" attributeType="XML" val- ues="394; 322;" dur="2.5s" begin="button2.click" fill="freeze" /> <animate id="open" attributeName="width" attributeType="XML" values="75; 1" dur="2.5s" begin="button1.click" fill="freeze"/> <animate id="open" attributeName="x" attributeType="XML" val- ues="322; 394" dur="2.5s" begin="button1.click" fill="freeze" /> </rect> <g id="controls"> <g id="button1"> <ellipse cx="258" cy="410" rx="34" ry="12" style="fill:red;" /> <text pointer-events="none" x="242" y="414" style="fill:white; font-weight:bold;">Open</text> </g> <g id="button2"> <ellipse cx="395" cy="410" rx="34" ry="12" style="fill:red "/> <text pointer-events="none" x="379" y="414" style="fill:white; font-weight:bold;">Close</text> </g> </g> </svg> </svg>
Did you find the problems? Ah, you were looking for only one? Debugging doesn't come as neatly packaged as that in real life. The problems arise in the following lines of code:
<animate id="close1" attributeName="width" attributeType="XML" values="1; 75;" dur="2.5s" begin="button2.click" fill="freeze"/> <animate id="close2" attributeName="x" attributeType="XML" values="394; 322;" dur="2.5s" begin="button2.click" fill="freeze" />
If you remove the final semicolons at the end of each values attribute (replace 75; with 75 and replace 322; with 322), the code is executed correctly. You can obtain three different erroneous animations by leaving one semicolon in either values attribute list or by including both. At least that's what happens with those syntax changes in Adobe SVG Viewer version 2.0.
The same problem lay behind the weird overlay of rotating text messages I mentioned in relation to the next-to-last example in Chapter 9, "Creating Logos and Banner Ads."
Because I normally (in CSS, for example) include a final semicolon, this problem caused me frequent additional problems.
If I now find a genuinely weird piece of animation behavior in an SVG animation, the trailing semicolon is high on my list of likely culprits. My guess is that it's likely a bug in the Adobe SVG Viewer.
Diagnosing and Solving Problems
In this section, I discuss a number of miscellaneous problems you might encounter and suggest some solutions. Some of the following sections are based simply on the problem or symptom as it might affect you; others depend on the error messages displayed by an SVG viewer.
The Adobe SVG Viewer displays a number of error messages in Internet Explorer in the browser status bar. Some of these error messages are helpful, some less so. Some, like the first example, are true, even if they're just a little insulting.
The "Junk after document element" message
I have only once received this not encouraging message from the Adobe SVG Viewer. I was experimenting with a new SVG filter and copying the filter within a <defs> element; I then inadvertently pasted the <defs> element in front of the <svg> element (rather than nested within it). The Adobe viewer interpreted the <defs> element as the document element and interpreted everything after the end </defs> tag as "junk." I guess that put me in my place!
If you are cutting and pasting SVG code, be sure that you don't inadvertently paste it in the wrong place.
The "No Element Found" message
Sometimes, when you are editing, you might see an error message from the Adobe viewer that says no element found, line XX, column XX. You see this error if you have nested an <svg> element within another one and have closed only one of the </svg> elements typically, if you add an end </svg> tag at the line given in the error message that fixes the problem.
A similar error message might arise if you have nested one grouping <g> element within another and then provided only one end </g> tag. However, in that case, the error message might not always indicate the exact point where you need to insert a </g> tag, particularly if you have a complex set of nested grouping <g> elements. The error message might indicate one place you can insert an end tag, but that might not create exactly the nested structure you want.
Links that don't work
In my experience, the most common cause by far of links that don't work is when you forget to include the xlink:href attribute, expressed properly.
This line works in HTML but not in SVG:
<a href="http://www.SVGSpider.com/default.svg">SVG Spider</a>
For SVG, you need this:
<a xlink:href="http://www.SVGSpider.com/default.svg">SVG Spider</a>
Similarly, for mailto links, this line would work in HTML or XHTML but not in SVG:
<a href="mailto://Consulting@AndrewWatt.com">Consulting Services</a>
For a working mailto link in SVG, you need this line:
<a xlink:href="mailto://Consulting@AndrewWatt.com">Consulting Services</a>
Don't forget to use the correct attribute name, xlink:href.
Comments
If you are having real problems with a particular piece of SVG (hopefully, it's a complex piece, but at the beginning anything can seem complex), you might want to start commenting out parts of your SVG document. This technique can be useful for trying to work out exactly what is going on or going wrong with, for example, a complex SVG filter or animation.
Commenting out parts of an SVG image can also be useful, however, with simpler problems. Suppose that you are having problems in getting some text to display (or so you think) and your code looks something like this:
Listing 14.10 (Diagnose01.svg)
<?xml version="1.0" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/PR-SVG-20010719/ DTD/svg10.dtd"> <svg width="300" height="200"> <rect x="50" y="50" width="200" height="100" style="fill:black; stroke:black"/> <text x="60" y="70" > Hello SVG World! </text> </svg>
Suppose also that you are wrestling with this problem. You just can't see what you have done wrong and are frustrated that your text isn't displayed.
You can comment out the rectangle so that the SVG rendering engine does-n't process it and therefore doesn't display it, like this:
Listing 14.11 (Diagnose01WithComments.svg)
<?xml version="1.0" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/PR-SVG-20010719/ DTD/svg10.dtd"> <svg width="300" height="200"> <!-- <rect x="50" y="50" width="200" height="100" style="fill:black; stroke:black"/> --> <text x="60" y="70" > Hello SVG World! </text> </svg>
Now that the black rectangle is removed from the display, you can see that the black text is displayed correctly against the whitish default background. You realize that forgetting to define the style attribute for the text means that it is also black, and black text on a black rectangle isn't easy to see or read.
So far, so good. In practice, you might try blocking out parts of an SVG document that already contains comments, in code a little like this:
Listing 14.12 (Comments01.svg)
<?xml version="1.0" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/PR-SVG-20010719/ DTD/svg10.dtd"> <svg width="300" height="200"> <rect x="50" y="50" width="200" height="100" style="fill:black; stroke:black"/> <text> <!-- My first clever <tspan> line. --> <tspan x="60" y="70" style="fill:red; stroke:red; font-size:14; font-weight:bold;"> Hello SVG World! </tspan> <!-- My second clever <tspan> line. --> <tspan x="60" y="90" style="fill:red; stroke:red; font-size:14; font-weight:bold;"> A second line. </tspan> <!-- My third clever <tspan> line. --> <tspan x="60" y="110" style="fill:red; stroke:red; font- size:14; font-weight:bold;"> A third line. </tspan> </text> </svg>
The code is nicely commented, but that nice commenting lays a potential trap for you if you plan to use <!-and --> comments for diagnosing problems.
Suppose that in your efforts at diagnosing some problem, you want to comment out all the text within the <text> element, with the code looking like this:
Listing 14.13 (Comments02.svg)
<?xml version="1.0" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/PR-SVG-20010719/ DTD/svg10.dtd"> <svg width="300" height="200"> <rect x="50" y="50" width="200" height="100" style="fill:black; stroke:black"/> <!-- <text> <!-- My first clever <tspan> line. --> <tspan x="60" y="70" style="fill:red; stroke:red; font-size:14; font-weight:bold;"> Hello SVG World! </tspan> <!-- My second clever <tspan> line. --> <tspan x="60" y="90" style="fill:red; stroke:red; font-size:14; font-weight:bold;"> A second line. </tspan> <!-- My third clever <tspan> line. --> <tspan x="60" y="110" style="fill:red; stroke:red; font-size:14; font-weight:bold;"> A third line. </tspan> </text> --> </svg>
Can you see the problem? You have placed the opening <!-and closing -> correctly to comment out all of the <text> element, if only it didn't already have comments within it. In XML, you cannot nest comments within other comments.
In this simple example, which was working before you inserted the illegal comments, the Adobe viewer helpfully shows the problem as seen in Figure 14.03.
Figure 14.03. Error, with indicative error message in the status bar, caused by incorrectly inserting comments in code.
You have a well-formedness error at line 10, column 4: You have opened a second comment nested within the one you just added. If you are using an XML editor with color coding, that might help you as you add the --> to close the comment (which is also illegal) in your document.
Spotting what is going on is easy when you have short, simple, already-working code. When you have complex SVG images, possibly heavily commented, which are already not working (otherwise, why would you be doing this?) and you add another error by illegally nesting comments, untangling the code can be a nightmare if you are unaware of this potential pitfall.
By all means, comment your code. To avoid the pitfall I just described, bring your comments up to just before a major SVG element, like this:
<!-- My very complex text element does marvellous things, and I am really proud of it. It has lovely <tspan> elements. --> <text> ... </text>
rather than split many comments within code blocks. To comment out the whole text block, simply add a comment, like this:
<!-- My very complex text element does marvellous things, and I am really proud of it. It has lovely <tspan> elements. --> <!-- This comment comments out the whole text block for diagno- sis <text> ... </text> and closes legally here. -->
All this is legal and likely to help you to diagnose that frustrating problem rather than add to your woes.
I hope that these various techniques help you diagnose and correct any errors in your SVG code. If you are struggling and desperate, the best source of general online help on SVG is the SVG-Developers mailing list on YahooGroups.com.
Here are the answers to the display problem shown in Listing 14.5. The second <rect> element had a missing opening quote on the y attribute. The third had a missing equals sign on the x attribute. The fourth had the name of the height attribute misspelled as hieght. The final <rect> had a semicolon rather than a colon between fill and red.
In this chapter, I have introduced you to many types of problems you might face while creating or tweaking SVG code. If you have created working code, you should follow my advice to then change one thing at a time. This strategy can help you avoid getting into a morass of errors that takes lots of time and frustration to escape. In listing a number of possible pitfalls, I hope that I haven't frightened you off from coding SVG. It takes care and patience, but after you master the basics it is often fun.
| CONTENTS | |
EAN: 2147483647
Pages: 26