for the Scalable Vector Graphics (SVG) file format for the Web and Adobe ... There are a number of stand-alone viewers for SVG that can also be used [40] ...
Download SVG Tutorial and more Summaries Computer Graphics in PDF only on Docsity!
SVG Tutorial
David Duce *, Ivan Herman +, Bob Hopgood *
* Oxford Brookes University, + World Wide Web Consortium
Contents
° (^) 1. Introduction n 1.1 Images on the Web n 1.2 Supported Image Formats n 1.3 Images are not Computer Graphics n 1.4 Multimedia is not Computer Graphics ° 2. Early Vector Graphics on the Web n (^) 2.1 CGM n (^) 2.2 CGM on the Web n 2.3 WebCGM Profile n 2.4 WebCGM Viewers ° 3. SVG: An Introduction n 3.1 Scalable Vector Graphics n 3.2 An XML Application n (^) 3.3 Submissions to W3C n (^) 3.4 SVG: an XML Application n 3.5 Getting Started with SVG ° 4. Coordinates and Rendering n 4.1 Rectangles and Text n 4.2 Coordinates n (^) 4.3 Rendering Model n (^) 4.4 Rendering Attributes and Styling Properties n (^) 4.5 Following Examples ° 5. SVG Drawing Elements n 5.1 Path and Text n 5.2 Path n 5.3 Text n (^) 5.4 Basic Shapes ° (^) 6. Grouping n 6.1 Introduction n 6.2 Coordinate Transformations n 6.3 Clipping ° 7. Filling n 7.1 Fill Properties n (^) 7.2 Colour n (^) 7.3 Fill Rule n 7.4 Opacity n 7.5 Colour Gradients ° 8. Stroking n 8.1 Stroke Properties n 8.2 Width and Style n (^) 8.3 Line Termination and Joining ° 9. Text n 9.1 Rendering Text n 9.2 Font Properties n 9.3 Text Properties
-- ii -- ° 10. Animation n (^) 10.1 Simple Animation n (^) 10.2 How the Animation takes Place n (^) 10.3 Animation along a Path n 10.4 When the Animation takes Place ° 11. Linking and Templates n 11.1 Linking n 11.2 Symbols and their Use n (^) 11.3 Images n (^) 11.4 Maskings ° 12. Interaction n 12.1 Scripting and the DOM n 12.2 Interaction Events n 12.3 Interaction Methods ° 13. Filter Effects n (^) 13.1 Motivation n (^) 13.2 Filter Data Flow n 13.3 Filter Primitives ° 14. Current State and the Future n 14.1 Implementations n 14.2 Metadata n 14.3 Extensions to SVG
Appendices
° A. SVG Colours ° B. SVG Elements and their Attributes n B.1 Attribute Value Types n (^) B.2 SVG Elements Described in this Document n B.3 SVG Global Attributes n B.4 SVG Style Properties and Attributes n B.5 Filtering Elements n B.6 Font Elements n B.7 Other Elements ° C. References
Figure 1.1: Images versus Vector Graphics
The image formats all share many disadvantages that are serious obstacles to the development and adoption of new technologies on the Web. Some of the major problems are listed below.
Bandwidth Images are large. Improvements in network bandwidth have helped to hide this. Also image compression techniques have improved. Even so, images are a major bottleneck to accessing Web sites. This creates significant problems when designers want to follow their own style in creating new Web pages. Flexibility Images inherently have a fixed resolution. In consequence, an application destined to run on a range of PCs, PDAs and mobile phones is unable to adapt to the constraints of the device. Colour, resolution, aspect ratio and bandwidth often differ significantly between devices. Hyperlinking Hyperlinking is a fundamental requirement on the Web. However, to link to different places, dependent on where the user clicks on an image, is not simple. Early on, image maps were added to HTML. This allowed the coordinates of where the user clicked to be returned to the server where a program was run to determine which page to link to. Server side image maps are not efficient adding another round trip from client to server. The map is separate from the HTML page and is dependent on the server for translation. Different servers used different map file formats so that pages often could only be read by certain browsers. Client side image maps were added in HTML 3.0 and these allowed rectangular, elliptical or polygonal areas to be defined. Clicking on an area causes the link defined for that area to be taken. Creating image maps is cumbersome and is not related to the real objects being viewed but their image on the display. Animation and Interaction Many applications profit from the use of animation and interaction (cartography, CAD, remote teaching, etc). Image formats only provide crude animation limited to the sequential playback of a sequence of images combined into a single file. Interaction is limited to the use of image maps. Separation of Style from Content The same drawing in terms of meaning can be represented in many different ways dependent on the capabilities of the device. Dotted line on a mono display might be rendered as a different colour on a colour display. Images do not have the ability to make such changes.
Integration In the early days of the Web, an HTML page was transmitted across the Internet using the HTTP protocol and there was a 1-1 relationship between documents and downloads. Today, the Web is much more complex. Separating style and content meant that a style sheet might be transmitted as well as the Web page. The move to XML [6] allows appropriate markup for different information in the Web page. No longer is it necessary to force the HTML elements defined for textual documents to be used for other purposes. Mathematical markup [7], multimedia [8], and chemical markup, for example, each use their own XML application. Any computer graphics on the Web should be integrated with this model of the Web. In consequence, the transmission of images as a final form rendering of something that has semantic content is likely to decrease. The image formats will be used for their primary purpose of transmitting real-world images where the photograph is the content.
This tutorial will concentrate on the way 2D vector computer graphics is being made a more integral part of the Web, in particular through open as opposed to vendor specific standards.
1.4 Multimedia is not Computer Graphics
Just as images are not computer graphics so multimedia presentations are not computer graphics. That is not to say that combining a variety of resources to create a meaningful presentation does not have merit. It is just that the emphasis is on integration and timing rather that the graphical content.
For example, SMIL is an open standard whose main aim is integrating a set of disparate resources scattered across the Web into a synchronised multimedia integration. Many problems arise such as layout, timing and bandwidth. Such systems are not considered further in this paper which concentrates on 2D graphics system in use on the Web.
Proprietary multimedia systems also exist that at times give the impression of being 2D graphics file formats. A good example is Macromedia Flash. Here we have two problems. It is neither multimedia or computer graphics in the strict sense as far as the Web is concerned. The multimedia integration occurs external to the Web. As far as the web is concerned, there is not a great deal of difference between a Flash presentation downloaded to a browser and the playback of an MPG video. Both show images that change over time. Neither make use of the Web as a distributed resource or the special features of high quality 2D graphics. A tutorial on Flash would start with the basic principle of a timeline followed by animation relative to that timeline and would eventually come round to describing the computer graphics and other objects to be integrated and animated.
At the other end of the spectra are proprietary systems such as Adobe Illustrator and its associated proprietary file format which have a much closer affinity to vector graphics. However, Illustrator is more the creation tool for the production of the computer graphics. Adobe has been a significant supported for the Scalable Vector Graphics (SVG) file format for the Web and Adobe Illustrator performs well as the creator of such files. For these reasons, this paper will concentrate on the open file format standards for the Web, WebCGM and SVG.
These provide the basis for searching and linking within and between CGM pictures. An object may be the target of a link. Browsers are expected to move the object into view and scale it to fit into the viewport. If the object has a ViewContext attribute the rectangle defining the view context must be within the viewport.
Links from WebCGM objects are defined by linkURI elements that are modelled on the XLink facilities [13]. Objects may have multiple links. Links can be bi-directional. Linkage can be from places outside the CGM and links from the CGM can be to any destination defined by a URL. Following a link can display the new picture in a separate window, load the picture into the current frame, load it over the parent of the current frame or replace the current picture.
Figure 2.1: CGM Architecture
WebCGM is a reasonably full profile of CGM containing a rich set of graphics elements:
° (^) Polylines, disjoint polylines, polygons, polygon sets. ° Rectangles, circles, ellipses, circular and elliptical arcs, pie slices. ° Text: both the Restricted Text primitive of CGM (which defines its extent box) and the Append Text element (continuation of a text string with a change of attributes). ° (^) Closed Figure and Compound Line: allows complex paths to be defined as a sequence of other primitives. ° Polysymbol: placement of a sequence of symbols defined in the Symbol Library (another valid WebCGM metafile). ° Smooth curves: the smooth piece-wise cubic Bezier defined by CGM's Polybezier element. ° Cell Array and Tile Array allow PNG, and JPEG images to be integrated with the vector drawing.
Most of the line and fill attributes of CGM are included but only as INDIVIDUAL attributes. The bundled attribute functionality of CGM is omitted. Thus, WebCGM diagrams consider properties such as linestyle, color, fill types etc as content rather than styling.
The full set of CGM colour models is provided including sRGB and sRGB-alpha. International text is defined by selecting either Unicode UTF-8 or UTF-16.
2.4 WebCGM Viewers
Probably the most widely used Viewer is the Micrografx free ActiveCGM plug-in [14]. SDI has also released a CGM Plug-in [15] while Tech Illustrator has a TI/WebCGM Hotspot Plug-in module [16] to author hotspots for exporting to CGMs. There is good industrial support for WebCGM and it is widely used in the CAD and aerospace industries. A major interoperability demonstration took place at XML Open in Granada in May 1999.
A good source of further information on CGM is CGM Open [11], an organisation dedicated to open and interoperable standards for the exchange of graphical information. The W3C Web site is also a valuable source of news and reference information.
° There can only be one outer element (the root element) that encloses the complete drawing definition. ° Every start tag must have a correctly nested end tag ° The form of the start and end tags must be identical. If the start tag is upper case so must be the end tag. ° Attributes must be enclosed in quotes (either single or double)
If the content of the element is null, a shorthand can be used:
The slash before the closing > in the second line indicates that the element does not have any content. Effectively, all the content is encapsulated in the name of the element and its attributes. The two examples of the rect element given above are equivalent.
3.3 Submissions to W3C
The question now arose: could XML markup be used to express vector graphics? In 1998, there were four Submissions to W3C proposing an XML-based vector graphics markup language for the Web. In order, these were:
° Web Schematics [17] : similar to the troff pic language, it defined objects with anchor points that could be composed into pictures. This submission was made by Bob hopgood and david Duce of the Rutherford Appleton Laboratory and Vincent Quint of INRIA. ° (^) Precision Graphics Markup Language (PGML) [18] : a lower level language that could be described as an XML-based version of PostScript. ° (^) Vector Markup Language (VML) [19] : just as PGML has a relationship to Postscript, VML had a similar relationship to PowerPoint. ° DrawML [20] : a constraint-based higher level language that allowed the drawing to adjust to the content. Changing the text in a box would increase the size of the box and adjust the box surrounding that box etc.
In retrospect, it is surprising that the CGM community did not put forward a proposal for a CGM Profile defined using XML notation.
These submissions resulted in a Working Group being formed to define a single language for vector drawings on the Web called Scalable Vector Graphics (SVG) [21]. The Candidate Recommendation stage within the W3C process exists just before the full Recommendation stage and is to allow trial implementations to test the quality of the specification. The strong interest in SVG meant that there were implementations of the Candidate Recommendation early in 2001 even though the Candidate Recommendation was not issued until November 2000. SVG became a W3C Recommendation in September 2001. The W3C Recommendation is the subject of this Tutorial.
Of the four Submissions, PGML probably had the most impact on the functionality of SVG. Even so, SVG has evolved into a standard significantly different from all of the initial Submissions.
3.4 SVG: an Application of XML
SVG is an application of XML. This has the benefit that the overall syntactic structure of SVG is known and parsers exist to handle it. It also means that SVG can benefit from the other activities within W3C concerned with the XML Family of standards. In many cases, this is a strong plus but occasionally the constraints imposed by the other standards will mean that the functionality provided within SVG may be less elegant or have different characteristics from the form it would have taken if it had not been part of the XML Family. However the advantages far outweigh the disadvantages. Some examples of the influences on SVG are:
° Cascading Style Sheets (CSS) [22] : CSS is used to separate style from content initially in an HTML document. A CSS style sheet consists of a set of commands that specify the styling to be associated with a specific element. As CSS is not restricted to HTML elements, it can also be used to style an XML application. ° Namespaces in XML [23] : with many XML applications emerging, it is more likely that several will be used together in which case it is necessary to identify which elements belong to which application. XML achieves this by defining a prefix that identifies the namespace. For example, <svg:text> defines the start of the SVG text element. The prefix may be anything the user wants it to be as long as the appropriate namespace declaration identifies the application. ° XML Linking Language (XLink) [13] : as all XML applications are likely to require hyperlinking, a separate Recommendation, XLink, defines a flexible hyperlinking mechanism. Rather than define its own, SVG is able to use the XLink hyperlinking functionality via the XLink namespace. ° XSL Transformations (XSLT) [24] : XSLT defines a transformation functionality to be applied to XML documents. CSS effectively performs a single pass through an HTML document transforming the elements by defining their styling. XSLT provides similar functionality in terms of styling but also allows complex transformations of the XML documents. For SVG, higher- level functionality can be realised by defining an XSLT transformation down into SVG. In consequence, SVG need not define such functionality within the core version of SVG. ° (^) Synchronised Multimedia Integration Language (SMIL) [8] : the SVG Working Group included animation functionality within its design objectives. SMIL was also considering similar functionality for multi-media presentations. The two Working Groups have, therefore, produced a single suite of animation functionality that can be used by both SMIL and SVG. ° (^) Document Object Model (DOM) [25] : The DOM provides a standard method of interacting with an XML application. In consequence, SVG can use this functionality as the basis for interaction between a user and an SVG drawing.
3.5 Getting Started with SVG
Figure 3.1 shows the result that an SVG-enabled browser or viewer would make of the SVG document defined below.
The initial XML declaration and the Document Type Declaration for SVG 1.0 can be omitted and future examples will do this.
4. Coordinates and Rendering
° (^) 4.1 Rectangles and Text ° (^) 4.2 Coordinates ° 4.3 Rendering Model ° 4.4 Rendering Attributes and Styling Properties ° 4.5 Following Examples
4.1 Rectangles and Text
It is difficult to talk about either coordinates or rendering in a vacuum so we first need to specify two SVG drawing elements so that we can illustrate the points being made. The two we will use for the moment are text and rect. We will come back and talk about the drawing primitives in more detail later.
The rect element has a large number of attributes but we shall consider just a few for the moment:
Abracadabra
Figure 4.1: SVG Coordinates
The first two attributes, x and y , of the rect element define the origin of the rectangle. The second two define its width and height. The rx and ry attributes define the radius to be used in rounding the corners. Finally, the style attribute defines its rendering. For the text element, the first two attributes, x and y , define the origin of the text string while the third attribute defines the rendering.
The first thing to notice is that the Y-axis in SVG points downwards. This can be a source of error when defining SVG diagrams so take extra care to remember this fact! The X-axis does go from left to right. The origin of the text by default is at the left-hand end of the text on the baseline. By convention the height of the text when used in an HTML page is the same as the medium size text in the HTML page. The font used is at the choice of the browser and plug-in.
4.2 Coordinates
All graphics elements are rendered conceptually on to an SVG infinite canvas. A viewport can be established that defines a finite rectangular region within the canvas. Rendering uses the painter's model; elements later in the document are rendered on top of the preceding ones.
The viewport is specified by attributes of the svg element. Explicit width and height attributes can be set as in the example in Section 3.5. An alternative is to use the viewBox attribute which specifies the lower and upper bounds of the viewport in bot the X and Y directions.
The coordinate system used by the SVG diagram as a whole, when displayed as part of a web page, is a negotiation between the SVG plug-in, what the user would like and the real estate available from the browser.
A complete SVG document containing the drawing defined above could be:
This could be embedded in an HTML page by the object element:
This situation is reasonably straightforward. The svg element has a viewBox attribute that requests that the area from (0,0) to (500,300) in user coordinates is visible in the browser window. The object element requests an area 500 wide and 300 high to put the diagram in. As no units are specified, the assumption is that the units requested are the browser's view of what a pixel width is. Assuming this area is available, the diagram will appear 500 pixels wide and 300 pixels high. A unit in the diagram will be equivalent to a pixel as specified by the browser.
The two approaches (width/height and viewport) are subtly different. In the first example using width and height, no units have been specified so pixels are the assumed coordinate system. The viewport required is 320 pixels wide and 220 pixels high. The local user coordinate system for the duck is also set to be 320 by 220 with one pixel equal to one local user coordinate. In the second case, the local user coordinate is set to 500 wide and 300 high and this is to be mapped to fit in the viewport. A small viewport would have the mapping from user coordinate to pixels different from a large viewport. If the aspect ratio of the viewport is different from that of the viewBox then various options are provided as to how the user would like the mapping to take place.
In SVG, if no units are specified the assumption is that the coordinates are defined in the local coordinate system. However, in defining the viewport size and in specifying the drawing, the complete set of units defined in CSS are available to the user (em, ex, px, pt, pc, cm, mm, in, %).
If the drawing is to be displayed as part of a Web page, a complex negotiation takes place between the SVG plug-in and the browser taking into account any constraints imposed by the user on inserting the drawing in the Web page or by the styling applied to the page as a whole. As a result of this negotiation, part of the image could be clipped, scaled or distorted, depending on how the constraints are resolved. The user can control the effect somewhat through a preserveAspectRatio attribute and by specifying whether all the drawing must be visible or whether some parts can be obscured.
We shall assume in our examples that the size of the SVG diagram is defined by the viewBox attribute and that the object element achieves a mapping of this into an equivalent area on the web page. There are other ways of defining the size of the SVG diagram and it can be specified in units other than pixels. The negotiation can be quite complex if the area required is unavailable or the units are real world ones (centimetres, say) and if the aspect ratio of the requested area is different from the area used by the SVG document.
The use of style sheets is not limited to HTML; style sheets may also be used with XML documents in a similar way.
There are some parallels in the development of style control in computer graphics. In early graphics systems it was commonplace to control the visual appearance of graphical output primitives by attributes, for example to control properties such as linestyle, line width, colour, text font, etc. Attributes were typically set modally, for example by a set_colour function, the value remaining in force until a new value was set. If a particular attribute value was not supported by a particular device, it was permissible to simulate the effect of that value using other values for that attribute, other attributes and other primitives. A particular dashed linestyle could, for example, be simulated by a sequence of individual lines. The essence of this approach was that the application provided a precise specification of the required appearance and the system did its best to achieve the specified effect.
During the development of the Graphical Kernel System (GKS) it became clear that visual appearance could be either styling or an intrinsic part of the information to be presented. In architecture, different patterns denote different types of building material in a precise way; indiscriminate substitution may result in a house of sand rather than of stone! At other times, patterns are used purely to achieve differentiation between different types of object, the precise pattern used is unimportant, what matters is that pattern A should be visually distinguishable from pattern B. GKS [26] distinguished between global attributes which have the same value on all devices and attributes defined indirectly by a pointer into a table located on the device. The attribute values in the table could be different for different devices. Some attributes were always specified globally while others could be defined globally or indirectly depending on the application usage.
SVG is defined as an XML language and makes use of the styling functionality provided by CSS for XML documents. However, as hinted at above, styling for graphics is potentially more complex than for text (or at least more complex than the styling model for Web documents). Is colour in graphics, for example, style or content? If colour is used on a map to differentiate different countries, it is probably style. What is important is that the colour of one country should be distinguishable from that of another. Styling can be very valuable in this situation: the best choice of colour might depend on the context in which the map is used, specifying colour through the style mechanism makes it straightforward to change colours from one context to another.
However colour is not always style. The colour chosen in a logo, or in an artistic image, or in the precise representation of real world objects is inherently a part of the content of the picture. In GKS: terms [27], colour here is an attribute completely defined in the NDC picture, to be rendered exactly (so far as is possible) in every view of the picture. Changing colour through a style sheet mechanism in such a picture in a Web document would be fundamentally wrong.
These cases: colour as style and colour as an intrinsic property of a primitive, are recognised in SVG and two different mechanisms for setting visual attributes are provided. One method is to set rendering attributes directly. For example:
This defines two rectangles, the first is yellow with a black border; the second is hollow with a red border.
The second method using styling is illustrated by:
...
This achieves the same visual result as the first approach. The "style" element encloses a style sheet expressed in the CSS syntax. (The CDATA annotation is used in order to escape the style language from the XML syntax checker.) Two styles are defined, the first for rectangles in general (filled in yellow with a black border) and a second for rectangles belonging to the class "different" defining rectangles with a red border and hollow interior.
The same effect could be achieved by defining an external sheet in the file mystyle.css as:
rect {stroke:black; fill:yellow} rect.different {stroke:red; fill:none}
and attaching it to the SVG document by:
Style can also be associated directly with an element through the style attribute. The example above could also be written:
SVG allows pictures to have arbitrary hierarchical structure. CSS provides powerful mechanisms for controlling appearance, both on the basis of the values of attributes (usually the class attribute, but other attributes could be used also) and the actual structure of the SVG element tree. It is also possible to write:
rect [class ~="different"] {stroke:red; fill:none}
which would select rectangles whose class attribute contains the value different in a set of space separated class attribute values. The "." notation introduced earlier in fact corresponds to the "~=" construct. A more complex example is shown below.
One of the important concepts in CSS is the notion of cascade. Three different types of style sheet can be associated with a document: author, user and user agent. The author of a document can supply style information, so can the user and so can the user agent (usually a browser). In general, style sheets from these three sources may overlap in the styling they specify for a particular element (indeed there may be overlap from within a single style sheet - there is an example of this in Figure 4.4) and so the notion of cascade is introduced to define the effect. In essence, weights are assigned to each style rule and when several rules apply, the one with the greatest weight takes precedence. The details are quite involved and go beyond the scope of this paper. The interested reader is referred to the CSS2 specification [22]. One of the consequences though of this general mechanism is that presentation attributes attached to SVG elements have lower priority than other CSS style rules specified in author style sheets or style attributes. SVG and CSS do not have the equivalent of the GKS Aspect Source Flags [26], so there is no general way to ensure that the analogues of individual attribute specification (presentation attributes) will actually apply in all contexts in which SVG is used. From a graphics perspective this might be considered unfortunate, but it is the price paid for embedding graphics in a context where different priorities normally pertain.
SVG is now looking at the requirements of mobile devices. One of the problems that has arisen is that for some devices it would be useful if the attributes could be tailored to the particular device. Zooming in on an SVG diagram using a mobile phone soon results in a single line covering the whole display. One option being considered by the Working Group is the possibility of attributes being defined indirectly with the values pointed at being set differently on different devices. So it is possible that the final attribute model for SVG will be quite similar to the one used in GKS.
Recall that HTML is a markup language for marking up the content of a textual document. The styling of that document is achieved by defining the style to be applied to each of the markup elements. For example, the element produces justified text, the element is bold and in red etc. Similarly, SVG defines the content of a diagram which may be styled in different ways. However, in graphics it is less clear what is style and what is content. For example, a pie chart might use colours to differentiate between individual segments. As long as it provides that differentiation, the specific colour chosen is normally not very relevant. On the other hand, if the diagram depicts a traffic light, interchanging the area to be drawn in green with the one in red would not be a good idea. This applies to most of the rendering attributes in SVG. Consequently the decision was made to allow all the rendering attributes to either be regarded as styling or as an integral part of the content of the diagram.
The use of styling is an extension of the use of styling in HTML. Styling can be achieved by adding a style element to the SVG file:
In this example, the first rectangle will be drawn in yellow with a black boundary whereas the second will be drawn with a red boundary and no internal fill as it belongs to the class different which has a more precise styling than rectangles in general. The stylesheet is enclosed within a CDATA construct to ensure that XML does not do any processing on the style rules. The same effect could be achieved by defining an external sheet in the file mystyle.css as:
rect {stroke:black;fill:yellow} rect.different {stroke:red; fill:none}
and attaching it to the SVG document by:
Finally, each element may use the style attribute directly:
The rules of precedence between linking to an external style sheet, embedding and importing style sheets, attaching styling to an element and user defined style sheets are the same as for CSS when used with HTML.
The alternative method of controlling the rendering of an element is to use the rendering attributes directly:
Each property that can be defined as part of the style attribute associated with the element can also be defined as a separate attribute. The local effect is the same in both cases. Rather than switch between the two approaches, in this Primer we will define all the local and global rendering via styling. Readers should be aware that they have the choice. A good basis for making a global choice is to use styling when the rendering is not content and use the individual attributes when the rendering is part of the content. Mixing the two does not give the effect that a graphics programmer might anticipate. If you use a rendering attribute, it has lower precedence than any styling introduced by a style sheet. In consequence, if you use rendering attributes do not use style sheets at all.
4.5 Following Examples
To avoid a great deal of duplication, the following examples are assumed to have an outer svg element as follows:
The title element is normally added straight after the svg element and it may be made available to the user by the browser. Similarly, the desc element can be used to provide comments throughout a document. Normally it is the first element after a g element.
