This specification defines the features and syntax for Scalable Vector Graphics (SVG) Tiny, Version 1.2, a modularized language for describing two-dimensional vector and mixed vector/raster graphics in XML. SVG Tiny 1.2 is the baseline profile of SVG, implementable on a range of devices from cellphones and PDAs to desktop and laptop computers, and is the core of SVG 1.2. Other SVG 1.2 specifications will extend this functionality to form supersets (for example, SVG 1.2 Full).

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is the 10 August 2006 Candidate Recommendation of SVG Tiny 1.2. W3C publishes a Candidate Recommendation to indicate that the document is believed to be stable and to encourage implementation by the developer community. The SVG Working Group expects to request that the Director advance this document to Proposed Recommendation once the Working Group has demonstrated at least two interoperable implementations for each test in the SVG Tiny 1.2 test suite; furthermore, at least one of the passing implementations must be on a mobile platform. The SVG Working Group, working closely with the developer community, expects to show these implementations by January 2007. This estimate is based on the Working Group's preliminary implementation report. The Working Group expects to revise this report over the course of the implementation period. The Working Group does not plan to request to advance to Proposed Recommendation prior to 10 November 2006.

This is a W3C Candidate Recommendation. The third Last Call Working Draft for this specification resulted in a number of Last Call comments which have all been addressed by the SVG Working Group; a list of all Last Call comments can be found in the Last Call Comments List. The list of changes made since the last public Working Draft is available in Appendix T.

The behavior when a fragment identifier contains a bare ID and does not contain a view specification has been modified compared to SVG 1.1. It is believed that the corrected behavior is more intuitive (bring the object with the given ID into view, panning and zooming out if necessary); that the old behavior was counter-intuitive; and that this change is welcomed by users and implementors. However, following the CR transition call, this feature was marked as "at risk" and, if not interoperably implemented by the end of the CR period, will be removed and the old behavior will be reinstated.

Please send comments to www-svg@w3.org, the public email list for issues related to SVG. This list is archived and acceptance of this archiving policy is requested automatically upon first post. To subscribe to this list send an email to www-svg-request@w3.org with the word "subscribe" in the subject line.

This document has been produced by the SVG Working Group as part of the W3C Graphics Activity, following the procedures set out for the W3C Process. The authors of this document are listed at the end in the Author List section.

Publication as a Candidate Recommendation does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Available languages

The authors of the SVG Tiny 1.2 specification are the people who participated in the SVG Working Group as members or alternates.

Acknowledgments

The SVG Working Group would like to acknowledge the many people outside of the SVG Working Group who help with the process of developing the SVG specification. These people are too numerous to list individually. They include but are not limited to the early implementers of the SVG languages (including viewers, authoring tools, and server-side transcoders), developers of SVG content, people who have contributed on the www-svg@w3.org and svg-developers@yahoogroups.com email lists, other Working Groups at the W3C, and the W3C Team. SVG is truly a cooperative effort between the SVG Working Group, the rest of the W3C, and the public and benefits greatly from the pioneering work of early implementers and content developers, feedback from the public.

1 Introduction

1.1 About SVG
1.2 SVG Tiny 1.2
- 1.2.1 Profiling the SVG specification
1.3 Defining an SVG Tiny 1.2 document
1.4 SVG MIME type, file name extension and Macintosh file type
1.5 Compatibility with other standards efforts
1.6 Definitions
1.7 How to reference this specification

1.1 About SVG

SVG is a language for describing two-dimensional graphics in XML [XML10, XML11]. SVG allows for three types of graphic objects: vector graphic shapes (e.g., paths consisting of straight lines and curves), multimedia (such as raster images and video) and text. Graphical objects can be grouped, styled, transformed and composited into previously rendered objects.

SVG documents can be interactive and dynamic. Animations can be defined and triggered either declaratively (i.e., by embedding SVG animation elements in SVG content) or via scripting.

Sophisticated applications of SVG are possible by use of a supplemental scripting language which accesses the SVG Micro Document Object Model (uDOM), which provides complete access to all elements, attributes and properties. A rich set of event handlers can be assigned to any SVG graphical object. Because of its compatibility and leveraging of other Web standards, features like scripting can be done on XHTML and SVG elements simultaneously within the same Web page.

SVG is a language for rich graphical content. For accessibility reasons, if there is an original source document containing higher-level structure and semantics, it is recommended that the higher-level information be made available somehow, either by making the original source document available, or making an alternative version available in a format which conveys the higher-level information, or by using SVG's facilities to include the higher-level information within the SVG content. For suggested techniques in achieving greater accessibility, see Accessibility.

It is believed that this specification is in accordance with the Web Architecture principles as described in Architecture of the World Wide Web [AWWW].

1.2 SVG Tiny 1.2

Industry demand, overwhelming support in the SVG working group and requests from the SVG developer community established the need for some form of SVG suited to displaying vector graphics on small devices. Moreover, the mission statement of SVG 1.0 specifically addressed small devices as a target area for vector graphics display. In order to meet these demands the SVG Working Group created a profile specification that was suitable for use on mobile devices as well as on desktops. The Mobile SVG Profiles specification [SVGM11] (also known as SVG Mobile 1.1) addressed that requirement and defined two profiles to deal with the variety of mobile devices having different characteristics in terms of CPU speed, memory size, and color support. The SVG Mobile 1.1 specification defined SVG Tiny (SVGT) 1.1, suitable for highly restricted mobile devices; it also defined a second profile, SVG Basic (SVGB) 1.1, targeted for higher level mobile devices. The major difference between SVG Tiny 1.1 and SVG Basic 1.1 was the absence of scripting and styling in SVG 1.1 Tiny, and thus any requirement to maintain a Document Object Model (DOM). This saved a substantial amount of memory in most implementations.

Experience with SVG Tiny 1.1, which was widely adopted in the industry and shipped as standard on a variety of cellphones, indicated that the profile was a little too restrictive in some areas. Features from SVG 1.1 such as gradients and opacity were seen to have substantial value for creating attractive content, and were shown to be implementable on cellphones. There was also considerable interest in adding audio and video capabilities, building on the SMIL support in SVG Tiny 1.1.

Advances such as DOM Level 3, which introduces namespace support and value normalization, prompted a second look at the use of programming languages and scripting with SVG Tiny. In conjunction with the Java JSR 226 group [JSR226], a lightweight interface called the microDOM, or uDOM, was developed. This could be, but need not be, implemented on top of DOM Level 3. With this advance, lightweight programmatic control of SVG (for example, for games or user interfaces) and use with scripting languages, became feasible on the whole range of platforms from cellphones through to desktops. In consequence, there is only a single Mobile profile for SVG 1.2: SVG Tiny 1.2.

This specification defines the features and syntax for Scalable Vector Graphics (SVG) Tiny 1.2, the core specification and baseline profile of SVG 1.2. Other SVG specifications will extend this baseline functionality to create supersets (for example, SVG 1.2 Full). The SVG Tiny 1.2 specification adds to SVG Tiny 1.1 features requested by SVG authors, implementors and users; SVG Tiny 1.2 is a superset of SVG Tiny 1.1.

1.2.1 Profiling the SVG specification

The Tiny profile of SVG 1.2 consists of all of the features defined within this specification. As a baseline specification, it is possible for: superset profiles (e.g., SVG Full 1.2) which include all of the Tiny profile but add other features to the baseline; subset profiles; and special-purpose profiles which incorporate some modules from this specification in combination with other features as needed to meet particular industry requirements.

When applied to conformance, the term "SVG Tiny 1.2" refers to the Tiny profile of SVG 1.2 defined by this specification. If an implementation does not implement the Tiny profile completely, the UA's conformance claims must state either the profile to which it conforms and/or the specific set of features it implements.

1.3 Defining an SVG Tiny 1.2 document

SVG Tiny 1.2 is a backwards compatible upgrade to SVG Tiny 1.1 [SVGM11]. Backwards compatible means that conformant SVG Tiny 1.1 content will render the same in conformant SVG Tiny 1.2 user agents as it did in conformant SVG Tiny 1.1 user agents. A few key differences from SVG Tiny 1.1 should be noted:

The value of the 'version' attribute on the rootmost 'svg' element should be "1.2". See the discussion of version control in the Implementation Requirements appendix for details.
There is no DTD for SVG 1.2, and therefore no need to specify the DOCTYPE for an SVG 1.2 document (unless it is desired to use the internal DTD subset ([XML10], section 2.8, and [XML11], section 2.8), for purposes of entity definitions for example). Instead, identification is by the SVG namespace, plus the 'version' and 'baseProfile' attributes. In SVG Tiny 1.2, validation can be performed using the RelaxNG schema.

The namespace for SVG Tiny 1.2 is the same as that of SVG 1.0 and 1.1, http://www.w3.org/2000/svg and is mutable [NSState]; names may be added over time by the W3C SVG Working Group by publication in W3C Technical Reports.

Here is an example of an SVG Tiny 1.2 document:

Example: 01_01.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     viewBox="0 0 30 30">
  <desc>Example SVG file</desc>
  <rect x="10" y="10" width="10" height="10" fill="red"/>
</svg>

Here is an example of defining an entity in the internal DTD subset. Note that in XML, there is no requirement to fetch the external DTD subset and so relying on an external subset reduces interoperability. Also note that the SVG Working Group does not provide a normative DTD for SVG Tiny 1.2 but instead provides a normative RelaxNG schema.

Example: entity.svg

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg [
    <!ENTITY Smile "
    <rect x='.5' y='.5' width='29' height='39' fill='black' stroke='red'/>
    <g transform='translate(0, 5)'>
    <circle cx='15' cy='15' r='10' fill='yellow'/>
    <circle cx='12' cy='12' r='1.5' fill='black'/>
    <circle cx='17' cy='12' r='1.5' fill='black'/>
    <path d='M 10 19 L 15 23 20 19' stroke='black' stroke-width='2'/>
    </g>
    ">
    ]>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny">
  <title>Smiley face</title>
  <desc>
    This example shows the use of an entity defined in the
    internal DTD subset. Note that there is no external DTD subset
    for SVG Tiny 1.2, and thus no formal public identifier.
  </desc>
  &Smile; 
</svg>

1.4 SVG MIME type, file name extension and Macintosh file type

The MIME type for SVG is "image/svg+xml" (see Media type registration for image/svg+xml).

It is recommended that SVG files have the extension ".svg" (all lowercase) on all platforms. It is recommended that gzip-compressed SVG files have the extension ".svgz" (all lowercase) on all platforms [RFC1952].

It is recommended that SVG files stored on Macintosh HFS file systems be given a file type of "svg " (all lowercase, with a space character as the fourth letter). It is recommended that gzip-compressed SVG files stored on Macintosh HFS file systems be given a file type of "svgz" (all lowercase).

(See Conformance Criteria for more information about gzip-compressed SVG files transmitted over HTTP.)

1.5 Compatibility with other standards efforts

SVG Tiny 1.2 leverages and integrates with other W3C specifications and standards efforts. By leveraging and conforming to other standards, SVG becomes more powerful and makes it easier for users to learn how to incorporate SVG into their Web sites.

The following describes some of the ways in which SVG maintains compatibility with, leverages and integrates with other W3C efforts:

