Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Exploring SVG
Let’s continue our step 1 discussion with a look at Scalable Vector Graphics (SVG), an XML vocabulary for defining rich, interactive, and powerful graphics and media. Like HTML, SVG is written in plain text and rendered by the browser, except that it’s not just text that’s rendered, but also shapes and images. Throw stylesheets and scripting into the mix, and it’s possible to control the look and feel of the image as well as provide interactivity and animation.
SVG is used for many things, ranging from simple web graphics and logos to online maps and charts. Unlike JPEGs or GIFs, which contain actual images, SVG describes in a very concise way (using XML) what to draw, leaving to an SVG engine the task of rendering the image onscreen.
In mobile computing, SVG has been generating quite a bit of interest as a way to create rich displays with minimal data transfer. Nokia and other manufacturers are now supporting SVG on their phones and developing SVG libraries for developers to use in creating rich SVG-based mobile applications. Following are just a few of the reasons for SVG’s popularity:
- Small file size. SVG files are smaller than JPEG or GIF graphics and are faster to download.
- Display independence. SVG images are sharp, both onscreen and in print. Because SVGs are drawn, you never get the jagged edges that occur when zooming in on a JPEG or GIF.
- Color control. SVG supports 16 million colors as well as gradients and masking.
- Interactivity and intelligence. Because SVG is XML-based, you can use scripting languages to get SVG images to respond to user actions with highlighting, tool tips, special effects, audio, and animation.
- Zoom. Users can magnify an image up to 1,600% without sacrificing sharpness. Text is editable and searchable, unlike GIF or JPEGs with text. SVG has no font or layout limitations; users always see the image no matter what browser they may be using.
- Text-based. SVG is based on text, not some mysterious binary format. Thus, it’s "human-readable," much like HTML. As we step through some SVG source, even if you’ve never seen SVG before, you can read the SVG source code and make sense of the descriptive content and graphic representation.
Let’s begin with some very simple SVG that draws some shapes and displays some text (see Listing 2). It’s tempting to talk about this as an SVG program, since we’re providing a description of what we want the computer to do. But this isn’t programming in the conventional sense. It’s what’s called declarative programming, in which we declare what we want and let some smart engine (such as the SVG renderer) take care of the details. Whether you want to think of it as a program or not, it’s still an XML document that abides by the rules of XML.
Listing 2 An SVG document.
<?xml version="1.0" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/SVG/DTD/svg10.dtd"> <svg xmlns="http://www.w3.org/2000/svg"> <text x="30" y= "20"> ZwiftBooks : Read it NOW! </text> <rect x="60" y="30" width="100" height="100" style="stroke:green; fill:blue; fill-opacity:.20"/> <circle cx="120" cy="120" r="30" style="fill:magenta; stroke:black; stroke-width:2; fill-opacity:.20"/> </svg>
Listing 2 shows the SVG for drawing some text, a rectangle, and a circle. (We’ll look at the output shortly.) Listing 2 shows some new aspects of XML, but first let’s consider what we already know:
- The tags <svg> and </svg> act as bookends for all the other elements. svg is considered the root or document element that encompasses all the others.
- The document contains four elements: svg, text, rect, and circle.
- The text element contains the text ZwiftBooks : Read it NOW! between the start tag <text> and the end tag </text>.
- The text element also includes the attributes x and y that tell the browser where to position the text.
Tree View
Figure 2 shows the drawn image and a corresponding tree view of the SVG document. Notice how the various SVG elements appear in their hierarchical relationships. Visualizing XML in its tree form is useful as you move toward XML mastery. As we’ll see later, many of the XML support technologies such as XSLT, DOM, XPath, and XQuery are based on this tree perspective, and are much easier to understand once you have the tree view.
)
Figure 2 SVG image and tree structure of the underlying document.
DTDs and Entities
Returning to the XML in Listing 2, we can see some aspects of XML that we haven’t come across in our previous discussion. Note the second line in Listing 2, the one that begins with <!DOCTYPE. This is a Document Type Declaration and refers to an external document known as a DTD. Part of this DOCTYPE says that the DTD for SVG is located at http://www.w3.org/TR/SVG/DTD/svg10.dtd. DTDs come to us from the SGML world and are used both to define the structure of an XML vocabulary and to provide abbreviation shortcuts or entities that an XML processor will use to make substitutions within the XML.
Entities are an important aspect of XML. As you start examining the DTDs of different XML vocabularies, you’re bound to run into these, so let’s have a quick look.
Entity References
Entity references are substitutions that allow one string of characters to be substituted for another in an XML document. In writing XML, they’re sometimes essential. For example, if you want to place the less-than sign (<) inside an XML element, the parser will generate an error because it sees < as the start of a new element. As a result, the following line is not well-formed XML:
<message>bob’s salary < 1000 </message>
To help address this issue, XML predefines five entity substitutions. To resolve Bob’s salary problem and actually get < inside the element, we can use an entity (<) that, when parsed by an XML processor, will generate the character we want. Thus, we can rewrite the message element as follows:
<message>bob’s salary < 1000 </message>
When included in an XML document, an entity reference must begin with an ampersand (&) and end with a semicolon (;). The five predefined XML entities are shown in the following table.
|
Entity |
Symbol |
Name |
|
< |
< |
Less than |
|
> |
> |
Greater than |
|
& |
& |
Ampersand |
|
' |
’ |
Apostrophe |
|
" |
" |
Quotation mark |
This substitution capability has proven so useful that users may define their own entity references within their DTDs. Thus, when trying to understand some XML vocabulary, if you see an entity declaration, think, "The DTD is where I can check what this means." For example, in a DTD, someone might write this:
<!ENTITY copyright "Copyright 2006, ZwiftBooks.">
Then, in the XML, you might see the following:
<p>©right;</p>
which would result in the XML parser substituting and giving us this result:
<p> Copyright 2006, ZwiftBooks.</p>
Because a DTD has the potential to define substitutions that affect the XML, we must alert XML parsers by modifying our XML prolog to read standalone = "no" as in Listing 2:
<?xml version="1.0" standalone="no"?>