Chapter 15. Planning and Building SVG Components

CONTENTS

In this chapter:

  •  Visual Components Defined
  •  Envisioning XML and Visual Components
  •  Understanding the <svg> Element and Visual Components
  •  Using Components that Save Time and Work
  •  Creating a Plug-In Component and Making It Mobile
  •  Building a Portfolio of Visual Components

Visual Components Defined

One key concept I hope that I have communicated to you in the earlier chapters of this book is that SVG opens up exciting new possibilities for creating visual components.

The SVG specification makes clear that the idea of visual components was in the mind of the SVG designers, although it doesn't explicitly use the term visual components.

Visual components in SVG can be created at various levels. The important point is to appreciate that careful planning of SVG visual components can help you reuse parts of graphics you have already created, therefore making you, as a practitioner of SVG Web graphic design, more efficient and better able to com-pete in what is already a highly competitive graphics marketplace. My prediction is that competition will become significantly more fierce.

Envisioning XML and Visual Components

In this book, I have largely avoided discussing the technical details of XML, as opposed to specific issues relating to SVG. However, you might find that envi-sioning the idea of SVG visual components in their XML context is helpful.

XML entities

Every XML document begins with a top-level, invisible entity the document entity that can contain one or many other entities. Those other entities can be contained within the document entity or be stored externally, typically on a computer file system.

You can look on these XML entities as predefined nonvisual components. The important thing to realize is that you can define your own entities and then use them as often as you want in XML documents.

An XML processor recognizes a few built-in entities. For example, to be able to use the < and > left and right angle brackets, in XML you must "escape" them as < and >, respectively. You don't need to declare those. An XML processor is already aware of what they mean.

If you want to have a paragraph in an XML document that refers to the "<svg> element," you need to write something like this:

<svg> element 

Then the XML processor doesn't try to process the text <svg> as though it were a live SVG element.

XML allows for several specific entity types that I don't consider in detail here. For purposes of this chapter, just be aware that entities can be considered as units of information, or storage objects.

Clearly, the document entity contains or accesses all other entities that make up an XML document. Similarly, one of the entities that a document entity contains or accesses can contain or access another entity.

Although you do not think in those terms all the time, an XML document is therefore made up of a hierarchy of entities that can contain other entities. In this discussion, thinking of XML entities as components (not visual components, but rather the component physical parts of an XML document) can be helpful.

If you move on from the general situation of an XML document and think of how an SVG document is put together, it also is composed of entities. That isn't too surprising because SVG is an application language of XML. In SVG, each of those entities, with the exception of the document entities, are likely to have a visible effect, given the nature of what SVG is.

Just as with XML entities, SVG visual components can exist in various sizes that can individually be self-contained or contain or access other visual components.

The very flexibility of how SVG visual components can be structured or interrelated means in part that some planning is necessary.

Types of SVG visual components

As I have just mentioned, SVG visual components can be constructed in many, many ways. In this section, I want you to look briefly at some of the ways in which it can be done.

Perhaps the most coarsely grained type of SVG visual component is the separate SVG document or document fragment. If you have created any HTML or XHTML Web pages using frames, you are already familiar with the concept.

The visual space of the browser window is filled using at least two, and typically three, frames. Each frame that is part of a frameset is filled with the content of a separate HTML or XHTML file.

The same principle can be applied to SVG. If you have an SVG Web page, for example, each "frame" of it can be constructed by importing an external SVG file, in much the same way as an HTML frameset was made up. For example, the containing SVG document might look pretty much like this:

Listing 15.1 (Frameset.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="100%" height="600">  <!-- Import the top frame -->  <svg x="20%" y="0" width="100%" height="100">  <image x="0" y="0" width="100%" height="100%"   xlink:href="TopFrame.svg"/>  </svg> <!-- Top frame ends here -->  <!-- Import the left frame -->  <svg x="0" y="0" width="20%" height="600">  <image x="0" y="0" width="100%" height="100%"   xlink:href="LeftFrame.svg"/>  </svg> <!-- Left frame ends here -->  <!-- Import the main frame -->  <svg x="20%" y="100" width="80%" height="500">  <image x="0" y="0" width="100%" height="100%"   xlink:href="MainFrame.svg"/>  </svg> <!-- Main frame ends here -->  </svg> 

Each of the three SVG files accessed by the <image> elements would be functioning as a visual component. For example, the left frame might con-ventionally be a navigation bar that can be reused exactly as it is in all the (main) pages of a Web site.

At the time this book was written, I was still waiting for the Adobe SVG Viewer to support the code you have just looked at. Until Adobe provides complete support for the <image> element, this type of SVG visual compo-nent although potentially one of the most useful essentially isn't usable. I hope that Adobe fills that gap soon, perhaps even by the time you read this book.

Understanding the <svg> Element and Visual Components

As I have indicated in earlier chapters, you can nest <svg> elements within an outer <svg> element. In some senses, that nesting functionally does the same thing as using an <image> element to import separate SVG files, each nested within its own outer <svg> element.

One use of such nested <svg> elements is as a grouping element. Another is for use as independent visual components. Because the <svg> element that ultimately is nested can be used as the outer <svg> element of a separate component during testing, you can develop all the content of the <svg> element as a separate document fragment.

In a team setting, assuming that the size and other relevant parameters of the (to be) nested <svg> element are sufficiently clear, individual members of the design team can implement separate parts of a complex SVG image or Web page.

After each team member has created the <svg> element assigned to her and the elements have been tested, they can be pasted into one SVG document that makes use of the visual components created by individual designers.

The <use> element

In Chapter 2, "SVG Document Overview," I discussed the SVG <use> element. It provides the straightforward reuse of visual components within a single SVG document.

If you want to create an SVG image of the United States flag, for example, you need to have a substantial number of identical stars. Rather than rede-fine those one at a time, creating one correctly sized and shaped star and then accessing it multiple times by using the <use> element makes much more sense. This process cuts down the length of the SVG code a little and means that the code for a star has to be tested only once. Testing the code for each <use> element should be straightforward because, apart from adjusting the x and y attributes to ensure correct placement of each star, there are no differences between each example.

The stars wouldn't be the only reusable component in the Stars and Stripes because the stripes can also be reused.

The <defs> element

The <defs> element, as described in Chapter 2, also helps you to reuse code. If you want to use a gradient in more than one element in an image, for example, you simply define the gradient once and refer to it twice or more. That technique saves code and also saves time for testing the gradient.

Multiple uses in a component

When I showed you how to create navigation bars in Chapter 5, "Creating Navigation Bars," you saw how you can create one <a> element and all its content and, after that is working correctly, copy it to create further parts of a navigation bar adjusting positioning attributes and the target of the xlink:href attribute, of course. Reuse on that small scale prevents typing mistakes from being introduced.

Use in multiple documents

At a deeper level, a navigation bar can be saved in its own file for copying and pasting into another application later. A limit must exist on how many ways a horizontal text navigation bar, for example, can be created. Of course, its colors and other characteristics are adapted in its new use, but the basic structure and function remain the same. So why not reuse the good code you already have at hand?

Using Components that Save Time and Work

As you gather experience with SVG and increase your stock of working SVG code, the reuse of that careful effort you invested earlier is sensible.

An important question is how you structure and store the visual components you have created. I return to that question later.

Saving debugging time

When you cut and paste code from previous SVG projects, you are, or ought to be, using code that has been well tested. You likely invested time in carefully constructing that code and testing its animations, interactivity, and links, for example, to ensure that they were working as you want them to.

Of course, when you reuse that code, you likely do not want to use it exactly in its original form. As you tweak some attribute values or refine some animation timing, you have to be careful not to introduce new errors into code that was previously working.

From time to time, you inevitably will make a syntax error as you adjust the code to its new purpose. If you have taken my advice to change one thing at a time and to test the static display and animations frequently, you likely know what changes you have made since the code last worked correctly. Those changes are where you should be focusing your debugging task. When you have made only one or two changes since last viewing the result, you have only one or two places to look, and spotting the error shouldn't take long.

If you have made ten or a dozen changes since you last checked whether the SVG was being displayed correctly, you have only yourself to blame if you can't even remember what two or three of the changes were. If you code in that way, expect to have some long, frustrating debugging ses-sions. I don't enjoy those one bit and try to code in such a way as to make them rare occurrences. I suggest that because you won't enjoy debugging, you should carefully follow a step-by-step approach on each part of an SVG project.

Breaking down the barriers to using components fully

At the time this book was written, some of the most helpful aspects of SVG for fully exploiting SVG components are missing. The biggest single omission is the absence of any implementation of the SVG <image> element that can include or import existing SVG images.

Hopefully, by the time you read this chapter, Adobe might have implemented the SVG image-import part of the <image> element. That facilitates the reuse of SVG components, pretty much along the lines of the XML entities I discussed in the early part of this chapter.

Creating a Plug-In Component and Making It Mobile

I pointed out to you earlier that the Adobe SVG Viewer does not now support the import of external SVG images using the <image> element. However, after the viewer has that functionality, you can add a whole new dimension to the reuse of code. Reusing code as separate files in some settings makes lots of sense.

Most of this chapter has been pretty abstract, so take a look at a practical issue that arises when you are trying to make an SVG visual component fully reusable.

One advantage of using nested <svg> elements whether in a single document or using the <image> element to import an external SVG file or visual component is the ability a separate <svg> element gives you to reposition a complex graphic on a Web page.

Consider the following adaptation from one of the logos I showed you in Chapter 9, "Creating Logos and Banner Ads." In Listing 15.2, you can see that I have used a nested <svg> element to contain the main rectangle, the group of lines, and the text. That graphic can be moved around the page but in only one dimension. You can move the graphic horizontally within another <svg> element, but if you want to move it vertically, you need to amend each y attribute. Although that's not a complex task, with just a little more planning, it is an avoidable one.

Listing 15.2 (RectLinesLogo05.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>  <defs>  <linearGradient id="MyGreenGradient"  gradientUnits="userSpaceOnUse"  x1="150" y1="150" x2="220" y2="50" >  <stop offset="10%" style="stop-color:#DDFFDD;  stop-opacity:0.8"/>  <stop offset="50%" style="stop-color:#99FF99; "/>  <stop offset="75%" style="stop-color:#DDFFDD"/>  </linearGradient>  <filter id="CombinedDropShadow" width="140%" y="-20%"  height="200%">  <feGaussianBlur in="SourceAlpha" stdDeviation="0.5"  result="ShadowOut" />  <feOffset in="ShadowOut" dx="2" dy="1" result="ShadowOnly" />  <feMerge>    <feMergeNode in="ShadowOnly"/>    <feMergeNode in="SourceGraphic"/>  </feMerge>  </filter>  </defs>  <svg x="30">  <rect x="5" y="55" width="300" height="80" rx="10" ry="10"  style="fill:white;  filter:url(#CombinedDropShadow)"/>  <rect x="10" y="60" width="295" height="2"  style="fill:url(#MyGreenGradient);  stroke:none;"/>  <rect x="10" y="65" width="295" height="2"  style="fill:url(#MyGreenGradient);  stroke:none;"/>  <rect x="10" y="70" width="295" height="2"  style="fill:url(#MyGreenGradient);  stroke:none;"/>  <rect x="10" y="75" width="295" height="2"  style="fill:url(#MyGreenGradient);  stroke:none;"/>  <rect x="10" y="80" width="295" height="2"  style="fill:url(#MyGreenGradient);  stroke:none;"/>  <rect x="10" y="85" width="295" height="2"  style="fill:url(#MyGreenGradient);  stroke:none;"/>  <rect x="10" y="90" width="295" height="2"  style="fill:url(#MyGreenGradient);  stroke:none;"/>  <rect x="10" y="95" width="295" height="2"  style="fill:url(#MyGreenGradient);  stroke:none;"/>  <rect x="10" y="100" width="295" height="2"  style="fill:url(#MyGreenGradient);  stroke:none;"/>  <rect x="10" y="105" width="295" height="2"  style="fill:url(#MyGreenGradient);  stroke:none;"/>  <rect x="10" y="110" width="295" height="2"  style="fill:url(#MyGreenGradient);  stroke:none;"/>  <rect x="10" y="115" width="295" height="2"  style="fill:url(#MyGreenGradient);  stroke:none;"/>  <rect x="10" y="120" width="295" height="2"  style="fill:url(#MyGreenGradient);  stroke:none;"/>  <rect x="10" y="125" width="295" height="2"  style="fill:url(#MyGreenGradient);  stroke:none;"/>  <rect x="10" y="130" width="295" height="2"  style="fill:url(#MyGreenGradient);  stroke:none;"/>  <text x="-300" y="110" style="font-family:'Times New Roman',  serif; font-size:48;  stroke:#339933; fill:white; filter:url(#CombinedDropShadow)">  <animate begin="1s" dur="2s" attributeName="x" from="-300"  to="30" fill="freeze"/>  SVGenius.com  </text>  </svg>  </svg> 

If you look at the y attribute of the nested <svg> element and the other elements in this code, you see that you can subtract 50 from each y attribute within the nested <svg> element and add 50 to the y attribute of the nested <svg> element, as shown here:

<svg x="30" y="50">  <rect x="5" y="5" width="300" height="80" rx="10" ry="10"  style="fill:white;  filter:url(#CombinedDropShadow)"/>  <rect x="10" y="10" width="295" height="2"  style="fill:url(#MyGreenGradient);  stroke:none;"/>  <rect x="10" y="15" width="295" height="2"  style="fill:url(#MyGreenGradient);  stroke:none;"/>  <rect x="10" y="20" width="295" height="2"  style="fill:url(#MyGreenGradient);  stroke:none;"/>  <rect x="10" y="25" width="295" height="2"  style="fill:url(#MyGreenGradient);  stroke:none;"/>  <rect x="10" y="30" width="295" height="2"  style="fill:url(#MyGreenGradient);  stroke:none;"/>  <rect x="10" y="35" width="295" height="2"  style="fill:url(#MyGreenGradient);  stroke:none;"/>  <rect x="10" y="40" width="295" height="2"  style="fill:url(#MyGreenGradient);  stroke:none;"/>  <rect x="10" y="45" width="295" height="2"  style="fill:url(#MyGreenGradient);  stroke:none;"/>  <rect x="10" y="50" width="295" height="2"  style="fill:url(#MyGreenGradient);  stroke:none;"/>  <rect x="10" y="55" width="295" height="2"  style="fill:url(#MyGreenGradient);  stroke:none;"/>  <rect x="10" y="60" width="295" height="2"  style="fill:url(#MyGreenGradient);  stroke:none;"/>  <rect x="10" y="65" width="295" height="2"  style="fill:url(#MyGreenGradient);  stroke:none;"/>  <rect x="10" y="70" width="295" height="2"  style="fill:url(#MyGreenGradient);  stroke:none;"/>  <rect x="10" y="75" width="295" height="2"  style="fill:url(#MyGreenGradient);  stroke:none;"/>  <rect x="10" y="80" width="295" height="2"  style="fill:url(#MyGreenGradient);  stroke:none;"/>  <text x="-300" y="60" style="font-family:'Times New Roman',  serif; font-size:48;  stroke:#339933; fill:white; filter:url(#CombinedDropShadow)">  <animate begin="1s" dur="2s" attributeName="x" from="-300"  to="30" fill="freeze"/>  SVGenius.com  </text>  </svg> 

After that is done, moving the graphic either vertically or horizontally is a straightforward process. You simply modify the value of the y or x attribute of the nested <svg> element, and the whole graphic can be relocated and the relative positions, including the animation, maintained.

As a generalized way of stating this concept, making the x and y attributes of elements within a potential visual component as close to zero as possible is helpful. Sometimes you might want to consciously leave a margin for some purpose, but the closer to zero the positioning attributes of the contained elements, the fuller control of positioning you have by using the x and y attributes of the outer <svg> element of the visual component. When that outer <svg> element becomes a nested <svg> element, positioning of the entire visual component is straightforward, depending simply on adjusting its x and y attributes.

Building a Portfolio of Visual Components

One of the issues that hits you as time passes and you build up a portfolio of SVG images is just where you can find that filter or animation you liked so much and that would be just right to make use of again.

Structuring a portfolio

I am working through this issue with my own collection of visual components. The fact that I, as you have seen, tend to make heavy use of nested <svg> elements has the advantage that I can break out those nested <svg> elements and simply copy them to separate files. Because they have an outer <svg> element, they are legal SVG document fragments and can stand alone in a file and be displayed by an SVG viewer.

I usually give visual components very long filenames, such as DiagonalGradientThreeStops01.svg or DiagonalGradientThreeStopsAnimated01.svg, which tells me at least a little about the nature of the visual component.

One of the more problematic areas, even when using very long filenames, is how best to store and use filters. Creating a nice filter can take quite a bit of effort, and yet it might contain multiple filters. I give those names such as FilterWhichDoesSomethingNice.svg. The visual effect is what I am most likely to remember them by, not any specific combination of SVG filter primitives.

Within each file, you can make use of the <desc> element to document important details of what the SVG does. Using the <desc> element, described in Chapter 2, is more convenient than using ordinary XML comments.

Backing up

I don't know how thorough you are about making backups of images or Web pages you create, but I suggest that you give serious thought to a backup strategy for your growing library of SVG visual components.

Those SVG visual components, properly used, are a significant asset for your graphics design activities, so it pays to take care of them. Think about how regularly you should back them up.

Of course, one side to this issue might make you less inclined to back up locally: You already have an off-site backup on the Web! All your SVG images on the Web are continuously accessible to you (barring server failure at your or your client's Web hosting company). I suggest that you don't rely solely on that and take active steps to store your visual components safely.

If you go on to build up your SVG skills, you can add to your library of SVG components all the more quickly. Chapter 16, "Building Your SVG Skills," looks at how you can build on your SVG skills.

 

CONTENTS


Designing SVG Web Graphics
Designing SVG Web Graphics
ISBN: 0735711666
EAN: 2147483647
Year: 2001
Pages: 26

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net