SVG Tiny 1.2 is an application of XML and is compatible with both the Extensible Markup Language (XML) 1.1 [XML11] and Extensible Markup Language (XML) 1.0 (Third Edition) [XML10] Recommendations.
SVG Tiny 1.2 is compatible with both the Namespaces in XML 1.0 [XML-NS10] and the Namespaces in XML 1.1 [XML-NS] Recommendations.
SVG Tiny 1.2 utilizes XML Linking Language (XLink) [XLINK10] for IRI referencing and requires support for base IRI specifications defined in XML Base [XML-BASE].
SVG Tiny 1.2 uses the 'xml:id' attribute as defined in xml:id Version 1.0 [XMLID].
SVG Tiny 1.2 content can be generated using XSL Transformations (XSLT) Version 1.0 [XSLT]. (See Styling with XSL.)
SVG Tiny 1.2 supports formatting properties drawn from CSS and XSL. (See SVG's styling properties).
SVG Tiny 1.2 includes a compatible subset of the Document Object Model (DOM) and supports many of the facilities described in Document Object Model (DOM) Level 3 Core [DOM3], including namespace support and event handling.
SVG Tiny 1.2 incorporates some features from the Synchronized Multimedia Integration Language (SMIL) 2.1 Specification [SMIL21], including the 'prefetch' 'switch' element, the 'systemLanguage' attribute, animation features (see Animation) and the ability to reference audio and video media (see Multimedia). SVG's animation features incorporate and extend the general-purpose XML animation capabilities described in SMIL 2.1. In addition, SVG Tiny 1.2 has been designed to allow SMIL 2.1 to use animated or static SVG content as media components.
SVG is compatible with W3C work on internationalization. References (W3C and otherwise) include: The Unicode Standard [UNICODE] and the Character Model for the World Wide Web 1.0 [CHARMOD]. (See Internationalization Support.)
SVG is compatible with W3C work on Web Accessibility [WAI]. (See Accessibility Support).

In environments which support the Document Object Model (DOM) Core [DOM3] for other XML grammars (e.g., XHTML 1.0 [XHTML]) and which also support SVG and the SVG DOM, a single scripting approach can be used simultaneously for both XML documents and SVG graphics, in which case interactive and dynamic effects will be possible on multiple XML namespaces using the same set of scripts.

1.6 Definitions

When used in this specification, terms have the meanings assigned in this section.

after-edge

Defined in the XSL Area Model ([XSL], section 4.2.3).

animation element

Using the various animation elements, you can define motion paths, fade-in or fade-out effects, and allow objects to grow, shrink, spin or change color. The following five elements are animation elements: 'animate', 'animateColor', 'animateMotion', 'animateTransform' and 'set'. Animation elements are further described in Animation elements.

basic shape

Standard shapes which are predefined in SVG as a convenience for common graphical operations. Specifically, any instance of the following elements: 'circle', 'ellipse', 'line', 'polygon', 'polyline' and 'rect'.

before-edge

Defined in the XSL Area Model ([XSL], section 4.2.3).

canvas

A surface onto which graphics elements are drawn, which can be real physical media such as a display or paper or an abstract surface such as a allocated region of computer memory. See the discussion of the SVG canvas in the Coordinate Systems, Transformations and Units chapter.

bounding box

The bounding box (or "bbox") of an element is the tightest fitting rectangle aligned with the axes of that element's user coordinate system that entirely encloses it and its descendants. The bounding box must be computed exclusive of any values for the 'fill', 'stroke', 'stroke-width', 'opacity' or 'visibility' properties. For curved shapes, the bounding box must enclose all portions of the shape along the edge, not just end points, but must not include control points for curves that are not within the shape itself.

Example bbox01 shows one shape (a 'path' element with a quadratic Bézier curve) with three possible bounding boxes, only the leftmost of which is correct.

Example: bbox01.svg

<svg xmlns='http://www.w3.org/2000/svg'
     xmlns:xlink='http://www.w3.org/1999/xlink'
     version='1.1' width='380px' height='120px' viewBox='0 0 380 120'>

  <title>Bounding Box of a Path</title>
  <desc>
    Illustration of one shape (a 'path' element with a quadratic Bézier) with
    three bounding boxes, only one of which is correct.
  </desc>

  <defs>
    <g id='shape'>
      <line x1='120' y1='50' x2='70' y2='10' stroke='#888'/>
      <line x1='20' y1='50' x2='70' y2='10' stroke='#888'/>
      <path stroke-width='2' fill='rgb(173, 216, 230)' stroke='none' fill-rule='evenodd'
            d='M20,50
               L35,100
               H120
               V50
               Q70,10 20,50'/>
      <circle cx='120' cy='50' r='3' fill='none' stroke='#888'/>
      <circle cx='20' cy='50' r='3' fill='none' stroke='#888'/>
      <circle cx='70' cy='10' r='3' fill='#888' stroke='none'/>
    </g>
  </defs>

  <g text-anchor='middle'>
    <g>
      <title>Correct Bounding Box</title>
      <use xlink:href='#shape'/>
      <rect x='20' y='30' width='100' height='70'
            fill='none' stroke='green' stroke-dasharray='2' stroke-linecap='round'/>
      <text x='70' y='115'>Correct</text>
    </g>

    <g transform='translate(120)'>
      <title>Incorrect Bounding Box</title>
      <desc>Bounding box does not encompass entire shape.</desc>
      <use xlink:href='#shape'/>
      <rect x='20' y='50' width='100' height='50'
            fill='none' stroke='red' stroke-dasharray='2' stroke-linecap='round'/>
      <text x='70' y='115'>Incorrect</text>
    </g>

    <g transform='translate(240)'>
      <title>Incorrect Bounding Box</title>
      <desc>Bounding box includes control points outside shape.</desc>
      <use xlink:href='#shape'/>
      <rect x='20' y='10' width='100' height='90'
            fill='none' stroke='red' stroke-dasharray='2' stroke-linecap='round'/>
      <text x='70' y='115'>Incorrect</text>
    </g>
  </g>
</svg>

The bounding box must be applicable for any rendering element with positive 'width' or 'height' attributes and with a 'display' property other than none, as well as for any container element that may contain such elements. Elements which do not partake in the rendering tree (e.g. elements in a 'defs' element, elements whose 'display' is none, etc.), and which have no child elements that partake in the rendering tree (e.g. 'g' elements with no children), shall not contribute to the bounding box of the parent element, but must return a bounding box for the sake of calculating their own geometry.

Elements and document fragments which derive from SVGLocatable but are not in the rendering tree, such as those in a 'defs' element or those which have been been created but not yet inserted into the DOM, must still have a bounding box. The geometry of elements outside the rendering tree must take into account only those properties and values (such as 'font-size') which are specified within that element or document fragment, or which have a lacuna value or an implementation-defined value.

For text content elements, for the purposes of the bounding box calculation, each glyph must be treated as a separate graphics element. The calculations must assume that all glyphs occupy the full glyph cell. For example, for horizontal text, the calculations must assume that each glyph extends vertically to the full ascent and descent values for the font. An exception to this is the 'textArea', which uses that element's geometry for the bounding box calculation.

Because declarative or scripted animation can change the shape, size, and position of an element, the bounding box is mutable. Thus, the bounding box for an element shall reflect the current values for the element at the snapshot in time at which the bounding box is requested, whether through a script call or as part of a declarative or linking syntax.

Note that an element which has either or both of 'width' and 'height' of '0' (such as a vertical or horizontal line, or a 'rect' element with an unspecified 'width' or 'height') still has a bounding box, with a positive value for the positive dimension, or with '0' for both 'width' and 'height' if no positive dimension is specified. Similarly, subpaths segments of a 'path' element with '0' 'width' and 'height' must be included in that element's geometry for the sake of the bounding box. Note also that elements which do not derive from SVGLocatable (such as gradient elements) do not have a bounding box, thus have no interface to request a bounding box.

Elements in the rendering tree which reference unresolved resources shall still have a bounding box, defined by the position and dimensions specified in their attributes, or by the lacuna value for those attributes if no values are supplied. For example, the element <use xlink:href="#bad" x="10" y="10"/> would have a bounding box with an 'x' and 'y' of '10' and a 'width' and 'height' of '0'.

For a formal definition of bounding boxes, see [FOLEY-VANDAM], section 15.2.3, Extents and Bounding Volumes. For further details, see bounding box calculations, the effects of visibility on bounding box, object bounding box units and text elements, and fragment identifiers.

conditional processing attribute

A conditional processing attribute is one of the five attributes that may appear on most SVG elements to control whether or not that element will be processed. Those attributes are 'requiredExtensions', 'requiredFeatures', 'requiredFonts', 'requiredFormats' and 'systemLanguage'.

container element

An element which can have graphics elements and other container elements as child elements. Specifically, the following elements are container elements: 'a', 'defs', 'g', 'svg' and 'switch'.

current SVG document fragment

The current SVG document fragment of an element is the XML document sub-tree such that:

The sub-tree is a valid SVG document fragment.
The sub-tree contains the element in question.
All ancestors of the element in question in the sub-tree are elements in the SVG language and namespace.

A given element may have no current SVG document fragment.

current transformation matrix (CTM)

Transformation matrices define the mathematical mapping from one coordinate system into another using a 3x3 matrix using the equation [x' y' 1] = [x y 1] * matrix. The current transformation matrix defines the mapping from the user coordinate system into the viewport coordinate system. See Coordinate system transformations.

decorated bounding box

The decorated bounding box follows the definition for bounding box, with the exception that it takes into account not only the geometry, but also all geometry-based drawing operations that are marked in their definitions as contributing to this calculation.

descriptive element

An element, not itself in the rendering tree, which provides supplementary information about the container element or graphics element to which it applies (i.e., the described element or elements). Specifically, the following elements are descriptive elements: 'desc', 'metadata', and 'title'.

document begin

The document begin for a given SVG document fragment is the time at which the document's timeline is considered to begin. It depends on the value of the 'timelineBegin' attribute:

If 'timelineBegin' is 'onLoad', then the document begin is the exact time at which the 'svg' element's load event is triggered.
Otherwise, if 'timelineBegin' is 'onStart', then the document begin is the exact time at which the 'svg' element's start-tag ([XML10, XML11], section 3.1) is fully parsed and processed.

document end

The document end of an SVG document fragment is the time at which the document fragment has been released and is no longer being processed by the user agent.

document time

Indicates the position in the timeline relative to the document begin of a given document fragment. Document time is sometimes also referred to as presentation time. For additional information see the SMIL 2.1 definition of document time ([SMIL21], section 10.7.1).

fill

The operation of painting the interior of a shape or the interior of the character glyphs in a text string.

font

A font represents an organized collection of glyphs in which the various glyph representations will share a common look or styling such that, when a string of characters is rendered together, the result is highly legible, conveys a particular artistic style and provides consistent inter-character alignment and spacing.

glyph

A glyph represents a unit of rendered content within a font. Often, there is a one-to-one correspondence between characters to be drawn and corresponding glyphs (e.g., often, the character "A" is rendered using a single glyph), but other times multiple glyphs are used to render a single character (e.g., use of accents) or a single glyph can be used to render multiple characters (e.g., ligatures). Typically, a glyph is defined by one or more shapes such as a path, possibly with additional information such as rendering hints that help a font engine to produce legible text in small sizes.

graphics element

A graphics element is an SVG element that can cause graphics to be drawn onto the target canvas. Specifically, the following elements are graphics elements: 'animation', 'circle', 'ellipse', 'image', 'line', 'path', 'polygon', 'polyline', 'rect', 'text', 'textArea', 'use' and 'video'.

graphics referencing element

A graphics referencing element is a graphics element that uses a reference to a different document or element as the source of its graphical content. The following elements are graphics referencing elements: 'animation', 'image', 'use' and 'video'.

host language

A host language is a syntax which incorporates one or more SVG document fragments by inclusion or by reference, and which defines the interactions between document fragments; an example of this is WICD Core 1.0, an XML framework which defines how XHTML, SVG, MathML, XForms, SMIL, and other syntaxes interact [WICD].

in error

A value is in error if it is specifically stated as being "in error" or "an error" in the prose of this specification. See Error Processing for more detail on handling errors.

inactive element

An element is inactive when it is outside the active duration or when it is paused. Aural aspects of elements which are inactive (e.g. audio, and the audio track of a video element) are silent. SMIL defines the behavior of inactive elements with respect to timing, events, and hyperlinking. See Modelling interactive, event-based content in SMIL, Paused Elements and Active Duration and Event Sensitivity ([SMIL21], sections 10.11.2 and 10.4.3).

IRI reference

An IRI reference is an Internationalized Resource Identifier with an optional fragment identifier, as defined in Internationalized Resource Identifiers [RFC3987]. An IRI reference serves as a reference to a resource or (with a fragment identifier) to a secondary resource. See References.

Invalid IRI reference

An invalid IRI reference is an IRI reference that is syntactically invalid, cannot be resolved to a resource or takes a form that is not allowed for a given attribute, as defined in Reference restrictions.

lacuna value

A lacuna value is a defined behavior used when an attribute or property is not specified, or when an attribute or property has an unsupported value. This value is to be used for the purposes of rendering, calculating animation values, and when accessing the attribute or property using the TraitAccess interface. As opposed to an XML default value, however, the attribute or property and its value are not visible in the DOM, and cannot be accessed with DOM methods (e.g. getAttribute). For lacunae which are properties, if the property is inherited and there is no inherited value (for example, on the root element), the lacuna value is the initial value as specified in the definition of that property ([CSS2], section 6.1.1). For non-inherited properties, the lacuna value is always the initial value.

Note that a lacuna value is distinct from the XML term default value, which uses DTD lookup to determine whether an attribute is required and what its value is, and inserts required attributes and their values into the DOM ([XML10], section 3.3.2). At the XML parser level, SVG Tiny 1.2 does not have default values; lacunae are part of the SVG application layer, and their values are derived from the UA.

local IRI reference

A local IRI reference is an IRI reference that references a fragment within the same resource. See References.

navigation attribute

A navigation attribute is an XML attribute that specifies the element to be focused when the user instructs the SVG user agent to navigate the focus in a particular direction or to set the focus to the next or previous element in the focus ring. Specifically, the following attributes are navigation attributes: 'nav-next', 'nav-prev', 'nav-up', 'nav-down', 'nav-left', 'nav-right', 'nav-up-left', 'nav-up-right', 'nav-down-left' and 'nav-down-right'. See Specifying navigation.

non-local IRI reference

A non-local IRI reference is an IRI reference that references a different document or an element within a different document.

media element

A media element is an element which defines its own timeline within its own time container. The following elements are media elements: 'animation', 'audio' and 'video'. See Multimedia.

paint

A paint represents a way of putting color values onto the canvas. A paint might consist of both color values and associated alpha values which control the blending of colors against already existing color values on the canvas. SVG Tiny 1.2 supports two types of built-in paint: color and gradients.

presentation attribute

A presentation attribute is an XML attribute on an SVG element which specifies a value for a given property for that element. See Styling.

property

A property is a parameter that helps specify how a document should be rendered. A complete list of the SVG properties can be found in the Attribute and Property Table appendix. Properties are assigned to elements in the SVG language by presentation attributes. See Styling.

rendering tree

The rendering tree is the set of elements being rendered, aurally or visually using the painters model, in an SVG document fragment. The following elements in the fragment and their children are part of the SVG document fragment, but not part of the rendering tree (and thus are not rendered):

a 'defs', 'discard', 'font', 'handler', 'linearGradient', 'listener', 'metadata', 'mpath', 'prefetch', 'radialGradient', 'script' or 'solidColor' element
elements whose 'display' property is set to 'none'
elements with one or more conditional processing attributes that evaluate to false
direct children of a 'switch' element, other than the child that evaluates to true
animation elements

The copies of elements referenced by a 'use' element, on the other hand, are not in the SVG document fragment but are in the rendering tree. Note that elements with zero opacity, or no 'fill' and no 'stroke', or with the 'visibility' property set to hidden, are still in the rendering tree.

rootmost 'svg' element

The rootmost 'svg' element is the furthest 'svg' ancestor element that does not exit an SVG context.

Note that this definition has been carefully chosen to be applicable not only to SVG Tiny 1.2 (where the rootmost 'svg' element is the only 'svg' element, except when there is an 'svg' element inside a 'foreignObject') but also for SVG Full 1.2 and SVG that uses XBL [XBL2]. See also SVG document fragment.

shadow tree

A tree fragment that is not part of the DOM tree, but which is attached to a referencing element (e.g. 'use' element) in a non-parent-child relationship, for the purpose of rendering and event propagation. The shadow tree is composed as if it were deep-structure clone of the referenced element in the rendering tree. The shadow tree is kept in synchronization with the contents of the referenced element, so that any animation, DOM manipulation, or non-DOM interactive state occurring on the referenced element are also applied to all the referencing instances. In SVG Tiny 1.2, only a subset of all SVG DOM methods to access the shadow tree are available.

Also referred to as an "instance tree".

shape

A shape is a graphics element that comprises a defined combination of straight lines and curves. Specifically, the following elements are shapes: 'circle', 'ellipse', 'line', 'path', 'polygon', 'polyline' and 'rect'.

stroke

Stroking is the operation of painting the outline of a shape or the outline of character glyphs in a text string.

SVG canvas

The canvas onto which the SVG content is rendered. See the discussion of the SVG canvas in the Coordinate Systems, Transformations and Units chapter.

SVG context

An SVG context is a document fragment where all elements within the fragment must be subject to processing by an SVG user agent according to the rules in this specification.

If SVG content is embedded inline within parent XML (such as XHTML), the SVG context does not include the ancestors above the rootmost 'svg' element. If the SVG content contains any 'foreignObject' elements which in turn contain non-SVG content, the SVG context does not include the contents of the 'foreignObject' elements.

In SVG Tiny 1.2, an SVG context contains one SVG document fragment.

SVG document fragment

An SVG document fragment is the XML document sub-tree whose rootmost element is an 'svg' element (that is, the rootmost 'svg' element.)

An SVG document fragment consists of either a stand-alone SVG document, or a fragment of a parent XML document where the fragment is enclosed by the rootmost 'svg' element.

In SVG Tiny 1.2, the SVG document fragment must not contain nested 'svg' elements. Nested 'svg' elements are unsupported elements and must not be rendered. Note that document conformance is orthogonal to SVG document fragment conformance.

For further details, see the section on Conforming SVG Document Fragments.

SVG element

An SVG element is an element within the SVG namespace defined by the SVG language specification.

SVG user agent

An SVG user agent is a user agent that is able to retrieve and render SVG content.

SVG viewport

The SVG viewport is the viewport within the SVG canvas which defines the rectangular region into which SVG content is rendered. See the discussion of the SVG viewport in the Coordinate Systems, Transformations and Units chapter.

syncbase

The syncbase of an animation element timing specifier is the element whose timing this element is relative to, as defined in SMIL 2.1 ([SMIL21], section 10.7.1).

text content element

A text content element is an SVG element that causes a text string to be rendered onto the canvas. The SVG Tiny 1.2 text content elements are the following: 'text', 'textArea' and 'tspan'.

text content block element

A text content block element is a text content element that serves as a standalone element for a unit of text, and which may optionally contain certain child text content elements (e.g. 'tspan'). SVG Tiny 1.2 defines two text content block elements: 'text' and 'textArea'.

timed element

A timed element is an element that supports the SVG timing attributes. The following elements are timed elements: 'audio', 'animate', 'animateColor', 'animateMotion', 'animateTransform', 'animation', 'set' and 'video'.

transformation

A transformation is a modification of the current transformation matrix (CTM) by providing a supplemental transformation in the form of a set of simple transformations specifications (such as scaling, rotation or translation) and/or one or more transformation matrices. See Coordinate system transformations.

transformation matrix

A transformation matrix defines the mathematical mapping from one coordinate system into another using a 3x3 matrix using the equation [x' y' 1] = [x y 1] * matrix. See current transformation matrix (CTM) and Coordinate system transformations.

unsupported value

An unsupported value is a value that does not conform to this specification, but is not specifically listed as being in error. See the Implementation Notes for more detail on processing unsupported values.

user agent

The general definition of a user agent is an application that retrieves and renders Web content, including text, graphics, sounds, video, images, and other content types. A user agent may require additional user agents that handle some types of content. For instance, a browser may run a separate program or plug-in to render sound or video. User agents include graphical desktop browsers, multimedia players, text browsers, voice browsers; used alone or in conjunction with assistive technologies such as screen readers, screen magnifiers, speech synthesizers, onscreen keyboards, and voice input software [UAAG].

A user agent may or may not have the ability to retrieve and render SVG content; however, an SVG user agent must be able to retrieve and render SVG content.

user coordinate system

In general, a coordinate system defines locations and distances on the current canvas. The current user coordinate system is the coordinate system that is currently active and which is used to define how coordinates and lengths are located and computed, respectively, on the current canvas. See initial user coordinate system and Coordinate system transformations.

user space

User space is a synonym for user coordinate system.

user units

A coordinate value or length expressed in user units represents a coordinate value or length in the current user coordinate system. Thus, 10 user units represents a length of 10 units in the current user coordinate system.

viewport

A viewport is a rectangular region within the current canvas onto which graphics elements are to be rendered. See the discussion of the SVG viewport in the Coordinate Systems, Transformations and Units chapter.

viewport coordinate system

In general, a coordinate system defines locations and distances on the current canvas. The viewport coordinate system is the coordinate system that is active at the start of processing of an 'svg' element, before processing the optional 'viewBox' attribute. In the case of an SVG document fragment that is embedded within a parent document which uses CSS to manage its layout, then the viewport coordinate system will have the same orientation and lengths as in CSS, with the origin at the top-left on the viewport. See The initial viewport and Establishing a new viewport.

viewport space

Viewport space is a synonym for viewport coordinate system.

viewport units

A coordinate value or length expressed in viewport units represents a coordinate value or length in the viewport coordinate system. Thus, 10 viewport units represents a length of 10 units in the viewport coordinate system.

Note: When this specification uses the term 'svg' element, 'path' element, or similar reference to an SVG element defined within this specification, it is referring to the element whose namespace URI is http://www.w3.org/2000/svg and whose local name is the string in quotes (e.g., "svg" or "path"). An exception to this is the 'listener' element, whose namespace URI is http://www.w3.org/2001/xml-events.

1.7 How to reference this specification

When referencing this specification as a whole or when referencing a chapter or major section, use the undated URI, http://www.w3.org/TR/SVGMobile12/, where possible. This allows the reference to always refer to the latest version of this specification.

5 Document Structure

5.1 Defining an SVG document fragment: the 'svg' element
- 5.1.1 Overview
- 5.1.2 The 'svg' element
5.2 Grouping: the 'g' element
- 5.2.1 Overview
- 5.2.2 The 'g' element
5.3 The 'defs' element
5.4 The 'discard' element
5.5 The 'title' and 'desc' elements
- 5.5.1 Applicable 'title' and 'desc'
- 5.5.2 Multiple 'title' and 'desc' elements
- 5.5.3 User interface behavior for 'title' and 'desc'
5.6 The 'use' element
5.7 The 'image' element
5.8 Conditional processing
- 5.8.1 Conditional processing overview
- 5.8.2 The 'switch' element
- 5.8.3 The 'requiredFeatures' attribute
- 5.8.4 The 'requiredExtensions' attribute
- 5.8.5 The 'systemLanguage' attribute
- 5.8.6 The 'requiredFormats' attribute
- 5.8.7 The 'requiredFonts' attribute
5.9 External resources
- 5.9.1 The 'externalResourcesRequired' attribute
- 5.9.2 Progressive rendering
- 5.9.3 The 'prefetch' element
5.10 Common attributes
- 5.10.1 Attributes common to all elements: 'id', 'xml:id', 'xml:base', 'class', 'role', 'rel', 'rev', 'about', 'content', 'datatype', 'property', 'resource', and 'typeof'
- 5.10.2 Attributes for character-content elements: 'xml:lang' and 'xml:space'

5.1 Defining an SVG document fragment: the 'svg' element

5.1.1 Overview

An SVG document fragment consists of any number of SVG elements contained within an 'svg' element, including the 'svg' element.

An SVG document fragment can range from an empty fragment (i.e., no content inside of the 'svg' element), to a very simple SVG document fragment containing a single SVG graphics element such as a 'rect', to a complex, deeply nested collection of container elements and graphics elements.

An SVG document fragment can stand by itself as a self-contained file or resource, in which case the SVG document fragment is an SVG document, or it can be embedded inline as a fragment within a parent XML document.

The following example shows simple SVG content embedded inline as a fragment within a parent XML document. Note the use of XML namespaces to indicate that the 'svg' and 'ellipse' elements belong to the SVG namespace:

Example: 05_01.xml

<?xml version="1.0"?>
<parent xmlns="http://example.org"
        xmlns:svg="http://www.w3.org/2000/svg">
   <!-- parent contents here -->
   <svg:svg width="4cm" height="8cm" version="1.2" baseProfile="tiny" viewBox="0 0 100 100">
      <svg:ellipse cx="50" cy="50" rx="40" ry="20" />
   </svg:svg>
   <!-- ... -->
</parent>

This example shows a slightly more complex (i.e., it contains multiple rectangles) stand-alone, self-contained SVG document:

Example: 05_02.svg

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="5cm" height="4cm" viewBox="0 0 100 100">

  <desc>Four separate rectangles</desc>

  <rect x="20" y="20" width="20" height="20"/>
  <rect x="50" y="20" width="30" height="15"/>
  <rect x="20" y="50" width="20" height="20"/>
  <rect x="50" y="50" width="20" height="40"/>

  <!-- Show outline of canvas using 'rect' element -->
  <rect x="1" y="1" width="98" height="98"
        fill="none" stroke="blue" stroke-width="2" />
</svg>

An SVG document fragment can only contain one single 'svg' element, this means that 'svg' elements cannot appear in the middle of SVG content.

In all cases, for compliance with either the Namespaces in XML 1.0 or Namespaces in XML 1.1 Recommendations [XML-NS10, XML-NS], an SVG namespace declaration must be in scope for the 'svg' element, so that all SVG elements are identified as belonging to the SVG namespace.

For example, an 'xmlns' attribute without a prefix could be specified on an 'svg' element, which means that SVG is the default namespace for all elements within the scope of the element with the 'xmlns' attribute:

Example: 05_03.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny">
  <desc>Demonstrates use of a default namespace prefix for elements.</desc>
  <rect width="7" height="3"/>
</svg>

If a namespace prefix is specified on the 'xmlns' attribute (e.g., xmlns:svg="http://www.w3.org/2000/svg"), then the corresponding namespace is not the default namespace, so an explicit namespace prefix must be assigned to the elements:

Example: 05_04.svg

<?xml version="1.0"?>
<s:svg xmlns:s="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny">
  <s:desc>Demonstrates use of a namespace prefix for elements.
    Notice that attributes are not namespaced</s:desc>
  <s:rect width="7" height="3"/>
</s:svg>

Namespace declarations can also be specified on ancestor elements (illustrated in example 05_01, above). For more information, refer to the Namespaces in XML 1.0 or Namespaces in XML 1.1 Recommendations [XML-NS10, XML-NS].

5.1.2 The 'svg' element

Schema: svg

    <define name='svg'>
      <element name='svg'>
        <ref name='svg.AT'/>
        <zeroOrMore><ref name='svg.G.group'/></zeroOrMore>
      </element>
    </define>

    <define name='svg.AT' combine='interleave'>
      <ref name='svg.Properties.attr'/>
      <ref name='svg.FocusHighlight.attr'/>
      <ref name='svg.External.attr'/>
      <ref name='svg.Focus.attr'/>
      <ref name='svg.AnimateSyncDefault.attr'/>
      <ref name='svg.Core.attr'/>
      <ref name='svg.WH.attr'/>
      <ref name='svg.PAR.attr'/>
      <optional>
        <attribute name='viewBox' svg:animatable='true' svg:inheritable='false'>
          <text/>
        </attribute>
      </optional>
      <optional>
        <attribute name='zoomAndPan' svg:animatable='false' svg:inheritable='false'>
          <choice>
            <value>disable</value>
            <value>magnify</value>
          </choice>
        </attribute>
      </optional>
      <optional>
        <attribute name='version' svg:animatable='false' svg:inheritable='false'>
          <choice>
            <value type='string'>1.0</value>
            <value type='string'>1.1</value>
            <value type='string'>1.2</value>
          </choice>
        </attribute>
      </optional>
      <optional>
        <attribute name='baseProfile' svg:animatable='false' svg:inheritable='false'>
          <choice>
            <value type='string'>none</value>
            <value type='string'>tiny</value>
            <value type='string'>basic</value>
            <value type='string'>full</value>
          </choice>
        </attribute>
      </optional>
      <optional>
        <attribute name='contentScriptType' svg:animatable='false' svg:inheritable='false'>
          <ref name='ContentType.datatype'/>
        </attribute>
      </optional>
      <optional>
        <attribute name='snapshotTime' svg:animatable='false' svg:inheritable='false'>
          <choice>
            <value type='string'>none</value>
            <ref name='Clock-value.datatype'/>
          </choice>
        </attribute>
      </optional>
      <optional>
        <attribute name='timelineBegin' svg:animatable='false' svg:inheritable='false'>
          <choice>
            <value type='string'>onLoad</value>
            <value type='string'>onStart</value>
          </choice>
        </attribute>
      </optional>
      <optional>
        <attribute name='playbackOrder' svg:animatable='false' svg:inheritable='false'>
          <choice>
            <value type='string'>all</value>
            <value type='string'>forwardOnly</value>
          </choice>
        </attribute>
      </optional>
    </define>

Attribute definitions:

version = "1.0" | "1.1" | "1.2"

Indicates the SVG language version to which this document fragment conforms.

In SVG 1.0 and SVG 1.1 this attribute had the value '1.0' or '1.1' respectively, and SVG 1.2 adds the value '1.2'. See rules for version processing for further instructions, notably on handling of unsupported values.

Modifying the 'version' attribute using the DOM does not cause any change in behavior. In this case, the original value of the attribute is the one used for document processing.

Animatable: no.

baseProfile = "profile-name"

Describes the minimum SVG language profile that the author believes is necessary to correctly render the content. See rules for baseProfile processing for further instructions.

This specification defines the values 'none' and 'tiny'. The value 'full' corresponds to all features in the SVG language; for SVG 1.1, this corresponds to the language features defined in the SVG 1.1 Specification [SVG11]. The value 'basic' was defined in the Mobile SVG Profiles: SVG Tiny and SVG Basic [SVGM11]. This specification corresponds to baseProfile="tiny" and version="1.2". A value of 'none' provides no information about the minimum language profile that is necessary to render the content.

The lacuna value is 'none'.

Modifying the 'baseProfile' attribute using the DOM does not cause any change in behavior. In this case, the original value of the attribute is the one used for document processing.

Animatable: no.

width = "<length>"

The intrinsic width of the SVG document fragment. Together with the 'height', 'viewBox' and 'preserveAspectRatio' attributes it defines the intrinsic aspect ratio and (unless both width and height are percentages) the intrinsic size of the svg element. See The initial viewport.

A negative value is unsupported. A value of zero disables rendering of the element.

The lacuna value is '100%'.

Animatable: yes.

height = "<length>"

The intrinsic height of the SVG document fragment.

A negative value is unsupported. A value of zero disables rendering of the element.

The lacuna value is '100%'.

Animatable: yes.

viewBox = "<list-of-numbers>" | "none"

See attribute definition for description.

Animatable: yes.

preserveAspectRatio = "[defer] <align> [<meet>]"

See attribute definition for description.

Animatable: yes.

snapshotTime = "<clock-value>" | "none"

Indicates a moment in time which is most relevant for a still-image of the animated SVG content. This time may be used as a hint to the SVG user agent for rendering a still-image of an animated SVG document, such as a preview. A value of 'none' means that no 'snapshotTime' is available. See example 05_22 for an example of using the 'snapshotTime' attribute.

The lacuna value is 'none'.

Animatable: no.

playbackOrder = "forwardOnly" | "all"

Indicates whether it is possible to seek backwards in the document. In earlier versions of SVG there was no need to put restrictions on the direction of seeking but with the newly introduced facilities for long-running documents (e.g. the 'discard' element) there is sometimes a need to restrict this.

If 'playbackOrder' is set to 'forwardOnly', the content will probably contain 'discard' elements or scripts that destroy resources, thus seeking back in the document's timeline may result in missing content. If 'playbackOrder' is 'forwardOnly', the content should not provide a way, through hyperlinking or script, of seeking backwards in the timeline. Similarly the UA should disable any controls it may provide in the user interface for seeking backwards. Content with 'playbackOrder' = 'forwardOnly' that provides a mechanism for seeking backwards in time may result in undefined behavior or a document that is in error.

'forwardOnly': This file is intended to be played only in the forward direction, sequentially, therefore seeking backwards should not be allowed.
'all': Indicates that the document is authored appropriately for seeking in both directions.

The lacuna value is 'all'.

Animatable: no.

timelineBegin = "onLoad" | "onStart"

Controls the initialization of the timeline for the document.

The 'svg' element controls the document timeline, which is the timeline of the 'svg' element's time container. For progressively loaded animations, the author would typically set this attribute to 'onStart', thus allowing the timeline to begin as the document loads, rather than waiting until the complete document is loaded.

'onLoad': The document's timeline starts the moment the load event for the rootmost 'svg' element is triggered.
'onStart': The document's timeline starts at the moment the rootmost 'svg' element's start-tag (as defined in XML 1.0 ([XML10], section 3.1), or XML 1.1 ([XML11], section 3.1), if the document is an XML 1.1 document) is fully parsed and processed.

The lacuna value is 'onLoad'.

Animatable: no.

contentScriptType = "<content-type>"

Identifies the default scripting language for the given document. This attribute sets the default scripting language for all the instances of script in the document fragment. This language must be used for all scripts that do not specify their own scripting language. The <content-type> value specifies a media type, per Multipart Internet Mail Extensions: (MIME) Part Two: Media Types [RFC2046]. The lacuna value is "application/ecmascript".

Animatable: no.

zoomAndPan = "magnify" | "disable"

See attribute definition for description.

Animatable: no.

focusable = "true" | "false" | "auto"

See attribute definition for description.

Animatable: yes.

Navigation Attributes

See definition.

Note that 'animateMotion' and 'animateTransform' are legal as children to 'svg' but don't apply to their 'svg' parent (since the 'svg' element doesn't have a 'transform' attribute). They only have any effect if the 'xlink:href' attribute is specified so that they target a different element for animation.

