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 drawings 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 Web Architecture
of the World Wide Web
[AWWW]. [
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 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, 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 -
1.2: SVG Tiny 1.2 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 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 . [ SVGM11
]. Backwards compatible means that
conformant SVG Tiny 1.1 content will render the same in conformant
SVG Tiny 1.2 User Agents user agents as it did in conformant SVG Tiny 1.1
User Agents. user
agents. A few key differences from SVG Tiny 1.1 should be
noted:
The value of the version 'version'
attribute on the rootmost
svg 'svg'
element should be "1.2".
"1.2" .
See the discussion of Version Control . 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 'version' and
baseProfile 'baseProfile'
attributes. In SVG Tiny 1.2, validation is
provided by can be performed
using the SVG Tiny 1.2 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 file: document:
<?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;<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>
The MIME type for SVG is " image/svg+xml
" "image/svg+xml"
(see Media Type
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. 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
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.)
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 Extensible Markup Language (XML) 1.1" Recommendation 1.1 [ XML11 ] and "Extensible Extensible Markup Language (XML) 1.0 (Third
Edition)" Recommendations Edition) [ XML10 ] Recommendations.
SVG Tiny 1.2 is compatible with both the "Namespaces
Namespaces in XML 1.0"
1.0 [ XML-NS10 ] and the "Namespaces
Namespaces in XML 1.1"
Recommendations 1.1 [
XML-NS ] Recommendations.
SVG Tiny 1.2 utilizes "XML XML Linking Language (XLink)" (XLink) [ XLINK XLINK10 ] for IRI referencing and requires
support for base IRI specifications defined in "XML Base" XML Base [ XML-BASE ].
SVG Tiny 1.2 uses the xml:id
'xml:id'
attribute as defined in xml:id Version 1.0 [ XMLID ].
SVG Tiny 1.2 content can be generated by
XSLT (see "XSL using XSL Transformations (XSLT) Version 1.0" 1.0 [
XSLT ]). ]. (See Styling with XSL ) .)
SVG Tiny 1.2 supports formatting properties drawn from CSS and
XSL. See (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
Document Object Model (DOM) level
3" Level 3 Core [
DOM3 ], including namespace
support and event handling.
SVG Tiny 1.2 incorporates some features from "Synchronized the
Synchronized Multimedia Integration Language
(SMIL) 2.0 Specification" 2.1 Specification [ SMIL2.0 SMIL21 ], including the 'prefetch'
'switch' element
, element, the systemLanguage '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: Unicode [ UNICODE The Unicode
Standard ], Resource
Identifiers [ CHARMOD-RI UNICODE ]
and the Character
Model for the World Wide Web
1.0 [ CHARMOD
]. Also, see (See Internationalization
Support . .)
SVG is compatible with W3C work on Web Accessibility [ WAI ]. Also,
see (See Accessibility Support . ).
In environments which support the Document
Object Model (DOM) Core [
DOM3 ].for ] 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.
When used in this specification, terms have the meanings assigned in this section.
The bounding box (or "bbox") of an
element is the tightest fitting rectangle aligned with the
axes of the applicable that element's user
coordinate system that entirely encloses the applicable element 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, shape along the
edge, not just end points.
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.
<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' 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 the a 'defs' element, elements with whose display 'display' =
is 'none' 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
may optionally must return a bounding box for the sake of
calculating their own geometry.
Elements and document fragments
which derive from SVGLocatable but are not found
shall 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 with an 'x' and 'y' box. The geometry of '0' and
a 'width' elements outside the
rendering tree must take into account only those properties
and values (such as 'height' 'font-size' of '-1' .
Elements ) which are specified
within that do not derive from
SVGLocatable do not element or document
fragment, or which have a bounding box,
and must raise lacuna value
or an exception
if the bounding box is requested. 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 .
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' container element and
'systemLanguage'
.
The current SVG document fragment of an element is the XML document sub-tree such that:
A given element may have no current SVG document fragment.
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.
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. The document begin for: attribute:
load
event is
The document end of an SVG
document fragment is the point time at which
the document fragment has been released and is no longer being
processed by the user agent.
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).
The operation of painting the interior of a shape or the interior of the character glyphs in a text string.
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.
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.
A graphics element is an SVG element
types that can cause graphics to be
drawn onto the target canvas. Specifically: Specifically,
the following elements are graphics elements: 'path' 'animation' , 'text' 'circle' , 'textArea' 'ellipse' , 'rect' 'image' , 'circle' 'line' , 'ellipse' 'path' , 'line' 'polygon' , 'polyline' , 'polygon' 'rect' , 'image' 'text' , 'use' 'textArea' , 'animation' 'use' and 'video' .
A graphics referencing element
which is a
graphics element that uses a reference to a different document or
element as the source of its graphical content. Specifically: The following
elements are graphics referencing elements: 'use' 'animation' , 'image' , 'animation' 'use' and 'video' .
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 ].
A value is 'in error' in error if it is specifically stated as being
'in error' "in
error" or 'an error' "an error" in the prose of this specification. See
Error Processing for
more detail on handling errors.
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 Timing
Modelling interactive, event-based content in
SMIL ,
Paused Elements and Active Duration , and
Event Sensitivity . ([ SMIL21 ], sections
10.11.2 and 10.4.3).
An IRI reference is an
Internationalized Resource Identifier (IRI).
Defined with an optional fragment
identifier, as defined in RFC
3987 . Serves 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 .
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 .
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.
A local IRI reference is an IRI reference that references a fragment within the same resource. See References .
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 .
A non-local IRI reference is an IRI reference ] that represents a
reference to references a
different document or an element within a different document.
A media element is an element which
defines its own timeline within its own time container. The
following elements are media elements: 'animation'
,'audio'
paint and
'video' .
See Multimedia .
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 .
A presentation attribute is an XML attribute on an SVG element which specifies a value for a given property for that element. See Styling .
A property is a parameter that helps
specify how a document should be rendered. A complete list of
SVG's the
SVG properties can be found in the Attribute and Property Index
. Table appendix. Properties are assigned to elements in
the SVG language by presentation attributes . See Styling .
The rendering tree is the set of
elements being rendered, aurally or visually using the painters
model, on in an SVG
document fragment . The following elements in the
fragment: fragment and their children are part of the
SVG document
fragment ,but
not part
of the rendering tree (and thus are not rendered):
The copies of elements referenced by
a 'radialGradient'
'use' element and their children, element, on the other hand, are part of not
in the SVG
document fragment , but
not part of are
in the rendering tree (and thus do not
get rendered). Elements 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. 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 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 'svg' element
is the only svg 'svg' element, except when there is an
svg 'svg' element inside a foreignObject) 'foreignObject' ) but also for SVG Full 1.2 and SVG that uses
sXBL. XBL [
XBL2
]. See also SVG
document fragment .
A tree fragment that is not part of the
DOM tree, but which is attached to a referencing element
(e.g. 'use'
shape 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".
A shape is a graphics
element that comprises a defined combination of straight
lines and curves. Specifically any instance
of Specifically, the element types: 'path' , 'rect' , following elements are shapes: 'circle' , 'ellipse' , 'line' , 'polyline'
'path' , 'polygon' . ,
'polyline'
stroke and
'rect' .
Stroking is the operation of painting the outline of a shape or the outline of character glyphs in a text string.
The canvas onto which the SVG content is
rendered. See the discussion of the SVG canvas in the chapter on Coordinate
Systems, Transformations and Units . chapter.
A 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 'svg' element . If the SVG content
contains any foreignObject 'foreignObject' elements which in turn
contain non-SVG content, the SVG context does not include the
contents of the foreignObject 'foreignObject' elements.
In SVG Tiny 1.2 1.2, an SVG context contains one SVG document fragment .
The An SVG
document fragment is the XML document sub-tree whose rootmost
element is an 'svg' element.
(i.e. element (that is, the
rootmost svg '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 an the rootmost 'svg' element element. .
In SVG Tiny 1.2 1.2, the SVG document fragment must not contain
nested 'svg' elements -
nested 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 .
An SVG element is an element within the SVG namespace defined by the SVG language specification.
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 chapter on Coordinate
Systems, Transformations and Units . Syncbase
chapter.
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).
A text content element is an SVG
element that can define
causes a text string that is to be rendered onto the canvas.
The SVG Tiny 1.2's 1.2 text content
elements are the following: 'text' , 'tspan' 'textArea' and 'textArea' 'tspan' .
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's 1.2 defines two
text content block elements are the
following: elements: 'text'
, and 'textArea' .
A timed element is an element that
support supports the SVG Timing
Attributes timing attributes
. They are: The
following elements are timed elements: animate 'audio' , animateColor 'animate' , animateMotion
'animateColor' , animateTransform
'animateMotion' , set 'animateTransform' , video 'animation' , audio 'set'
and animation 'video' .
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 .
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 [x' y' 1] =
[x y 1] * matrix . See current
transformation matrix (CTM) and Coordinate system
transformations .
An unsupported value is a value that does not conform to this
specification, but is not specifically listed as 'in error'. being
in error . See the Implementation Notes for more
detail on processing unsupported values.
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 [UAAG10] [UAAG] .
A User Agent user agent may or may not have the ability to
retrieve and render SVG content; however, an SVG User Agent user
agent must be able to retrieve and render SVG
content.
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 is a synonym for user coordinate system .
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.
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
chapter on Coordinate Systems, Transformations and Units
. chapter.
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 '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 hav 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 is a synonym for viewport coordinate system .