SVG is a language for describing two-dimensional graphics in XML [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 drawings 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 Web Architecture [AWWW].
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 SVG Mobile 1.1 specification 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 programatic 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.
This specification describes a collection of abstract modules that provide specific units of functionality. These modules may be combined with each other and with modules defined in other specifications (such as XHTML) to create SVG subset and extension document types that qualify as members of the SVG family of document types. See Conformance for a description of SVG family documents, and [XHTMLplusMathMLplusSVG] for a profile that combines XHTML, MathML and SVG.
Each major section of the SVG specification produces a module named after that section, e.g. "Text Module" or "Structure Module".
Modules define a named collection of either elements or attributes. These collections are used as a shorthand when describing the set of attributes allowed on a particular element (eg. the "Style" attibute collection) or the set of elements allowed as children of a particular element (eg. the "Shape" element collection). All collections have names that begin with an uppercase character.
When defining a profile, it is assumed that all the element and attribute collections are defined to be empty. That way, a module can redefine the collection as it is included in the profile, adding elements or attributes to make them available within the profile. Therefore, it is not a mistake to refer to an element or attribute collection from a module that is not included in the profile, it simply means that collection is empty.
This specification defines the baseline language definition for SVG 1.2. The specification is defined in terms of a series of modules, each of which consists of a collection of language features. The modular definition of the language enables alternate profiles of the SVG language.
The Tiny profile of SVG 1.2 consists of all of the features defined within this specification. As a modularized 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.
SVG Tiny 1.2 is a backwards compatible upgrade to SVG Tiny 1.1 . A few key differences from SVG Tiny 1.1 should be noted:
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
Here is an example of an SVG 1.2 file:
<?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.
<?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 1.2, and thus no formal public identifier.</desc>
&Smile;
</svg>
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.
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).
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:
In environments which support the Document Object Model (DOM) [DOM3].for other XML grammars (e.g., XHTML [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.
When used in this specification, terms have the meanings assigned in this section.
The set of elements being rendered when the painters model is applied to 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 do not get rendered). Elements with zero opacity, or no fill and no stroke, or with the visibility property set to hidden, are still in the rendering tree. 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.
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 sXBL. See also SVG document fragment.
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.
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 localname is the string in quotes (e.g., "svg" or "path").