Content produced by illustration programs originally targeted at print often has a fixed width and height, which will prevent it scaling for different display resolutions. The first example below has a fixed width and height in pixels, and no 'viewBox'.

Example: width-height.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="300px" height="600px">
  <desc>...</desc>
</svg>

Normally, SVG content is designed to be scalable. In order for the SVG content to scale automatically to fill the available viewport, it must include a 'viewBox' attribute on the 'svg' element. This describes the region of world coordinate space (the initial user coordinate system) used by the graphic. This attribute thus provides a convenient way to design SVG documents to scale-to-fit into an arbitrary viewport.

The second example is scalable, using a 'viewBox' rather than a fixed width and height.

Example: viewBox.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" 
     baseProfile="tiny" viewBox="0 0 300 600">
  <desc>...</desc>
</svg>

Below is an example of 'snapshotTime'. An SVG user agent is displaying a number of SVG files in a directory by rendering a thumbnail image. It uses the 'snapshotTime' as the time to render when generating the image, thus giving a more representative static view of the animation. The appearance of the thumbnail for an SVG user agent that honors the 'snapshotTime' and for an SVG user agent that does not is shown below the example (UA which generates thumbnails based on 'snapshotTime' at the left, UA which doesn't generate thumbnails based on 'snapshotTime' at the right, e.g. a static viewer).

Example: 05_22.svg

<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     viewBox="0 0 400 300" snapshotTime="3">

  <title>Snapshot time example</title>
  <desc>This example shows the use of snapshotTime on an animation of color.</desc>

  <rect x="60" y="85" width="256" height="65" fill="none" stroke="rgb(60,126,220)" stroke-width="4"/>
    
  <text x="65" y="140" fill="white" font-size="60">
    Hello SVG
    <animateColor attributeName="fill" begin="0" dur="3" from="white" to="rgb(60,126,220)"/>  
  </text> 
</svg>

5.2 Grouping: the 'g' element

5.2.1 Overview

The 'g' element is a container element for grouping together related graphics elements.

Grouping constructs, when used in conjunction with the 'desc' and 'title' elements, provide information about document structure and semantics. Documents that are rich in structure may be rendered graphically, as speech, or as braille, and thus promote accessibility.

A group of elements, as well as individual objects, can be given a name using the 'xml:id' attribute. Named groups are needed for several purposes such as animation and re-usable objects.

An example:

Example: 05_05.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="5cm" height="5cm" viewBox="0 0 5 5">

  <desc>Two groups, each of two rectangles</desc>

  <g xml:id="group1" fill="red">
    <desc>First group of two red rectangles</desc>
    <rect x="1" y="1" width="1" height="1"/>
    <rect x="3" y="1" width="1" height="1"/>
  </g>
  <g xml:id="group2" fill="blue">
    <desc>Second group of two blue rectangles</desc>
    <rect x="1" y="3" width="1" height="1"/>
    <rect x="3" y="3" width="1" height="1"/>
  </g>

  <!-- Show outline of canvas using 'rect' element -->
  <rect x=".01" y=".01" width="4.98" height="4.98"
        fill="none" stroke="blue" stroke-width=".02"/>
</svg>

A 'g' element can contain other 'g' elements nested within it, to an arbitrary depth. Thus, the following is possible:

Example: 05_06.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="5cm" height="5cm">

  <desc>Groups can nest</desc>

  <g>
    <g>
      <g>
      </g>
    </g>
  </g>
</svg>

Any element that is not contained within a 'g' is treated (at least conceptually) as if it were in its own group.

5.2.2 The 'g' element

Schema: g

    <define name='g'>
      <element name='g'>
        <ref name='g.AT'/>
        <zeroOrMore><ref name='svg.G.group'/></zeroOrMore>
      </element>
    </define>

    <define name='g.AT' combine='interleave'>
      <ref name='svg.Properties.attr'/>
      <ref name='svg.FocusHighlight.attr'/>
      <ref name='svg.Core.attr'/>
      <ref name='svg.External.attr'/>
      <ref name='svg.Conditional.attr'/>
      <ref name='svg.Focus.attr'/>
      <ref name='svg.Transform.attr'/>
    </define>

Attribute definitions:

focusable = "true" | "false" | "auto"

See attribute definition for description.

Animatable: yes.

Navigation Attributes

See definition.

5.3 The 'defs' element

The 'defs' element is a container element for referenced elements. For understandability and accessibility reasons, it is recommended that, whenever possible, referenced elements be defined inside of a 'defs'. For performance reasons, authors should put the 'defs' element before other document content, so that all resources are available to be referenced.

The content model for 'defs' is the same as for the 'g' element; thus, any element that can be a child of a 'g' can also be a child of a 'defs', and vice versa.

Elements that are descendants of a 'defs' are not rendered directly; they are prevented from becoming part of the rendering tree just as if the 'defs' element were a 'g' element and the 'display' property were set to none. Note, however, that the descendants of a 'defs' are always present in the source tree and can be referenced by other elements. The actual value of the 'display' property on the 'defs' element or any of its descendants does not change the rendering of these elements or prevent these elements from being referenced.

Schema: defs

    <define name='defs'>
      <element name='defs'>
        <ref name='defs.AT'/>
        <zeroOrMore><ref name='svg.G.group'/></zeroOrMore>
      </element>
    </define>

    <define name='defs.AT' combine='interleave'>
      <ref name='svg.Properties.attr'/>
      <ref name='svg.Core.attr'/>
    </define>

Creators of SVG content are encouraged to place all elements which are targets of local IRI references (except of course for animation targets) within a 'defs' element which is a direct child of one of the ancestors of the referencing element. For example:

Example: 05_10.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="100%" height="100%" viewBox="0 0 8 3">     

  <desc>Local URI references within ancestor's 'defs' element.</desc>

  <defs>
    <linearGradient xml:id="Gradient01">
      <stop offset="0.2" stop-color="#39F"/>
      <stop offset="0.9" stop-color="#F3F"/>
    </linearGradient>
  </defs>

  <rect x="1" y="1" width="6" height="1" fill="url(#Gradient01)"/>

  <!-- Show outline of canvas using 'rect' element -->
  <rect x=".01" y=".01" width="7.98" height="2.98"
        fill="none" stroke="blue" stroke-width=".02" />
</svg>

In the document above, the linear gradient is defined within a 'defs' element which is the direct child of the 'svg' element, which in turn is an ancestor of the 'rect' element which references the linear gradient. Thus, the above document conforms to the guideline.

5.4 The 'discard' element

The 'discard' element allows authors to specify the time at which particular elements are to be discarded, thereby reducing the resources required by an SVG user agent. This is particularly useful to help SVG viewers conserve memory while displaying long-running documents. This element will not be processed by static SVG viewers.

The 'discard' element may occur wherever the 'animate' element may.

Schema: discard

    <define name='discard'>
      <element name='discard'>
        <ref name='discard.AT'/>
        <ref name='discard.CM'/>
      </element>
    </define>

    <define name='discard.AT' combine='interleave'>
      <ref name='svg.Core.attr'/>
      <ref name='svg.XLink.attr'/>
      <ref name='svg.AnimateBegin.attr'/>
      <ref name='svg.Conditional.attr'/>
    </define>

    <define name='discard.CM'>
      <zeroOrMore>
        <ref name='svg.Desc.group'/>
        <ref name='svg.Handler.group'/>
      </zeroOrMore>
    </define>

Attribute definitions:

xlink:href = "<IRI>"

An IRI reference that identifies the target element to discard. See the definition of 'xlink:href' on animation elements for details on identifying a target element.

Note that if the target element is not part of the current SVG document fragment then whether the target element will be removed or not is defined by the host language.

If the 'xlink:href' attribute is not provided, then the target element will be the immediate parent element of the discard element.

Animatable: no.

begin = "begin-value-list"

Indicates when the target element will be discarded. See the definition of 'begin' on animation elements for details.

The lacuna value is '0s'. This indicates that the target element should be discarded immediately once the document begins.

Animatable: no.

The 'discard' element has an implicit simple duration of "indefinite". As soon as the element's active duration starts, the SVG user agent discards the element identified by the 'xlink:href' attribute ([SMIL21], section 10.4.3). The removal operation acts as if the method removeChild were called on the parent of the target element with the target element as parameter. The SVG user agent must remove the target node as well as all of its attributes and descendants.

After removal of the target element, the 'discard' element is no longer useful. It must also be discarded following the target element removal. If the 'xlink:href' attribute has an invalid IRI reference (the target element did not exist, for example), the 'discard' element itself must still be removed following activation.

Seeking backwards in the timeline ([SMIL21], section 10.4.3) must not re-insert the discarded elements. Discarded elements are intended to be completely removed from memory. So, authors are encouraged to set the 'playbackOrder' attribute to "forwardOnly" when using the 'discard' element.

The 'discard' element itself can be discarded prior to its activation, in which case it will never trigger the removal of its own target element. User agents must allow the 'discard' element to be the target of another 'discard' element.

The following example demonstrates a simple usage of the 'discard' element. The list below describes relevant behavior in the document timeline of this example:

At time = 0:: When the document timeline starts, the blue ellipse starts to move down the page.
At time = 1 second:: The red rectangle starts moving up the page.
At time = 2 seconds:: The 'animateTransform' on the 'ellipse' ends. The 'ellipse' and its children are also discarded, as it is the target element of a 'discard' with begin="2". The green 'polygon' starts to move across the page.
At time = 3 seconds:: The animation on the red rectangle ends. The rectangle and its children are discarded as it is the target of a 'discard' element with begin="3".
At time = 4 seconds:: The animation on the green triangle ends. The green 'polygon' and its children are discarded as it is the target of a 'discard' element with begin="4".

Example: discard01.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny" 
     width="352" height="240" playbackOrder="forwardOnly">
    
  <ellipse cx="98.5" cy="17.5" rx="20.5" ry="17.5" fill="blue" stroke="black" 
           transform="translate(9 252) translate(3 -296)">
    <animateTransform attributeName="transform" begin="0s" dur="2s" fill="remove"
                      calcMode="linear" type="translate" additive="sum"
                      from="0 0" to="-18 305"/>
    <discard begin="2s"/>
  </ellipse>
  
  <rect x="182" y="-39" width="39" height="30" fill="red" stroke="black"
        transform="translate(30 301)">
    <animateTransform attributeName="transform" begin="1s" dur="2s" fill="remove"
                      calcMode="linear" type="translate" additive="sum"
                      from="0 0" to="-26 -304"/>
    <discard begin="3s"/>
  </rect>
  
  <polygon points="-66,83.5814 -43,123.419 -89,123.419" fill="green" stroke="black" 
           transform="matrix(1 0 0 1.1798 0 -18.6096)">
    <animateTransform attributeName="transform" begin="2s" dur="2s"
                      fill="remove" calcMode="linear" type="translate" additive="sum"
                      from="0 0" to="460 63.5699"/>
    <discard begin="4s"/>
  </polygon>
</svg>

5.5 The 'title' and 'desc' elements

Each container element or graphics element in an SVG document may contain one or more of each of the 'title' and 'desc' descriptive elements. The 'title' element must contain a short title for the container or graphics element containing it. This short title must provide information supplementary to the rendering of the element, but will normally not be sufficient to replace it. The 'desc' element contains a longer, more detailed description for the container or graphics element containing it. This description must be usable as replacement content for cases when the user cannot see the rendering of the SVG element for some reason.

Authors should always provide at least a 'title', and preferably a 'desc', as an immediate child element to the 'svg' element within an SVG document, and to every significant individual graphical composition within the document. The 'title' child element to an 'svg' element serves the purposes of identifying the content of the given SVG document fragment. Since users often consult documents out of context, authors should provide context-rich titles. Thus, instead of a title such as "Introduction", which doesn't provide much contextual background, authors should supply a title such as "Introduction to Medieval Bee-Keeping" instead. For reasons of accessibility, SVG user agents should always make the content of the 'title' child element to the 'svg' element available to users (See the User Agent Accessibility Guidelines 1.0 [UAAG]). The mechanism for doing so depends on the SVG user agent (e.g., as a caption, spoken).

When descriptive elements are present, alternate presentations of the document are possible, both visual and aural, which display the 'title' and 'desc' elements but do not display graphics elements.

For both the 'title' and the 'desc' element, the content must be plain text. To provide structured data in other markup languages, authors should use the 'metadata' or 'foreignObject' elements instead, as appropriate. When markup is included as a child of the 'title' or the 'desc', a user agent should present only the text content of the descriptive elements.

Note that the 'title' element is distinct in purpose from the 'xlink:title' attribute of the 'a' element. The 'xlink:title' attribute content is intended not to describe the current resource, but the nature of the linked resource.

5.5.1 Applicable 'title' and 'desc'

Normally, the descriptive elements that describe a container element or graphics element are direct children of that element. However, SVG documents can have a rich structure, with nested elements each potentially containing 'title' or 'desc' child elements, as well as 'use' elements with 'title' or 'desc' in both the 'use' element itself and in the referenced content. Because of this complex structure, and because the descriptive elements may or may not be present at any level, the applicable descriptive elements for any given content is determined by the structure, as described here.

For each container element or graphics element, the applicable descriptive elements shall be those that are most shallowly nested in that document fragment, without taking into account descriptive elements in any 'use' element shadow trees. If the document fragment has no descriptive elements, and it is a 'use' element, the applicable descriptive elements shall be those contained in the shadow tree. If no descriptive elements are found in the document fragment or any shadow tree, the applicable descriptive elements shall be the nearest ancestor descriptive elements. This algorithm allows authors to reuse descriptive elements defined in referenced resources when desired, or to override them as needed, as well as to describe whole groups of elements.

Note that the applicable descriptive elements for elements in a container element does not necessarily entail a description of the individual graphical elements in question, but rather their membership in a more inclusive group (e.g., if the image is of a basket of fruit, with a title of "Fruit Basket" for the containing group and no other descriptive elements, while no one piece of fruit is a fruit basket, the title would still be applicable through inclusion). Authors should take care to designate all important elements with their own descriptive elements to avoid misconstrued identities and entailments.

5.5.2 Multiple 'title' and 'desc' elements

It is strongly recommended that at most one 'title' and at most one 'desc' element appear as a child of any particular element, and that these elements appear before any other child elements (except possibly 'metadata' elements) or character data content. If SVG user agents need to choose among multiple 'title' or 'desc' elements for processing (e.g., to decide which string to use for a tooltip), the user agent shall choose the first of each of the available descriptive elements as the applicable elements or elements.

Authors may wish to deliberately provide multiple descriptive elements, such as to provide alternate content for different languages. In this case, the author should use conditional processing attributes to allow the user agent to select the best choice according to the user's preferences. For example, the 'systemLanguage' attribute, with or without the 'switch' element, will determine the applicable descriptive elements.

5.5.3 User interface behavior for 'title' and 'desc'

When the current SVG document fragment is rendered as SVG on visual media, 'title' and 'desc' elements are not rendered as part of the canvas. Often, the intent of authors is for descriptive elements to remain hidden (e.g., for aesthetic reasons in pieces of art). However, other authors may wish for this content to be displayed, and providing tangible benefit to these authors encourages best practice in providing descriptive elements. In this case, authors are encouraged to use the 'role' attribute, with the value aria:tooltip (as described in ARIA) to indicate their intent.

It is strongly recommended that when the appropriate 'role' attribute value is present, user agents display the text content of the applicable 'title' and 'desc' elements in a highly visible manner supported by the user agent, such as in a tooltip or status bar, when the pointing device is hovered over the described element or elements, or when the described element is given focus (e.g., through keyboard or pointer navigation). If a tooltip is provided, the user agent is recommended to display the applicable title and descriptions on separate lines, title first, with font styling that distinguishes the two. For long descriptions, the tooltip may wrap the text, and truncate longer passages to a reasonable length. A user agent may preserve spaces and line breaks in the text content in order to structure the presentation of the text.

When an element with descriptive elements is itself the child of an 'a' element with an 'xlink:title' attribute, the user agent should display as much of the available information as possible. The user agent is suggested to display the 'xlink:title' attribute value on a separate line, with a label to identify it, such as "link: ". Commonly, many user agents display the URI of the link (i.e., the value of the 'xlink:href' attribute) in the status bar or other display area. This information is important, and should not be overridden by any descriptive element content, but may be supplemented by such content.

The rootmost 'title' element should be used as the document title, and for stand-alone SVG documents, the title should not be displayed as a tooltip, but rather in the browser chrome (as appropriate for the user agent). For embedded SVG documents, such as an SVG image referenced in an HTML document, displaying the title and description as a tooltip is more appropriate, and the user agent should do so.

If a user agent is an accessibility tool, all available descriptions of the currently focused or hovered element should be exposed to the user in a categorical manner, such that the user may selectively access the various descriptions. The 'desc' element, in particular, may be given different semantic distinctions by use of values in the 'role' attribute, such as the ARIA ontology values aria:description for textual equivalents of the graphics, and aria:tooltip for giving instructions to the user.

Schema: desc

    <define name='desc'>
      <element name='desc'>
        <ref name='DTM.AT'/>
        <ref name='DTM.CM'/>
      </element>
    </define>

    <define name='DTM.AT' combine='interleave'>
      <ref name='svg.Core.attr'/>
      <ref name='svg.Conditional.attr'/>
      <ref name='svg.Media.attr'/>
    </define>

    <define name='DTM.CM'>
      <text/>
    </define>

Schema: title

    <define name='title'>
      <element name='title'>
        <ref name='DTM.AT'/>
        <ref name='DTM.CM'/>
      </element>
    </define>

The following is an example in which an SVG user agent might present the 'title' and 'desc' elements as a tooltip.

Example: title-desc-tooltip.svg

<svg xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink"
     version="1.1"
     width="100%" height="100%" viewBox="0 0 160 170">


  <title>Titles and Descriptions</title>
  <desc>An example of how the contents of the 'title' and 'desc' elements may be presented in a user agent.</desc>

  <defs>
    <polygon id="beeCell" points="-13.75,-22.75 13.75,-22.75 26.25,0 13.75,22.75 -13.75,22.75 -26.25,0" stroke="yellow" stroke-width="3" stroke-linejoin="round">
      <title role="aria:tooltip">Beehive cell</title>
      <desc role="aria:tooltip">A simple hexagon with a yellow outline and no fill.</desc>
      <metadata>cx="26.25" cy="22.75" width="52.5" height="45.5"</metadata>
    </polygon>
     
  </defs>

  <g fill="white">
    <use xlink:href="#beeCell" x="30" y="60" />
    <use xlink:href="#beeCell" x="75" y="35" />
    <use xlink:href="#beeCell" x="120" y="60" />
    <use xlink:href="#beeCell" x="120" y="110" />
    <use xlink:href="#beeCell" x="30" y="110" />
    <use xlink:href="#beeCell" x="75" y="135" />

    <a xlink:href="http://www.example.com/bees.html" xlink:title="Beekeeper's Hive: an apiary resource">
      <title role="aria:tooltip">Link to Beekeeper's Hive: an apiary resource</title>
      <use xlink:href="#beeCell" x="75" y="85" fill="#9900CC">
        <title role="aria:tooltip">Queen's Cell</title>
        <desc role="aria:tooltip">
          A hexagonal beehive cell.
          
          A purple hexagon in the middle of 6 other empty hexagons, symbolizing that it's filled with royal jelly.
        </desc>
      </use>
    </a>  
     
  </g>

</svg>

5.6 The 'use' element

Any 'g' or graphics element is potentially a template object that can be re-used (i.e. "instantiated") in the SVG document via a 'use' element, thus creating an instance tree. The 'use' element references another element and indicates that the graphical contents of that element is to be included and drawn at that given point in the document.

Unlike 'animation', the 'use' element cannot reference entire files.

Besides what is described about the 'use' element in this section important restrictions for 'use' can be found in the Reference Section.

The 'use' element has optional attributes 'x' and 'y' which are used to place the referenced element and its contents into the current coordinate system.

The effect of a 'use' element is as if the SVG element contents of the referenced element were deeply cloned into a separate non-exposed DOM tree which had the 'use' element as its parent and all of the 'use' element's ancestors as its higher-level ancestors. Because the cloned DOM tree is non-exposed, the SVG Document Object Model (DOM) only contains the 'use' element and its attributes. The SVG DOM does not show the referenced element's contents as children of the 'use' element. The deeply-cloned tree, also referred to as the shadow tree, is then kept in synchronization with the contents of the referenced element, so that any animation, DOM manipulation, or non-DOM interactive state occurring on the referenced element are also applied to the 'use' element's deeply-cloned tree.

Relative IRIs on a node in a shadow tree are resolved relative to any 'xml:base' on the node itself, then recursively on any 'xml:base' on its parentNode, and finally any 'xml:base' on the ownerDocument if there is no parentNode.

Property inheritance works as if the referenced element had been textually included as a deeply cloned child of the 'use' element. The referenced element inherits properties from the 'use' element and the 'use' element's ancestors. An instance of a referenced element does not inherit properties from the referenced element's original parents.

The behavior of the 'visibility' property conforms to this model of property inheritance. Thus, a computed value of visibility="hidden" on a 'use' element does not guarantee that the referenced content will not be rendered. If the 'use' element has a computed value of visibility="hidden" and the element it references specifies visibility="hidden" or visibility="inherit", then that element will be hidden. However, if the referenced element instead specifies visibility="visible", then that element will be visible even if the 'use' element specifies visibility="hidden".

If an event listener is registered on a referenced element, then the actual target for the event will be the SVGElementInstance object within the "instance tree" corresponding to the given referenced element.

The event handling for the non-exposed tree works as if the referenced element had been textually included as a deeply cloned child of the 'use' element, except that events are dispatched to the SVGElementInstance objects. The event's target and currentTarget attributes are set to the SVGElementInstance that corresponds to the target and current target elements in the referenced subtree. An event propagates through the exposed and non-exposed portions of the tree in the same manner as it would in the regular document tree: first going to the target of the event, then bubbling back through non-exposed tree to the 'use' element and then back through regular tree to the rootmost 'svg' element in the bubbling phase.

An element and all its corresponding SVGElementInstance objects share an event listener list. The currentTarget attribute of the event can be used to determine through which object an event listener was invoked.

Animations on a referenced element will cause the instances to also be animated.

As listed in the Reference Section the 'use' element is not allowed to reference an 'svg' element.

A 'use' element has the same visual effect as if the 'use' element were replaced by the following generated content:

In the generated content, the 'use' will be replaced by 'g', where all attributes from the 'use' element except for 'x', 'y', 'xml:base' and 'xlink:href' are transferred to the generated 'g' element. An additional transformation translate(x,y) is appended to the end (i.e., right-side) of the 'transform' attribute on the generated 'g', where x and y are the values of the 'x' and 'y' attributes of the 'use' element. The referenced object and its contents are deep-cloned into the generated tree.

except for resolution of relative IRI references as noted above and until the referenced elements are modified. Note also that any changes to the used element are immediately reflected in the generated content.

When a 'use' references another element which is another 'use' or whose content contains a 'use' element, then the deep cloning approach described above is recursive. However, a set of references that directly or indirectly reference a element to create a circular dependency is an error, as described in the References section.

Schema: use

    <define name='use'>
      <element name='use'>
        <ref name='use.AT'/>
        <ref name='use.CM'/>
      </element>
    </define>

    <define name='use.AT' combine='interleave'>
      <ref name='svg.Properties.attr'/>
      <ref name='svg.FocusHighlight.attr'/>
      <ref name='svg.Core.attr'/>
      <ref name='svg.Conditional.attr'/>
      <ref name='svg.Transform.attr'/>
      <ref name='svg.XLinkEmbed.attr'/>
      <ref name='svg.Focus.attr'/>
      <ref name='svg.External.attr'/>
      <ref name='svg.XY.attr'/>
    </define>

    <define name='use.CM'>
      <zeroOrMore>
        <choice>
          <ref name='svg.Desc.group'/>
          <ref name='svg.Animate.group'/>
          <ref name='svg.Handler.group'/>
        </choice>
      </zeroOrMore>
    </define>

Attribute definitions:

x = "<coordinate>"

The x-axis coordinate of one corner of the rectangular region into which the referenced element is placed.

The lacuna value is '0'.

Animatable: yes.

y = "<coordinate>"

The y-axis coordinate of one corner of the rectangular region into which the referenced element is placed.

The lacuna value is '0'.

Animatable: yes.

xlink:href = "<IRI>"

An IRI reference to an element/fragment within an SVG document. An invalid IRI reference is an unsupported value. An empty attribute value (xlink:href="") disables rendering of the element. The lacuna value is the empty string.

Animatable: yes.

focusable = "true" | "false" | "auto"

See attribute definition for description.

Animatable: yes.

Navigation Attributes

See definition.

Below are two examples of the 'use' element. For another example see use and animation example.

Example 05_13 below has a simple 'use' on a 'rect'.

Example: 05_13.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
     version="1.2" baseProfile="tiny"
     width="10cm" height="3cm" viewBox="0 0 100 30">     

  <desc>Simple case of 'use' on a 'rect'</desc>

  <defs>
    <rect xml:id="MyRect" width="60" height="10"/>
  </defs>
  <rect x=".1" y=".1" width="99.8" height="29.8"
        fill="none" stroke="blue" stroke-width=".2"/>
  <use x="20" y="10" xlink:href="#MyRect" />
</svg>

The visual effect would be equivalent to the following document:

Example: 05_14.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" 
     version="1.2" baseProfile="tiny"
     width="10cm" height="10cm" viewBox="0 0 100 30">

  <desc>
    The equivalent rendering tree of example 05_13 once the
    'use' element's shadow tree has been created.
  </desc>

  <!-- 'defs' section left out -->

  <rect x=".1" y=".1" width="99.8" height="29.8"
        fill="none" stroke="blue" stroke-width=".2" />

  <!-- begin shadow tree content that the <use> element in the original
       file would generate -->
  <g transform="translate(20,10)">
    <rect width="60" height="10"/>
  </g>
  <!-- end of shadow tree content -->
</svg>

Example 05_17 illustrates what happens when a 'use' has a 'transform' attribute.

Example: 05_17.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
     version="1.2" baseProfile="tiny"
     width="10cm" height="3cm" viewBox="0 0 100 30">

  <desc>'use' with a 'transform' attribute</desc>

  <defs>
    <rect xml:id="MyRect" x="0" y="0" width="60" height="10"/>
  </defs>

  <rect x=".1" y=".1" width="99.8" height="29.8"
        fill="none" stroke="blue" stroke-width=".2"/>
  <use xlink:href="#MyRect" transform="translate(20,2.5) rotate(10)"/>
</svg>

The visual effect would be equivalent to the following document:

Example: 05_18.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
     version="1.2" baseProfile="tiny"
     width="100%" height="100%" viewBox="0 0 100 30">

  <desc>'use' with a 'transform' attribute</desc>

  <!-- 'defs' section left out -->

  <rect x=".1" y=".1" width="99.8" height="29.8"
        fill="none" stroke="blue" stroke-width=".2"/>

  <!-- begin shadow tree content that the <use> element in the original
       file would generate -->
  <g transform="translate(20,2.5) rotate(10)">
    <rect x="0" y="0" width="60" height="10"/>
  </g>
  <!-- end of shadow tree content-->
</svg>

Example use-bubble-example-1.svg illustrates four cases of event bubbling with use elements. In case 1, all instances of the 'rect' element are filled blue on mouse over. For cases 2 and 3, in addition to the 'rect' elements being filled blue, a black stroke will also appear around the referencing rectangle on mouse over. In case 4, all the rectangles turn blue on mouse over, and a black stroke appears on mouse click.

Example: use-bubble-example-1.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink"
     xmlns:ev="http://www.w3.org/2001/xml-events"
     version="1.2" baseProfile="tiny">

  <defs>
    <rect id="rect" width="20" height="20" fill="red">
      <set attributeName="fill" begin="mouseover" end="mouseout" to="blue"/>
    </rect>
  </defs>

  <use fill="red" x="5" y="5" xlink:href="#rect"/>
  <text x="10" y="35">1</text>
  
  <use id="use2" fill="red" x="30" y="5" xlink:href="#rect"/>  
  <rect pointer-events="none" x="30" y="5" width="20" height="20"
        fill="none" stroke-width="3" stroke="none">
    <set attributeName="stroke" begin="use2.mouseover" end="use2.mouseout" to="black"/>
  </rect>
  <text x="35" y="35">2</text>
  
  <g id="g1">
    <use fill="red" x="5" y="40" xlink:href="#rect"/>  
    <rect pointer-events="none" x="5" y="40" width="20" height="20"
          fill="none" stroke-width="3" stroke="none">
      <set attributeName="stroke" begin="g1.mouseover" end="g1.mouseout" to="black"/>
    </rect>
  </g>
  <text x="10" y="70">3</text>
  
  <use id="use3" fill="red" x="30" y="40" xlink:href="#rect"/>  
  <rect pointer-events="none" x="30" y="40" width="20" height="20"
        fill="none" stroke-width="3" stroke="none">
    <set attributeName="stroke" begin="use3.click" dur="500ms" to="black"/>
  </rect>  
  <text x="35" y="70">4</text>
</svg>

Example use-bubble-example-2.svg illustrates event bubbling with nested 'use' elements. On mouse over, the 'rect' element is filled blue and displays a green and black ring.

Example: use-bubble-example-2.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink"
     xmlns:ev="http://www.w3.org/2001/xml-events"
     version="1.2" baseProfile="tiny">

  <defs>
    <rect id="rect" width="20" height="20" fill="red">
      <set attributeName="fill" begin="mouseover" end="mouseout" to="blue"/>
    </rect>    
    <g id="use">
      <use fill="red" xlink:href="#rect"/>  
      <rect pointer-events="none" width="20" height="20"
            fill="none" stroke-width="8" stroke="none">
        <set attributeName="stroke" begin="use.mouseover" end="use.mouseout" to="green"/>
      </rect>
    </g>
  </defs>
  
  <use x="5" y="5" id="use2" fill="red" xlink:href="#use"/>  
  <rect pointer-events="none" x="5" y="5" width="20" height="20" fill="none" stroke-width="3" stroke="none">
    <set attributeName="stroke" begin="use2.mouseover" end="use2.mouseout" to="black"/>
  </rect>
</svg>

Example image-use-base.svg illustrates the handling of relative IRI references. All three use elements result in the same image being displayed, http://a.example.org/aaa/bbb/ddd/foo.jpg.

Example: image-use-base.svg

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
     version="1.2" baseProfile="tiny" viewBox="00 100 100">

  <g xml:base="http://a.example.org/aaa/">
    <g xml:base="/bbb/ccc/">
      <g xml:base="../ddd/" xml:id="bar">
        <image xml:id="foo" xlink:href="foo.jpg" width="100" height="100"/>
      </g>
    </g>
  </g>
  <g xml:base="http://z.example.net/zzz/">
    <g xml:base="/yyy/xxx/">
      <g xml:base="../xxx/">
        <use xlink:href="#foo" width="90" height="90"/>
        <use xlink:href="#bar" width="60" height="60"/>
        <use xlink:href="#bar" xml:base="../ggg/" width="30" height="30"/>
      </g>
    </g>
  </g>
</svg>

5.7 The 'image' element

The 'image' element indicates that the contents of a complete document are to be rendered into a given rectangle within the current user coordinate system. In SVG Tiny 1.2, the 'image' must reference content that is a raster image format, such as PNG or JPEG [PNG, JPEG]. SVG Tiny 1.2 does not allow an SVG document to be referenced by the 'image' element; instead, authors should use the 'animation' element for referencing SVG documents. Conforming SVG viewers must support PNG and JPEG image file formats. Other image file formats may be supported.

For details of the required JPEG support see the JPEG Support appendix. PNG support is required as defined in the Portable Network Graphics (PNG) Specification (Second Edition) [PNG].

The result of processing an 'image' is always a four-channel RGBA result. When an 'image' element references a raster image file such as PNG or JPEG files which only has three channels (RGB), then the effect is as if the object were converted into a 4-channel RGBA image with the alpha channel uniformly set to 1. For a single-channel raster image, the effect is as if the object were converted into a 4-channel RGBA image, where the single channel from the referenced object is used to compute the three color channels and the alpha channel is uniformly set to 1.

The 'image' element supports the 'opacity' property for controlling the image opacity. The 'fill-opacity' property does not affect the rendering of an image.

An 'image' element establishes a new viewport for the referenced file as described in Establishing a new viewport. The bounds for the new viewport are defined by attributes 'x', 'y', 'width' and 'height'. The placement and scaling of the referenced image are controlled by the 'preserveAspectRatio' attribute on the 'image' element.

The value of the 'viewBox' attribute to use when evaluating the 'preserveAspectRatio' attribute is defined by the referenced content. For content that clearly identifies a 'viewBox' that value should be used. For most raster content (such as PNG and JPEG) the bounds of the image should be used (i.e. the 'image' element has an implicit 'viewBox' of "0 0 raster-image-width raster-image-height"). Where no value is readily available the 'preserveAspectRatio' attribute is ignored and only the translate due to the 'x' and 'y' attributes of the viewport is used to display the content.

For example, if the 'image' element referenced a PNG or JPEG and preserveAspectRatio="xMinYMin meet", then the aspect ratio of the raster would be preserved (which means that the scale factor from the image's coordinates to the current user space coordinates would be the same for both x and y), the raster would be sized as large as possible while ensuring that the entire raster fits within the viewport, and the top left of the raster would be aligned with the top left of the viewport as defined by the attributes 'x', 'y', 'width' and 'height' on the 'image' element. If the value of 'preserveAspectRatio' was "none" then aspect ratio of the image would not be preserved. The image would be positioned such that the top-left corner of the raster exactly aligns with coordinate ('x', 'y') and the bottom-right corner of the raster exactly aligns with coordinate ('x'+'width', 'y'+'height').

The SVG specification does not specify when an image that is not being displayed should be loaded. An SVG user agent is not required to load image data for an image that is not displayed (e.g. is is outside the initial document viewport), except when that image is contained inside a subtree for which 'externalResourcesRequired' is set to "true". However, it should be noted that this may cause a delay when an image becomes visible for the first time. In the case where an author wants to suggest that the SVG user agent loads image data before it is displayed, they should use the 'prefetch' element.

Note that an SVG user agent may choose to incrementally render an image as it is loading but is not required to do so.

Schema: image

    <define name='image'>
      <element name='image'>
        <ref name='image.AT'/>
        <ref name='image.CM'/>
      </element>
    </define>

    <define name='image.AT' combine='interleave'>
      <ref name='svg.Core.attr'/>
      <ref name='svg.FocusHighlight.attr'/>
      <ref name='svg.Media.attr'/>
      <ref name='svg.XLinkEmbed.attr'/>
      <ref name='svg.Conditional.attr'/>
      <ref name='svg.External.attr'/>
      <ref name='svg.Focus.attr'/>
      <ref name='svg.Transform.attr'/>
      <ref name='svg.Opacity.attr'/>
      <ref name='svg.XYWH.attr'/>
      <ref name='svg.PAR.attr'/>
      <ref name='svg.ContentType.attr'/>
    </define>

    <define name='image.CM'>
      <zeroOrMore>
        <choice>
          <ref name='svg.Desc.group'/>
          <ref name='svg.Animate.group'/>
          <ref name='svg.Discard.group'/>
          <ref name='svg.Handler.group'/>
        </choice>
      </zeroOrMore>
    </define>

Attribute definitions:

x = "<coordinate>"

The x-axis coordinate of one corner of the rectangular region.

If the attribute is not specified, the effect is as if a value of "0" were specified.

Animatable: yes.

y = "<coordinate>"

The y-axis coordinate of one corner of the rectangular region.

If the attribute is not specified, the effect is as if a value of "0" were specified.

Animatable: yes.

width = "<length>"

The width of the rectangular region.

A negative value is unsupported. A value of zero disables rendering of the element. If the attribute is not specified, the effect is as if a value of "0" were specified.

Animatable: yes.

height = "<length>"

The height of the rectangular region.

A negative value is unsupported. A value of zero disables rendering of the element. If the attribute is not specified, the effect is as if a value of "0" were specified.

Animatable: yes.

preserveAspectRatio = "[defer] <align> [<meet>]"

See attribute definition for description.

Animatable: yes.

xlink:href = "<IRI>"

An IRI Reference to the image. An invalid IRI reference is an unsupported value. An empty attribute value (xlink:href="") disables rendering of the element. The lacuna value is the empty string.

Animatable: yes.

type = "<content-type>"

A hint about the expected Internet Media Type of the raster image. Implementations may choose to not fetch images of formats that they do not support. Note that if an Internet Media type returned by the server, the server metadata is authoritative over the type attribute. See Metadata hints in specifications in the Authoritative Metadata TAG finding ([MIME-RESPECT], section 5). For optimizing download time by requiring a particular content format authors are encouraged to use 'requiredFormats', instead of 'type'.

Animatable: no.

focusable = "true" | "false" | "auto"

See attribute definition for description.

Animatable: Yes

Navigation Attributes

See definition.

An example:

Example: 05_21.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
     version="1.2" baseProfile="tiny">

  <desc>This document has a reference to an external image</desc>

  <image x="200" y="200" width="100" height="100" xlink:href="externalImage.png">
    <title>External image</title>
  </image>
</svg>

5.8 Conditional processing

5.8.1 Conditional processing overview

SVG provides a 'switch' element and five conditional processing attributes — 'requiredExtensions', 'requiredFeatures', 'requiredFonts', 'requiredFormats' and 'systemLanguage' — which provide the ability to specify alternate content depending on the capabilities of a given SVG user agent or the user's language.

Schema: conditional

    <define name='svg.Conditional.attr' combine='interleave'>
      <optional>
        <attribute name='requiredFeatures' svg:animatable='false' svg:inheritable='false'>
          <ref name='ListOfIRI.datatype'/>
        </attribute>
      </optional>
      <optional>
        <attribute name='requiredExtensions' svg:animatable='false' svg:inheritable='false'>
          <ref name='ListOfIRI.datatype'/>
        </attribute>
      </optional>
      <optional>
        <attribute name='requiredFormats' svg:animatable='false' svg:inheritable='false'>
          <ref name='FormatList.datatype'/>
        </attribute>
      </optional>
      <optional>
        <attribute name='requiredFonts' svg:animatable='false' svg:inheritable='false'>
          <ref name='FontList.datatype'/>
        </attribute>
      </optional>
      <optional>
        <attribute name='systemLanguage' svg:animatable='false' svg:inheritable='false'>
          <ref name='LanguageIDs.datatype'/>
        </attribute>
      </optional>
    </define>

Conditional processing attributes do not affect the processing of all elements. They can be specified only on graphics elements, container elements, text content elements, descriptive elements, timed elements and the 'foreignObject' and 'discard' elements. A conditional processing attribute on any other element does not affect whether that element will be processed. For example, a 'requiredExtensions' attribute on a 'script' element will not control whether the script is executed.

The conditional processing attributes act as boolean tests and evaluate to either true or false. If one is not specified, then it is assumed to evaluate to true. The attributes can be used in two ways, depending on the context of the element on which the attributes are specified. If the element's parent node is a 'switch' element, then at most one of the 'switch' element's children that conditional processing attributes apply to will be processed. (See the description of the 'switch' element for details.) Otherwise, if the element's parent node is not a 'switch' element, and conditional processing attributes do apply to the element, then the attributes determine whether that element will be processed.

What it means for an element not to be processed because of conditional processing attributes specified on it, or because it is a child of a 'switch' that has selected a different child for processing, depends on the type of element:

If the element is a graphics element, container element, text content element or a 'foreignObject' element, then the element is not rendered and is not a part of the rendering tree.
If the element is a timed element, then the element will never begin, regardless of its timing attributes and any invocations of methods on the SVGTimedElement and ElementTimeControl interfaces. If the element serves as a syncbase for any other timed elements in the document, then those syncbase references will never resolve to a concrete time. Thus, for example, if the element is an animation element, the animation will never have an effect, and if the element is an 'audio' element, then it will never generate any sound.
If the element is a 'discard' element, then it will never trigger the removal of its target element, nor will it remove itself.

Similar to the 'display' property, conditional processing attributes only affect the direct rendering and processing of applicable elements and do not prevent elements from being successfully referenced by other elements (such as via a 'use'). Conditional processing attributes in a shadow tree are processed normally.

Example systemLanguage below displays one of three text strings (in Welsh, Greek, or Spanish) if one of those is the user's preferred language. Otherwise, in this example, it displays nothing.

Example: systemLanguage.svg

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink"
     version="1.2" baseProfile="tiny" viewBox="0 0 170 200">

  <title>systemLanguage example</title>

  <switch>
    <g systemLanguage="cy">
      <text x="20" y="220" xml:lang="cy" font-size="20">Pam dydyn nhw ddim yn
        siarad Cymraeg?</text>
    </g>
    <g systemLanguage="el">
      <text x="20" y="220" xml:lang="el-GR" font-size="22">Μα γιατί δεν μπορούν
        να μιλήσουν Ελληνικά ;</text>
    </g>
    <g systemLanguage="es">
      <text x="20" y="220" xml:lang="es-ES" font-size="18">¿Por qué no pueden
        simplemente hablar en castellano?</text>
    </g>
  </switch>
</svg>

5.8.2 The 'switch' element

The 'switch' element is a container element that can be used to select one of its child elements to process based on their conditional processing attributes. The first direct child element of a 'switch' whose conditional processing attributes all evaluate to true will be processed as normal. All other direct child elements of the 'switch' that support conditional processing attributes will not be processed. The elements that support conditional processing attributes are listed in the Conditional processing overview section, above.

While conditional processing attributes are supported only on certain elements, those attributes on all direct child elements of a 'switch' are used to determine which children to disable processing for.

The values of the 'display' and 'visibility' properties have no effect on 'switch' element processing. In particular, setting 'display' to none on a child of a 'switch' element has no effect on the testing associated with 'switch' element processing.

Note that regardless of whether they are processed or disabled, child elements of the 'switch' element are still part of the DOM, and rules applying to the uniqueness of the 'id' and 'xml:id' attributes still apply. Additionally, elements which would not otherwise be rendered due to conditional processing can still be referenced, for example as the target of a 'use' element or as a paint server reference in a 'fill' property.

The element definition schema and content model for 'switch' are not defined here. It is defined in all the places it can occur.

Schema: switch.at

    <define name='switch.AT' combine='interleave'>
      <ref name='svg.Core.attr'/>
      <ref name='svg.Conditional.attr'/>
      <ref name='svg.Properties.attr'/>
      <ref name='svg.FocusHighlight.attr'/>
      <ref name='svg.External.attr'/>
      <ref name='svg.Transform.attr'/>
      <ref name='svg.Focus.attr'/>
    </define>

For more information and an example, see Embedding foreign object types.

Attribute definitions:

requiredExtensions = "<list-of-strings>"

See attribute definition for description.

Animatable: no.

requiredFeatures = "<list-of-strings>"

See attribute definition for description.

Animatable: no.

requiredFonts = "<list-of-strings>"

See attribute definition for description.

Animatable: no.

requiredFormats = "<list-of-content-types>"

See attribute definition for description.

Animatable: no.

systemLanguage = "<list-of-language-ids>"

See attribute definition for description.

Animatable: no.

focusable = "true" | "false" | "auto"

See attribute definition for description.

Animatable: yes.

Navigation Attributes

See definition.

5.8.3 The 'requiredFeatures' attribute

Definition of 'requiredFeatures':

requiredFeatures = "<list-of-strings>"

A conditional processing attribute that controls conditional processing based on whether the specified features are supported by the SVG user agent. The value is a list of feature strings, with the individual values separated by white space. Only feature strings defined in an existing version of the SVG specification at the time the document is authored (such as those listed in this document's Feature String appendix) should be used, while third party extension features that are not part of an SVG standard should be indicated using the 'requiredExtensions' attribute instead.

This attribute evaluates to true for the purpose of conditional processing if and only if all of the specified features are supported. As with all conditional processing attributes, if 'requiredFeatures' is not specified, then it implicitly evaluates to true. However, if the attribute is specified, but has an empty string value, it evaluates to false. See Conditional processing overview for details on how conditional processing attributes influence document processing.

Animatable: no.

5.8.4 The 'requiredExtensions' attribute

The 'requiredExtensions' attribute specifies a list of required language extensions. Language extensions are capabilities within an SVG user agent that go beyond the feature set defined in this specification. Each extension is identified by an IRI reference.

Definition of 'requiredExtensions':

requiredExtensions = "<list-of-strings>"

A conditional processing attribute that controls conditional processing based on whether the specified extensions are supported by the SVG user agent. The value is a list of IRI references which identify the required extensions, with the individual values separated by white space.

This attribute evaluates to true for the purpose of conditional processing if and only if all of the specified extensions are supported. As with all conditional processing attributes, if 'requiredExtensions' is not specified, then it implicitly evaluates to true. However, if the attribute is specified, but has an empty string value, it evaluates to false. See Conditional processing overview for details on how conditional processing attribute influence document processing.

Animatable: no.

Since white space is used to separate values in the attribute, any white space characters in the IRI reference must be escaped.

5.8.5 The 'systemLanguage' attribute

Definition of 'systemLanguage':

systemLanguage = "<list-of-language-ids>"

A conditional processing attribute that controls conditional processing based on the system language. The value is a comma-separated list of language tags as defined in BCP 47 ([BCP 47], section 2).

This attribute evaluates to true for the purpose of conditional processing if one of the languages indicated by user preferences equals one of the languages given in the value of this attribute, or if one of the languages indicated by user preferences exactly equals a prefix of one of the languages given in the value of this attribute such that the first tag character following the prefix is U+002D HYPHEN-MINUS ("-"). As with all conditional processing attributes, if 'systemLanguage' is not specified, then it implicitly evaluates to true. However, if the attribute is specified, but has an empty string value, it evaluates to false. See Conditional processing overview for details on how conditional processing attribute influence document processing.

Animatable: no.

Note that the use of a prefix matching rule to determine whether the attribute evaluates to true or false does not imply that language tags are assigned to languages in such a way that it is always true that if a user understands a language with a certain tag, then this user will also understand all languages with tags for which this tag is a prefix. The prefix rule simply allows the use of prefix tags if this is the case.

Implementation note: When making the choice of linguistic preference available to the user, implementers should take into account the fact that users are not familiar with the details of language matching as described above, and should provide appropriate guidance. As an example, users may assume that on selecting "en-GB", they will be served any kind of English document if British English is not available. The user interface for setting user preferences should guide the user to add "en" to get the best matching behavior.

Multiple languages may be listed for content that is intended for multiple audiences. For example, content that is presented simultaneously in the original Maori and English versions, would call for:

<text systemLanguage="mi, en"><!-- content
  goes here --></text>

However, just because multiple languages are present within the element on which the 'systemLanguage' conditional processing attribute is placed, this does not mean that it is intended for multiple linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin," which is clearly intended to be used by an English-literate audience. In this case, the 'systemLanguage' conditional processing attribute should only include "en".

Authoring note: Authors should realize that if several alternative language objects are enclosed in a 'switch', and none of them matches, this may lead to situations where no content is displayed. It is thus recommended to include a "catch-all" choice at the end of such a 'switch' which is acceptable in all cases.

5.8.6 The 'requiredFormats' attribute

Many resources, especially media such as audio and video, have a wide range of formats. As it is often not possible to require support for a particular format, due to legal or platform restrictions, it is often necessary for content to provide alternatives so that SVG user agents can choose the format they support. The 'requiredFormats' attribute can be used to control conditional processing based on whether a particular format is supported by the user agent.

Definition of 'requiredFormats':

requiredFormats = "<list-of-content-types>"

A conditional processing attribute that controls conditional processing based on whether the specified formats are supported by the SVG user agent. The value is a list of Internet media types, with the individual values separated by white space. For a list of registered Internet media types (formerly called MIME types), see the IANA Media Type registry [MIMETYPES]. For a list of Internet media types types for audio and video codecs, see the IANA codec registry and WAVE and AVI Codec Registries [CODECS, RFC2361].

As with all conditional processing attributes, if 'requiredFormats' is not specified, then it implicitly evaluates to true. However, if the attribute is specified, but has an empty string value, it evaluates to false. See Conditional processing overview for details on how conditional processing attribute influence document processing.

Animatable: no.

The following formats must always evaluate to true in conforming SVG viewers:

image/png
image/jpeg
image/svg+xml

5.8.7 The 'requiredFonts' attribute

If the author wishes to have complete control over the appearance and location of text in the document then they must ensure that the correct font is used when rendering the text. This can be achieved by using SVG fonts and embedding the font in the document. However, this is not practical in all cases, especially when the number of glyphs used is very large or if the licensing of the font forbids such embedding.

Definition of 'requiredFonts':

requiredFonts = "<list-of-family-names>"

A conditional processing attribute that controls conditional processing based on whether the specified fonts are available. The value is a list of font family names, using the same syntax as the 'font-family' property, for example when processing quoted strings, multiple, leading and trailing spaces, and case sensitivity. Generic family names may not be used, however.

This attribute evaluates to true for the purpose of conditional processing if and only if all of the specified fonts are available, either installed on the system or as an SVG font defined or embedded within the document. As with all conditional processing attributes, if 'requiredFonts' is not specified, then it implicitly evaluates to true. However, if the attribute is specified, but has an empty string value, it evaluates to false. See Conditional processing overview for details on how conditional processing attribute influence document processing.

Animatable: no.

5.9 External resources

5.9.1 The 'externalResourcesRequired' attribute

Documents often reference and use the contents of other document and other web resources as part of their rendering or processing. In some cases, authors want to specify that particular resources are required for a document to be considered correct.

The 'externalResourcesRequired' attribute is available on all container elements except 'defs' and on all elements which potentially can reference external resources. It specifies whether referenced resources that are not part of the current document are required for proper rendering of the given element.

Attribute definition:

externalResourcesRequired = "false" | "true"

An attribute that specifies whether external resources are required for correct rendering of this element and its descendants.

false: (The lacuna value.) Indicates that resources external to the current document are optional. Document rendering can proceed even if external resources are unavailable to the current element and its descendants.
true: Indicates that resources external to the current document are required. If an external resource is not available (for example the request for the required resource times out), progressive rendering is suspended, the load event is not fired for the element, and the document goes into an error state (see Error processing). The document remains in an error state until all required resources become available.

Animatable: no.

Attribute 'externalResourcesRequired' is not inheritable (from a sense of attribute value inheritance), but if set on a container element, its value will apply to all elements within the container.

Because setting externalResourcesRequired="true" on a container element will have the effect of disabling progressive display of the contents of that container, if that container includes elements that reference external resources, tools that generate SVG content should normally not just set externalResourcesRequired="true" on the 'svg' element on a universal basis. Instead, it is better to specify externalResourcesRequired="true" on those particular elements which specifically need the availability of external resources in order to render properly.

5.9.2 Progressive rendering

When progressively downloading a document, an SVG user agent conceptually builds a tree of nodes in various states. The possible states for these nodes are unresolved, resolved and error.

This description uses two conceptual parsing events to simplify the prose in explaining the intended behaviour of progressive rendering. The events referred to in the following prose are the start element and end element events. The start element event is considered to be triggered when a start-tag or an empty-element tag is read. The end element event occurs either immediately following the start element event in the case of an empty-element tag, or when an end-tag is read. The terms start-tag, end-tag and empty-element tag are as defined in Extensible Markup Language (XML) 1.0 ([XML10], section 3.1) and Extensible Markup Language (XML) 1.1 ([XML11], section 3.1).

When loading a document following the start element event on a node, that node becomes part of the document tree in the unresolved state. It is appended as the last child of the most recently opened element that is still open (that is, the most recent element for which a start element event has occurred with no corresponding end element event). If the node's dependencies are successfully resolved, then the node enters the resolved state or if the node's dependencies are found to be in error, then the node enters the error state.

When an end element event occurs for a 'script' element, that element is processed according to the Script processing section of the Scripting chapter. Further parsing of the document will be blocked until processing of the 'script' is complete.

Node dependencies include both children content (like the child elements on a 'g') and resources (e.g. images referenced by an 'image') referenced from that node or from its children. Empty elements (elements without children) become resolved when the end element event occurs on the element; elements with child nodes become resolved when all their children are resolved and when the end element event occurs on the element. Resources become resolved (or found in error) by an SVG user agent specific mechanism.

SVG user agents must implement progressive rendering although there is no minimum rendering update frequency required for conformance. Implementations should find their own balance between processing the changes in the document tree and rendering the tree to produce a smooth rendering avoiding significant pauses. The following rules apply to progressive rendering:

The SVG user agent has the opportunity to update the rendering following each start element and/or end element event, i.e. each time the SVG user agent parses a start-tag, empty-element tag or end-tag.
The SVG user agent renders the conceptual document tree nodes in document order up to, and not including the first node in the unresolved state which has 'externalResourcesRequired' set to "true". Nodes in the resolved state are always rendered. Nodes in the unresolved state but with 'externalResourcesRequired' set to "false" are rendered in their current state. If the node has no rendering (e.g, an 'image' pending a resource), then nothing is rendered for that node.
If a node enters the error state then the document enters the error state and progressive rendering stops.

Note that even if the SVG user agent has the opportunity to update the rendering after each start/end element event there are situations where such an update shouldn't be done. For example, 'font' element children ('font-face', 'hkern', 'missing-glyph', 'glyph') should not cause an update of the document rendering, only the end element event on the 'font' element should cause a document rendering as for other node types.

Note that forward referencing from a 'discard' element should be avoided when using progressive rendering. If it fails to find (and thus discard) an element, it will not later discard the element when it has finally loaded.

In Example progRend01 below, the 'g' element rendering may start when the 'g' end-tag has been parsed and processed and when all the resources needed by its children have been resolved. This means that the group's rendering may start when the group has been fully parsed and myImage.png has been successfully retrieved.

Example: progRend01.svg

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
     version="1.2" baseProfile="tiny" viewBox="0 0 480 360">

  <desc>externalResourcesRequired example.</desc>

  <g externalResourcesRequired="true">
    <rect xml:id="rect_1" width="5" height="7"/>
     ...
    <rect xml:id="rect_1000" width="5" height="7"/>

    <image xlink:href="myImage.png" width="5" height="7" externalResourcesRequired="true"/>
    <rect xml:id="rect_1001" width="5" height="7"/>
  </g>
</svg>

Example progRend02 demonstrates how progressive rendering is performed when there is a 'use' element with a forward reference.

Example: progRend02.svg

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
     version="1.2" baseProfile="tiny" viewBox="0 0 480 360">

  <desc>Forward reference of use element</desc>

  <use xlink:href="#myRect" x="200" fill="green"/>
  <circle cx="450" cy="50" r="50" fill="yellow"/>

  <g fill="red">
    <rect xml:id="myRect" width="100" height="100"/>
  </g>
</svg>

The following list shows the possible renderings of the document as it is parsed (the rendering state follows the colon):

'use' → start element: empty
'circle' → start element: yellow circle
'g' → start element: no update
'rect' → start element (use reference becomes resolved): green rect, yellow circle, red rect

Example progRend03 demonstrates how progressive rendering is performed when there is a 'use' element with a forward reference and which has externalResourcesRequired="true".

Example: progRend03.svg

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
     version="1.2" baseProfile="tiny" viewBox="0 0 480 360">

  <desc>Forward reference on use with eRR=true</desc>

  <use xlink:href="#myGroup" x="200" fill="green" externalResourcesRequired="true"/>
  <circle cx="450" cy="50" r="50" fill="yellow"/>

  <g fill="red">
    <g xml:id="myGroup">
      <rect xml:id="myRect" width="100" height="100"/>
      <use xlink:href="#myRect" x="50" fill="purple"/>
    </g>
  </g>
</svg>

The possible rendering states are as follows:

'use' → start element: empty
'circle' → start element: empty 'use' is unresolved, externalResourcesRequired="true", rendering is stopped at the 'use')
Outer 'g' → start element: no update
Inner 'g' → start element: no update (use is resolved but externalResourcesRequired="true" so rendering may not proceed until that reference enters the resolved state)
'rect' → start element: no update
'use' → start element: no update
Inner 'g' → end element (#myGroup reference becomes resolved, rendering can proceed): green rect, purple rect, yellow circle, red rect, purple rect

Example progRend04 shows a 'use' element with a reference to an element that is in a container with externalResourcesRequired="true".

Example: progRend04.svg

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
     version="1.2" baseProfile="tiny" viewBox="0 0 480 360">

  <desc>Forward reference to a use under a container with eRR=true</desc>

  <use xlink:href="#myRect" x="200" fill="green"/>
  <circle cx="250" cy="50" r="50" fill="pink"/>

  <g fill="red" externalResourcesRequired="true">
    <circle cx="450" cy="50" r="50" fill="yellow"/>
    <rect xml:id="myRect" width="100" height="100"/>
  </g>
</svg>

The possible rendering states as the document is parsed are as follows:

'use' → start element: empty
Pink 'circle' → start element: pink circle
'g' → start element: no update (rendering is suspended because of externalResourcesRequired="true" on the 'g' element, i.e. because the children of 'g' are not resolved at the time of parsing of the start tag of the 'g').
Yellow 'circle' → start element: no update (rendering suspended because of 'g')
'rect' → start element: no update
'g' → end element (resources referenced by 'use' become resolved and can be rendered, so rendering can proceed): green rect, pink circle, yellow circle, red rect

Example progRend05 shows an example of progressive rendering with a forward reference to an SVG font. Rendering updates do not occur mid-way through parsing a 'font' element.

Example: progRend05.svg

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
     version="1.2" baseProfile="tiny" viewBox="0 0 480 360">

  <desc>Font Resolution Example</desc>

  <text x="240" y="230" text-anchor="middle" font-size="120"
        font-family="fontC, fontB, fontA">A</text>

  <defs>
    <font xml:id="fontA" horiz-adv-x="224" >
      <font-face
        font-family="fontA"
        units-per-em="1000"
        panose-1="0 0 0 0 0 0 0 0 0 0"
        ascent="917"
        descent="-250"
        alphabetic="0"/>
      <missing-glyph horiz-adv-x="800" d="..." />
      <glyph unicode="A" glyph-name="A"  d="..."/>
    </font>

    <font xml:id="fontB" horiz-adv-x="224">
      <font-face
        font-family="fontB"
        units-per-em="1000"
        panose-1="0 0 0 0 0 0 0 0 0 0"
        ascent="917"
        descent="-250"
        alphabetic="0"/>
      <missing-glyph horiz-adv-x="800" d="..."/>
      <glyph unicode="A" glyph-name="B" d="..." />
    </font>

    <font xml:id="fontC" horiz-adv-x="224" >
      <font-face
        font-family="fontC"
        units-per-em="1000"
        panose-1="0 0 0 0 0 0 0 0 0 0"
        ascent="917"
        descent="-250"
        alphabetic="0"/>
      <missing-glyph d="..."/>
      <glyph unicode="A" glyph-name="C" d="..."/>
    </font>
  </defs>
</svg>

Rendering update possibilities as the document is parsed are as follows:

'text' → start element: "A" rendered with the default font
'defs' → start element: no update
#fontA → start element: no update
#fontA / 'font-face' → start element: no update
#fontA / 'missingGlyph' → start element: no update
#fontA / 'glyph' → start element: no update
#fontA → end element: "A" rendered with fontA (represents current document state rendering)
#fontB → start element: no update
#fontB / 'font-face' → start element: no update
#fontB / 'missingGlyph' → start element: no update
#fontB / 'glyph' → start element: no update
#fontB → end element: "A" rendered with fontB (represents current document state rendering)
#fontC → start element: no update
#fontC / 'font-face' → start element: no update
#fontC / 'missingGlyph' → start element: no update
#fontC / 'glyph' → start element: no update
#fontC → end element: "A" rendered with fontC (represents current document state rendering)

5.9.3 The 'prefetch' element

SVG 1.1 did not specify when an SVG user agent should begin downloading referenced media. This lead to implementation differences particularly when the media was not used in the initial document state (e.g. it was offscreen or hidden). SVG Tiny 1.2 does not require SVG user agents to download referenced media that is not visible at the time the document is loaded, unless those media are contained inside a subtree for which 'externalResourcesRequired' is set to "true". This means there may be a pause to download the file the first time a piece of media is displayed. More advanced SVG user agents may wish to predict that particular media streams will be needed and therefore download them in anticipation.

SVG Tiny 1.2 therefore adds functionality to allow content developers to suggest prefetching content from the server before it is needed to improve the rendering performance of the document. The SMIL 2.1 'prefetch' element ([SMIL21], section 4.4) has been incorporated into SVG as the 'prefetch' element, with the following modifications:

Attributes cannot be given <percent-value> values.
The 'xlink:href' attribute is permitted to point into the document in which the 'prefetch' element appears so that this feature can be used as a hint indicating how much of the document is required before playback can start.
In order to adequately support non-local IRI references, the 'mediaCharacterEncoding' and 'mediaContentEncodings' attributes have been added.

The 'prefetch' element provides a hint to the SVG user agent that media will be used in the future and the author would like part or all of it fetched ahead of time to make document playback smoother. As it is a hint, user agents may ignore 'prefetch' elements, although doing so may cause an interruption in the document playback when the resource is needed. It gives authoring tools and authors the ability to schedule retrieval of resources when they think that there is available bandwidth or time to do it.

When instead of referring to external media, 'prefetch' refers to the same document it occurs in, then it can only reference a top level 'g' element. A top level 'g' element is a 'g' element that is a direct child of the rootmost 'svg' element.

To enable smooth playback during progressive downloading in this scenario, it is recommended that each adjacent top level 'g' elements contain adjacent chronological scenes in the animation. In this case the 'prefetch' element must appear in a 'defs' block before all defined 'g' elements in the document. In such cases, 'prefetch' is used to tell the SVG user agent how much it needs to buffer in order to be able to play content back in a smooth and predictable manner.

Schema: prefetch

    <define name='prefetch'>
      <element name='prefetch'>
        <ref name='prefetch.AT'/>
        <ref name='prefetch.CM'/>
      </element>
    </define>

    <define name='prefetch.AT' combine='interleave'>
      <ref name='svg.Core.attr'/>
      <ref name='svg.XLinkRequired.attr'/>
      <optional>
        <attribute name='mediaSize' svg:animatable='false' svg:inheritable='false'>
          <ref name='Number.datatype'/>
        </attribute>
      </optional>
      <optional>
        <attribute name='mediaTime' svg:animatable='false' svg:inheritable='false'><text/></attribute>
      </optional>
      <optional>
        <attribute name='mediaCharacterEncoding' svg:animatable='false' svg:inheritable='false'><text/></attribute>
      </optional>
      <optional>
        <attribute name='mediaContentEncodings' svg:animatable='false' svg:inheritable='false'><text/></attribute>
      </optional>
      <optional>
        <attribute name='bandwidth' svg:animatable='false' svg:inheritable='false'>
          <choice>
            <ref name='Number.datatype'/>
            <value>auto</value>
          </choice>
        </attribute>
      </optional>
    </define>

    <define name='prefetch.CM'>
      <zeroOrMore>
        <ref name='svg.Desc.group'/>
      </zeroOrMore>
    </define>

Attribute definitions:

mediaSize = "<long>"

Defines how much of the media to fetch in bytes as a function of the file size of the media.

When 'prefetch' refers to a resource in the same document (i.e. a top level 'g' element), the 'mediaSize' attribute indicates the size in bytes of the 'g' element and its children. That size corresponds to the encodings used when transmitting the document. If the document is encoded in UTF-8 [RFC3629] and gzipped [RFC1952], then the size of the gzipped UTF-8 fragment applies. If that same document were decompressed and transcoded to UTF-16 [RFC2781] the hints will become stale. Since streaming hints are to be used primarily in streaming scenarios, it is not expected that hint staleness will occur frequently.

Animatable: no.

mediaTime = "<clock-value>"

Defines how much of the media to fetch as a function of the duration of the media. For discrete media (non-time based media such as PNG) using this attribute causes the entire resource to be prefetched.

When 'prefetch' refers to a resource in the same document (i.e. a top level 'g' element), this is the active duration of the referenced element. In cases where the exact active duration can not be calculated beforehand (e.g. if the end of an animation depends on user interaction), it is suggested that the content author estimate the minimum active duration for the referenced element. This estimate, even if zero, will allow the SVG user agent to calculate how much of the overall document to download before beginning playback in a streaming scenario.

Animatable: no.

bandwidth = "<long>"

Defines how much network bandwidth, in bits per second, the SVG user agent should use when performing the prefetch. If the attribute is not specified, all available bandwidth should be used.

Animatable: no.

mediaCharacterEncoding = "<string>"

Indicates the XML character set encoding (UTF-8, ISO-8859-1, etc.) that the 'mediaSize' attribute applies to. Tools that produce SVG should include this attribute if they specify the 'mediaSize' attribute. The main use of this attribute is to know what character encoding was used when measuring 'mediaSize' so that staleness of the hints may be easily detected. If the attribute is not specified, the encoding that was used to calculate the size is that which is returned by the server.

Animatable: no.

mediaContentEncodings = "<list-of-strings>"

The 'mediaContentEncodings' attribute is a white space separated list of the content encodings as defined in section 3.5 of HTTP/1.1 [RFC2616] (gzip, compress, etc.) that the 'mediaSize' attribute applies to. The order of the list is the order in which the content encodings were applied to encode the data. Note that while situations in which multiple content codings are applied are currently rare, they are allowed by HTTP/1.1 and thus that functionality is supported by SVG. Tools that produce SVG must include this attribute if they specify the 'mediaSize' attribute and the Content-Encoding is other than the identity encoding. The main use of this attribute is to know what parameters were used when measuring 'mediaSize' so that staleness of the hints may be easily detected. If the 'mediaContentEncodings' attribute is not specified it is as if the identity encoding value from HTTP/1.1 had been specified. This indicates that no transformation (i.e. encodings) at all has been used.

Animatable: no.

xlink:href = "<IRI>"

An IRI reference to the resource to prefetch. An invalid IRI reference is an unsupported value. An empty attribute value (xlink:href="") means that no prefetching will occur. The lacuna value is the empty string.

Animatable: no.

When 'prefetch' refers to external media, if both 'mediaSize' and 'mediaTime' are specified, then 'mediaSize' shall be used and 'mediaTime' is ignored. If neither 'mediaSize' nor 'mediaTime' is specified, the behavior is that the entire resource should be fetched.

When 'prefetch' refers to a resource in the same document (i.e. a top level 'g' element), both the 'mediaSize' and 'mediaTime' attributes can be used together by a more advanced SVG user agent to determine how much it needs to buffer in order to be able to play content back in a smooth manner.

Example prefetch01 demonstrates the use of the 'prefetch' element when it refers to external media:

Example: prefetch01.svg

<svg width="400" height="300" version="1.2"
        xmlns="http://www.w3.org/2000/svg" baseProfile="tiny"
        xmlns:xlink="http://www.w3.org/1999/xlink">

     <desc>
        Prefetch the large images before starting the animation
        if possible.
     </desc>

     <defs>
       <prefetch xlink:href="http://www.example.com/images/huge1.png"/>
       <prefetch xlink:href="http://www.example.com/images/huge2.png"/>
       <prefetch xlink:href="http://www.example.com/images/huge3.png"/>
     </defs>

     <image x="0" y="0" width="400" height="300"
        xlink:href="http://www.example.com/images/huge1.png"
        display="none">

        <set attributeName="display" to="inline" begin="10s"/>
 
        <animate attributeName="xlink:href" values="
               http://www.example.com/images/huge1.png;
               http://www.example.com/images/huge2.png;
               http://www.example.com/images/huge3.png"
            begin="15s" dur="30s"/>
     </image>

   </svg>

Example prefetch02 is an example of the 'prefetch' element referring to a resource in the same document (i.e. a top level 'g' element):

Example: prefetch02.svg

<?xml version="1.0" encoding="utf-8"?>
<svg width="400" height="300" version="1.2"
        xmlns="http://www.w3.org/2000/svg" baseProfile="tiny"
        xmlns:xlink="http://www.w3.org/1999/xlink"
        timelineBegin="onStart"
        playbackOrder="forwardOnly">

     <desc>
        Example of using SVGT 1.2 features for smooth playback
        during progressive downloading.
     </desc>

     <defs>

       <prefetch xlink:href="#scene1"
                 mediaCharacterEncoding="UTF-16"
                 mediaTime="5s" mediaSize="94230" />

       <prefetch xlink:href="#scene2"
                 mediaCharacterEncoding="UTF-16"
                 mediaTime="10s" mediaSize="283474" />

       <prefetch xlink:href="#scene3"
                 mediaCharacterEncoding="UTF-16"
                 mediaTime="15s" mediaSize="627638" />

     </defs>

     <g xml:id="scene1">
       <discard begin="6s"/>
       <!-- graphics for scene 1 go here -->
     </g>

     <g xml:id="scene2">
       <discard begin="16s"/>
       <!-- graphics for scene 2 go here -->
     </g>

     <g xml:id="scene3">
       <discard begin="21s"/>
       <!-- graphics for scene 3 go here -->
     </g>

</svg>

5.10 Common attributes

5.10.1 Attributes common to all elements: 'id', 'xml:id', 'xml:base', 'class', 'role', 'rel', 'rev', 'about', 'content', 'datatype', 'property', 'resource', and 'typeof'

The 'id', 'xml:id', 'xml:base', 'class', 'role', 'rel', 'rev', 'about', 'content', 'datatype', 'property', 'resource', and 'typeof' attributes are available on all elements defined by SVG Tiny 1.2. Some of these elements, such as 'xml:id', 'id', and 'xml:base' may have a direct effect on the structure and rendering of SVG, while others may only affect SVG indirectly, or may be used only for auxiliary processing of SVG content. See extensible metadata attributes for more details.

Attribute definitions:

id = "<ID>"

This attribute specifies a unique identifier for the element. Refer to xml:id Version 1.0 [XMLID]. It is recommended that new content use 'xml:id' instead.

Animatable: no.

xml:id = "<ID>"

This attribute specifies a unique identifier for the element. Refer to xml:id Version 1.0 [XMLID]. Recommended for new content.

Animatable: no.

xml:base = "<IRI>"

This attribute specifies a base IRI.

Animatable: no.

class = "<XML-NMTOKENS>"

This attribute indicates membership in one or more sets. Any number of elements may be assigned to the same set. Multiple set names must be separated by white space characters.

Animatable: yes.

role = "<list-of-strings>"

This attribute indicates membership in one or more sets. Any number of elements may be assigned to the same set. Multiple set names must be separated by white space characters.

Animatable: yes.

rel = "<list-of-strings>"

This attribute indicates membership in one or more sets. Any number of elements may be assigned to the same set. Multiple set names must be separated by white space characters.

Animatable: yes.

rev = "<list-of-strings>"

This attribute indicates membership in one or more sets. Any number of elements may be assigned to the same set. Multiple set names must be separated by white space characters.

Animatable: yes.

about = "<list-of-strings>"

This attribute indicates membership in one or more sets. Any number of elements may be assigned to the same set. Multiple set names must be separated by white space characters.

Animatable: yes.

content = "<string>"

This attribute contains plain text strings to be interpreted as appropriate.

Animatable: yes.

datatype = "<string>"

This attribute denotes a datatype for an attribute with a plain text string.

Animatable: yes.

property = "<list-of-strings>"

This attribute indicates membership in one or more sets. Any number of elements may be assigned to the same set. Multiple set names must be separated by white space characters.

Animatable: yes.

resource = "<string>"

This attribute contains a reference to a resource, normally expressed with an IRI reference

Animatable: yes.

typeof = "<list-of-strings>"

This attribute indicates membership in one or more sets. Any number of elements may be assigned to the same set. Multiple set names must be separated by white space characters.

Animatable: yes.

The 'id' and 'xml:id' attributes

Both the 'xml:id' and 'id' attributes specify a unique identifier for the element. 'xml:id' is intended to represent type <ID> universally across all document types.

It is strongly recommended that SVG generators only use 'xml:id' to assign identity to elements. For backwards compatibility purposes, one may also specify the 'id' attribute but such an approach is not without issues:

The 'id' attribute may be deprecated in a future version of this specification, and therefore SVG generators should transition to using 'xml:id' only as early as possible.
There remains only one single id field on the SVGElement interface, therefore when it is updated both attributes must be updated correspondingly.
Consequently, since the id attribute of the SVGElement interface is updated when one of the attribute values is modified (e.g. using by the setAttributeNS(), setTraitNS() or setTrait() methods), the other attribute must be set to the same value.
When both 'id' and 'xml:id' are specified on the same element but with different values, the SVGElement::id field must return the value of the 'xml:id' attribute.
When both 'id' and 'xml:id' are specified on the same element, implementations should not consider the 'id' attribute to be of type ID.

The 'xml:base' attribute

This attribute specifies a base IRI other than the base IRI of the document or external entity. Refer to XML Base [XML-BASE].

The 'class' attribute

The 'class' attribute assigns one or more class names to an element. The element may be said to belong to these classes. A class name may be shared by several element instances. The class attribute has several roles:

As a style sheet selector (when an author wishes to assign style information to a set of elements). Note: SVG Tiny 1.2 does not mandate the support of style sheets.
For general purpose processing by user agents.

The 'role' attribute

The 'role' attribute assigns one or more role values to an element. The element may be said to have these roles. A role value may be shared by several element instances. Unlike the 'class' attribute, 'role' attribute values are intended to be selected from a predefined set of values with specific semantic aspects that are assigned to the element, such as those defined in the ARIA ontology and with future SVG specifications.

The 'role' attribute is intended to functionally align with the XHTML Role Attribute Module.

The 'rel' attribute

The 'rel' attribute assigns one or more relationship values to an element. The value of the 'rel' attribute expresses the relationships between two resources. For 'a' elements in particular, the 'rel' attribute indicates the relationship that the linked resource holds for the element's children or the element's containing document.

The 'rev' attribute

The 'rev' attribute assigns one or more relationship values to an element. The value of the 'rev' attribute expresses the reverse relationships between two resources. For 'a' elements in particular, the 'rev' attribute indicates the relationship that the element's children or the element's containing document holds for the linked resource.

The 'about' attribute

The 'about' attribute assigns one or more relationship values to an element. The value of the 'about' attribute is intended to be used for stating the subject of the element's data.

The 'content' attribute

The 'content' attribute provides a plain text value that may be suitable for humans, or may be machine-readable, depending on the context. In general, this should only be used to supplement textual child content, or to be used on elements which do not normally take text as child content.

The 'datatype' attribute

The 'datatype' attribute associates a datatype for another attribute with an attribute with a plain text string.

The 'property' attribute

The 'property' attribute is used for expressing relationships between a subject and some literal text.

The 'resource' attribute

The 'resource' attribute associates a resource, normally expressed with an IRI reference, to the element, in a manner that does not normally resolve the IRI reference.

The 'typeof' attribute

The 'typeof' attribute associates one or more datatypes with the element.

5.10.2 Attributes for character-content elements: 'xml:lang' and 'xml:space'

Elements that might contain character data content have attributes 'xml:lang' and 'xml:space' to specify the natural language and whitespace processing of the content.

Schema: langspace

<attribute name='xml:space' svg:animatable='false' svg:inheritable='false'>
   <choice>
      <value>default</value>
      <value>preserve</value>
   </choice>
</attribute>

<attribute name='xml:lang' svg:animatable='false' svg:inheritable='false'>
  <choice>
     <ref name='LanguageCode.datatype'/>
     <empty/>
  </choice>
</attribute>

Attribute definitions:

xml:lang = "<language-id>"

This is a standard XML attribute used to specify the language (e.g., English) used in the child text content and attribute values of the element it occurs on. The value is either a language tag as defined in IETF BCP 47 [BCP 47] or the empty string, "". Refer to Extensible Markup Language (XML) 1.0 ([XML10], section 2.12) and Extensible Markup Language (XML) 1.1 ([XML11], section 2.12) for the definition of this attribute.

Animatable: no.

xml:space = "default" | "preserve"

This is a standard XML attribute used to specify whether white space is preserved in character data. The only possible values are "default" and "preserve". Refer to Extensible Markup Language (XML) 1.0 ([XML10], section 2.10) and Extensible Markup Language (XML) 1.1 ([XML11], section 2.10) for the definition of this attribute. See also the discussion of white space handling for text content elements in SVG.

Animatable: no.

7 Coordinate Systems, Transformations and Units

7.1 Introduction
7.2 The initial viewport
7.3 The initial coordinate system
7.4 Coordinate system transformations
7.5 Nested transformations
7.6 The 'transform' attribute
- 7.6.1 The TransformList value
7.7 Constrained transformations
- 7.7.1 The user transform
- 7.7.2 ViewBox to viewport transformation
- 7.7.3 Element transform stack
- 7.7.4 The current transformation matrix
- 7.7.5 The TransformRef value
7.8 The 'viewBox' attribute
7.9 The 'preserveAspectRatio' attribute
7.10 Establishing a new viewport
7.11 Units
7.12 Object bounding box units
7.13 Intrinsic sizing properties of the viewport of SVG content
7.14 Geographic coordinate systems
7.15 The 'svg:transform' attribute

7.1 Introduction

For all media, the SVG canvas describes "the space where the SVG content is rendered." The canvas is infinite for each dimension of the space, but rendering occurs relative to a finite rectangular region of the canvas. This finite rectangular region is called the SVG viewport. For visual media ([CSS2], section 7.3.1), the SVG viewport is the viewing area where the user sees the SVG content.

The size of the SVG viewport (i.e., its width and height) is determined by a negotiation process (see Establishing the size of the initial viewport) between the SVG document fragment and its parent (real or implicit). Once the viewport is established, the SVG user agent must establish the initial viewport coordinate system and the initial user coordinate system (see Initial coordinate system). The viewport coordinate system is also called viewport space and the user coordinate system is also called user space.

A new user space (i.e., a new current coordinate system) can be established at any place within an SVG document fragment by specifying transformations in the form of transformation matrices or simple transformation operations such as rotation, skewing, scaling and translation (see Coordinate system transformations). Establishing new user spaces via coordinate system transformations are fundamental operations to 2D graphics and represent the usual method of controlling the size, position, rotation and skew of graphic objects.

New viewports also can be established. By establishing a new viewport, one can provide a new reference rectangle for "fitting" a graphic into a particular rectangular area. ("Fit" means that a given graphic is transformed in such a way that its bounding box in user space aligns exactly with the edges of a given viewport.)

7.2 The initial viewport

The SVG user agent negotiates with its parent user agent to determine the viewport into which the SVG user agent can render the document. In some circumstances, SVG content will be embedded (by reference or inline) within a containing document. This containing document might include attributes, properties and/or other parameters (explicit or implicit) which specify or provide hints about the dimensions of the viewport for the SVG content. SVG content itself optionally can provide information about the appropriate viewport region for the content via the 'width' and 'height' XML attributes on the 'svg' element. The negotiation process uses any information provided by the containing document and the SVG content itself to choose the viewport location and size.

If the parent document format defines rules for referenced or embedded graphics content, then the negotiation process is determined by the parent document format specification. If the parent document is styled with CSS, then the negotiation process must follow the CSS rules for replaced elements. If there are CSS width and height properties (or corresponding XSL properties) on the referencing element (or rootmost 'svg' element for inline SVG content) that are sufficient to establish the width and height of the viewport, then these positioning properties establish the viewport's width, height, and aspect ratio.

If there is no parent document, the SVG user agent must use the 'width' and 'height' attributes on the rootmost 'svg' element element as the width and height for the viewport.

7.3 The initial coordinate system

For the 'svg' element, the SVG user agent must establish an initial viewport coordinate system and an initial user coordinate system such that the two coordinates systems are identical. The origin of both coordinate systems must be at the origin of the viewport, and one unit in the initial coordinate system must equal one "pixel" (i.e., a px unit as defined in CSS ([CSS2], section 4.3.2)) in the viewport. In most cases, such as stand-alone SVG documents or SVG document fragments embedded (by reference or inline) within XML parent documents where the parent's layout is determined by CSS [CSS2] or XSL [XSL], the SVG user agent must establish the initial viewport coordinate system (and therefore the initial user coordinate system) such that its origin is at the top/left of the viewport, with the positive x-axis pointing towards the right, the positive y-axis pointing down, and text rendered with an "upright" orientation, which means glyphs are oriented such that Roman characters and full-size ideographic characters for Asian scripts have the top edge of the corresponding glyphs oriented upwards and the right edge of the corresponding glyphs oriented to the right.

If the SVG implementation is part of a user agent which supports styling XML documents using CSS2-compatible px units, then the SVG user agent should get its initial value for the size of a px unit in real world units to match the value used for other XML styling operations; otherwise, if the user agent can determine the size of a px unit from its environment, it should use that value; otherwise, it should choose an appropriate size for one px unit. In all cases, the size of a px must be in conformance with the rules described in CSS ([CSS2], section 4.3.2).

Example 07_02 below shows that the initial coordinate system has the origin at the top/left with the x-axis pointing to the right and the y-axis pointing down. The initial user coordinate system has one user nit equal to the parent (implicit or explicit) user agent's "pixel".

Example: 07_02.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="300px" height="100px">

  <desc>Example InitialCoords - SVG's initial coordinate system</desc>

  <g fill="none" stroke="black" stroke-width="3">
    <line x1="0" y1="1.5" x2="300" y2="1.5"/>
    <line x1="1.5" y1="0" x2="1.5" y2="100"/>
  </g>
  <g fill="red" stroke="none">
    <rect x="0" y="0" width="3" height="3"/>
    <rect x="297" y="0" width="3" height="3"/>
    <rect x="0" y="97" width="3" height="3"/>
  </g>
  <g font-size="14" font-family="Verdana">
    <text x="10" y="20">(0,0)</text>
    <text x="240" y="20">(300,0)</text>
    <text x="10" y="90">(0,100)</text>
  </g>
</svg>

7.4 Coordinate system transformations

A new user space (i.e., a new current coordinate system) can be established by specifying transformations in the form of a 'transform' attribute on a container or graphics element, or a 'viewBox' attribute on the 'svg' element. The 'transform' and 'viewBox' attributes transform user space coordinates and lengths on sibling attributes on the given element (see effect of the 'transform' attribute on sibling attributes and effect of the 'viewBox' attribute on sibling attributes) and all of its descendants. Transformations can be nested, in which case the effect of the transformations are cumulative.

Example 07_03 below shows a document without transformations. The text string is specified in the initial coordinate system.

Example: 07_03.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="400px" height="150px">

  <desc>Example OrigCoordSys - Simple transformations: original picture</desc>

  <g fill="none" stroke="black" stroke-width="3">
    <!-- Draw the axes of the original coordinate system -->
    <line x1="0" y1="1.5" x2="400" y2="1.5"/>
    <line x1="1.5" y1="0" x2="1.5" y2="150"/>
  </g>
  <g>
    <text x="30" y="30" font-size="20" font-family="Verdana">
      ABC (orig coord system)
    </text>
  </g>
</svg>

Example 07_04 establishes a new user coordinate system by specifying transform="translate(50,50)" on the third 'g' element below. The new user coordinate system has its origin at location (50,50) in the original coordinate system. The result of this transformation is that the coordinate (30,30) in the new user coordinate system gets mapped to coordinate (80,80) in the original coordinate system (i.e., the coordinates have been translated by 50 units in x and 50 units in y).

Example: 07_04.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="400px" height="150px">

  <desc>Example NewCoordSys - New user coordinate system</desc>

  <g fill="none" stroke="black" stroke-width="3">
    <!-- Draw the axes of the original coordinate system -->
    <line x1="0" y1="1.5" x2="400" y2="1.5"/>
    <line x1="1.5" y1="0" x2="1.5" y2="150"/>
  </g>
  <g>
    <text x="30" y="30" font-size="20" font-family="Verdana">
      ABC (orig coord system)
    </text>
  </g>
  <!-- Establish a new coordinate system, which is
       shifted (i.e., translated) from the initial coordinate
       system by 50 user units along each axis. -->
  <g transform="translate(50,50)">
    <g fill="none" stroke="red" stroke-width="3">
      <!-- Draw lines of length 50 user units along 
           the axes of the new coordinate system -->
      <line x1="0" y1="0" x2="50" y2="0" stroke="red"/>
      <line x1="0" y1="0" x2="0" y2="50"/>
    </g>
    <text x="30" y="30" font-size="20" font-family="Verdana">
      ABC (translated coord system)
    </text>
  </g>
</svg>

Example 07_05 illustrates simple rotate and scale transformations. The example defines two new coordinate systems:

one which is the result of a translation by 50 units in x and 30 units in y, followed by a rotation of 30 degrees
another which is the result of a translation by 200 units in x and 40 units in y, followed by a scale transformation of 1.5.

Example: 07_05.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="400px" height="120px">

  <desc>Example RotateScale - Rotate and scale transforms</desc>

  <g fill="none" stroke="black" stroke-width="3">
    <!-- Draw the axes of the original coordinate system -->
    <line x1="0" y1="1.5" x2="400" y2="1.5"/>
    <line x1="1.5" y1="0" x2="1.5" y2="120"/>
  </g>
  <!-- Establish a new coordinate system whose origin is at (50,30)
       in the initial coord. system and which is rotated by 30 degrees. -->
  <g transform="translate(50,30)">
    <g transform="rotate(30)">
      <g fill="none" stroke="red" stroke-width="3">
        <line x1="0" y1="0" x2="50" y2="0"/>
        <line x1="0" y1="0" x2="0" y2="50"/>
      </g>
      <text x="0" y="0" font-size="20" font-family="Verdana" fill="blue">
        ABC (rotate)
      </text>
    </g>
  </g>
  <!-- Establish a new coordinate system whose origin is at (200,40)
       in the initial coord. system and which is scaled by 1.5. -->
  <g transform="translate(200,40)">
    <g transform="scale(1.5)">
      <g fill="none" stroke="red" stroke-width="3">
        <line x1="0" y1="0" x2="50" y2="0"/>
        <line x1="0" y1="0" x2="0" y2="50"/>
      </g>
      <text x="0" y="0" font-size="20" font-family="Verdana" fill="blue">
        ABC (scale)
      </text>
    </g>
  </g>
</svg>

Example 07_06 defines two coordinate systems which are skewed relative to the origin coordinate system.

Example: 07_06.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="400px" height="120px">

  <desc>Example Skew - Show effects of skewX and skewY</desc>

  <g fill="none" stroke="black" stroke-width="3">
    <!-- Draw the axes of the original coordinate system -->
    <line x1="0" y1="1.5" x2="400" y2="1.5"/>
    <line x1="1.5" y1="0" x2="1.5" y2="120"/>
  </g>
  <!-- Establish a new coordinate system whose origin is at (30,30)
       in the initial coord. system and which is skewed in X by 30 degrees. -->
  <g transform="translate(30,30)">
    <g transform="skewX(30)">
      <g fill="none" stroke="red" stroke-width="3">
        <line x1="0" y1="0" x2="50" y2="0"/>
        <line x1="0" y1="0" x2="0" y2="50"/>
      </g>
      <text x="0" y="0" font-size="20" font-family="Verdana" fill="blue">
        ABC (skewX)
      </text>
    </g>
  </g>
  <!-- Establish a new coordinate system whose origin is at (200,30)
       in the initial coord. system and which is skewed in Y by 30 degrees. -->
  <g transform="translate(200,30)">
    <g transform="skewY(30)">
      <g fill="none" stroke="red" stroke-width="3">
        <line x1="0" y1="0" x2="50" y2="0"/>
        <line x1="0" y1="0" x2="0" y2="50"/>
      </g>
      <text x="0" y="0" font-size="20" font-family="Verdana" fill="blue">
        ABC (skewY)
      </text>
    </g>
  </g>
</svg>

Mathematically, all transformations can be represented as 3x3 transformation matrices of the following form:

Since only six values are used in the above 3x3 matrix, a transformation matrix is also expressed as a vector: [a b c d e f].

Transformations map coordinates and lengths from a new coordinate system into a previous coordinate system:

Simple transformations are represented in matrix form as follows:

Translation is equivalent to the matrix:

or [1 0 0 1 tx ty], where tx and ty are the distances to translate coordinates in x and y, respectively.
Scaling is equivalent to the matrix:

or [sx 0 0 sy 0 0]. One unit in the x and y directions in the new coordinate system equals sx and sy units in the previous coordinate system, respectively.
Rotation about the origin is equivalent to the matrix:

or [cos(a) sin(a) -sin(a) cos(a) 0 0], which has the effect of rotating the coordinate system axes by angle a.
A skew transformation along the x-axis is equivalent to the matrix:

or [1 0 tan(a) 1 0 0], which has the effect of skewing x coordinates by angle a.
A skew transformation along the y-axis is equivalent to the matrix:

or [1 tan(a) 0 1 0 0], which has the effect of skewing y coordinates by angle a.

7.5 Nested transformations

Transformations can be nested to any level. The effect of nested transformations is to post-multiply (i.e., concatenate) the subsequent transformation matrices onto previously defined transformations:

For each given element, the accumulation of all transformations that have been defined on the given element and all of its ancestors up to and including the element that established the current viewport (usually, the 'svg' element which is the most immediate ancestor to the given element) is called the current transformation matrix or CTM. The CTM thus represents the mapping of current user coordinates to viewport coordinates:

Example 07_07 illustrates nested transformations.

Example: 07_07.svg

<?xml version="1.0"?>
<svg width="400px" height="150px" version="1.2" baseProfile="tiny"
     xmlns="http://www.w3.org/2000/svg">
  <desc>Example Nested - Nested transformations</desc>
  <g fill="none" stroke="black" stroke-width="3" >
    <!-- Draw the axes of the original coordinate system -->
    <line x1="0" y1="1.5" x2="400" y2="1.5" />
    <line x1="1.5" y1="0" x2="1.5" y2="150" />
  </g>
  <!-- First, a translate -->
  <g transform="translate(50,90)">
    <g fill="none" stroke="red" stroke-width="3" >
      <line x1="0" y1="0" x2="50" y2="0" />
      <line x1="0" y1="0" x2="0" y2="50" />
    </g>
    <text x="0" y="0" font-size="16" font-family="Verdana" >
      ....Translate(1)
    </text>
    <!-- Second, a rotate -->
    <g transform="rotate(-45)">
      <g fill="none" stroke="green" stroke-width="3" >
        <line x1="0" y1="0" x2="50" y2="0" />
        <line x1="0" y1="0" x2="0" y2="50" />
      </g>
      <text x="0" y="0" font-size="16" font-family="Verdana" >
        ....Rotate(2)
      </text>
      <!-- Third, another translate -->
      <g transform="translate(130,160)">
        <g fill="none" stroke="blue" stroke-width="3" >
          <line x1="0" y1="0" x2="50" y2="0" />
          <line x1="0" y1="0" x2="0" y2="50" />
        </g>
        <text x="0" y="0" font-size="16" font-family="Verdana" >
          ....Translate(3)
        </text>
      </g>
    </g>
  </g>
</svg>

In the example above, the CTM within the third nested transformation (i.e., the transform="translate(130,160)") consists of the concatenation of the three transformations, as follows:

7.6 The 'transform' attribute

Attribute definition:

transform = "<transform-list>" | "<transform-ref>" | "none"

This attribute specifies a coordinate system transformation to apply to the element it appears on. The value of this attribute takes one of three forms:

<transform-list>: Specifies a list of affine transformations. See the definition in The TransformList value section below for details.
<transform-ref>: Specifies a constrained transformation. See the definition in The TransformRef value section below for details.
none: Specifies the identity transformation. Using this value has the same effect on the element's CTM as using the identity matrix (transform="matrix(1 0 0 1 0 0)") or not specifying the 'transform' attribute at all.

Animatable: yes.

If the 'transform' attribute cannot be parsed according to the syntaxes above, then it has an unsupported value. In this case, as with any instance of an unsupported value, the SVG user agent must process the element as if the 'transform' attribute had not been specified, which will result in the element's transformation being the identity transformation.

7.6.1 The TransformList value

A <transform-list> is defined as a list of transform definitions, which are applied in the order provided. The individual transform definitions are separated by white space and/or a comma. The available types of transform definitions are as follows:

matrix(<a> <b> <c> <d> <e> <f>), which specifies a transformation in the form of a transformation matrix of six values. matrix(a,b,c,d,e,f) is equivalent to applying the transformation matrix [a b c d e f].
translate(<tx> [<ty>]), which specifies a translation by tx and ty. If <ty> is not provided, it is assumed to be zero.
scale(<sx> [<sy>]), which specifies a scale operation by sx and sy. If <sy> is not provided, it is assumed to be equal to <sx>.
rotate(<rotate-angle> [<cx> <cy>]), which specifies a rotation by <rotate-angle> degrees about a given point.

If optional parameters <cx> and <cy> are not supplied, the rotation is about the origin of the current user coordinate system. The operation corresponds to the matrix [cos(a) sin(a) -sin(a) cos(a) 0 0].

If optional parameters <cx> and <cy> are supplied, the rotation is about the point (cx, cy). The operation represents the equivalent of the following specification: translate(<cx>, <cy>) rotate(<rotate-angle>) translate(-<cx>, -<cy>).
skewX(<skew-angle>), which specifies a skew transformation along the x-axis.
skewY(<skew-angle>), which specifies a skew transformation along the y-axis.

All numeric values are real <number>s.

If the list of transforms includes a matrix with all values set to zero (that is, matrix(0,0,0,0,0,0)) then rendering of the element is disabled. Such a value is not an unsupported value.

If a list of transforms includes more than one transform definition, then the net effect is as if each transform had been specified separately in the order provided. For example,

Example: 07_08.svg

<g transform="translate(-10,-20) scale(2) rotate(45) translate(5,10)">
  <!-- graphics elements go here -->
</g>

will have the same rendering as:

Example: 07_09.svg

<g transform="translate(-10,-20)">
  <g transform="scale(2)">
    <g transform="rotate(45)">
      <g transform="translate(5,10)">
        <!-- graphics elements go here -->
      </g>
    </g>
  </g>
</g>

The 'transform' attribute is applied to an element before processing any other coordinate or length values supplied for that element. In the element

Example: 07_10.svg

<rect x="10" y="10" width="20" height="20" transform="scale(2)"/>

the 'x', 'y', 'width' and 'height', values are processed after the current coordinate system has been scaled uniformly by a factor of 2 by the 'transform' attribute. Attributes 'x', 'y', 'width' and 'height' (and any other attributes or properties) are treated as values in the new user coordinate system, not the previous user coordinate system. Thus, the above 'rect' element is functionally equivalent to:

Example: 07_11.svg

<g transform="scale(2)">
  <rect x="10" y="10" width="20" height="20"/>
</g>

The following is an EBNF grammar for <transform-list> values [EBNF]:

transform-list ::=
    wsp* transforms? wsp*
transforms ::=
    transform
    | transform comma-wsp+ transforms
transform ::=
    matrix
    | translate
    | scale
    | rotate
    | skewX
    | skewY
matrix ::=
    "matrix" wsp* "(" wsp*
       number comma-wsp
       number comma-wsp
       number comma-wsp
       number comma-wsp
       number comma-wsp
       number wsp* ")"
translate ::=
    "translate" wsp* "(" wsp* number ( comma-wsp number )? wsp* ")"
scale ::=
    "scale" wsp* "(" wsp* number ( comma-wsp number )? wsp* ")"
rotate ::=
    "rotate" wsp* "(" wsp* number ( comma-wsp number comma-wsp number )? wsp* ")"
skewX ::=
    "skewX" wsp* "(" wsp* number wsp* ")"
skewY ::=
    "skewY" wsp* "(" wsp* number wsp* ")"
number ::=
    sign? integer-constant
    | sign? floating-point-constant
comma-wsp ::=
    (wsp+ comma? wsp*) | (comma wsp*)
comma ::=
    ","
integer-constant ::=
    digit-sequence
floating-point-constant ::=
    fractional-constant exponent?
    | digit-sequence exponent
fractional-constant ::=
    digit-sequence? "." digit-sequence
    | digit-sequence "."
exponent ::=
    ( "e" | "E" ) sign? digit-sequence
sign ::=
    "+" | "-"
digit-sequence ::=
    digit
    | digit digit-sequence
digit ::=
    "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
wsp ::=
    (#x20 | #x9 | #xD | #xA)

7.7 Constrained transformations

SVG 1.2 extends the coordinate system transformations allowed on container elements and graphics element to provide a method by which graphical objects can remain fixed in the viewport without being scaled or rotated. Use cases include thin lines that do not become fatter on zooming in, map symbols or icons of a constant size, and so forth.

The following summarizes the different transforms that are applied to a graphical object as it is rendered.

7.7.1 The user transform

The user transform is the transformation that the SVG user agent positioning controls apply to the viewport coordinate system. This transform can be considered to be applied to a group that surrounds the 'svg' element of the document.

The SVG user agent positioning controls consist of a translation (commonly referred to as the "pan"), a scale (commonly referred to as the "zoom") and a rotate.

US = Matrix corresponding to the user scale  (currentScale on SVGSVGElement)
UP = Matrix corresponding to the user pan    (currentTranslate on SVGSVGElement)
UR = Matrix corresponding to the user rotate (currentRotate on SVGSVGElement)

The user transform is the product of these component transformations.

U = User transform
  = UP . US . UR

7.7.2 ViewBox to viewport transformation

Some SVG elements, such as the rootmost 'svg' element, create their own viewport. The 'viewBox' to viewport transformation is the transformation on an 'svg' element that adjusts the coordinate system to take the 'viewBox' and 'preserveAspectRatio' attributes into account.

We use the following notation for a 'viewBox' to viewport transformation:

VB(svgId)

The svgId parameter is the value of the 'id' or 'xml:id' attribute on a given 'svg' element.

7.7.3 Element transform stack

All elements in an SVG document have a transform stack. This is the list of transforms that manipulate the coordinate system between the element and its nearest ancestor 'svg' element, i.e. in this specification, the root element.

We use the following notation for the element transform stack on a given element:

TS(id)

The id parameter is the value of the 'id' or 'xml:id' attribute on a given element.

Similarly, we use the following notation for the transform defined by the 'transform' attribute on the given element with identifier id:

Txf(id)

With the above definition, the transformation TS of an element is equal to the product of all the transformations Txf from that element to its nearest ancestor 'svg'.

TS(id) = Txf(id.nearestViewportElement) . [...] . Txf(id.parentElement) . Txf(id)

Example: Element transform stack

<svg xml:id="root" version="1.2" baseProfile="tiny">
  <g xml:id="g" transform="scale(2)">
    <rect xml:id="r" transform="scale(4)"/>
    <g xml:id="g2">
      <rect xml:id="r2" transform="scale(0.5)"/>
    </g>
  </g>
</svg>

In this example, the transforms are:

TS(g)  = scale(2)
TS(r)  = TS(g) . scale(4)   = scale(8)
TS(g2) = TS(g) . I          = scale(2)   (where I is the identity matrix)
TS(r2) = TS(g) . scale(0.5) = scale(1)

7.7.4 The current transformation matrix

Each element in the rendering tree has the concept of a current transformation matrix or CTM. This is the product of all coordinate system transformations that apply to an element, effectively mapping the element into a coordinate system that is then transformed into device units by the SVG user agent.

Consider the following example, with a rectangle having a set of ancestor 'g' elements with IDs "g-0" to "g-n".

Example: Current transformation matrix

<svg xml:id="root" version="1.2" baseProfile="tiny">
  ...
  <g xml:id="g-n">
    ...
    <g xml:id="g-2">
      ...
      <g xml:id="g-1">
        ...
        <g xml:id="g-0">
          ...
          <rect xml:id="elt" .../>
        </g>
      </g>
    </g>
  </g>
</svg>

With the above definitions for U, VB, and TS, the CTM for the rectangle with xml:id="elt" is computed as follows:

CTM(elt) = U . VB(root) . TS(elt)
         = U . VB(root) . Txf(g-n) . [...] . Txf(g-0) . Txf(elt)

Example: Current transformation matrix, n=2

<svg xml:id="root" version="1.2" baseProfile="tiny">
  ...
  <g xml:id="g-1">
    ...
    <g xml:id="g-0">
      ...
      <rect xml:id="elt" .../>
    </g>
  </g>
</svg>

This produces the following transformations:

CTM(elt) = U . VB(root) . Txf(g-1) . Txf(g-0) . Txf(elt)

Note the important relationship between an element's CTM and its parent CTM, for elements which do not define a viewport:

CTM(elt) = CTM(elt.parentElement) . Txf(elt)

7.7.5 The TransformRef value

By using the ref() attribute value on the 'transform' attribute it is possible to specify simple constrained transformations.

The ref(svg, x, y) transform evaluates to the inverse of the element's parent's CTM multiplied by the rootmost 'svg' element's CTM but exclusive of that 'svg' element's zoom/pan/rotate user transform, if any.

The x and y parameters are optional. If they are specified, an additional translation is appended to the transform so that (0, 0) in the element's user space maps to (x, y) in the 'svg' element's user space. If no x and y parameters are specified, no additional translation is applied.

Using the definitions provided above, and using "svg[0]" to denote the rootmost 'svg' element:

Inverse of the parent's CTM: inv(CTM(elt.parentElement))

The svg element's user transform, exclusive of zoom,
pan and rotate transforms:
CTM(svg[0].parentElement) . VB(svg[0])

CTM(svg[0].parentElement) evaluates to Identity since there
is no svg[0].parentElement element.

In addition, the T(x, y) translation is such that:

CTM(elt) . (0, 0) = CTM(svg[0]) . (x, y)

So the transform evaluates to:

Txf(elt) = inv(CTM(elt.parentElement)) . CTM(svg[0].parentElement) . VB(svg[0]) . T(x, y)

Thus, the element's CTM is:

CTM(elt) = CTM(elt.parentElement) . Txf(elt)
         = CTM(svg[0].parentElement) . VB(svg[0]) . T(x,y)

Example: ref() transform
A small rectangle initially marks the middle of a line. The SVG user agent viewport is a square with sides of 200 units.

<svg xml:id="root" version="1.2" baseProfile="tiny" viewBox="0 0 100 100">
  <line x1="0" x2="100" y1="0" y2="100"/>
  <rect xml:id="r" transform="ref(svg)"
        x="45" y="45" width="10" height="10"/>
</svg>

In this case:

Txf(r) = inv(CTM(r.parent)) . CTM(root.parentElement) . VB(root) . T(x, y)

CTM(root.parentElement) evaluates to Identity.

T(x, y) evaluates to Identity because (x, y) is not specified

CTM(r) = CTM(r.parent) . Txf(r)
       = CTM(r.parent) . inv(CTM(r.parent)) . VB(root)
       = VB(root)
       = scale(2)

Consequently, regardless of the user transform (due to currentTranslate, currentScale and currentRotate) the rectangle's coordinates in viewport space will always be: (45, 45, 10, 10) * scale(2) = (90, 90, 20, 20). Initially, the line is from (0, 0) to (200, 200) in the viewport coordinate system. If we apply a user agent zoom of 3 (currentScale = 3), the rectangle is still (90, 90, 20, 20) but the line is (0, 0, 600, 600) and the marker no longer marks the middle of the line.

Example: ref() transform
A small rectangle always marks the middle of a line. Again, the SVG user agent viewport is a square with sides of 200 units.

<svg xml:id="root" version="1.2" baseProfile="tiny" viewBox="0 0 100 100"> 
  <line x1="0" x2="100" y1="0" y2="100"/>
  <g xml:id="g" transform="ref(svg, 50, 50)">
    <rect xml:id="r" x="-5" y="-5" width="10" height="10"/>
  </g>
</svg>

In this case:

Txf(g) = inv(CTM(g.parent)) . CTM(root.parentElement) . VB(root) . T(x,y)

CTM(root.parentElement) evaluates to Identity.

CTM(g) = CTM(g.parent) . Txf(r)
       = CTM(g.parent) . inv(CTM(g.parent)) . VB(root) . T(x,y)
       = VB(root) . T(x,y)
       = scale(2) . T(x,y)

Initially, (50, 50) in the 'svg' user space is (100, 100) in viewport space. Therefore:

CTM(g) . [0, 0] = CTM(root) . [50, 50]
                = scale(2) . [50, 50]
                = [100, 100]

and

scale(2) . T(x,y) = [100, 100]

T(x,y) = translate(50, 50)

If the SVG user agent pan was (50, 80) (modifying currentTranslate) then we now have (50, 50) in the 'svg' element's user space located at (150, 180) in the viewport space. This produces:

CTM(g) . [0, 0] = CTM(root) . [50, 50]
                = translate(50, 80) . scale(2) . [50, 50]
                = [150, 180]

and

scale(2) . T(x,y) = [150, 180]

T(x, y) = translate(75, 90)

Therefore, regardless of the user transform, the rectangle will always overlap the middle of the line. Note that the rectangle will not rotate with the line (e.g., if currentRotate is set) and it will not scale either.

The following is an EBNF grammar for <transform-ref> values [EBNF]:

transform-ref ::=
    wsp* ref wsp*
ref ::=
    "ref" wsp* "(" wsp* "svg" wsp* ")"
    | "ref" wsp* "(" wsp* "svg" comma-wsp number comma-wsp number wsp* ")"
number ::=
    sign? integer-constant
    | sign? floating-point-constant
comma-wsp ::=
    (wsp+ comma? wsp*) | (comma wsp*)
comma ::=
    ","
integer-constant ::=
    digit-sequence
floating-point-constant ::=
    fractional-constant exponent?
    | digit-sequence exponent
fractional-constant ::=
    digit-sequence? "." digit-sequence
    | digit-sequence "."
exponent ::=
    ( "e" | "E" ) sign? digit-sequence
sign ::=
    "+" | "-"
digit-sequence ::=
    digit
    | digit digit-sequence
digit ::=
    "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
wsp ::=
    (#x20 | #x9 | #xD | #xA)

7.8 The 'viewBox' attribute

It is often desirable to specify that a given set of graphics stretch to fit a particular container element. The 'viewBox' attribute provides this capability. All elements that establish a new viewport (see elements that establish viewports) can have the 'viewBox' attribute specified on them.

Attribute definition:

viewBox = "<list-of-numbers>" | "none"

Specifies a rectangular region into which child graphical content must be fit. The value of this attribute takes one of two forms:

<list-of-numbers>: A list of four <number>s (<min-x>, <min-y>, <width> and <height>), separated by white space and/or a comma, which specify a rectangle in user space which must be be mapped to the bounds of the viewport established by the given element, taking into account the 'preserveAspectRatio' attribute. If specified, an additional transformation is applied to all descendants of the given element to achieve the specified effect.
none: Specifying a value of "none" indicates that a supplemental transformation due to the 'viewBox' attribute must not be used. Using this value will have the same affect on child content as not specifying the 'viewBox' attribute at all.

Animatable: yes.

A negative value for <width> or <height> is unsupported. A value of zero for either of these two parameters disables rendering of the element.

Example 07_12 illustrates the use of the 'viewBox' attribute on the 'svg' element to specify that the SVG content must stretch to fit the bounds of the viewport.

Example: 07_12.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="300px" height="200px" viewBox="0 0 1500 1000"
     preserveAspectRatio="none">

  <desc>
    Example ViewBox - uses the viewBox attribute to automatically create an
    initial user coordinate system which causes the graphic to scale to fit
    into the viewport no matter what size the viewport is.
  </desc>

  <!-- This rectangle goes from (0,0) to (1500,1000) in user space.
       Because of the viewBox attribute above,
       the rectangle will end up filling the entire area
       reserved for the SVG content. -->
  <rect x="0" y="0" width="1500" height="1000" 
        fill="yellow" stroke="blue" stroke-width="12"/>

  <!-- A large, red triangle -->
  <path fill="red"  d="M 750,100 L 250,900 L 1250,900 z"/>

  <!-- A text string that spans most of the viewport -->
  <text x="100" y="600" font-size="200" font-family="Verdana">
    Stretch to fit
  </text>
</svg>

Rendered into viewport with width=300px, height=200px		width=150px, height=200px

The effect of the 'viewBox' attribute is that the SVG user agent automatically supplies the appropriate transformation matrix to map the specified rectangle in user space to the bounds of a designated region (often, the viewport). To achieve the effect of the example on the left, with viewport dimensions of 300 by 200 pixels, the SVG user agent needs to automatically insert a transformation which scales both x and y by 0.2. The effect is equivalent to having a viewport of size 300px by 200px and the following supplemental transformation in the document, as follows:

<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="300px" height="200px">
  <g transform="scale(0.2)">
    <!-- Rest of document goes here -->
  </g>
</svg>

To achieve the effect of the example on the right, with viewport dimensions of 150 by 200 pixels, the SVG user agent needs to automatically insert a transformation which scales x by 0.1 and y by 0.2. The effect is equivalent to having a viewport of size 150px by 200px and the following supplemental transformation in the document, as follows:

<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="150px" height="200px">
  <g transform="scale(0.1 0.2)">
    <!-- Rest of document goes here -->
  </g>
</svg>

(Note: in some cases the SVG user agent will need to supply a translate transformation in addition to a scale transformation. For example, on an 'svg' element, a translate transformation will be needed if the 'viewBox' attribute specifies values other than zero for <min-x> or <min-y>.)

Unlike the 'transform' attribute (see effect of the 'transform' attribute on sibling attributes), the automatic transformation that is created due to a 'viewBox' does not affect the 'x', 'y', 'width' and 'height' attributes on the element with the 'viewBox' attribute. Thus, in the example above which shows an 'svg' element which has attributes 'width', 'height' and 'viewBox', the 'width' and 'height' attributes represent values in the coordinate system that exists before the 'viewBox' transformation is applied. On the other hand, like the 'transform' attribute, it does establish a new coordinate system for all other attributes and for descendant elements.

The following is an EBNF grammar for values of the 'viewBox' attribute [EBNF]:

viewbox ::=
    wsp* viewboxSpec wsp*
viewboxSpec ::=
    number comma-wsp number comma-wsp number comma-wsp number
    | "none"
number ::=
    sign? integer-constant
    | sign? floating-point-constant
comma-wsp ::=
    (wsp+ comma? wsp*) | (comma wsp*)
comma ::=
    ","
integer-constant ::=
    digit-sequence
floating-point-constant ::=
    fractional-constant exponent?
    | digit-sequence exponent
fractional-constant ::=
    digit-sequence? "." digit-sequence
    | digit-sequence "."
exponent ::=
    ( "e" | "E" ) sign? digit-sequence
sign ::=
    "+" | "-"
digit-sequence ::=
    digit
    | digit digit-sequence
digit ::=
    "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
wsp ::=
    (#x20 | #x9 | #xD | #xA)

7.9 The 'preserveAspectRatio' attribute

In some cases, typically when using the 'viewBox' attribute, it is desirable that the graphics stretch to fit non-uniformly to take up the entire viewport. In other cases, it is desirable that uniform scaling be used for the purposes of preserving the aspect ratio of the graphics.

'preserveAspectRatio' is available for all elements that establish a new viewport (see elements that establish viewports), indicates whether or not to force uniform scaling.

'preserveAspectRatio' only applies when a value has been provided for 'viewBox' on the same element. Or, in some cases, if an implicit 'viewBox' value can be established for the element (see each element description for details on this). If a 'viewBox' value can not be determined then 'preserveAspectRatio' is ignored.

Attribute definition:

preserveAspectRatio = ""[defer] <align> [<meet>]"

defer

If the value of 'preserveAspectRatio' on an element that references data ('image', 'animation' and 'video') starts with defer then the value of the 'preserveAspectRatio' attribute on the referenced content if present must be used. If the referenced content lacks a value for 'preserveAspectRatio' then the 'preserveAspectRatio' attribute must be processed as normal (ignoring defer). For 'preserveAspectRatio' on all other elements the defer portion of the attribute is ignored.

<align>

Indicates whether to force uniform scaling and, if so, the alignment method to use in case the aspect ratio of the 'viewBox' doesn't match the aspect ratio of the viewport. The <align> parameter must be one of the following strings:

none - Do not force uniform scaling. Scale the graphic content of the given element non-uniformly if necessary such that the element's bounding box exactly matches the viewport rectangle.
xMinYMin - Force uniform scaling.
Align the <min-x> of the element's 'viewBox' with the smallest X value of the viewport.
Align the <min-y> of the element's 'viewBox' with the smallest Y value of the viewport.
xMidYMin - Force uniform scaling.
Align the midpoint X value of the element's 'viewBox' with the midpoint X value of the viewport.
Align the <min-y> of the element's 'viewBox' with the smallest Y value of the viewport.
xMaxYMin - Force uniform scaling.
Align the <min-x>+<width> of the element's 'viewBox' with the maximum X value of the viewport.
Align the <min-y> of the element's 'viewBox' with the smallest Y value of the viewport.
xMinYMid - Force uniform scaling.
Align the <min-x> of the element's 'viewBox' with the smallest X value of the viewport.
Align the midpoint Y value of the element's 'viewBox' with the midpoint Y value of the viewport.
xMidYMid (the default) - Force uniform scaling.
Align the midpoint X value of the element's 'viewBox' with the midpoint X value of the viewport.
Align the midpoint Y value of the element's 'viewBox' with the midpoint Y value of the viewport.
xMaxYMid - Force uniform scaling.
Align the <min-x>+<width> of the element's 'viewBox' with the maximum X value of the viewport.
Align the midpoint Y value of the element's 'viewBox' with the midpoint Y value of the viewport.
xMinYMax - Force uniform scaling.
Align the <min-x> of the element's 'viewBox' with the smallest X value of the viewport.
Align the <min-y>+<height> of the element's 'viewBox' with the maximum Y value of the viewport.
xMidYMax - Force uniform scaling.
Align the midpoint X value of the element's 'viewBox' with the midpoint X value of the viewport.
Align the <min-y>+<height> of the element's 'viewBox' with the maximum Y value of the viewport.
xMaxYMax - Force uniform scaling.
Align the <min-x>+<width> of the element's 'viewBox' with the maximum X value of the viewport.
Align the <min-y>+<height> of the element's 'viewBox' with the maximum Y value of the viewport.

<meet>

Optional and only available due to historical reasons. The <meet> is separated from the <align> value by one or more spaces and must equal the string meet.

meet indicates to scale the graphic such that:

aspect ratio is preserved
the entire 'viewBox' is visible within the viewport
the 'viewBox' is scaled up as much as possible, while still meeting the other criteria

In this case, if the aspect ratio of the graphic does not match the viewport, some of the viewport will extend beyond the bounds of the 'viewBox' (i.e., the area into which the 'viewBox' will draw will be smaller than the viewport).

Animatable: yes.

Example PreserveAspectRatio illustrates the various options on 'preserveAspectRatio'. The example creates several new viewports by including 'animation' elements (see Establishing a new viewport).

Example PreserveAspectRatio

7.10 Establishing a new viewport

Some elements establish a new viewport. By establishing a new viewport, you implicitly establish a new viewport coordinate system and a new user coordinate system. Additionally, there is a new meaning for percentage units defined to be relative to the current viewport since a new viewport has been established (see Units)

'viewport-fill' and 'viewport-fill-opacity' properties can be applied on the new viewport.

The bounds of the new viewport are defined by the 'x', 'y', 'width' and 'height' attributes on the element establishing the new viewport, such as an 'animation' element. Both the new viewport coordinate system and the new user coordinate system have their origins at (x, y), where x and y represent the value of the corresponding attributes on the element establishing the viewport. The orientation of the new viewport coordinate system and the new user coordinate system correspond to the orientation of the current user coordinate system for the element establishing the viewport. A single unit in the new viewport coordinate system and the new user coordinate system are the same size as a single unit in the current user coordinate system for the element establishing the viewport.

For an extensive example of creating new viewports, see Example PreserveAspectRatio.

The following elements establish new viewports:

The 'svg' element establishes the root viewport for the document.
The 'animation' element.
The 'image' element.
The 'video' element.

The following paragraph is informative.

Note that no clipping of overflow is performed, but that such clipping will take place if the content is viewed in an SVG user agent that supports clipping, since the lacuna value for 'overflow' is hidden for elements that establish viewports. Content authors that want content to be fully forward compatible are advised to either specify the 'overflow' property or to make sure that content that shouldn't be clipped is inside of the established viewport.

7.11 Units

Besides the exceptions listed below all coordinates and lengths in SVG must be specified in user units, which means that unit identifiers are not allowed.
Two exceptions exist:

Unit identifiers are allowed on the 'width' and 'height' XML attributes on the 'svg' element.
Object bounding box units are allowed on 'linearGradient' and 'radialGradient' elements.

A user unit is a value in the current user coordinate system. For example:

Example: 07_17.svg

<text font-size="50">Text size is 50 user units</text>

For the 'svg' element's 'width' and 'height' attributes a coordinate or length value can be expressed as a number following by a unit identifier (e.g., '25cm' or '100%'). The list of unit identifiers in SVG are: in, cm, mm, pt, pc, px and percentages (%). These values on 'width' and 'height' contribute towards the calculation of the initial viewport.

Using percentage values on 'width' and 'height' attributes mandates how much space the SVG viewport must take of the available initial viewport. In particular:

For any width value expressed as a percentage of the viewport, the value to use is the specified percentage of the actual-width in user units for the nearest containing viewport, where actual-width is the width dimension of the viewport element within the user coordinate system for the viewport element.
For any height value expressed as a percentage of the viewport, the value to use is the specified percentage of the actual-height in user units for the nearest containing viewport, where actual-height is the height dimension of the viewport element within the user coordinate system for the viewport element.

See the discussion on the initial viewport for more details.

7.12 Object bounding box units

The following elements offer the option of expressing coordinate values and lengths as fractions of the bounding box (via keyword 'objectBoundingBox') on a given element:

Element	Attribute	Effect
'linearGradient'	gradientUnits="objectBoundingBox"	Indicates that the attributes which specify the gradient vector ('x1', 'y1', 'x2', 'y2') represent fractions of the bounding box of the element to which the gradient is applied.
'radialGradient'	gradientUnits="objectBoundingBox"	Indicates that the attributes which specify the center ('cx', 'cy') and the radius ('r') represent fractions of the bounding box of the element to which the gradient is applied.

In the discussion that follows, the term applicable element is the element to which the given effect applies. For gradients the applicable element is the graphics element which has its 'fill' or 'stroke' property referencing the given gradient. (See Inheritance of painting properties. For special rules concerning text elements, see the discussion of object bounding box units and text elements.)

When keyword 'objectBoundingBox' is used, then the effect is as if a supplemental transformation matrix were inserted into the list of nested transformation matrices to create a new user coordinate system.

First, the (minx, miny) and (maxx, maxy) coordinates are determined for the applicable element and all of its descendants. The values minx, miny, maxx and maxy are determined by computing the maximum extent of the shape of the element in x and y with respect to the user coordinate system for the applicable element.

Then, coordinate (0, 0) in the new user coordinate system is mapped to the (minx, miny) corner of the tight bounding box within the user coordinate system of the applicable element and coordinate (1, 1) in the new user coordinate system is mapped to the (maxx, maxy) corner of the tight bounding box of the applicable element. In most situations, the following transformation matrix produces the correct effect:

[ (maxx-minx) 0 0 (maxy-miny) minx miny ]

Any numeric value can be specified for values expressed as a fraction of object bounding box units. In particular, fractions less are zero or greater than one can be specified.

Keyword 'objectBoundingBox' should not be used when the geometry of the applicable element has no width or no height, such as the case of a horizontal or vertical line, even when the line has actual thickness when viewed due to having a non-zero stroke width since stroke width is ignored for bounding box calculations. When the geometry of the applicable element has no width or height and 'objectBoundingBox' is specified, then the given effect (e.g., a gradient) will be ignored.

7.13 Intrinsic sizing properties of the viewport of SVG content

SVG needs to specify how to calculate some intrinsic sizing properties to enable inclusion within other languages. The intrinsic width and height of the viewport of SVG content must be determined from the 'width' and 'height' attributes. If either of these are not specified, the lacuna value of '100%' must be used. Note: the 'width' and 'height' attributes are not the same as the CSS width and height properties. Specifically, percentage values do not provide an intrinsic width or height, and do not indicate a percentage of the containing block. Rather, they indicate the portion of the viewport that is actually covered by image data.

The intrinsic aspect ratio of the viewport of SVG content is necessary for example, when including SVG from an object element in XHTML styled with CSS. It is possible (indeed, common) for an SVG graphic to have an intrinsic aspect ratio but not to have an intrinsic width or height. The intrinsic aspect ratio must be calculated based upon the following rules:

The aspect ratio is calculated by dividing a width by a height.
If the 'width' and 'height' of the rootmost 'svg' element are both specified with unit identifiers (in, mm, cm, pt, pc, px, em, ex) or in user units, then the aspect ratio is calculated from the 'width' and 'height' attributes after resolving both values to user units.
If either/both of the 'width' and 'height' of the rootmost 'svg' element are in percentage units (or omitted), the aspect ratio is calculated from the width and height values of the 'viewBox' specified for the current SVG document fragment. If the 'viewBox' is not correctly specified, or set to 'none', the intrinsic aspect ratio cannot be calculated and is considered unspecified.

Examples:

Example: Intrinsic Aspect Ratio 1

<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="10cm" height="5cm">
  ...
</svg>

In this example the intrinsic aspect ratio of the viewport is 2:1. The intrinsic width is 10cm and the intrinsic height is 5cm.

Example: Intrinsic Aspect Ratio 2

<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="100%" height="50%" viewBox="0 0 200 200">
  ...
</svg>

In this example the intrinsic aspect ratio of the rootmost viewport is 1:1. An aspect ratio calculation in this case allows embedding in an object within a containing block that is only constrained in one direction.

Example: Intrinsic Aspect Ratio 3

<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="10cm" viewBox="0 0 200 200">
  ...
</svg>

In this case the intrinsic aspect ratio is 1:1.

Example: Intrinsic Aspect Ratio 4

<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="75%" height="10cm" viewBox="0 0 200 200">
  ...
</svg>

In this example, the intrinsic aspect ratio is 1:1.

7.14 Geographic coordinate systems

In order to allow interoperability between SVG content generators and SVG user agents dealing with maps encoded in SVG, the use of a common metadata definition for describing the coordinate system used to generate SVG documents is encouraged.

Such metadata must be added under the 'metadata' element of the topmost 'svg' element describing the map, consisting of an RDF description of the Coordinate Reference System definition used to generate the SVG map [RDF]. Note that the presence of this metadata does not affect the rendering of the SVG in any way; it merely provides added semantic value for applications that make use of combined maps.

The definition must be conformant to the XML grammar described in GML 3.2.1, an OpenGIS Standard for encoding common CRS data types in XML [GML]. In order to correctly map the 2-dimensional data used by SVG, the CRS must be of subtype ProjectedCRS or Geographic2dCRS. The first axis of the described CRS maps the SVG x-axis and the second axis maps the SVG y-axis.

The main purpose of such metadata is to indicate to the user agent that two or more SVG documents can be overlayed or merged into a single document. Obviously, if two maps reference the same Coordinate Reference System definition and have the same SVG 'transform' attribute value then they can be overlayed without reprojecting the data. If the maps reference different Coordinate Reference Systems and/or have different SVG 'transform' attribute values, then a specialized cartographic user agent may choose to transform the coordinate data to overlay the data. However, typical SVG user agents are not required to perform these types of transformations, or even recognize the metadata. It is described in this specification so that the connection between geographic coordinate systems and the SVG coordinate system is clear.

7.15 The 'svg:transform' attribute

Attribute definition:

svg:transform = "<transform>" | "none"

<transform>: Specifies the affine transformation that has been applied to the map data. The syntax is identical to that described in The 'transform' attribute section.
none: Specifies that no supplemental affine transformation has been applied to the map data. Using this value has the same meaning as specifying the identity matrix, which in turn is just the same as not specifying the 'svg:transform' the attribute at all.

Animatable: no.

This attribute describes an optional additional affine transformation that may have been applied during this mapping. This attribute may be added to the OpenGIS 'CoordinateReferenceSystem' element. Note that, unlike the 'transform' attribute, it does not indicate that a transformation is to be applied to the data within the file. Instead, it simply describes the transformation that was already applied to the data when being encoded in SVG.

There are three typical uses for the 'svg:transform' global attribute. These are described below and used in the examples.

Most ProjectedCRS have the north direction represented by positive values of the second axis and conversely SVG has a y-down coordinate system. That's why, in order to follow the usual way to represent a map with the north at its top, it is recommended for that kind of ProjectedCRS to use the 'svg:transform' global attribute with a 'scale(1, -1)' value as in the third example below.
Most Geographic2dCRS have the latitude as their first axis rather than the longitude, which means that the south-north axis would be represented by the x-axis in SVG instead of the usual y-axis. That's why, in order to follow the usual way to represent a map with the north at its top, it is recommended for that kind of Geographic2dCRS to use the 'svg:transform' global attribute with a 'rotate(-90)' value as in the first example (while also adding the 'scale(1, -1)' as for ProjectedCRS).
In addition, when converting for profiles which place restrictions on precision of real number values, it may be useful to add an additional scaling factor to retain good precision for a specific area. When generating an SVG document from WGS84 geographic coordinates (EPGS 4326), we recommend the use of an additional 100 times scaling factor corresponding to an 'svg:transform' global attribute with a 'rotate(-90) scale(100)' value (shown in the second example). Different scaling values may be required depending on the particular CRS.

Below is a simple example of the coordinate metadata, which describes the coordinate system used by the document via a URI.

Example: 07_19.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="100" height="100" viewBox="0 0 1000 1000">

  <desc>An example that references coordinate data.</desc>

  <metadata>
    <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:crs="http://www.ogc.org/crs"
             xmlns:svg="http://wwww.w3.org/2000/svg">
      <rdf:Description rdf:about="">
        <!-- The Coordinate Reference System is described
             through a URI. -->
        <crs:CoordinateReferenceSystem
            svg:transform="rotate(-90)"
            rdf:resource="http://www.example.org/srs/epsg.xml#4326"/>
      </rdf:Description>
    </rdf:RDF>
  </metadata>

  <!-- The actual map content -->
</svg>

The second example uses a well-known identifier to describe the coordinate system. Note that the coordinates used in the document have had the supplied transform applied.

Example: 07_20.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="100" height="100" viewBox="0 0 1000 1000">

  <desc>Example using a well known coordinate system.</desc>

  <metadata>
    <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:crs="http://www.ogc.org/crs"
             xmlns:svg="http://wwww.w3.org/2000/svg">
      <rdf:Description rdf:about="">
        <!-- In case of a well-known Coordinate Reference System
             an 'Identifier' is enough to describe the CRS -->
        <crs:CoordinateReferenceSystem svg:transform="rotate(-90) scale(100, 100)">
          <crs:Identifier>
            <crs:code>4326</crs:code>
            <crs:codeSpace>EPSG</crs:codeSpace>
            <crs:edition>5.2</crs:edition>
          </crs:Identifier>
        </crs:CoordinateReferenceSystem>
      </rdf:Description>
    </rdf:RDF>
  </metadata>

  <!-- The actual map content -->
</svg>

The third example defines the coordinate system completely within the SVG document.

Example: 07_21.svg

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
     width="100" height="100" viewBox="0 0 1000 1000">

  <desc>Coordinate metadata defined within the SVG document</desc>

  <metadata>
    <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:crs="http://www.ogc.org/crs"
             xmlns:svg="http://wwww.w3.org/2000/svg">
      <rdf:Description rdf:about="">
        <!-- For other CRS it should be entirely defined -->
        <crs:CoordinateReferenceSystem svg:transform="scale(1,-1)">
          <crs:NameSet>
            <crs:name>Mercator projection of WGS84</crs:name>
          </crs:NameSet>
          <crs:ProjectedCRS>
            <!-- The actual definition of the CRS -->
            <crs:CartesianCoordinateSystem>
              <crs:dimension>2</crs:dimension>
              <crs:CoordinateAxis>
                <crs:axisDirection>north</crs:axisDirection>
                <crs:AngularUnit>
                  <crs:Identifier>
                    <crs:code>9108</crs:code>
                    <crs:codeSpace>EPSG</crs:codeSpace>
                    <crs:edition>5.2</crs:edition>
                  </crs:Identifier>
                </crs:AngularUnit>
              </crs:CoordinateAxis>
              <crs:CoordinateAxis>
                <crs:axisDirection>east</crs:axisDirection>
                <crs:AngularUnit>
                  <crs:Identifier>
                    <crs:code>9108</crs:code>
                    <crs:codeSpace>EPSG</crs:codeSpace>
                    <crs:edition>5.2</crs:edition>
                  </crs:Identifier>
                </crs:AngularUnit>
              </crs:CoordinateAxis>
            </crs:CartesianCoordinateSystem>
            <crs:CoordinateReferenceSystem>
              <!-- the reference system of that projected system is
                         WGS84 which is EPSG 4326 in EPSG codeSpace -->
              <crs:NameSet>
                <crs:name>WGS 84</crs:name>
              </crs:NameSet>
              <crs:Identifier>
                <crs:code>4326</crs:code>
                <crs:codeSpace>EPSG</crs:codeSpace>
                <crs:edition>5.2</crs:edition>
              </crs:Identifier>
            </crs:CoordinateReferenceSystem>
            <crs:CoordinateTransformationDefinition>
              <crs:sourceDimensions>2</crs:sourceDimensions>
              <crs:targetDimensions>2</crs:targetDimensions>
              <crs:ParameterizedTransformation>
                <crs:TransformationMethod>
                  <!-- the projection is a Mercator projection which is
                        EPSG 9805 in EPSG codeSpace -->
                  <crs:NameSet>
                    <crs:name>Mercator</crs:name>
                  </crs:NameSet>
                  <crs:Identifier>
                    <crs:code>9805</crs:code>
                    <crs:codeSpace>EPSG</crs:codeSpace>
                    <crs:edition>5.2</crs:edition>
                  </crs:Identifier>
                  <crs:description>Mercator (2SP)</crs:description>
                </crs:TransformationMethod>
                <crs:Parameter>
                  <crs:NameSet>
                    <crs:name>Latitude of 1st standart parallel</crs:name>
                  </crs:NameSet>
                  <crs:Identifier>
                    <crs:code>8823</crs:code>
                    <crs:codeSpace>EPSG</crs:codeSpace>
                    <crs:edition>5.2</crs:edition>
                  </crs:Identifier>
                  <crs:value>0</crs:value>
                </crs:Parameter>
                <crs:Parameter>
                  <crs:NameSet>
                    <crs:name>Longitude of natural origin</crs:name>
                  </crs:NameSet>
                  <crs:Identifier>
                    <crs:code>8802</crs:code>
                    <crs:codeSpace>EPSG</crs:codeSpace>
                    <crs:edition>5.2</crs:edition>
                  </crs:Identifier>
                  <crs:value>0</crs:value>
                </crs:Parameter>
                <crs:Parameter>
                  <crs:NameSet>
                    <crs:name>False Easting</crs:name>
                  </crs:NameSet>
                  <crs:Identifier>
                    <crs:code>8806</crs:code>         
                    <crs:codeSpace>EPSG</crs:codeSpace>
                    <crs:edition>5.2</crs:edition>
                  </crs:Identifier>
                  <crs:value>0</crs:value>
                </crs:Parameter>
                <crs:Parameter>
                  <crs:NameSet>
                    <crs:name>False Northing</crs:name>
                  </crs:NameSet>
                  <crs:Identifier>
                    <crs:code>8807</crs:code>
                    <crs:codeSpace>EPSG</crs:codeSpace>
                    <crs:edition>5.2</crs:edition>
                  </crs:Identifier>
                  <crs:value>0</crs:value>
                </crs:Parameter>
              </crs:ParameterizedTransformation>
            </crs:CoordinateTransformationDefinition>
          </crs:ProjectedCRS>
        </crs:CoordinateReferenceSystem>
      </rdf:Description>
    </rdf:RDF>
  </metadata>

  <!-- the actual map content -->
</svg>

Scalable Vector Graphics (SVG) Tiny 1.2 Specification

W3C Editor’s Draft 12 September 2008

Abstract

Status of this document

Available languages

Table of Contents

Acknowledgments

Expanded Table of Contents

1 Introduction

Contents

1.1 About SVG

1.2 SVG Tiny 1.2

1.2.1 Profiling the SVG specification

1.3 Defining an SVG Tiny 1.2 document

1.4 SVG MIME type, file name extension and Macintosh file type

1.5 Compatibility with other standards efforts

1.6 Definitions

1.7 How to reference this specification

2 Concepts

Contents

2.1 Explaining the name: SVG

2.1.1 Scalable

2.1.2 Vector

2.1.3 Graphics

2.1.4 XML

2.1.5 Namespace

2.1.6 Scriptable

2.2 Important SVG concepts

2.2.1 Graphical objects

2.2.2 Re-use

2.2.3 Fonts

2.2.4 Animation

2.3 Options for using SVG in Web pages

3 Rendering Model

Contents

3.1 Introduction

3.2 The painters model

3.3 Rendering order

3.4 Types of graphics elements

3.4.1 Rendering shapes and text

3.4.2 Rendering raster images

3.4.3 Rendering video

3.5 Object opacity

3.6 Parent compositing

4 Basic Data Types

5 Document Structure

Contents

5.1 Defining an SVG document fragment: the 'svg' element

5.1.1 Overview

5.1.2 The 'svg' element

5.2 Grouping: the 'g' element

5.2.1 Overview

5.2.2 The 'g' element

5.3 The 'defs' element

5.4 The 'discard' element

5.5 The 'title' and 'desc' elements

5.5.1 Applicable 'title' and 'desc'

5.5.2 Multiple 'title' and 'desc' elements

5.5.3 User interface behavior for 'title' and 'desc'

5.6 The 'use' element

5.7 The 'image' element

5.8 Conditional processing

5.8.1 Conditional processing overview

5.8.2 The 'switch' element

5.8.3 The 'requiredFeatures' attribute

5.8.4 The 'requiredExtensions' attribute

5.8.5 The 'systemLanguage' attribute

5.8.6 The 'requiredFormats' attribute

5.8.7 The 'requiredFonts' attribute

5.9 External resources

5.9.1 The 'externalResourcesRequired' attribute

5.9.2 Progressive rendering

5.9.3 The 'prefetch' element

5.10 Common attributes

5.10.1 Attributes common to all elements: 'id', 'xml:id', 'xml:base', 'class', 'role', 'rel', 'rev', 'about', 'content', 'datatype', 'property', 'resource', and 'typeof'

The 'id' and 'xml:id' attributes

The 'xml:base' attribute

The 'class' attribute

The 'role' attribute

The 'rel' attribute