This specification defines the features and syntax for
Scalable Vector Graphics (SVG) Tiny, Version 1.2, a language for describing
two-dimensional vector graphics in XML, combined with raster graphics and multimedia.
Its goal is to provide the ability to create a whole range of graphical
content, from static images to animations to interactive Web applications.
SVG 1.2 Tiny is a profile of SVG intended for implementation on a range of
devices, from cellphones and PDAs to laptop and desktop computers, and thus
includes a subset of the features included in
SVG 1.1 Full,
along with new features to extend the capabilities of SVG. Further extensions
are planned in the form of modules which will be compatible with
SVG 1.2 Tiny, and which when combined with this specification, will match and
exceed the capabilities of
SVG 1.1 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 22 December 2008 Recommendation of SVG Tiny 1.2.

This document has been reviewed by W3C Members, by software developers, and by
other W3C groups and interested parties, and is endorsed by the Director as a
W3C Recommendation. It is a stable document and may be used as reference
material or cited from another document. W3C's role in making the Recommendation
is to draw attention to the specification and to promote its widespread
deployment. This enhances the functionality and interoperability of the Web.

The SVG Working Group
working closely with the developer community, has produced an
implementation
report to prove the implementability of this specification.
Previous drafts for this specification resulted in a number of comments
which have been addressed by the
SVG Working Group, with a
Disposition of Comments
available on the W3C SVG site. A list of
changes made since the Proposed Recommendation Working Draft is available in
Appendix T.

As described in the abstract, this specification represents the core for a set
of modular extensions, but is named SVG Tiny for historical reasons, as a profile
for mobile devices. Future versions of this specification will maintain
backwards compatibility with previous versions of the language, in a continuing
line of technology, but will bear the name "SVG Core" to represent this
relationship.

Please send questions or comments regarding the SVG 1.2 Tiny specification
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.

Authors

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

Authors:

Ola Andersson, Ikivo

Phil Armstrong, Corel Corporation

Henric Axelsson, Ericsson AB

Selim Balcısoy, Nokia

Robin Berjon, Expway

Benoît Bézaire, Itedo (formerly Corel Corporation)

John Bowler, Microsoft Corporation

Gordon Bowman, Corel Corporation

Craig Brown, Canon Information Systems Research Australia

Mike Bultrowicz, Savage Software

Tolga Çapin, Nokia

Milt Capsimalis, Autodesk Inc.

Mathias Larsson Carlander, Ericsson AB

Jakob Cederquist, Ikivo

Suresh Chitturi, Nokia

Charilaos Christopoulos, Ericsson AB

Richard Cohn, Adobe Systems Inc.

Lee Cole, Quark

Cyril Concolato, Groupe des Ecoles des Télécommunications (GET)

Don Cone, America Online Inc.

Erik Dahlström, Opera Software (Working Group Chair)

Alex Danilo, Canon Information Systems Research Australia

Thomas DeWeese, Eastman Kodak

David Dodds, Lexica

Andrew Donoho, IBM

David Duce, Oxford Brookes University

Jean-Claude Dufourd, Streamezzo (formerly GET)

Andrew Emmons, BitFlash (Working Group Chair)

Jerry Evans, Sun Microsystems

Jon Ferraiolo, Adobe Systems Inc.

藤沢 淳 (FUJISAWA Jun), Canon

Darryl Fuller, Schema Software

Scott Furman, Netscape Communications Corporation

Brent Getlin, Macromedia

Diego Gibellino, Telecom Italia

Christophe Gillette, Motorola (formerly BitFlash)

Peter Graffagnino, Apple

Rick Graham, BitFlash

Anthony Grasso, Canon Information Systems Research Australia

Niklas Hagelroth, Ikivo

Vincent Hardy, Sun Microsystems Inc.

端山 貴也 (HAYAMA Takanari), KDDI Research Labs

Scott Hayman, Research In Motion Limited

Stephane Heintz, OpenText (formerly BitFlash)

Lofton Henderson, OASIS

Jan Christian Herlitz, Excosoft

Ivan Herman, W3C

Alan Hester, Xerox Corporation

Olaf Hoffmann, Invited Expert

Bob Hopgood, RAL (CCLRC)

Bin Hu, Motorola

Michael Ingrassia, Nokia

石川 雅康 (ISHIKAWA Masayasu), W3C

Dean Jackson, W3C (W3C Team Contact)

Christophe Jolif, ILOG S.A.

Lee Klosterman, Hewlett-Packard

小林 亜令 (KOBAYASHI Arei), KDDI Research Labs

Thierry Kormann, ILOG S.A.

Yuri Khramov, Schema Software

Kelvin Lawrence, IBM

Håkon Lie, Opera

Chris Lilley, W3C (Working Group Chair)

Vincent Mahe, France Telecom

Philip Mansfield, Schema Software

Lee Martineau, Quickoffice

Charles McCathieNevile, Opera Software

Kevin McCluskey, Netscape Communications Corporation

Cameron McCormack, Invited Expert

水口 充 (MINAKUCHI Mitsuru), Sharp Corporation

Luc Minnebo, Agfa-Gevaert N.V.

Jean-Claude Moissinac, Groupe des Ecoles des Télécommunications (GET)

Tuan Nguyen, Microsoft Corporation

Craig Northway, Canon Information Systems Research Australia

小野 修一郎 (ONO Shuichiro), Sharp Corporation

Lars Piepel, Vodafone

Antoine Quint, Fuchsia Design (formerly ILOG)

णन्दिनि ऱमनि (Nandini Ramani), Sun Microsystems

Bruno David Simões Rodrigues, Vodafone

相良 毅 (SAGARA Takeshi), KDDI Research Labs

Troy Sandal, Visio Corporation

Peter Santangeli, Macromedia

Doug Schepers, W3C (formerly Vectoreal) (W3C Team Contact)

Sebastian Schnitzenbaumer, SAP AG

Haroon Sheikh, Corel Corporation

Andrew Shellshear, Canon Inc.

Brad Sipes, Ikivo

Andrew Sledd, Ikivo

Пётр Соротокин (Peter Sorotokin), Adobe Systems Inc.

Gavriel State, Corel Corporation

Robert Stevahn, Hewlett-Packard

Timothy Thompson, Eastman Kodak

上田 宏高 (UEDA Hirotaka), Sharp Corporation

Rick Yardumian, Canon Development Americas

Charles Ying, Openwave Systems Inc.

Shenxue Zhou, Quark

Atanas Zlatinski, Samsung Electronics

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, but are greatly appreciated.
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,
and from public feedback.

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.

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 Micro DOM, 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.

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:

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 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.

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

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 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.

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.

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 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.

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.

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.

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.

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):

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.

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

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.

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.

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.

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.

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.

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/SVGTiny12/,
where possible. This allows the reference to always refer to
the latest version of this specification.

1.8 How to use this specification

This section is informative.

This specification is meant to serve both as a guide to
authors in creating SVG content, and as a detailed reference
for implementors of browsers, viewers, authoring tools,
content processing tools, and other user agents to
create conforming interoperable implementations for
viewing SVG documents or outputting robust SVG code. It is
not intended as a comprehensive manual for authoring content,
and it is expected that books, tutorials, and other materials
based on this specification will be produced to appeal to
different audiences. It is meant to serve as a definitive
source for authors and users to reference when reporting bugs
and feature requests to implementations.

2.1 Explaining the name: SVG

2.1.1 Scalable

To be scalable means to increase or decrease uniformly. In
terms of graphics, scalable means not being limited to a
single, fixed, pixel size. On the Web, scalable means that a
particular technology can grow to a large number of files, a
large number of users, a wide variety of applications. SVG,
being a graphics technology for the Web, is scalable in both
senses of the word.

SVG graphics are scalable to different display resolutions,
so that for example printed output uses the full resolution of
the printer and can be displayed at the same size on screens of
different resolutions. The same SVG graphic can be placed at
different sizes on the same Web page, and re-used at different
sizes on different pages. SVG graphics can be magnified to see
fine detail, or to aid those with low vision.

SVG graphics are scalable because the same SVG content can
be a stand-alone graphic or can be referenced or included
inside other SVG graphics, thereby allowing a complex
illustration to be built up in parts, perhaps by several
people. The use and font
capabilities promote re-use of graphical components, maximize the advantages
of HTTP caching and avoid the need for a centralized registry of approved
symbols.

2.1.2 Vector

Vector graphics contain geometric objects such as lines and
curves. This gives greater flexibility compared to raster-only
formats (such as PNG and JPEG) which have to store information
for every pixel of the graphic. Typically, vector formats can
also integrate raster images and can combine them with vector
information to produce a complete illustration; SVG is no exception.

Since all modern displays are raster-oriented, the
difference between raster-only and vector graphics comes down
to where they are rasterized; client side in the case of vector
graphics, as opposed to already rasterized on the server. SVG
provides hints to control the rasterization process, for example to
allow anti-aliased artwork without the ugly aliasing typical of
low quality vector implementations.

2.1.3 Graphics

Most existing XML grammars represent either textual
information, or represent raw data such as financial
information. They typically provide only rudimentary graphical
capabilities, often less capable than the HTML 'img' element.
SVG fills a gap in the market by providing a rich, structured
description of vector and mixed vector/raster graphics; it can
be used stand-alone, or as an XML namespace with
other grammars.

2.1.4 XML

XML [XML10, XML11],
a W3C Recommendation for structured information exchange, has become extremely
popular and is both widely and reliably implemented. By being written
in XML, SVG builds on this strong foundation and gains many
advantages such as a sound basis for internationalization,
powerful structuring capability, an object model, and so on. By
building on existing, cleanly-implemented specifications,
XML-based grammars are open to implementation without a huge
reverse engineering effort.

2.1.5 Namespace

It is certainly useful to have a stand-alone, SVG-only
viewer. But SVG is also intended to be used as one component in
a multi-namespace XML application. This multiplies the power of
each of the namespaces used, to allow innovative new content to
be created. For example, SVG graphics may be included in a
document which uses any text-oriented XML namespace — including
XHTML. A scientific document, for example, might also use
MathML
[MATHML] for mathematics
in the document. The combination of SVG and SMIL leads to
interesting, time based, graphically rich presentations.

SVG is a good, general-purpose component for any multi-namespace grammar
that needs to use graphics.

2.1.6 Scriptable

The combination of scripting and the HTML DOM is often termed
"Dynamic HTML" and is widely used for animation, interactivity
and presentational effects. Similarly SVG allows the script-based
manipulation of the document tree using a subset of the XML DOM
and the SVG uDOM.

2.2 Important SVG concepts

2.2.1 Graphical objects

With any XML grammar, consideration has to be given to what
exactly is being modelled. For textual formats, modelling is
typically at the level of paragraphs and phrases, rather than
individual nouns, adverbs, or phonemes. Similarly, SVG models
graphics at the level of graphical objects rather than
individual points.

SVG provides a general path element, which can be used to
create a huge variety of graphical objects, and also provides
common basic shapes
such as rectangles and ellipses. These are convenient for hand
coding and may be used in the same ways as the more general
path element. SVG provides fine control over the coordinate
system in which graphical objects are defined and the
transformations that will be applied during rendering.

2.2.2 Re-use

It would have been possible to define some standard, pre-defined graphics
that all SVG implementations would provide. But which ones? There would always be
additional symbols for electronics, cartography, flowcharts,
etc., that people would need that were not provided until the
"next version". SVG allows users to create, re-use and share
their own graphical assets without requiring a centralized registry.
Communities of users can create and refine the graphics that
they need, without having to ask a committee. Designers can be
sure exactly of the graphical appearance of the graphics they
use and not have to worry about unsupported graphics.

Graphics may be re-used at different sizes and orientations.

2.2.3 Fonts

Graphically rich material is often highly dependent on the
particular font used and the exact spacing of the glyphs. In
many cases, designers convert text to outlines to avoid any
font substitution problems. This means that the original text
is not present and thus searchability and accessibility suffer.
In response to feedback from designers, SVG includes font
elements so that both text and graphical appearance are
preserved.

2.2.4 Animation

Animation can be produced via script-based manipulation of
the document, but scripts are difficult to edit and interchange
between authoring tools is harder. Again in response to
feedback from the design community, SVG includes declarative
animation elements which were designed collaboratively by the
SVG and SYMM Working Groups. This allows the animated effects
common in existing Web graphics to be expressed in SVG.

2.3 Options for using SVG in Web pages

There are a variety of ways in which SVG content can be
included within a Web page. Here are some of the options:

A stand-alone SVG Web page

In this case, an SVG document (i.e., a Web resource whose
MIME type is "image/svg+xml") is loaded directly
into a user agent such as a Web browser. The SVG document is
the Web page that is presented to the user.

Embedding by reference

In this case, a parent Web page references a separately
stored SVG document and specifies that the given SVG
document should be embedded as a component of the parent
Web page. For HTML or XHTML, here are three options:

The (X)HTML 'img' element is
the most common method for using graphics in HTML pages. For
faster display, the width and height of the image can be
given as attributes. One attribute that is required is
'alt', used to give an
alternate textual string for people browsing with images
off, or who cannot see the images. The string cannot
contain any markup. A 'longdesc'
attribute lets you point to a longer description — often in
HTML — which can have markup and richer formatting.

The (X)HTML 'object' element can
contain other elements nested within it, unlike
'img', which is empty. This
means that several different formats can be offered,
using nested 'object'
elements, with a final textual alternative (including
markup, links, etc). The rootmost element which can be
displayed will be used.

The (X)HTML 'applet' element
which can invoke a Java applet to view SVG content within the given
Web page. These applets can do many things, but a common
task is to use them to display images, particularly ones
in unusual formats or which need to be presented under
the control of a program for some other reason.

Embedding inline

In this case, SVG content is embedded inline directly within
the parent Web page. An example is an XHTML Web page with an
SVG document fragment textually included within the
XHTML.

External link, using the HTML 'a' element

This allows any stand-alone SVG viewer to be used, which can
(but need not) be a different program to that used to display
HTML. This option typically is used for unusual image
formats.

3.1 Introduction

Implementations of SVG are expected to behave as though they
implement a rendering (or imaging) model corresponding to the
one described in this chapter. A real implementation is not
required to implement the model in this way, but the result on
any device supported by the implementation shall match that
described by this model.

The appendix on conformance requirements
describes the extent to which an actual
implementation may deviate from this description. In practice
an actual implementation will deviate slightly because of
limitations of the output device (e.g. only a limited gamut of
colors might be supported) and because of practical limitations
in implementing a precise mathematical model (e.g. for
realistic performance curves may be approximated by straight
lines, the approximation need only be sufficiently precise to
match the conformance requirements).

3.2 The painters model

SVG uses a "painters model" of rendering.
Paint is
applied in successive operations to the output device such that each operation
paints over some area of the output device. When the area overlaps a
previously painted area the new paint partially or completely
obscures the old. When the paint is not completely opaque the
result on the output device is defined by the (mathematical)
rules for compositing described under
simple alpha compositing.

3.3 Rendering order

SVG defines a rendering tree.
Elements in the rendering tree have an implicit drawing order. Elements are
rendered using a pre-order, depth-first walk of the SVG document fragment.
Subsequent elements are painted on top of previously painted elements.

3.4 Types of graphics elements

Shapes,
which represent some combination of straight lines and curves.

Text, which represents some combination of character glyphs.

Replaced content:

Raster images, which represent an array of values that
specify the paint color and opacity (often termed alpha) at a
series of points on a rectangular grid. (SVG requires support
for specified raster image formats under
conformance requirements.)

Video, which represents a timed sequence of raster images.

Animation, which represents a timed vector animation.

Foreign objects, which represent rendering of non-SVG content.

3.4.1 Rendering shapes and text

Shapes and text can be
filled (i.e.,
paint can be applied to the interior of the shape) and
stroked
(i.e., painted applied along the outline of the shape). A stroke operation is
centered on the outline of the object; thus, in effect, half of the
paint falls on the interior of the shape and half of the paint
falls outside of the shape.

The fill is painted first, then the stroke.

Each fill and stroke operation has its own opacity settings;
thus, you can fill and/or stroke a shape with a
semi-transparently drawn solid color, with different opacity
values for the fill and stroke operations.

The fill and stroke operations are entirely independent
rendering operations; thus, if you both fill and stroke a shape,
half of the stroke will be painted on top of part of the
fill.

SVG Tiny supports the following built-in types of paint which can
be used in fill and stroke operations:

3.4.2 Rendering raster images

When a raster image is rendered, the original samples are
"resampled" using standard algorithms to produce samples at the
positions required on the output device. Resampling
requirements are discussed under
conformance requirements.

3.4.3 Rendering video

As a video stream is a timed sequence of raster images, rendering
video has some similarity to rendering raster images. However, given
the processing required to decode a video stream, not all implementations
may be able to transform the video output into SVG's userspace. Instead
they may be limited to rendering in device space.
More information can be found in the definition for
video.

3.5 Object opacity

Each fill or stroke painting operation must behave as though the
operation were first performed to an intermediate canvas which
is initialized to transparent black onto which either the solid
color or gradient paint is applied. Then, the alpha values on
the intermediate canvas are multiplied by the
'fill-opacity'
or 'stroke-opacity'
values. The resulting canvas is composited into the background using
simple alpha compositing.

3.6 Parent compositing

SVG document fragments can be semi-opaque. In many
environments (e.g., Web browsers), the SVG document fragment
has a final compositing step where the document as a whole is
blended translucently into the background canvas.

4 Basic Data Types

This chapter defines a number of common data types used in the definitions
of SVG properties and attributes. Some data types that are not referenced
by multiple properties and attributes are defined inline in subsequent
chapters.

All of the syntax alternatives for
<color> defined in
Syntax for color values must be
supported. All RGB colors are specified in the sRGB color space
[SRGB]. Using sRGB
provides an unambiguous and objectively measurable definition
of the color, which can be related to international standards
[COLORIMETRY].

A <coordinate> is a length
in the user coordinate system that is the given distance from the
origin of the user coordinate system along the relevant axis
(the x-axis for X coordinates, the y-axis for Y coordinates). Its syntax is the
same as that for <length>.

A length is a distance measurement. The format of a <length> is a
<number> optionally
followed by a unit identifier. If the <length> is expressed as a
value without a unit identifier (e.g.,
'48'), then the <length> represents
a distance in the current user coordinate system.

SVG Tiny 1.2 only supports optional units on the
'width' and
'height'
attributes on the 'svg' element.
These can specify values in any of the following units: in, cm, mm, pt, pc, px and %.
If one of the unit identifiers is provided (e.g.,
'12mm'), then the <length> is
processed according to the description in
Units.

Percentage values (e.g., '10%') on the
'width'
and 'height'
attributes of the 'svg'
element represent a percentage of the viewport size (refer to the section that discusses
Units in general).

<list-of-content-types>

A space-separated list of Internet media types, as used by the
'requiredFormats'
attribute.

The following is an EBNF grammar describing the <list-of-content-types>
syntax [EBNF]:

A <list-of-family-names> is a list of font family names using the same syntax
as the 'font-family'
property, excluding the <generic-family> and 'inherit'
values.

<list-of-language-ids>

A <list-of-language-ids> is a comma separated list of
non-empty <language-id> values. White space
may be used before or after the commas.

<list-of-strings>

A <list-of-strings> consists of a separated sequence of <string>s.
String lists are white space-separated, where white space is defined as one or more of the
following consecutive characters: "space" (U+0020), "tab" (U+0009), "line feed" (U+000A) and
"carriage return" (U+000D).

The following is an EBNF grammar describing the <list-of-strings>
syntax [EBNF]:

(Where T is a type other than
<content-type>,
<string>,
<language-id> and
<family-name>.)
A list consists of a separated sequence of values. Unless explicitly
described differently, each pair of list items can be separated either
by a comma (with optional whitespace before and after the comma)
or by white space alone.

White space in lists is defined as one or more of the
following consecutive characters: "space" (U+0020), "tab" (U+0009),
"line feed" (U+000A) and "carriage return" (U+000D).

The following is a template for an EBNF grammar describing the
<list-of-Ts> syntax
[EBNF]:

A <number> value is specified in either decimal or scientific notation.
A <number> using decimal notation
consists of either an <integer>,
or an optional sign character followed by zero or more
digits followed by a dot (.) followed by one or more
digits. Using scientific notation, it
consists of a number in decimal notation followed by
the letter "E" or "e", followed by an
<integer>.

The following is an EBNF grammar describing the <number> syntax
[EBNF]:

<number> values in conforming SVG Tiny 1.2 content must
have no more than 4 decimal digits in the fractional part of their
decimal expansion and must be in the range -32,767.9999 to +32,767.9999,
inclusive. It is recommended that higher precision floating point
storage and computation be performed on operations such as
coordinate system transformations to provide the best
possible precision and to prevent round-off errors.

The <QName> type is a qualified name, as defined by the
QName
production in
Namespaces in XML 1.0
([XML-NS10], section 3), or the
QName
production in
Namespaces in XML 1.1
([XML-NS], section 3)
if the document is an XML 1.1 document. If the <QName> has a
prefix, then the prefix is expanded into a tuple of an IRI reference
and a local name, using
the namespace declarations in effect where the name occurs.
Note that, as with unprefixed attributes, the default namespace is not used for unprefixed names.

A <transform> is a transformation specification, as can be specified in the
'transform'
attribute. As described in The 'transform' attribute,
three types of values are allowed: a transform list, a transform reference and the
'none' value.

The following is an EBNF grammar describing the <transform> syntax
[EBNF]:

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:

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:

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:

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.

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.

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 '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.

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'.

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.

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).

5.2 Grouping: the 'g' element

5.2.1 Overview

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
'id' or
'xml:id'
attribute. Named groups are needed for several purposes such as animation and
re-usable objects.

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.

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:

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.

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.
SVG 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.

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, which together comprise a sort of
heading and summary of the containing element. The
'title'
element must contain a brief plain text passage representing the 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 must contain
a longer, more detailed plain text description for the
container
or graphics element containing
it. This description, along with the content of the
'title'
element, must be usable as replacement content for cases
when the user cannot see the rendering of the
SVG
element for whatever 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). If for any reason, a graphical presentation
of the document is not available, the rootmost
descriptive elements
may represent the complete document and its purpose
in a textual manner, and authors should supply meaningful
content accordingly.

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.

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). In essence, there is a difference between
container elements
and graphics
elements when it comes to determining the applicability of a
descriptive element; a 'title' or 'desc' for a graphics element
should be assumed to apply only to that element, while a 'title' or 'desc' for a 'g' may apply to each of the children of that
group. 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 authors use at most one
'title'
and at most one
'desc'
element as an immediate child of any particular element,
and that these elements appear before any other child
elements (except possibly 'metadata' elements) or
character data content.

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 tooltip ([ARIA],
section 4.4.1) to indicate their intent. Future SVG specifications may define
an explicit mechanism for indicating whether a tooltip should be displayed.

In order to honor authorial intent, it is strongly recommended
that when, and only 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
rootmost 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 value description ([ARIA], section 4.4.1)
for textual equivalents of the graphics (the default role).

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.

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.

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.

Except for resolution of relative IRI references as noted and until the
referenced elements are modified, 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.

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.

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.

5.7 The 'image' element

The 'image'
element indicates that the contents of an image 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.

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.

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-widthraster-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.
an image which 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.

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). To ensure that a user agent only downloads media in formats that it supports,
thus optimizing download time and bandwidth usage, authors are encouraged to use
'requiredFormats',
instead of 'type'.

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
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.

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.

5.8.3 The 'requiredFeatures'
attribute

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.

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.

Language extensions may be vendor-specific or experimental features for the
SVG language itself, or may be separate languages (e.g., XHTML, MathML). If
an extension is a separate language that supports the Namespaces in XML 1.0
specification [XML-NS10]
or the Namespaces in XML 1.1 specification
[XML-NS], the
IRI reference
should be the Namespace URI for that language (e.g.,
"http://www.w3.org/1999/xhtml", "http://www.w3.org/1998/Math/MathML").
If the language does not support either Namespaces in XML
specification, the
IRI reference
should be an otherwise unique identifier for that language.

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.

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:

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.

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.

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.

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 becomes
in error
(see Error processing).
The document remains
in error
until all required resources become available.

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.

'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').

#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.

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'
element contains 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.

Defines how much of the media to fetch in bytes in terms 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.

Defines how much of the media to fetch in terms 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.

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.

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.

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.

This attribute specifies a unique identifier for the element.
Because of wider use and compatibility with legacy content and
existing user agents (including authoring tools), it is recommended that
content intended for use in a Web browser environment use
'id'
instead of
'xml:id'.
(See details on ID attributes below.)

This attribute specifies a unique identifier for the element.
Refer to xml:id Version 1.0
[XMLID]. It is recommended that
content intended for use with generic XML processing tools, particularly
in a scenario where the datatype of the
'id' attribute
is not known, use
'xml:id'.
(See details on ID attributes below.)

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 attribute value 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.

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.

This attribute is an analog of the HTML [HTML4]
attribute of the same name. It is intended to be used in the same manner,
such as with
RDFa [RDFA],
Microformats [MF],
and other semantic purposes.

The attribute value 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.

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.

This attribute is an analog of the HTML [HTML4]
attribute of the same name. It is intended to be used in the same manner,
such as with
RDFa [RDFA],
Microformats [MF],
and other semantic purposes.

The attribute value 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.

The 'content'
attribute provides a plain text value that may be suitable for humans, or
may be machine-readable, or both, 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.

This attribute is intended to functionally align with the
attribute of the same name in the
RDFa [RDFA]
specification, but is not limited to use with that format.

The 'property'
attribute is used for expressing relationships between the element's subject
(e.g., the text content of a child node or of an attribute value) and
a set of known or referenced properties.

This attribute is intended to functionally align with the
attribute of the same name in the
RDFa [RDFA]
specification, but is not limited to use with that format.

The attribute value 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.

The 'typeof'
attribute associates one or more datatypes with the element.
This attribute should not be confused with the
'type'
attribute, and has no direct effect on the rendering or execution of the element.

This attribute is intended to functionally align with the
attribute of the same name in the
RDFa [RDFA]
specification, but is not limited to use with that format.

The attribute value 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.

The 'id' and
'xml:id' attributes

Both the 'id'
and 'xml:id'
attributes specify a unique identifier for the element. Both are
have the data type <NCName>, but are
of type <ID> for purposes of validation.
'xml:id'
is intended to represent type
<ID>
universally across all document types. This makes it more suitable for
certain compound documents with arbitrary XML, or with generic XML toolchains
which require explicit knowledge of
<ID>-typed
attributes.

It is strongly recommended that SVG generators only use
'id' to
assign identity to elements, to maintain backwards compatibility
with existing viewers, authoring tools, and other content.

Because they are intended for different environments, the
'id' and
'xml:id' attributes must not
be used together on SVG elements in the same document. Such
documents are not conforming SVG 1.2 Tiny content, and the behavior
is not specified.

Transforming between
'id' and
'xml:id'

In order to facilitate the creation of content that can be used in
both primary scenarios (that is, in existing desktop
browsers and authoring tools, and in XML toolchains), an
XSLT stylesheet can be used to convert the
'id' attributes to
'xml:id' attributes (and
vice versa). For example, when content that has been
authored with the browser environment in mind
is being prepared for consumption by a generic XML tool,
it can be preprocessed by using the
id2xmlid.xsl sample stylesheet.
This allows the same content to be used with little overhead
or risk of breaking content. Example transformation stylesheets
are provided below:

6.1 SVG's styling properties

SVG uses styling properties to describe many of its document
parameters. Styling properties define how the
graphics elements
in the SVG content are to be rendered. SVG uses styling properties for
the following:

Parameters which are clearly visual in nature and thus
lend themselves to styling. Examples include all attributes
that define how an object is "painted," such as
fill and
stroke
colors, line widths and dash styles.

SVG shares many of its styling properties with CSS
[CSS2] and XSL
[XSL]. Except for any
additional SVG-specific rules explicitly mentioned in this
specification, the normative definition of properties that are
shared with CSS and XSL is the definition of the property from
the CSS 2 specification [CSS2].
Note: The CSS 2 specification is no longer
maintained, and implementors may wish to refer instead to its
future replacement, CSS 2.1
[CSS21], for more precise
details. SVG 1.2 Tiny refers to CSS 2 due to the maturity
of that specification on the W3C Recommendation track.

The following properties are shared between CSS 2 and SVG.
Apart from
'display',
these properties are also defined in XSL:

A table that lists and summarizes the styling properties can be found in
the Property Index.

6.2 Usage scenarios for styling

SVG has many usage scenarios, each with different needs.
Here are three common usage scenarios:

SVG content used as an exchange format (style
sheet language-independent):

In some usage scenarios, reliable interoperability of
SVG content across software tools is the main goal. Since
support for a particular style sheet language is not
guaranteed across all implementations, it is a requirement
that SVG content can be fully specified without the use of
a style sheet language.

XSLT offers the ability to take a stream of arbitrary
XML content as input, apply potentially complex
transformations, and then generate SVG content as output.
XSLT can be used to transform XML data extracted for instance from
databases into an SVG graphical representation of that
data. It is a requirement that fully specified SVG content
can be generated from XSLT.

CSS is a widely implemented declarative language for
assigning styling properties to XML content, including SVG.
It represents a combination of features, simplicity and
compactness that makes it very suitable for many
applications of SVG. SVG Tiny 1.2 does not require support for CSS selectors
applied to SVG content. Authors must not rely on external, author
stylesheets to style documents that are intended to be used with SVG Tiny
1.2 user agents.

6.3
Specifying properties using the presentation attributes

For each styling property defined in this specification (see
Property Index), there is a
corresponding XML attribute (the
presentation attribute)
with the same name that is available on all relevant SVG elements. For
example, SVG has a
'fill'
property that defines how to paint the interior of a shape. There is a
corresponding presentation attribute with the same name (i.e.,
'fill') that can be used to specify a
value for the
'fill'
property on a given element.

The following example shows how the
'fill'
and 'stroke'
properties can be assigned to a rectangle using the
'fill' and 'stroke'
presentation attributes. The rectangle will be filled with red and outlined
with blue:

Simplicity. Styling properties can be
attached to elements by simply providing a value for the
presentation attribute on the proper elements.

Restyling. SVG content that uses the
presentation attributes is highly compatible with downstream
processing using XSLT [XSLT]
or supplemental styling by adding CSS style rules to override some of the
presentation attributes.

Convenient generation using XSLT
[XSLT]. In some
cases, XSLT can be used to generate fully styled SVG content.
The presentation attributes are compatible with convenient
generation of SVG from XSLT.

In some situations, SVG content that uses the presentation
attributes has potential limitations versus SVG content that is
styled with a style sheet language such as CSS. In
other situations, such as when an XSLT style sheet generates
SVG content from semantically rich XML source files, the
limitations below may not apply.

Styling attached to content. The
presentation attributes are attached directly to particular
elements, thereby diminishing potential advantages that comes
from abstracting styling from content, such as the ability to
restyle documents for different uses and environments.

Flattened data model. In and of
themselves, the presentation attributes do not offer the
higher level abstractions that you get with a styling system,
such as the ability to define named collections of properties
which are applied to particular categories of elements. The
result is that, in many cases, important higher level
semantic information can be lost, potentially making document
reuse and restyling more difficult.

Potential increase in file size. Many
types of graphics use similar styling properties across
multiple elements. For example, a company organization chart
might assign one collection of styling properties to the
boxes around temporary workers (e.g., dashed outlines, red
fill), and a different collection of styling properties to
permanent workers (e.g., solid outlines, blue fill). Styling
systems such as CSS allow collections of properties to be
defined once in a file. With the styling attributes, it might
be necessary to specify presentation attributes on each
different element.

Note: An
!important
declaration ([CSS2], section 6.4.2)
within a presentation attribute definition is unsupported and
causes that attribute to have an unsupported value.

Note: there are no presentation attributes for
shorthand properties
([CSS2], section 1.3.3),
only for the individual properties that make up the shorthand. (In XML,
attribute order is not significant.)

Note: Animation of presentation attributes and animation of properties are
related, see the
'attributeType'
attribute definition for more information.

6.4 Styling with XSL

XSL style sheets [XSLT] define how to
transform XML content into something else, usually other XML.
When XSLT is used in conjunction with SVG, sometimes SVG
content will serve as both input and output for XSL style
sheets. Other times, XSL style sheets will take non-SVG content
as input and generate SVG content as output.

The following example uses an external XSL style sheet to
transform SVG content into modified SVG content. The style sheet sets the
'fill'
and 'stroke'
properties on all rectangles to red and blue, respectively:

6.5 Case sensitivity of property names and values

Property declarations via
presentation attributes
are expressed in XML, which is case-sensitive and must match the exact
property name. When using a presentation attribute to specify a value for the
'fill'
property, the presentation attribute must be specified as
'fill' and not 'FILL' or
'Fill'. Keyword values, such as "italic" in
font-style="italic",
are also case-sensitive and must be specified using the exact
case used in the specification which defines the given keyword.
For example, the keyword "sRGB" must have
lowercase "s" and uppercase "RGB".

6.6 Facilities from CSS and XSL used by SVG

SVG shares various relevant properties and approaches common to CSS and
XSL, plus the semantics of many of the processing rules. Many of SVG's
properties are shared between CSS 2, XSL and SVG. (See
list of shared properties).

6.7 Property inheritance and computation

SVG supports property inheritance to child elements. In the definition of
each property it is stated whether it is inherited or not. Inherited
properties inherit the computed value, and not the specified value.
For the calculation of computed values, see the definition of each property.
Note that the keyword inherit may be used to
force the property value of the parent to be used, even for non-inherited
properties.

7.1 Introduction

For all media, the 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.

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.

Note that the time at which the viewport size negotiation is finalized
is implementation-specific. Authors who need to be sure of the dimensions
of the viewport should do so with
load-event or
resize-event handlers.

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 unit equal to the parent (implicit or explicit)
user agent's
"pixel".

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).

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:

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. This is the lacuna value.

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>).

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:

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.

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'.

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".

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.

Note that the inverse of the parent element's
CTM
may not always exist. In such cases, the user agent can instead calculate the
CTM
of the element with the constrained transformation by looking up the
CTM
of the rootmost 'svg' element
directly. The 'ref(...)' value in this case
is not an unsupported value.

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.

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.

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 agentviewport is
a square with sides of 200 units.

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.

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
viewport space which must 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. This is the
lacuna value.

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:

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:

(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>.)

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.

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 lacuna value) -
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.

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).

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 (e.g. a user agent that supports SVG 1.1 Full [SVG11]), since the initial value for the
'overflow' property is hidden for non-root elements that establish viewports ([SVG11], section 14.3.3). 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:

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:

7.12 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 related properties,
the stroke related properties,
the opacity related properties
or the visibility
property. For curved shapes, the bounding box must enclose all
portions of the shape along the edge, not just end points.
Note that control points for a curve which are not defined as
lying along the line of the resulting curve (e.g., the second
coordinate pair of a
Cubic Bézier command)
must not contribute to the dimensions of the bounding box
(though those points may fall within the area of the bounding
box, if they lie within the shape itself, or along or close to
the curve). For example, control points of a curve that are at
a further distance than the curve edge, from the non-enclosing
side of the curve edge, must be excluded from the bounding box.

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.

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. Elements that do not contribute to the bounding box
of a parent element must still return their own bounding box value when
required.

To illustrate, example bbox-calc below shows a set of elements. Given this example, the following results shall be calculated for each of the elements.

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'.

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.14 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:

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.

7.15 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.16 The 'svg:transform'
attribute

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.

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.

8.1 Introduction

A path is described using the concept of a current point. In
an analogy with drawing on paper, the current point can be
thought of as the location of the pen. The position of the pen
can be changed, and the outline of a shape (open or closed) can
be traced by dragging the pen in either straight lines or
curves.

Paths represent the geometry of the outline of an object,
defined in terms of moveto (set a new current point),
lineto (draw a straight line), curveto (draw
a curve using a cubic Bézier) and closepath (close the current
shape by drawing a line to the last moveto) elements.
Compound paths (i.e., a path with multiple subpaths) are
possible to allow effects such as "donut holes" in objects.

The authoring length of the path, in user units. This value is used to calibrate the user agent's own distance-along-a-path calculations with that of the author. The user agent shall scale all distance-along-a-path computations by the ratio of 'pathLength' to the user agent's own computed value for total path length. 'pathLength' potentially affects calculations for motion animation and various stroke operations.

8.2.1 Animating path data

Interpolated path data animation is only possible when each normalized path data specification within an animation specification has exactly the same list of path data commands as the 'd' attribute after normalization. This means that each path data specification and the 'd' attribute would have the exact same list of commands if normalized as defined in Path Normalization. If an animation is specified and the list of path data commands is not the same, then the animation specification must be ignored as unsupported. The animation engine shall interpolate each parameter to each path data command separately based upon the attributes on the given animation element.

Path data can contain newline characters and thus can be
broken up into multiple lines to improve readability.

The syntax of path data is concise in order to allow for
minimal file size and efficient downloads, since many SVG files
will be dominated by their path data. Some of the ways that SVG
attempts to minimize the size of path data are as follows:

All instructions are expressed as one character (e.g., a moveto is expressed as an M).

Superfluous white space and separators such as commas can be eliminated (e.g., 'M 100 100 L 200 200' contains unnecessary spaces and could be expressed more compactly as 'M100 100L200 200').

The command letter can be eliminated on subsequent commands if the same command is used multiple times in a row (e.g., you can drop the second "L" in 'M 100 200 L 200 100 L -100 -200' and use 'M 100 200 L 200 100 -100 -200' instead).

Alternate forms of lineto are available to optimize the special cases of horizontal and vertical lines (absolute and relative).

Alternate forms of curve are available to optimize the special cases where some of the control points on the current segment can be determined automatically from the control points on the previous segment.

The path data syntax is a prefix notation (i.e., commands
followed by parameters). The only allowable decimal point is a
Unicode U+002E
FULL STOP (".") character (also referred to in Unicode as
PERIOD, dot and decimal point) [UNICODE] and no other delimiter
characters are allowed. (For example, the following is an
invalid numeric value in path data: "13,000.56".
Instead, say: "13000.56".)

For the relative versions of the commands, all coordinate values shall be relative to the current point at the start of the command.

In the tables below, the following notation is used:

(): grouping of parameters

+: 1 or more of the given parameter(s) is required

Coordinates following commands in uppercase (e.g., M) shall be treated as absolute coordinates.

Coordinates following commands in lowercase (e.g., m) shall be treated as relative coordinates.

The following sections list the commands.

8.3.2 The "moveto" commands

The 'moveto' commands (M or m) establish a new current point. The effect is as if the "pen" were lifted and moved to a new location. A path data segment (if there is one) must begin with a 'moveto' command. Subsequent 'moveto' commands (i.e., when the 'moveto' is not the first command) represent the start of a new subpath:

Command

Name

Parameters

Description

M (absolute)m (relative)

moveto

(x y)+

A new sub-path at the given (x,y) coordinate shall be started. This shall also establish a new current point at the given coordinate. If a relative 'moveto' (m) appears as the first element of the 'path', then it shall treated as a pair of absolute coordinates. If a 'moveto' is followed by multiple pairs of coordinates, the subsequent pairs shall be treated as implicit 'lineto' commands.

8.3.3 The "closepath" command

A straight line shall be drawn from the current point to the initial point of the current subpath, and shall end the current subpath. If a 'closepath' (Z or z) is followed immediately by any other command, then the next subpath must start at the same initial point as the current subpath.

When a subpath ends in a 'closepath', it differs in behavior from what happens when "manually" closing a subpath via a 'lineto' command in how 'stroke-linejoin' and 'stroke-linecap' are implemented. With 'closepath', the end of the final segment of the subpath shall be "joined" with the start of the initial segment of the subpath using the current value of 'stroke-linejoin'. If instead the subpath is closed "manually" via a 'lineto' command, the start of the first segment and the end of the last segment are not joined but instead shall each be capped using the current value of 'stroke-linecap'. At the end of the command, the new current point shall be set to the initial point of the current subpath.

Command

Name

Parameters

Description

Z orz

closepath

(none)

The current subpath shall be closed by drawing a straight line from
the current point to current subpath's initial point, which then shall
become the new current point. Since the Z and z commands take no
parameters, they have an identical effect.

8.3.4 The "lineto" commands

The various 'lineto' commands draw straight lines from the
current point to a new point:

Command

Name

Parameters

Description

L (absolute)l (relative)

lineto

(x y)+

A line shall be drawn from the current point to the given (x,y) coordinate, which then shall become the new current point. If more than one coordinate pair is specified, a polyline shall be drawn. At the end of the command, the new current point shall be set to the final set of coordinates provided.

H (absolute)h (relative)

horizontal lineto

x+

A horizontal line shall be drawn from the current point (cpx, cpy) to (x, cpy). If more than one x value is specified, multiple horizonal lines shall be drawn (although usually this doesn't make sense). At the end of the command, the new current point shall be (x, cpy) for the final value of x.

V (absolute)v (relative)

vertical lineto

y+

A vertical line shall be drawn from the current point (cpx, cpy) to (cpx, y). If more than one y value is specified, multiple vertical lines shall be drawn (although usually this doesn't make sense). At the end of the command, the new current point shall be (cpx, y) for the final value of y.

8.3.5 The Curve commands

These groups of commands draw curves:

Cubic
Bézier commands (C,
c, S and
s). A cubic Bézier segment is defined
by a start point, an end point, and two control points.

Quadratic
Bézier commands (Q,
q, T and
t). A quadratic Bézier segment is
defined by a start point, an end point, and one control
point.

8.3.6 The Cubic Bézier curve commands

A cubic Bézier curve shall be drawn from the current point to (x,y) using (x1,y1) as the control point at the beginning of the curve and (x2,y2) as the control point at the end of the curve. If multiple sets of coordinates are specified, a polybézier shall be drawn. At the end of the command, the new current point shall be the final (x,y) coordinate pair used in the polybézier.

S (absolute)s (relative)

shorthand/smooth curveto

(x2 y2 x y)+

A cubic Bézier curve shall be drawn from the current point to (x,y). The first control point shall be the reflection of the second control point on the previous command relative to the current point. (If there is no previous command or if the previous command was not an C, c, S or s, the first control point shall be coincident with the current point.) (x2,y2) shall be used as the second control point (i.e., the control point at the end of the curve). If multiple sets of coordinates are specified, a polybézier shall be drawn. At the end of the command, the new current point shall be the final (x,y) coordinate pair used in the polybézier.

Example 08_02 shows some
simple uses of 'Cubic Bézier' commands within a 'path'. Note that the control point for the "S" command is
computed automatically as the reflection of the control point
for the previous "C" command relative to the start point of the
"S" command.

The following picture shows some how cubic Bézier
curves change their shape depending on the position of the
control points. The first five examples illustrate a single
cubic Bézier path segment. The example at the lower
right shows a "C" command followed by an "S" command.

8.3.7 The Quadratic Bézier curve commands

A quadratic Bézier curve is drawn from the current point to (x,y) using (x1,y1) as the control point. If multiple sets of coordinates are specified, a polybézier shall be drawn. At the end of the command, the new current point shall be the final (x,y) coordinate pair used in the polybézier.

T (absolute)t (relative)

Shorthand/smooth quadratic Bézier curveto

(x y)+

A quadratic Bézier curve is drawn from the current point to (x,y). The control point shall be the reflection of the control point on the previous command relative to the current point. (If there is no previous command or if the previous command was not a Q, q, T or t, the control point shall be current point.) If multiple sets of coordinates are specified, a polybézier shall be drawn. At the end of the command, the new current point shall be the final (x,y) coordinate pair used in the polybézier.

Example quad01 shows some
simple uses of 'Quadratic Bézier' commands within a path.
Note that the control point for the "T" command is computed
automatically as the reflection of the control point for the
previous "Q" command relative to the start point of the "T"
command.

The processing of the EBNF must consume as much of a given
EBNF production as possible, stopping at the point when a
character is encountered which no longer satisfies the
production. Thus, in the string 'M 100-200', the first
coordinate for the "moveto" consumes the characters "100" and
stops upon encountering the minus sign because the minus sign
cannot follow a digit in the production of a "coordinate". The
result is that the first coordinate will be "100" and the
second coordinate will be "-200".

Similarly, for the string 'M 0.6.5', the first coordinate of
the "moveto" consumes the characters "0.6" and stops upon
encountering the second decimal point because the production of
a "coordinate" only allows one decimal point. The result is
that the first coordinate will be "0.6" and the second
coordinate will be ".5".

Note that the EBNF allows the path 'd' attribute to be empty. This is not
an error, instead it disables rendering of the path. Values of
the 'd' that do not match the
EBNF are treated as unsupported.

8.4 Distance along a path

To aid hand authoring by allowing convenient round numbers to be used, the 'pathLength' attribute can be used
to provide the author's computation of the total length of the
path so that the user agent can scale distance-along-a-path
computations by the ratio of 'pathLength' to the user agent's own
computed value for total path length.

A "moveto" operation within a 'path' element is defined to have
zero length. Only the various "lineto" and "curveto" commands
contribute to path length calculations.

Mathematically, these shape elements are equivalent to a 'path' element that would
construct the same shape. The basic shapes may be stroked,
and filled. All of the properties available
for 'path' elements also apply to
the basic shapes.

9.2 The 'rect'
element

The 'rect' element defines
a rectangle which is axis-aligned with the current user coordinate
system. Rounded rectangles can be achieved by setting
appropriate values for attributes 'rx' and 'ry'.

For rounded rectangles, the x-axis radius of the
ellipse used to round off the corners of the
rectangle.
A negative value is unsupported.
See the notes below about what happens if the attribute is
not specified.

For rounded rectangles, the y-axis radius of the
ellipse used to round off the corners of the
rectangle.
A negative value is unsupported.
See the notes below about what happens if the attribute is
not specified.

If a properly specified value is provided for 'rx' but not for 'ry', then the user agent must process
the 'rect' element with the
effective value for 'ry' as equal to 'rx'. If a properly specified value
is provided for 'ry' but not for 'rx', then the user agent must process
the 'rect' element with the
effective value for 'rx' as equal to 'ry'. If neither 'rx' nor 'ry' has a properly specified value,
then the user agent must process the 'rect' element as if no
rounding had been specified, resulting in square corners. If 'rx' is greater than half of the
width of the rectangle, then the user agent must process the 'rect' element with the
effective value for 'rx' as half of the width of the
rectangle. If 'ry' is greater than half of the
height of the rectangle, then the user agent must process the 'rect' element with the
effective value for 'ry' as half of the height of the
rectangle.

A 'rect' element, taking its rounded
corners into account, must be rendered in a way that produces the
same result as if the following
outline were specified instead
(note: all coordinate and length values are first converted
into user space coordinates according to Units):

Perform an absolute moveto operation to location (x+rx,y), where x and y are the values of the
'rect' element's 'x'
and 'y' attribute converted to user space, and rx and ry are the effective values of the
'rx' and 'ry' attributes converted to user space.

Perform an absolute elliptical arc operation to coordinate (x+width,y+ry), where the effective values for the 'rx' and 'ry' attributes on the
'rect' element converted to user space are used as the semimajor and semiminor axis, respectively, zero x-axis-rotation, a clockwise sweep direction and choosing the smaller arc sweep.

Example 09_02 shows two
rounded rectangles. The 'rx' specifies how to round the
corners of the rectangles. Note that since no value has been
specified for the 'ry' attribute, it will be assigned
the same value as the 'rx' attribute.

9.3 The 'circle'
element

The 'circle' element
defines a circle based on a center point and a radius.

Within the current user coordinate system,
stroking operations on a circle begin at the point (cx+r,cy)
and then proceed through the points (cx,cy+r), (cx-r,cy), (cx,cy-r) and finally back to (cx+r,cy).
For stroking operations, there is only one line segment
which has its beginning joined to its end.

9.4 The 'ellipse'
element

The 'ellipse' element
defines an ellipse which is axis-aligned with the current user coordinate
system based on a center point and two radii.

Within the current user coordinate system,
stroking operations on a ellipse begin at the point (cx+rx,cy)
and then proceed through the points (cx,cy+ry), (cx-rx,cy), (cx,cy-ry) and finally back to (cx+rx,cy).
For stroking operations, there is only one line segment
which has its beginning joined to its end.

A 'line' element must be rendered in a way that produces the
same result as if the following
path were specified instead
(note: all coordinate and length values are first converted
into user space coordinates according to Units):

Perform an absolute moveto operation
to absolute location (x1,y1), where
x1 and y1 are the values of the 'line' element's 'x1' and 'y1' attributes converted to
user space, respectively.

Perform an absolute lineto operation
to absolute location (x2,y2), where
x2 and y2 are the values of the 'line' element's 'x2' and 'y2' attributes converted to
user space, respectively.

Because 'line' elements are single
lines and thus are geometrically one-dimensional, they have no
interior; thus, 'line' elements are never
filled (see the 'fill' property).

Example 09_05 below
specifies the coordinates of the five lines in the
user coordinate system established by the 'viewBox' attribute on the 'svg' element. The lines have
different thicknesses.

Each 'text' element causes a single
string of text to be rendered. The 'text' element performs no automatic line
breaking or word wrapping. To achieve the effect of multiple
lines of text, use one of the following methods:

Use the 'textArea' element to specify a rectangular area in which to flow the text.

Pre-compute the line breaks (which can be done by the author or authoring tool)
and use individual 'text' elements to manually place the lines of text.
(Note: this is discouraged for accessibility
reasons.)

Express the text to be rendered in another XML namespace
such as XHTML [XHTML] embedded
inline within a 'foreignObject' element.
(Note: the exact semantics of this approach are not
completely defined at this time.)

The text strings within 'text' elements shall be rendered in one straight line.
SVG supports the following international text processing features for straight line text:

left-to-right or bidirectional text (i.e., languages
which intermix right-to-left and left-to-right text, such as
Arabic and Hebrew)

when SVG fonts are
used, automatic selection of the correct glyph corresponding
to the current form for Arabic
and Han
text

For accessibility reasons, it is recommended that text which
is included in a document have appropriate semantic markup to
indicate its function. See SVG accessibility
guidelines for more information.

10.2 Characters and their corresponding glyphs

In XML [XML10, XML11],
textual content is defined in terms of a sequence of XML characters, where each character is
defined by a particular Unicode code point [UNICODE].
Fonts, on the other hand, consist of a collection of glyphs and other associated
information, such as font tables. A glyph
is a presentable form of one or more characters (or a part of a
character in some cases). Each glyph consists of some sort of
identifier (in some cases a string, in other cases a number)
along with drawing instructions for rendering that particular
glyph.

In many cases, there is a one-to-one mapping of Unicode
characters (i.e., Unicode code points) to glyphs in a font. For
example, it is common for a font designed for Latin languages
(where the term Latin is used for European languages
such as English with alphabets similar to or derivative to
the Latin language) to contain a single glyph for each of the
standard ASCII characters (i.e., A-to-Z, a-to-z, 0-to-9, plus
the various punctuation characters found in ASCII). Thus, in
most situations, the string "XML", which consists of three
Unicode characters, would be rendered by the three glyphs
corresponding to "X", "M" and "L", respectively.

In various other cases, however, there is not a strict
one-to-one mapping of Unicode characters to glyphs. Some of the
circumstances when the mapping is not one-to-one:

Ligatures — For best looking typesetting, it is often
desirable that particular sequences of characters are
rendered as a single glyph. An example is the word "office".
Many fonts will define an "ffi" ligature. When the word
"office" is rendered, sometimes the
user agent
will render the glyph for the "ffi" ligature instead of rendering
distinct glyphs (i.e., "f", "f" and "i") for each of the
three characters. Thus, for ligatures, multiple Unicode
characters map to a single glyph. Note that for proper
rendering of many languages, ligatures are required for
certain character combinations, and are not optional
typographic features. For example, this is the case
for most languages throughout South and South East Asia.

Composite characters — In many situations, commonly
used adornments such as diacritical marks will be stored once
in a font as a particular glyph and then composed with one or
more other glyphs to result in the desired character. For
example, it is possible that a font engine might render the
é character by
first rendering the glyph for e and then rendering the glyph
for ´ (the accent
mark) such that the accent mark will appear over the e.
In this situation, a single
Unicode character maps to multiple glyphs.

Context-sensitive glyph positioning — In many scripts, the
precise positioning of the glyph for a given character
(especially diacritics) will vary according to the visual context.
For example, Thai tone marks are rendered above the base
consonant, but need to be moved upwards further if a vowel-sign
also appears above the base consonant. The same character is used
in memory, but the final location of the glyph is sensitive to
context.

Complex positioning of character glyphs — In scripts such as
those used for Indian languages, a combining vowel character that
appears after a base consonant in memory may be displayed to the
left of the base consonant, or on two sides of the base consonant,
(i.e., the left-most glyph in rendered text may not be the first
character in a text element.) Indeed, such vowel characters may
be rendered to the left of, or on more than one side of, a
cluster of consonants that ends with the character they
follow in memory. On the other hand, a Hindi RA
character at the beginning of a consonant cluster in memory may
be displayed over a following vowel sign to the right of the
following syllabic cluster. The location, from left to right,
in which glyphs are displayed in these scripts can differ
significantly from the order of the characters in memory.

Glyph substitution — Many typography systems examine the
nature of the textual content and utilize different glyphs in
different circumstances. For example, in Arabic, the same
Unicode character might render as any of four different
glyphs, depending on such factors as whether the character
appears at the start, the end or the middle of a sequence of
cursively joined characters. Different glyphs might be used
for a punctuation character depending on
inline-progression-direction (e.g., horizontal vs. vertical).
In these situations, a single Unicode character might map to
one of several alternative glyphs.

In many languages, particular sequences of characters
will be converted into multiple glyphs such that parts of a
particular character are in one glyph and the remainder of
that character is in another glyph.

In many situations, the algorithms for mapping from
characters to glyphs are system-dependent, resulting in the
possibility that the rendering of text might be (usually
slightly) different when viewed in different user environments.
If the author of SVG content requires precise selection of
fonts and glyphs, then it is recommended that the necessary
fonts (potentially subsetted to include only the glyphs needed
for the given document) be available either as SVG fonts embedded within the
SVG content or as WebFonts
posted at the same Web location as the SVG content.

Throughout this chapter, the term character shall be equivalent to the
definition of a character in XML [XML11].

10.3 Fonts, font tables and baselines

A font consists of a collection of glyphs together with the
information (the font tables) necessary to use those glyphs to
present characters on some medium. The combination of the
collection of glyphs and the font tables is called the font
data. The font tables include the information necessary to
map characters to glyphs, to determine the size of glyph areas
and to position the glyph area. Each font table consists of one
or more font characteristics, such as the 'font-weight' and
'font-style'.

The geometric font characteristics are expressed in a
coordinate system based on the EM box. (The EM is a relative
measure of the height of the glyphs in the font; see CSS2 em
square ([CSS2], section 15.4.3).) The box 1 EM high and 1 EM wide is called the
design space. This space is given geometric
coordinates by sub-dividing the EM into a number of units-per-em
([CSS2], section 15.3.4).

Note: Units-per-em is a font characteristic. A typical value
for units-per-EM is 1000 or 2048.

The coordinate space of the EM box is called the design
space coordinate system. For scalable fonts, the curves
and lines that are used to draw a glyph are represented using
this coordinate system.

Note: Most often, the (0,0) point in this coordinate system
is positioned on the left edge of the EM box, but not at the
bottom left corner. The Y coordinate of the bottom of a roman
capital letter is usually zero. And the descenders on lowercase
roman letters have negative coordinate values.

SVG assumes that the font tables will provide at least three
font characteristics: an ascent, a descent and a set of
baseline-tables. The ascent is the distance to the top of the
EM box from the (0,0) point of the font; the descent is the
distance to the bottom of the EM box from the (0.0) point of
the font. The baseline-table is explained below.

Note: Within an OpenType font, for horizontal writing-modes,
the ascent and descent are given by the sTypoAscender and
sTypoDescender entries in the OS/2 table. For vertical
writing-modes, the descent (the distance, in this case from the
(0,0) point to the left edge of the glyph) is normally zero
because the (0,0) point is on the left edge. The ascent for
vertical writing-modes is either 1 em or is specified by the
ideographic top baseline value in the OpenType Base table for
vertical writing-modes.

In horizontal writing-modes, the glyphs of a given script
are positioned so that a particular point on each glyph, the
alignment-point, is
aligned with the alignment-points of the other glyphs in that
script. The glyphs of different scripts, for example, Western,
Northern Indic and Far-Eastern scripts, are typically aligned
at different points on the glyph. For example, Western glyphs
are aligned on the bottoms of the capital letters, northern
indic glyphs are aligned at the top of a horizontal stroke near
the top of the glyphs and far-eastern glyphs are aligned either
at the bottom or center of the glyph. Within a script and
within a line of text having a single font-size, the sequence
of alignment-points defines, in the inline-progression-direction,
geometric line called a
baseline. Western and most other alphabetic and
syllabic glyphs are aligned to an "alphabetic" baseline, the
northern indic glyphs are aligned to a "hanging" baseline and
the far-eastern glyphs are aligned to an "ideographic"
baseline.

A baseline-table specifies the position of one or
more baselines in the design space coordinate system. The
function of the baseline table is to facilitate the alignment
of different scripts with respect to each other when they are
mixed on the same text line. Because the desired relative
alignments may depend on which script is dominant in a line (or
block), there may be a different baseline table for each
script. In addition, different alignment positions are needed
for horizontal and vertical writing modes. Therefore, the font
may have a set of baseline tables: typically, one or more for
horizontal writing-modes and zero or more for vertical
writing-modes.

Note: Some fonts may not have values for the baseline
tables. Heuristics are suggested for approximating the baseline
tables when a given font does not supply baseline tables.

SVG further assumes that for each glyph in the font data for
a font, there is a width value, an alignment-baseline and an
alignment-point for horizontal writing-mode. (Vertical
writing-mode is not supported in SVG Tiny 1.2.)

In addition to the font characteristics required above, a
font may also supply substitution and positioning tables that
can be used by a formatter to re-order, combine and position a
sequence of glyphs to make one or more composite glyphs. The
combination may be as simple as a ligature, or as complex as an
indic syllable which combines, usually with some re-ordering,
multiple consonants and vowel glyphs.

10.4 The 'text'
element

The 'text' element defines
a graphics element consisting of text. The
XML content
within the 'text' element,
along with relevant attributes and properties and
character-to-glyph mapping tables within the font itself,
define the glyphs to be rendered. (See Characters and their
corresponding glyphs.) The attributes and properties on the
'text' element indicate such
things as the writing direction, font specification and
painting attributes which describe how exactly to render the
characters. Subsequent sections of this chapter describe the
relevant text-specific attributes and properties, in particular text layout and bidirectionality.

Text behaves like other graphical objects,
and it is therefore possible to apply a gradient to text. When this facility is applied
to text then the object bounding box units are computed relative to the entire
'text'
element in all cases, even when different effects are applied to different
'tspan'
elements within the same
'text' element.

The 'text'
element renders its first glyph (after
bidirectionality
reordering) at the initial
current text position,
which is established by the
'x' and
'y'
attributes on the 'text'
element (with possible adjustments due to the value of the
'text-anchor'
property). After the glyph(s) corresponding to the given character is (are) rendered,
the current text position is updated for the next glyph. In the simplest
case, the new current text position is the previous current
text position plus the glyph's advance value. See
text layout
for a description of glyph placement and glyph advance.

If a single <coordinate>
is provided, then the value represents the new absolute X
coordinate for the current text
position for rendering the glyphs that correspond to
the first character within this element or any of its
descendants.

If a comma- or space-separated list of n<coordinate>s
is provided, then the values represent new absolute X
coordinates for the current text
position for rendering the glyphs corresponding to each
of the first n characters within this element or
any of its descendants.

The corresponding list of absolute Y coordinates for
the glyphs corresponding to the characters within this
element. The processing rules for the 'y' attribute parallel the
processing rules for the 'x' attribute.

This attribute indicates the supplemental rotation about the alignment-point that must be applied to the glyphs corresponding to characters within this element according to the following rules:

A comma- or space-separated list of <number>s must be provided. The first <number>
specifies the supplemental rotation that must be applied to the glyphs
corresponding to the first character within this element or
any of its descendants, the second <number>
specifies the supplemental rotation that must be applied to the glyphs that
correspond to the second character, and so on.

If more <number>s are
provided than there are characters, then the extra <number>s must
be ignored.

If more characters are provided than <number>s, then
for each of these extra characters the rotation value specified by the last number must be used.

Where multiple characters map to one glyph, the rotation specified
for the first character of the ligature should be used for the glyph,
and the subsequent rotations for the other contributing characters
should be ignored.

Within a
text content block element,
graphic and font properties can be adjusted by including a
'tspan'
element. Positional attributes such as 'x',
'y', and 'rotate'
are not available on 'tspan' in SVG Tiny 1.2.

10.6 Text layout

10.6.1 Text layout introduction

This section describes the text layout features supported by
SVG. Text layout is described in a general and directionally neutral way,
to provide a single reference point for layout information which applies
to left-to-right (e.g., Latin scripts),
bidirectional (e.g., Hebrew or Arabic) and vertical (e.g.,
Asian scripts). In SVG Tiny 1.2, vertical writing is not supported.
The descriptions in this section assume
straight line text (i.e., text that is either strictly
horizontal or vertical with respect to the current
user coordinate system).

Based on the reference orientation the
SVG user agent
determines the current inline-progression-direction.
For left-to-right text, the inline-progression-direction points 90
degrees clockwise from the reference orientation vector. For
right-to-left text, the inline progression points 90 degrees
counter-clockwise from the reference orientation vector.

Based on the reference orientation the
SVG user agent
determines the current block-progression-direction. For
left-to-right and right-to-left text, the
block-progression-direction points 180 degrees from the
reference orientation vector because the only available
horizontal writing modes are
lr-tb and
rl-tb.

The current text position is adjusted after each glyph to
establish a new current text position at which the next glyph
shall be rendered. The adjustment to the current text position
is based on the current inline-progression-direction,
glyph-specific advance values corresponding to the glyph orientation of the
glyph just rendered, kerning tables in the font and the current
values of various attributes and properties, such as the spacing properties
and
any 'x' and 'y' attributes on
text content block elements.
If a glyph does not provide explicit advance values corresponding to the
current glyph orientation, then an appropriate approximation should be
used. For vertical text, a suggested approximation is the sum
of the ascent and descent values for the glyph. Another
suggested approximation for an advance value for both
horizontal and vertical text is the size of an em (see
'units-per-em').

For each glyph to be rendered, the SVG user
agent determines
an appropriate alignment-point on
the glyph which will be placed exactly at the current text
position. The alignment-point is determined based on glyph cell
metrics in the glyph itself, the current inline-progression-direction
and the glyph
orientation relative to the inline-progression-direction.
For most uses of Latin text
the alignment-point in the glyph will be the intersection of
left edge of the glyph cell (or some other glyph-specific
x-axis coordinate indicating a left-side origin point) with the
Latin baseline of the glyph. For many cases with top-to-bottom
vertical text layout, the reference point will be either a
glyph-specific origin point based on the set of vertical
baselines for the font or the intersection of the center of the
glyph with its top line (see
[CSS2] section 15.3.8
for a definition of top line). If a glyph does not
provide explicit origin points corresponding to the current glyph orientation, then
an appropriate approximation should be used, such as the
intersection of the left edge of the glyph with the appropriate
horizontal baseline for the glyph or intersection of the top
edge of the glyph with the appropriate vertical baseline. If
baseline tables are not available, user agents should establish
baseline tables that reflect common practice.

Adjustments to the current text position are either absolute position adjustments or relative position adjustments. An
absolute position adjustment occurs in the following
circumstances:

For each character within a 'text' element which has
an 'x' or 'y' attribute value assigned to it
explicitly

All other position adjustments to the current text position
are relative position adjustments.

Each absolute position adjustment defines a new text chunk. Absolute position
adjustments impact text layout in the following ways:

Ligatures only occur when a set of characters which might
map to a ligature are all in the same text chunk.

Each text chunk represents a separate block of text for
alignment due to 'text-anchor' property
values.

Reordering of characters due to bidirectionality
only occurs within a text chunk. Reordering does not
happen across text chunks.

The following additional rules apply to ligature
formation:

As in the discussion
of the CSS2 spacing properties ([CSS2], section 16.4),
when the resultant space between two characters
is not the same as the default letter spacing, user agents should
either not use ligatures or not apply letter-spacing depending on
their knowledge of which behavior will produce the most coherent
results for the script being used (for example, when the letter-spacing
is high it is likely that breaking ligatures will produce the best
result with Roman scripts, but be less than optimal for Arabic
scripts, where ignoring the letter-spacing and maintaining the
ligatures will be preferred).

Ligature formation must only occur between characters that are not
separated by element markup, and must still be enabled between characters
separated by other XML markup, such as comments, processing instructions,
or CDATA sections. Ligature processing must take place only after entity
and character references have been resolved. For example, assuming that
there is a ligature defined for the string "dahut" and that the '&hu-ent;'
entity reference contains the string "hu", in all the following examples
the "dahut" ligature will be enabled:

As mentioned above, ligature formation should not be
enabled for the glyphs corresponding to characters within
different text chunks.

10.6.2 Relationship with bidirectionality

The characters in certain scripts are written from right to
left. In some documents, in particular those written with the
Arabic or Hebrew script, and in some mixed-language contexts,
text in a single line may appear with mixed directionality.
This phenomenon is called bidirectionality, or "bidi" for
short.

The Unicode standard ([UNICODE],
specifically [UAX9]) defines a
complex algorithm for determining the proper directionality of
text. The algorithm consists of an implicit part based on
character properties, as well as explicit controls for
embeddings and overrides. The
SVG user agent
applies this bidirectional algorithm when determining the layout of characters within a
text content block element.

The 'direction'
and
'unicode-bidi'
properties allow authors to override the inherent directionality
of the content characters and thus explicitly control how the
elements and attributes of a document language map to this algorithm. These
two properties are applicable to all characters whose glyphs are
perpendicular to the inline-progression-direction.

In many cases, the bidirectional algorithm from Unicode
[UNICODE] produces the desired
result automatically, and in such cases the author does not need
to use these properties. For other cases, such as when using
right-to-left languages, it may be sufficient to add the
'direction'
property to the
rootmost 'svg' element,
and allow that direction to inherit to all text elements,
as in the following example (which may be used as a template):

A more complete discussion of bidirectionality can be found
in the Text direction
section of CSS 2 ([CSS2], section 9.10).

The processing model for bidirectional text is as follows.
The user agent processes the characters which are provided in
logical order (i.e., the order
the characters appear in the original document). The user agent
determines the set of independent blocks within each of which
it should apply the Unicode bidirectional algorithm. Each text chunk represents an
independent block of text. After
processing the Unicode bidirectional algorithm and properties
'direction' and 'unicode-bidi' on each of the
independent text blocks, the user agent will have a potentially
re-ordered list of characters which are now in left-to-right
rendering order. While kerning or ligature
processing might be font-specific, the preferred model is that
kerning and ligature processing occurs between combinations of
characters or glyphs after the characters have been
re-ordered.

10.6.3 The 'direction' property

This property specifies the base writing direction of text
and the direction of embeddings and overrides (see
'unicode-bidi')
for the Unicode bidirectional algorithm. For the
'direction'
property to have any effect on an element that does not by itself establish a new
text chunk
(such as the
'tspan'
element in SVG 1.2 Tiny), the
'unicode-bidi'
property's value must be
embed or
bidi-override.

Note: though this property can be declared on any element for purposes of inheritance,
it only affects text content. It does not effect the coordinate system or the
positioning of shapes.

10.7 Text rendering order

The glyphs associated with the characters within
text content block elements
are rendered in the logical order of the characters in the
original document, independent of any re-ordering necessary for
visual display (e.g to implement bidirectionality). Thus, for text
that goes right-to-left visually, the glyphs associated with the
rightmost character are rendered before the glyphs associated with
the other characters, as they come earlier in logical order.

Additionally, each distinct glyph is rendered in its
entirety (i.e., it is filled and stroked as specified by the 'fill' and 'stroke' properties) before the
next glyph gets rendered.

10.8 Alignment properties

10.8.1 Text alignment properties

The
'text-anchor'
property is used to align a string of
text relative to a given point, along a given axis. This axis of
alignment varies by writing mode; for horizontal writing mode (the
norm for Latin or Arabic) the axis is horizontal, while for vertical
writing mode (often used for Japanese) the axis is vertical.
(Note: SVG Tiny 1.2 does not include
support for vertical text.) The point of orientation
depends upon the
'text-anchor'
property value.

The 'text-anchor' property is
applied to each individual text
chunk within a given 'text' element. Each text chunk
has an initial current text position, which represents the
point in the
user coordinate system
resulting from (depending on context) application of the
'x'
and 'y'
attributes on the
'text'
element assigned explicitly to the first rendered character in a
text chunk.

Values have the following meanings (where right,
left, top, and bottom refer to alignment
in an untransformed coordinate space):

start

The rendered characters are aligned such that the start
of the resulting rendered text is at the initial current text position.
For an element with a
'direction'
property value of "ltr"
(typical for most European languages),
the left side of the text is rendered at the initial text
position. For an element with a
'direction'
property value of "rtl"
(typical for Arabic and Hebrew),
the right side of the text is rendered at the initial text
position. For an element with a vertical primary text
direction (often typical for Asian text),
the top side of the text is rendered at the initial text position.
(Note: SVG Tiny 1.2 does not include
support for vertical text.)

middle

The rendered characters are aligned such that the geometric middle
of the resulting rendered text is at the initial current text position.

end

The rendered characters are aligned such that the end of
the resulting rendered text is at the initial current text position.
For an element with a
'direction'
property value of "ltr"
(typical for most European languages),
the right side of the text is rendered at the initial text
position. For an element with a
'direction'
property value of "rtl"
(typical for Arabic and Hebrew),
the left side of the text is rendered at the initial text
position. For an element with a vertical primary text
direction (often typical for Asian text),
the bottom of the text is rendered at the initial text position.
(Note: SVG Tiny 1.2 does not include
support for vertical text.)

10.9 Font selection properties

SVG uses the following font specification properties. Except
for any additional information provided in this specification,
the normative definition of the property
is in XSL 1.1 ([XSL], section 7.9).

This property indicates which font family is to be used to
render the text, specified as a prioritized list of font family
names and/or generic family names. Except for any additional
information provided in this specification, the normative
definition of the property is in XSL 1.1 ([XSL], section 7.9.2).

This property specifies whether the text is to be rendered
using a normal, italic or oblique face. The font-style value "backslant" defined in XSL 1.1 is not supported. Except for any
additional information provided in this specification, the
normative definition of the property is in XSL 1.1
([XSL], section 7.9.7).

This property indicates whether the text is to be rendered
using the normal glyphs for lowercase characters or using
small-caps glyphs for lowercase characters. Except for any
additional information provided in this specification, the
normative definition of the property is in XSL 1.1
([XSL], section 7.9.8).

one of the legal numeric values, non-numeric values shall be converted to numeric values according to the rules defined below.

This property refers to the boldness or lightness of the
glyphs used to render the text, relative to other fonts in the
same font family. Except for any additional information
provided in this specification, the
normative definition of the property is in XSL 1.1
([XSL], section 7.9.9).

Non-numeric values are interpreted as follows:

normal

Same as "400".

bold

Same as "700".

bolder

Specifies the next weight that is assigned to a font that
is darker than the inherited one. If there is no such weight, it
simply results in the next darker numerical value (and the font
remains unchanged), unless the inherited value was "900", in which case
the resulting weight is also "900".

lighter

Specifies the next weight that is assigned to a font that
is lighter than the inherited one. If there is no such weight, it
simply results in the next lighter numerical value (and the font
remains unchanged), unless the inherited value was "100", in which case
the resulting weight is also "100".

This property refers to the size of the font from baseline
to baseline when multiple lines of text are set solid in a
multiline layout environment. The SVG user agent processes
the <length> as a height
value in the current user coordinate system. Percentage values are not supported.

The initial value for
'xml:space'. When xml:space="default", the SVG user agent will do the following using a copy of the original
character data content. First, it will remove all newline
characters. Then it will convert all tab characters into
space characters. Then, it will strip off all leading and
trailing space characters. Then, all contiguous space
characters will be consolidated.

preserve

When xml:space="preserve", the SVG user agent will do
the following using a copy of the original character data
content. It will convert all newline and tab characters into
space characters. Then, it will draw all space characters,
including leading, trailing and multiple contiguous space
characters. Thus, when drawn with
xml:space="preserve", the string
"a b" (three spaces between "a"
and "b") will produce a larger separation between "a" and "b"
than "a b" (one space between "a" and
"b").

The following example illustrates that line indentation can
be important when using xml:space="default". The
fragment below show two pairs of similar 'text' elements, with both 'text' elements using xml:space='default'. For these
examples, there is no extra white space at the end of any of
the lines (i.e., the line break occurs immediately after the
last visible character).

The first pair of 'text'
elements above show the effect of indented character data. The
attribute xml:space='default'
in the first 'text' element
instructs the SVG user agent to:

convert all tabs (if any) to space characters,

strip out all line breaks (i.e., strip out the line
breaks at the end of lines [01], [02] and [03]),

strip out all leading space characters (i.e., strip out
space characters before "WS example" on line [02]),

strip out all trailing space characters (i.e., strip out
space characters before "</text>" on line [04]),

consolidate all intermediate space characters (i.e., the
space characters before "indented lines" on line [03]) into a
single space character.

The second pair of 'text'
elements above show the effect of non-indented character data.
The attribute xml:space='default' in the third
'text' element instructs the
SVG user agent to:

convert all tabs (if any) to space characters,

strip out all line breaks (i.e., strip out the line
breaks at the end of lines [07], [08] and [09]),

strip out all leading space characters (there are no
leading space characters in this example),

strip out all trailing space characters (i.e., strip out
space characters before "</text>" on line [10]),

consolidate all intermediate space characters into a
single space character (in this example, there are no
intermediate space characters).

Note that XML parsers are required to convert the standard
representations for a newline indicator (e.g., the literal
two-character sequence "#xD#xA" or the stand-alone literals #xD
or #xA) into the single character #xA before passing character
data to the application. See XML
end-of-line handling ([XML11], section 2.11).

Any features in the SVG language or the SVG DOM that are
based on character position number are based
on character position after applying the white space handling
rules described here. In particular, if
xml:space="default", it is often the case that
white space characters are removed as part of processing.
Character position numbers index into the text string after the
white space characters have been removed per the rules in this
section.

10.11 Text in an area

10.11.1 Introduction to text in an area

The 'textArea' element allows simplistic wrapping of text content within a given region. This profile of SVG specifies a single rectangular region.
Other profiles may allow a sequence of arbitrary shapes.

Text wrapping via the 'textArea' element is
available as a lightweight and convenient facility for simple text wrapping
where a complete box model layout engine is not required.

The layout of wrapped text is user agent dependent; thus, content
developers need to be aware that there might be different results,
particularly with regard to where line breaks occur.

If both 'width' and 'height' have the value 'auto', the text will be rendered in a single line along the direction of the text progression until all the text is rendered,
or until a line-breaking element such as 'tbreak' is encountered, in which case the remaining text is rendered on a new line.

10.11.3 The 'tbreak' element

The 'tbreak' element is an empty element that forcibly breaks the current
line of text, even if the current line of text is empty (i.e. multiple consecutive
'tbreak' elements each cause a line break.)

The 'tbreak'
element has no attributes aside from the standard core and conditional
attributes.

10.11.4 The 'line-increment' property

The 'line-increment' property provides limited control over the size of each line in the block-progression-direction. This property applies to the 'textArea' element, and to child elements of the 'textArea' element. The 'line-increment' property must not have any effect when used on an element which is not, or does not have as an ancestor, a 'textArea' element.

Subsequent lines are offset from the
previous line by the maximum font-size for any glyphs drawn
within that line, multiplied by some reasonable value for default line spacing. This
specification recommends a value of 1.1 for this multiplier.

<number>

Subsequent lines are offset from the previous line by this amount (in
user units). Negative values are unsupported.

10.11.5 The 'text-align' property

Alignment in the inline progression direction in flowing text is provided by the text-align property. It is a modified version of the XSL 1.1 text-align property ([XSL], section 7.16.9).

For details refer to the XSL 1.1 text-align property ([XSL], section 7.16.9).
Note that SVG does not require user agents to support the following values for this property: justify, inside, outside, <string>, left, or right. The lacuna value is start.

As with the
'text-anchor'
property, the values start and
end are dependent on the
value of the
'direction'
property (typically, as appropriate for the writing
system being used).

For left to right horizontal (French, Russian, Thai, etc.):
start is left and end is right

For right to left horizontal (Hebrew, Arabic, etc.):
start is right and end is left

For top to bottom vertical (vertical Chinese, etc.):
start is top and end is bottom
(Note: SVG Tiny 1.2 does not include support for vertical text.)

10.11.6 The 'display-align' property

The 'display-align' property specifies the alignment, in the
block-progression-direction, of the text content of the
'textArea' element.

The following sentence is informative: For a better understanding of the 'display-align' property this diagram from the XSL specification (the final diagram in [XSL], section 4.2.3) illustrates the correspondence between the various edge names for a mixed writing-mode example (western and japanese writing-mode).

10.11.7 Text in an area layout rules

Text in an area layout is defined as a post processing step to
the standard text layout model of SVG.

A conformant SVG user agent can implement a simplistic layout algorithm which
consists simply of inserting line breaks whenever the content explicitly
specifies a line break with a 'tbreak'
element or when the current line cannot fit all of the remaining glyphs.
Any lines of glyphs that do not completely fit within the region(s) are not
rendered.

SVG user agents should implement a line-breaking algorithm that supports at a
minimum the features described below as a post processing step to SVG's
standard text layout model.

Text layout is performed as normal, on one infinitely long line; soft
hyphens are included in the line. The result is a set of positioned Glyphs.

The first line is positioned such that its before edge is flush
against the region's before edge, relative to the block-progression-direction.

Glyphs represent a character or characters within a word. Each glyph
is associated with the word that contains its respective characters. In
cases where characters from multiple words contribute to the same glyph, the
words are merged and all the glyphs are treated as part of the earliest
word in logical order.

The glyphs from a word are collapsed into Glyph Groups. A Glyph Group
is comprised of all consecutive glyphs from the same word. In most cases,
each word generates one glyph group; however, in some cases the interaction
between BIDI and special markup may cause glyphs from one word to have
glyphs from other words embedded in it.

Each Glyph Group has two extents calculated: its normal extent, and
its last in text area extent. Its normal extent is the sum of the
advances of all glyphs in the group except soft hyphens. The normal extent
is the extent used when a Glyph Group from a later word is in the same text
area. The last in text area extent includes the advance of a trailing
soft hyphen, but does not include the advance of trailing white space or
non-spacing combining marks. The last in text region extent is used when
this glyph group is from the last word (in logical order) in this text
area. (If the entire line consists of a single word which is not
breakable, the
SVG user agent
may choose to force a break in the line so that
at least some text will appear for the given line.)

If xml:space="default", any space character that causes a line break in a 'textArea' element will be consumed by the line break and thus not rendered. However, if xml:space="preserve", any space character that causes a line break and subsequent spaces that will not fit on the line shall be included in the next line.

Words are added to the current line in logical order. All the Glyph
Groups from a word must be in the same line, and all the glyphs from a Glyph
Group must be in the same
'textArea'.

If 'line-increment' is a number, then each line will be sized in the
block-progression-direction to the value of 'line-increment'. If
'line-increment' is auto, then the maximum
'font-size' for any glyph in the
line will determine the size of the line in the
block-progression-direction. When a word is added, the line increment may
increase; it can never decrease from the first word. An increase in the
line increment can only reduce the space available for text placement in
the span. The span will have the maximum possible number of words.
The position of the dominant baseline for a given line is determined by
first computing the line-increment value for that line and then choosing a
position for the dominant baseline, using the position where the given
baseline would appear for the font that will be used to render the first
character and an assumed font-size equal to the line-increment value.

The Glyphs from the Glyph Groups are then collapsed into the text
regions by placing the first selected glyph (in display order) at the start
of the text area and each subsequent glyph at the location of the glyph
following the preceding selected glyph (in display order).

The next word is selected, and the next line location is determined.
The next line is positioned such that its before edge is flush against the
after edge of the previous line relative to the
block-progression-direction. Go to step 8.

Any lines which extend outside of the area(s) in the
block-progression-direction are not rendered.

10.12 Editable text fields

SVG Tiny 1.2 allows text elements to be edited. Although simple text editing can be implemented directly in script, implementing an intuitive and well internationalized text input system which works on a variety of platforms is complex.Therefore, this functionality is provided by
the SVG user agent, which has access to system text
libraries. Content authors can build higher level widgets, such as form entry fields, on top of the editable text functionality.

10.12.1 The 'editable' attribute

The text content block elements
have an editable attribute which specifies whether the contents of the elements can be edited in place.

If a clipboard is supported by the platform, the
SVG user agent must also provide a way
to cut or copy the selected text from the element to the clipboard, and to paste text from the clipboard into
the element.

Whenever the
'editable' attribute is set to
'simple', the
'focusable'
attribute is considered to be set to 'true', irrespective of what the actual
value is.

SVG user agents should allow for the editing of
text in-place. However, editing with a modal editing dialog is an alternate possibility, and may be the only option on some platforms. The current editing position should be indicated, for example with a caret. SVG Tiny 1.2 user agents must also
support system functions such as copy/paste and drag/drop if they are available to applications on the platform.

To start editing, the current
presentation value
of the 'editable' attribute must be
'simple', the
text content block element
must have focus, and it must then be activated, e.g. by using an Enter key or clicking on the text region with a
pointer device. When editing text in a text field, all
text
and key events
are dispatched to the
SVG user agent,
which processes the events for proper handling of text entry.

For editing in-place the following functionality must be made available:

movement to the next/previous character (in logical order), for example with
Left/Right arrows

in 'textArea' elements, movement to the next/previous line, for example with the Down/Up keys

movement to the beginning of the line, for example with the Home key

movement to the end of the line, for example with the End key

copy/cut/paste, if a clipboard is supported, for example with Copy and Paste keys

The functionality should use the normal key bindings that are used for those tasks on the given platform.
For devices without keyboard access, the equivalent system input
methods should be used wherever possible to provide the functionality
described above.

When doing editing in-place, the content of the DOM nodes that are being edited should be live at
all times and reflect the current state of the edited string as it is being edited.
When using a modal editing dialog, the content of the DOM nodes will only change once the user commits
the edit (for example, by using an Enter key or clicking an "OK" button, or an alike behavior native to the platform),
firing a single textInput event.

If an Input Method Editor (IME) is used (for example, to input Kanji text, or to input Latin text using number keys on mobile phones), the text events correspond to the actual text entered (eg the Kanji character, or the Latin character) and not to the keyboard or mouse gestures needed to produce it (such as the sequence of kana characters, or the number of sequential presses of a numeric key).

While text is being edited, the SVG user agent should always make the caret visible to the user
as it is moved around the edited text (either due to typing more characters or to moving it
within existing text). The precise behavior in which this functionality is supported depends
on the SVG user agent.

If the text of an editable element is edited, and the element has child
elements, the contents of the edited element must first be stripped of all
non-'tbreak'
elements, preserving the contents of each
non-'tbreak'
element in place.

If the editable element does not have text content, it may not be possible
to activate the editability with a pointer, since there will be no rendered element to click
on. In the case of the 'textArea' element,
which has inherent 'width' and
'height' geometry, setting the
'pointer-events' property value to
boundingBox will allow the user to
initiate the editing (see Example textArea02).
This functionality does not exist for the 'text' element
since it has no inherent geometry without text content.

Example textArea02 below shows how to use the
'pointer-events' property value
boundingBox to create a declarative input box that can be activated with a pointer device.

10.13 Text selection and clipboard operations

If SVG
viewers support text selection and copy/paste operations then they
must support:

user selection of text strings in SVG content

the ability to copy selected text strings to the system
clipboard

A text selection operation starts when all of the following
occur:

the user positions the pointing device or caret over a glyph that has been rendered as part of a
text content block element,
initiates a select operation (e.g., pressing the standard system
mouse button for select operations) and then moves the
current text position while continuing the select
operation (e.g., continuing to press the standard system
mouse button for select operations);

no other visible graphics element has been painted above
the glyph at the point at which the pointing device was
clicked.

As the text selection operation proceeds (e.g., the user
continues to press the given mouse button), all associated
events with other graphics elements are ignored (i.e., the text
selection operation is modal) and the SVG user agent shall
dynamically indicate which characters are selected by an
appropriate highlighting technique, such as redrawing the
selected glyphs with inverse colors. As the current text position is moved
during the text selection process, the end glyph for the text
selection operation is the glyph within the same 'text' element whose glyph cell
is closest to the pointer. All characters within the 'text' element whose position
within the 'text' element is between the
start of selection and end of selection shall be highlighted,
regardless of position on the canvas and regardless of any
graphics elements that might be above the end of selection
point.

Once the text selection operation ends (e.g., the user
releases the given mouse button), the selected text will stay
highlighted until an event occurs which cancels text selection,
such as a pointer device activation event (e.g., pressing a
mouse button).

For systems which have system clipboards, the SVG user agent
should provide a user interface for initiating a copy
of the currently selected text to the system clipboard. It is
sufficient for the SVG user agent to post the selected text
string in the system's appropriate clipboard format for plain
text, but it is preferable if the SVG user agent also posts a
rich text alternative which captures the various font properties
associated with the given text string.

For bidirectional text, the SVG user agent must support text
selection in logical order, which will result in discontinuous
highlighting of glyphs due to the bidirectional reordering of
characters. SVG user agents can also optionally provide an alternative ability to
select bidirectional text in visual rendering order (i.e.,
after bidirectional
text layout algorithms have been applied), with the result that
selected character data might be discontinuous logically. In
this case, if the user requests that bidirectional text be
copied to the clipboard, then the SVG user agent is required to
make appropriate adjustments to copy only the visually selected
characters to the clipboard.

When feasible, it is recommended that generators of SVG
attempt to order their text strings to facilitate properly
ordered text selection within SVG viewing applications such as
Web browsers.

In addition to discrete text selection, the
SVG user agent
should provide facility for the mass selection of entire text passages,
for whatever text is in scope. If a
text content element
has focus, such a select-all operation should include only the contents
of that element. If no
text content element
is in focus, the select-all operation should select all the text in the
document. This may be a progressive operation, widening the scope with
each subsequent operation. For example, a common idiom is to allow a
user to select text with a single click on a word, with first the word
selected, then the entire passage with a second click, then the entire
document with a third click. For purposes of accessibility, the user
agent must allow any such operation to be performed by keyboard as well
as pointer device (such as in the ctrl/command+A "select-all"
keyboard shortcut), and should also expose appropriate accessibility APIs.

10.14 Text search

If the user agent supports searching for text strings, then it must
support searching for text strings in SVG content as well. An
SVG viewer which supports
search must allow the user to find all instances of the searched text
string within the document that are in the
rendering tree
(e.g., those with a 'display'
property other than none), and must
highlight or otherwise indicate each instance. SVG viewers
which allow sequential searches for text strings must pan and zoom the
viewport, as appropriate, in order to show the text string in context,
and are recommended to adjust the viewport as if there had been a
fragment identifier link traversal
to the element containing the text string.

In other words, if the containing
text content element
is too large to be enclosed in the viewport, the
SVG user agent is
recommended to zoom out, but if the text does fit, the
user agent is
recommended only to pan, and not to zoom. In order to enable
maximum usability, authors should create their content accordingly,
breaking text into discrete
text content elements
that fit within the expected viewport at a readable size, while
providing sufficient context. Additionally, users must be provided
a way to zoom in on text
that is too small for the user to read.

Example 'text_search.svg' below
contains a long text string which extends outside of the initial viewport, and which needs to
be adjusted when searching for one of the words outside the viewport. The image shows
the results of a text search using the Batik SVG toolkit.

11.1 Introduction

Graphics elements,
including text content elements
and shapes,
can be filled (which means painting the interior of the object) and
stroked (which means painting along the outline of the object). Filling
and stroking both can be thought of in more general terms as painting
operations.

With SVG, you can paint (i.e., fill or stroke) with:

a single color, possibly with some level of transparency

a gradient (linear or radial)

SVG uses the general notion of a paint server. Apart from system paint,
paint servers are specified using a local IRI reference
on a 'fill'
or 'stroke'
property. Gradients and colors are just specific types of paint servers.

Indicates that painting shall be done using the color specified by the current
animated value of the 'color'
property. This mechanism is provided to facilitate sharing of color attributes
between parent grammars such as other (non-SVG) XML. This mechanism allows you to define
a style in your HTML which sets the 'color'
property and then pass that style to the SVG user agent
so that your SVG text will draw in the same color.

The 'fill' property specifies that the interior of the given graphical element must be painted.
The area to be painted shall consist of any areas inside the outline of the shape. To
determine the inside of the shape, all subpaths must be considered, and the interior shall
be determined according to the rules associated with the current value of the 'fill-rule' property. The zero-width geometric outline of a shape must be included in the area to
be painted.

Open subpaths must be filled by performing the fill operation as if an additional
"closepath" command were added to the path to connect the last point of the subpath with
the first point of the subpath. Thus, fill operations apply to both open subpaths within 'path' elements (i.e., subpaths without a closepath command) and 'polyline' elements.

The 'fill-rule' property indicates the algorithm which must be used to determine what parts of the canvas are included inside the shape. For a simple, non-intersecting path, it is intuitively
clear what region lies "inside"; however, for a more complex path, such as a path that
intersects itself or where one subpath encloses another, the interpretation of "inside" is
not so obvious.

The 'fill-rule' property provides two options for how the
inside of a shape is determined:

nonzero

The following algorithm, or any other that gives the same result, must be used to
determine the "insideness" of a point on the canvas. Draw a ray from the point to infinity in any direction and then examine the places
where a segment of the shape crosses the ray. Starting with a count of zero, add one
each time a path segment crosses the ray from left to right and subtract one each time a
path segment crosses the ray from right to left. After counting the crossings, if the
result is zero then the point is outside the path. Otherwise, it is
inside. The following drawing illustrates the nonzero rule:

The following algorithm, or any other that gives the same result, must be used to
determine the "insideness" of a point on the canvas. Draw a ray from the point to infinity in any direction and counting the number of
path segments from the given shape that the ray crosses. If this number is odd, the
point is inside; if even, the point is outside. The following drawing illustrates the
evenodd rule:

(Note: the above explanations do not specify what to do if a path segment coincides with
or is tangent to the ray. Since any ray will do, one may simply choose a different ray that
does not have such problem intersections.)

11.4 Stroke properties

The following are the properties which affect how an element is stroked.

In all cases, strokes which are affected by directionality, such as those having dash
patterns, must be rendered such that the stroke operation starts at the same point at which
the graphics element starts. In particular, for 'path' elements, the start of the path is the first point of the initial "moveto" command.

For strokes, such as dash patterns whose computations are dependent on progress along the
outline of the graphics element, distance calculations must use the SVG user agent's standard distance along a path algorithms.

When stroking is performed using a complex paint server, such as a gradient, the stroke
operation must be identical to the result that would have occurred if the geometric shape
defined by the geometry of the current graphics element and its associated stroking properties were converted to an equivalent 'path' element and then filled using the given paint server.

A subpath (see Paths) consisting of a single moveto shall not be stroked. A subpath
consisting of a moveto and lineto to the same exact location or a
subpath consisting of a moveto and a closepath shall not be stroked if the 'stroke-linecap' property has a value of butt and shall be stroked if
the 'stroke-linecap' property has a value of round or square, producing respectively a circle or a square centered
at the given point.

The width of the stroke which shall be used on the current object. No stroke
shall be painted for a zero value. A negative value is unsupported and must be treated
as if the stroke had not been specified.

When two line segments meet at a sharp angle and miter
joins have been specified for 'stroke-linejoin', it is possible for the miter to extend far beyond the thickness of the line stroking
the path. The 'stroke-miterlimit' imposes a limit on the ratio of the miter length to the 'stroke-width'. When the limit is exceeded, the join must be converted from a miter to a bevel.

<miterlimit>

The limit on the ratio of the miter length to the 'stroke-width'. The value of <miterlimit> must be a
number greater than or equal to 1. Any other value shall be treated as unsupported and
processed as if the property had not been specified.

The ratio of miter length (distance between the outer tip and the inner corner of the
miter) to 'stroke-width' is directly related to the angle (theta) between the segments in user space by the
formula:

miterLimit = miterLength / stroke-width = 1 / sin(theta / 2)

For example, a miter limit of 1.414 converts miters to bevels for theta less than 90
degrees, a limit of 4.0 converts them for theta less than approximately 29 degrees, and a
limit of 10.0 converts them for theta less than approximately 11.5 degrees.

'stroke-dasharray' specifies the pattern of dashes and gaps that shall be used to stroke paths. The <list-of-lengths>
contains the list of <length>s
that specify the lengths of alternating dashes and gaps that must be used. If an odd number
of values is provided, then the list of values shall be repeated to yield an even number of
values. Thus, stroke-dasharray="5,3,2" is equivalent to
stroke-dasharray="5,3,2,5,3,2". The computed value of the attribute 'stroke-linecap' is applied to both
sides of each dash. If a dash has zero length, linecaps are still added
if the stroke-linecap values round and square are used.

none

Indicates that no dashing shall be used. If stroked, the line must be drawn solid.

<list-of-lengths>

The list of <length>s that specify the lengths of alternating dashes and gaps that must be used.
A negative <length> value shall be treated as
unsupported and processed as if the property had not been specified. If the sum of the
<length>s is zero, then the
stroke shall be rendered as if a value of none were
specified.

Note:
Certain cases regarding the behavior of 'stroke-dasharray' are not fully
specified because SVG Tiny implementations often rely on underlying
graphics libraries with predetermined behaviors they cannot easily
change. Examples include: rendering of 'stroke-linejoin' and 'stroke-linecap' in
case a dash ends exactly at a corner of two path segments, continuation
of stroke-dasharray in subpaths, and others. These cases may be fully
specified in version SVG 1.2 Full. Additional attributes, such as
dash-caps that can be defined separately from linecaps may be added.
Authors are encouraged not to rely on a specific behavior of a specific
viewer for 'stroke-dasharray' regarding these currently unspecified cases.

'stroke-dashoffset' specifies the distance into the dash
pattern that must be used to start the dash. When rendering a 'path' element with multiple subpaths, the value of
'stroke-dashoffset' should start from scratch with the original value of
'stroke-dashoffset' for each subpath. SVG 1.2 Full may be stricter
and also add an additional attribute to change this behavior.

11.5 Non-scaling stroke

Sometimes it is of interest to let the outline of an object keep its original width no
matter which transforms are applied to it. For example, in a map with a 2px wide line representing
roads it is of interest to keep the roads 2px wide even when the user zooms into the
map. To achieve this, SVG Tiny 1.2 introduces the 'vector-effect'
property. Future versions of the SVG language will allow for more powerful vector
effects through this property but this version restricts it to being able to
specify the non-scaling stroke behavior.

Specifies that no vector effect shall be applied, i.e. the default rendering behaviour
from SVG 1.1 is used which is to first fill the geometry of a shape with a specified
paint, then stroke the outline with a specified paint.

non-scaling-stroke

Modifies the way an object is stroked. Normally stroking involves calculating stroke
outline of the shape's path in current user space and filling that outline with the
stroke paint (color or gradient). With the non-scaling-stroke vector effect, stroke outline
shall be calculated in the "host" coordinate space instead of user coordinate space.
More precisely: a user agent establishes a host coordinate space which in SVG Tiny 1.2 is
always the same as "screen coordinate space". The stroke outline is calculated in the
following manner: first, the shape's path is transformed into the host coordinate space.
Stroke outline is calculated in the host coordinate space. The resulting outline is
transformed back to the user coordinate system.
(Stroke outline is always filled with stroke paint in the current user space). The resulting visual effect of this
modification is that stroke width is not dependant on the transformations of the element
(including non-uniform scaling and shear transformations) and zoom level.

Note: Future versions of SVG may allow ways to control the host coordinate system.

11.6 Simple alpha compositing

Graphics elements are blended into the elements already rendered on the canvas using simple alpha compositing, in which the resulting color and opacity at any given
pixel on the canvas must be the result of the following formulas (all color values use premultiplied
alpha):

11.6.1 Compositing the currentColor value

The currentColor value may be assigned a color value that
has an opacity component. This opacity value is used in the rendering operation using the
alpha compositing method described above. That is, the opacity value in currentColor is used when compositing the color into a paint
server (which may have its own values for opacity).

11.7 The 'viewport-fill' property

SVG enables the author to specify a solid color which will be used to fill the viewport of any element that creates a viewport, such as the 'svg' element.

The 'viewport-fill' property specifies the color which shall be used to fill the viewport created by a particular element. It must cause the entire canvas of the element that it applies to to be filled with the specified solid color. That canvas may then be clipped by that element's 'viewBox'.

<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
viewBox="0 0 300 100" viewport-fill="yellow">
<desc>
The viewport has a yellow background.
The rectangle is filled and covers the viewport, so the yellow
background will only show through in the "leftovers" if the
aspect ratio of the viewport differs from that of the viewBox.
</desc>
<rect x="0" y="0" width="300" height="100" fill="red" fill-opacity="0.3" stroke="black"/>
</svg>

The filling of the viewport is the first operation in the rendering chain of an element. Therefore:

The viewport fill operation happens before filling and stroking.

The viewport fill operation occurs before compositing, and thus is part of the input
to the compositing operations.

A value of display="none" indicates that the given element
and its children shall not be rendered directly or made audible (i.e., those elements are not present in
the rendering tree). Any computed value other than none indicates that
the given element shall be rendered or made audible by the SVG user agent.

The 'display' property only affects the direct rendering or audibility of
a given element, whereas it does not prevent elements from being referenced by other
elements.

Elements with display="none" do not take up space in text
layout operations, do not receive events and do not contribute to bounding box calculations.

11.10 Rendering hints

11.10.1 The 'color-rendering' property

The creator of SVG content might want to provide a hint to the implementation about how to
make speed versus quality tradeoffs as it performs color interpolation and compositing. The 'color-rendering' property provides a hint to the SVG user agent about how to optimize its color
interpolation and compositing operations.

11.10.2 The 'shape-rendering' property

The creator of SVG content might want to provide a hint to the implementation about what
tradeoffs to make as it renders vector graphics elements such as 'path' elements and basic shapes such as circles and rectangles. The 'shape-rendering' property provides these hints.

Indicates that the user agent shall make appropriate tradeoffs to balance speed, crisp
edges and geometric precision, but with geometric precision given more importance than
speed and crisp edges.

optimizeSpeed

Indicates that the user agent shall emphasize rendering speed over geometric precision
and crisp edges. This option will sometimes cause the user agent to turn off shape
anti-aliasing.

crispEdges

Indicates that the user agent shall attempt to emphasize the contrast between clean
edges of artwork over rendering speed and geometric precision. To achieve crisp edges,
the user agent might turn off anti-aliasing for all lines and curves or possibly just
for straight lines which are close to vertical or horizontal. Also, the user agent might
adjust line positions and line widths to align edges with device pixels.

Indicates that the user agent shall make appropriate tradeoffs to balance speed,
legibility and geometric precision, but with legibility given more importance than speed
and geometric precision.

optimizeSpeed

Indicates that the user agent shall emphasize rendering speed over legibility and
geometric precision. This option will sometimes cause the user agent to turn off text
anti-aliasing.

optimizeLegibility

Indicates that the user agent shall emphasize legibility over rendering speed and
geometric precision. The user agent will often choose whether to apply anti-aliasing
techniques, built-in font hinting or both to produce the most legible text.

geometricPrecision

Indicates that the user agent shall emphasize geometric precision over legibility and
rendering speed. This option will usually cause the user agent to suspend the use of
hinting so that glyph outlines are drawn with comparable geometric precision to the
rendering of path data.

11.10.4 The 'image-rendering' property

The creator of SVG content might want to provide a hint to the implementation about how to
make speed vs. quality tradeoffs as it performs image processing. The 'image-rendering' property provides a hint to the SVG user agent about how to optimize its image
rendering.

Indicates that the user agent shall make appropriate tradeoffs to balance speed and
quality, but quality shall be given more importance than speed. The user agent shall
employ a resampling algorithm at least as good as nearest neighbor resampling, but
bilinear resampling is strongly preferred. For Conforming High-Quality SVG
Viewers, the user agent shall employ a resampling algorithm at least as good as
bilinear resampling.

optimizeQuality

Indicates that the user agent shall emphasize quality over rendering speed. The user
agent shall employ a resampling algorithm at least as good as bilinear resampling.

optimizeSpeed

Indicates that the user agent shall emphasize rendering speed over quality. The user
agent should use a resampling algorithm which achieves the goal of fast rendering, with
the requirement that the resampling algorithm shall be at least as good as nearest
neighbor resampling. If performance goals can be achieved with higher quality
algorithms, then the user agent should use the higher quality algorithms instead of
nearest neighbor resampling.

In all cases, resampling must be done in a truecolor (e.g., 24-bit) color space even if
the original data and/or the target device is indexed color.

11.10.5 The 'buffered-rendering' property

The creator of SVG content might want to provide a hint to the implementation about how often an element is modified to
make speed vs. memory tradeoffs as it performs rendering. The 'buffered-rendering' property provides a hint to the SVG user agent about how to buffer the rendering of elements:

Indicates that the user agent is expected to use a reasonable compromise between speed of update and resource allocation.

dynamic

Indicates that the element is expected to be modified often.

static

Indicates that the element is not expected to be modified often.
This suggests that user agent may be able to allocate resources, such as an offscreen buffer, that would allow increased performance in redraw.
It does not mean that the element will never change. If an element is modified when the value is 'static',
then redraw might have reduced performance.

11.11 Inheritance of painting properties

The values of any of the painting properties described in this chapter can be inherited
from a given object's parent. Painting, however, is always done on each graphics element individually, never at the container element (e.g., a 'g') level. Thus, for the following SVG, even though the gradient fill is specified on the
'g', the gradient is simply inherited through the 'g' element down into each rectangle, each of which is rendered such that its interior is
painted with the gradient.

11.12 Object and group opacity: the 'opacity'
property

Except for object/group opacity (described just below), all other opacity properties are
involved in intermediate rendering operations. Object/group opacity can be thought of
conceptually as a postprocessing operation. Conceptually, after the object/group is
rendered into an RGBA offscreen image, the object/group opacity setting specifies how to
blend the offscreen image into the current background.

Object/group opacity can, if applied to container elements, be a resource intensive operation. Therefore this version of SVG restricts this
property to only be set on, and only apply to, the 'image' element. Note: if the value is set to inherit, then the initial value
of 1 for the opacity property will be used, meaning full opacity. This is the same as not specifying it at all.

11.13 Color

In SVG Tiny 1.2, all colors are specified in the sRGB color space [SRGB]. SVG Tiny 1.2 user agents are not required to, but
may, support color management. However, SVG Tiny 1.2 user agents should apply gamma
correction if the response curve of the display system differs from that of sRGB.

11.13.1 Syntax for color values

Five syntactical forms are specified for SVG Tiny 1.2, and all of them must be supported in a
conforming SVG Interpreter:

Three digit hex — #rgb

Each hexadecimal digit, in the range 0 to F, represents one sRGB color component in the
order red, green and blue. The digits A to F may be in either uppercase or lowercase.
The value of the color component is obtained by replicating digits, so 0 become 00, 1
becomes 11, F becomes FF. This compact syntactical form can represent only 4096 colors.
Examples: #000 (i.e. black) #fff (i.e. white) #6CF (i.e. #66CCFF, rgb(102, 204, 255)).

Six digit hex — #rrggbb

Each pair of hexadecimal digits, in the range 0 to F, represents one sRGB color
component in the order red, green and blue. The digits A to F may be in either uppercase
or lowercase.This syntactical form, originally introduced by HTML, can represent
16777216 colors. Examples: #9400D3 (i.e. a dark violet), #FFD700 (i.e. a golden color).

Integer functional — rgb(rrr, ggg, bbb)

Each integer represents one sRGB color component in the order red, green and blue,
separated by a comma and optionally by white space. Each integer is in the range 0 to
255. This syntactical form can represent 16777216 colors. Examples: rgb(233, 150, 122)
(i.e. a salmon pink), rgb(255, 165, 0) (i.e. an orange).

Float functional — rgb(R%, G%, B%)

Each percentage value represents one sRGB color component in the order red, green and
blue, separated by a comma and optionally by white space. For colors inside the sRGB
gamut, the range of each component is 0.0% to 100.0% and an arbitrary number of decimal
places may be supplied. Scientific notation is not supported. This syntactical form can
represent an arbitrary range of colors, completely covering the sRGB gamut. Color values
where one or more components are below 0.0% or above 100.0% represent colors outside the
sRGB gamut Examples: rgb(12.375%, 34.286%, 28.97%).

Color keyword

The sixteen color keywords below (originally from HTML 4 [HTML4])
must be supported, with the further restriction that they must be
lowercase.

11.13.2 HTML color keywords

black

rgb(0, 0, 0)

green

rgb(0, 128, 0)

silver

rgb(192, 192, 192)

lime

rgb(0, 255, 0)

gray

rgb(128, 128, 128)

olive

rgb(128, 128, 0)

white

rgb(255, 255, 255)

yellow

rgb(255, 255, 0)

maroon

rgb(128, 0, 0)

navy

rgb(0, 0, 128)

red

rgb(255, 0, 0)

blue

rgb(0, 0, 255)

purple

rgb(128, 0, 128)

teal

rgb(0, 128, 128)

fuchsia

rgb(255, 0, 255)

aqua

rgb(0, 255, 255)

11.14 Paint servers

With SVG, you can fill (i.e., paint the interior of) or stroke (i.e., paint the outline of) shapes and text using one of the following:

11.14.1 System paint servers

The following list of system paint servers must be supported. If a paint specification specifies one of the system
paint servers, then the user agent must either paint using a system-provided paint server
or paint with a substitute paint server, such as a color or gradient. System paint servers
often depend on the operating system, user choices, and the implementation. Substitute
paint servers should attempt to match the appearance of corresponding user interface
elements on the platform, including user color choices. In environments which do not
provide adequate system paint server APIs, a conformant user agent may use substitute paint
servers which do not necessarily match the environment's system paint servers.

The computed value of a paint specified as a system paint is the specified value.

The 'solid-color' property specifies the color that shall be used for this 'solidColor' element. The keyword currentColor can be specified in
the same manner as within a <paint>
specification for the 'fill' and 'stroke' properties.

11.14.3 The 'color' property

The 'color' property, which is defined in CSS2 as the color of text, does not directly apply to SVG
elements. The value of the SVG color property may however be used to provide an indirect
value for those properties which allow the currentColor
keyword: the 'fill', 'stroke', 'solid-color' and 'stop-color' properties.

11.15 Gradients

Gradients consist of continuously smooth color transitions along a vector from one color to
another, possibly followed by additional transitions along the same vector to other colors.
SVG provides for two types of gradients, 'linearGradient' and 'radialGradient'.

Once defined, gradients are then referenced using 'fill' or 'stroke' properties on a given graphics element to indicate that the given element shall be filled or stroked with the referenced
gradient.

Defines the coordinate system for attributes 'x1', 'y1', 'x2', 'y2' that shall be used when rendering the gradient.

If gradientUnits="userSpaceOnUse", 'x1', 'y1', 'x2', 'y2' shall represent values in the coordinate system that results from taking the
current user coordinate system in place at the time when the gradient element is
referenced (i.e., the user coordinate system for the element referencing the gradient
element via a 'fill' or 'stroke' property).

When gradientUnits="objectBoundingBox" the stripes of the linear gradient shall be
perpendicular to the gradient vector in object bounding box space (i.e., the abstract
coordinate system where (0,0) is at the top/left of the object bounding box and (1,0)
is at the top/right of the object bounding box). When the object's bounding box is
not square, the stripes that are conceptually perpendicular to the gradient vector
within object bounding box space shall render non-perpendicular relative to the
gradient vector in user space due to application of the non-uniform scaling
transformation from bounding box space to user space.

Defines the coordinate system for attributes 'cx', 'cy', 'r' that shall be used when rendering the gradient.

If gradientUnits="userSpaceOnUse", 'cx', 'cy', 'r' shall represent values in the coordinate system that results from taking the
current user coordinate system in place at the time when the gradient element is
referenced (i.e., the user coordinate system for the element referencing the gradient
element via a 'fill' or 'stroke' property).

When gradientUnits="objectBoundingBox" the rings of the radial gradient shall be
circular with respect to the object bounding box space (i.e., the abstract coordinate
system where (0,0) is at the top/left of the object bounding box and (1,1) is at the
bottom/right of the object bounding box). When the object's bounding box is not
square, the rings that are conceptually circular within object bounding box space
shall render as elliptical due to application of the non-uniform scaling
transformation from bounding box space to user space.

The 'offset' attribute is a <number>
which indicates where the gradient stop shall be
placed. For linear gradients, the 'offset' attribute represents a location along the gradient vector. For radial
gradients, it represents a relative distance from ('cx', 'cy') to the edge of the outermost/largest circle.

The 'stop-color' property specifies the color that shall be used at the gradient stop. The keyword
currentColor can be specified in the same manner as
within a <paint> specification for the 'fill' and 'stroke' properties.

It is necessary that at least two 'stop' elements are specified to have a gradient effect. If no 'stop' elements are specified, then painting shall occur as if none were specified as the paint style. If one 'stop' is specified, then painting shall occur with the solid color fill using the color
defined for that gradient stop.

Each gradient offset value is required to be equal to or greater than the previous
gradient stop's offset value. If a given gradient stop's offset value is not equal to or
greater than all previous offset values, then the offset value must be adjusted to be
equal to the largest of all previous offset values.

If two gradient stops have the same offset value, then the latter gradient stop shall
control the color value at the overlap point. In particular:

12.1.1 Media timeline and document timeline

Media elements start playing when they become active, i.e. at a time specified in the document timeline which depends on their 'begin' attribute (see SVG timing attributes). However, depending on the value of the 'timelineBegin' attribute on the rootmost 'svg' element, the actual beginning of the document timeline may be delayed until the whole document is loaded. This is the case when 'timelineBegin' is set to 'onLoad'. In that case, the beginning of the actual playback of the media will be delayed, but the media begin time in the document timeline will remain as specified.

Note: 'image' elements are not considered as media elements because they are not timed. They start playing at time 0 in the document timeline.

In this example, the document timeline will start after the document is fully processed, i.e. at time t0+t1+t2 ≥ 6s. The video will start when the document is loaded. But, at that time, the document time will be 0. So, the video will start with the first frame of the video.

In this example, the document timeline will start when the 'svg' element is fully parsed and processed, i.e. at time t0. The video will also start at document time 0, but since the video will only be processed when document time is t0+t1+t2, the video will start displaying the frame at time t0+t1+t2 in the video timeline.

Furthermore, the time in the media timeline which is played, e.g. the exact frame of video or the exact sample of audio that is played, can be altered by the 'syncBehavior' attribute. The following examples illustrate this behavior. These examples are the same as the previous ones, but the values of the 'syncBehavior' attributes are changed from the default value to 'independent'.

In example video-timelineBegin-03.svg, the video does not start until the document's load event, whereas in example video-timelineBegin-04.svg, the video begins as soon as the video element is parsed and the video is ready for rendering. In both cases, since the timeline of the document and of the video are independent, when the video will start, it will start from the first frame, i.e. time 0 in the media timeline.

12.1.2 Media availability

The value of the 'externalResourcesRequired' attribute may also delay the actual time at which a media (even images) will start playing, but it does not affect the time in the document timeline. Indeed, media elements and the image element may require external resources referenced by the 'xlink:href' attribute. If the 'externalResourcesRequired' attribute is set to 'true', on the resource or on a parent in the scene tree, e.g. a 'g' element, then this external resource has to become available before the media can start. If the 'externalResourcesRequired' attribute is set to 'false', the media element or the image element will start playing as soon as it becomes active.

The meaning of "available" depends on the media type, on the protocol used to access the resource as well as on the implementation. For example, if a protocol like HTTP is used, "available" may mean that the whole resource is downloaded. It may also mean that a coarse version of the resource is available, for example in case of progressive PNG (see PNG Pass extraction ([PNG], section 4.5.2)). In that case, it is an implementation choice to decide whether to display the coarse version before the whole resource is downloaded. Another example is when streaming protocols like RTSP/RTP are used. In that case, "available" usually means that enough stream has been buffered before the playback may start. To reduce the amount of time required for a media to become available, authors are encouraged to use the 'prefetch' element to signal that external resources have to be prefetched.

12.1.3 Platform limits

Particular platforms may have restrictions on the number of audio voices or channels that can be mixed, or the number of video streams that may be presented concurrently. Since these vary, the SVG language itself does not impose any such limits on audio or video.

12.1.4 Audio mixing for 'audio' and 'video' elements

If two or more audio streams from 'audio' or 'video' elements are active at the same time, their rendering should be mixed in proportions equal to the computed value of the 'audio-level' property of each audio stream. An audio stream may be active if it is referred to by an active audio element or if it is part of video content that is referred to by an active 'video' element.

12.1.5 Discrete control of audio and video

Authors may wish to independently control both the visual and auditory aspects of the 'video' element. Through a combination of the various properties available, all permutations are possible, as described below:

play both video and audio: this is the default setting, and nothing special needs to be done

play video with no audio: use the 'audio-level' property with a value of 0

12.2 The 'audio' element

The 'audio' element specifies an audio file which is to be rendered to provide synchronized audio. The usual SMIL timing features are used to start and stop the audio at the appropriate times. An 'xlink:href' must be used to link to the audio content. No visual representation shall be produced. However, content authors can if desired create graphical representations of control panels to start, stop, pause, rewind, or adjust the volume of audio content.

When the value of this attribute is animated or otherwise modified,
if the media timeline can be controlled, then the media timeline is
restarted only if the
'syncBehavior'
attribute is set to independent. If
the media timeline cannot be controlled, then the media timeline is
unaffected by such modification.

The audio format. Implementations may choose not to fetch audios of formats that
they do not support. For optimizing download time by requiring a particular content format authors are encouraged to use
'requiredFormats', instead of 'type'.

12.3 The 'video' element

The 'video' element specifies a video file which is to be rendered to provide synchronized video. The usual SMIL timing features are used to start and stop the video at the appropriate times. An 'xlink:href' must be used to link to the video content. It is assumed that the video content may also include an audio stream, since this is the usual way that video content is produced, and thus the audio shall be controlled by the 'video' element's media attributes.

The value of the 'viewBox' attribute to use when evaluating the 'preserveAspectRatio' attribute shall be defined by the referenced content. For content that clearly identifies a 'viewBox' that value shall be used. For most video content the bounds of the video should be used (i.e. the 'video' element has an implicit 'viewBox' of "0 0 video-widthvideo-height"). Where no value is readily available the
'preserveAspectRatio' attribute shall be ignored.

The x-axis coordinate of the rectangular region into which the video is placed. The lacuna value
is '0'.

If the transform behavior of the video is geometric, this coordinate is one corner of the rectangular region. If it is pinned, this coordinate is the pin point of the rectangular region.
See the 'transformBehavior' attribute for the interpretation of this attribute.

The y-axis coordinate of the rectangular region into which the video is placed. The lacuna value
is '0'.

If the transform behavior of the video is geometric, this coordinate is one corner of the rectangular region. If it is pinned, this coordinate is the pin point of the rectangular region.
See the 'transformBehavior' for the interpretation of this attribute.

When the value of this attribute is animated or otherwise modified,
if the media timeline can be controlled, then the media timeline is
restarted only if the
'syncBehavior'
attribute is set to independent. If
the media timeline cannot be controlled, then the media timeline is
unaffected by such modification.

The video format. Implementations may choose not to fetch videos of formats that
they do not support. For optimizing download time by requiring a particular content format authors are encouraged to use
'requiredFormats', instead of 'type'.

The following example illustrates the use of the 'video' element. The video content is partially obscured by other graphics elements. This example shows the 'video' element being rendered into an offscreen buffer and then transformed and composited in the normal way, so that it behaves like any other graphical primitive such as an image or a rectangle. In this manner, the 'video' element may be scaled, rotated, skewed, displayed at various sizes, and animated.

The content creator should be aware that video is a feature that may not be available on all target devices. In order to create interoperable content the content creator should provide a fall-back alternative by using the 'switch' element. The following feature string is defined for checking for video support: http://www.w3.org/Graphics/SVG/feature/1.2/#Video. Video may not be completely supported on a resource limited device. SVG Tiny 1.2 introduces more granular video rendering control to provide reproducible results in all environments. This control is documented in the two following sections.

12.3.1 Restricting the transformation of the 'video' element

Transforming video is an expensive operation that should be used with caution, especially on content targeted for mobile devices. Using transformed video may also lead to non-interoperable content since not all devices will support this feature. To give the content creator control over video transformation, SVG Tiny 1.2 introduces the 'transformBehavior' attribute and a corresponding feature string: http://www.w3.org/Graphics/SVG/feature/1.2/#TransformedVideo. A viewer supporting video transformation must treat the 'video' element like any other element regarding transformations. A viewer not supporting video transformation must treat the video as a point (given by the 'x' and 'y' attributes). The 'width' and 'height' attributes shall be ignored if present and instead the width and height (in device pixels) shall be taken from the media itself. The video must be displayed with its center aligned with the origin of the local coordinate system.

A content creator can use the 'transformBehavior' attribute to explicitly choose the transform behavior on a viewer supporting transformed video. This might be of interest to increase the performance of content targeting restricted devices.

Defines whether a video is transformed/resampled (in essence treated as a geometric rectangle) or pinned/unresampled (i.e., treated as a pin point for a non-geometric blit region).

The attribute can take one of the five following values:

geometric

The media shall be treated as a geometric rectangle in the local coordinate
system, defined by 'x',
'y',
'width' and
'height'
attributes. The media must be resampled to fill the rectangle
and is subject to transformation. This is the lacuna value.

pinned

The video is displayed without rotation.

pinned90

The video is displayed with a fixed rotation equivalent to the effect of transform="rotate(90)".

pinned180

The video is displayed with a fixed rotation equivalent to the effect of transform="rotate(180)".

pinned270

The video is displayed with a fixed rotation equivalent to the effect of transform="rotate(270)".

If one of the four values 'pinned',
'pinned90',
'pinned180' and
'pinned270' is specified,
the media shall be treated as a point, defined by 'x' and
'y' attributes. This
point must be transformed to the nearest actual device pixel. Video at
the native resolution given by the media shall then be painted on a region
whose center is the pin point and whose width and height are
defined by the media. The pixels must be aligned to the device pixel grid
and there shall be no resampling.
The values of the 'width'
and 'height'
attributes in this case shall have no effect on the rendering of the video.

12.3.2 Restricting compositing of the 'video' element

For the same reasons as restricting transformations the content creator might need to restrict the compositing of video with other elements. Not all devices support compositing of the video element with other content. In that case it is necessary to render the video on top of all other svg content. SVG Tiny 1.2 therefore introduces the 'overlay' attribute and a corresponding feature string: http://www.w3.org/Graphics/SVG/feature/1.2/#ComposedVideo. A viewer supporting compositing of video must render the 'video' element according to the SVG painter's model, and thus graphical elements might be rendered on top of the video. A viewer not supporting video compositing must always render the video on top of all other SVG elements.

A content creator can use the 'overlay' attribute to explicitly choose the compositing behavior on a viewer supporting composited video. This may increase the performance of content that is targeted at restricted devices.

Attribute definition:

overlay = "top" | "none"

Defines whether a 'video'
is rendered according to the SVG painter's model or if it must be
positioned on top of all other SVG elements.

The attribute value can be either of the following:

top

The 'video' element must not be composited on to the background as usual. Instead a temporary video canvas must be set aside and drawn last in the whole document's compositing process.

If multiple 'video' elements have overlay="top", the drawing order of those 'video' elements follows the typical SVG rendering order.

12.3.3 Examples

The following example illustrates the use of the http://www.w3.org/Graphics/SVG/feature/1.2/#TransformedVideo feature string. A 'switch' element is wrapped around two groups. The first group will render a scaled and rotated video sequence on a viewer supporting video transformations while the second group will render the untransformed video on viewers that don't support video transformations.

The above images show the rendering of Example media04 in
two SVG user agents: the first one supporting transformed video (on the left) and the
second one not (on the right).

The following example illustrates the use of the http://www.w3.org/Graphics/SVG/feature/1.2/#ComposedVideo feature string. A 'switch' element is wrapped around two groups. The first group must render a video with text composited on top on viewers supporting composed video while the second group must render a video with text placed above the video on viewers that do not support composed video.

The above images show the rendering of Example media05 in
two SVG user agents: the first one supporting composed video (on the left) and the
second one not (on the right).

12.4 The 'animation' element

The 'animation' elements specifies an SVG document providing synchronized animated vector graphics. Like 'video', the 'animation' element is a graphical object with size determined by its
'x',
'y',
'width' and
'height'
attributes. Furthermore, the 'animation' element supports timing and synchronization attributes which allow multiple animations to run with independent timelines
in the same SVG document.
Just like 'video' and
'image', the
'animation' element must not point to document
fragments within SVG files.

The value of the 'viewBox'
attribute to use when evaluating the
'preserveAspectRatio' attribute is defined by the referenced document's
'viewBox' value.
When no value is available the
'preserveAspectRatio'
attribute must be ignored, and only the translation due to the
'x' and
'y'
attributes of the viewport must be used to display the content.

The referenced SVG document represents a separate document which
generates its own parse tree and document object model. Thus, there is
no inheritance of properties into the referenced animation. For details,
see Processing of external references to documents.

The SVG specification does not specify when an animation that is not
being displayed should be loaded. A user agent is not required to load
animation data for an animation that is not displayed (e.g.
display="none"). However, it should be noted that this may cause a delay
when an animation becomes visible for the first time. In the case where
an author wants to suggest that the user agent load animation data
before it is displayed, they should use the 'prefetch' element.

When the value of this attribute is animated or otherwise modified,
if the media timeline can be controlled, then the media timeline is
restarted only if the
'syncBehavior'
attribute is set to independent. If
the media timeline cannot be controlled, then the media timeline is
unaffected by such modification.

This sentence is informative: An element's volume cannot be louder than the
volume of its parent.

The output signal level is calculated using the logarithmic scale described below (where vol is the value of the element volume):

dB change in signal level = 20 * log10(vol)

User agents may limit the actual signal level to some maximum, based on user preferences and hardware limitations.

If the element has an element volume of 0, then the output signal must be inaudible. If the element has an element volume of 1, then the output signal must be at the system volume level. Neither the 'audio-level' property nor the element volume override the system volume setting.

This attribute has the value 'locked', which means that all the timed elements in the subtree share the same timeline. In this case, the main scene timeline, the 'video' and 'animation' timelines are then locked to each other.

Then, the master is given to the video, which means that if the video is stalled in the streaming session, the timeline of the video will be paused and, as a consequence, the timeline of the lyrics and of the main scene will be paused as well.

12.7 The 'initialVisibility' attribute

The 'initialVisibility' attribute applies to visual media elements ('video' and 'animation') and is used to control the visibility of the media object before its first active duration period has started. A visible media element that is visible before activation shall have its first frame displayed. For an 'animation' element this means the referenced file rendered at time 0. For a 'video' element it means the first frame of the video sequence.

Attribute definition:

initialVisibility = "whenStarted" | "always"

Controls the visibility of the media object before its first active duration period has started.

The attribute value can be either of the following:

whenStarted

The lacuna value. Indicates that the media object is not displayed, as though the element had display="none", until its first active duration starts.

always

The media element is visible from the initialization of the parent time container (i.e. time 0 of the parent SVG document).
During this time, and until the active duration starts, the media element is initialized but remains inactive.

Occurs when the pointing device button is clicked over an element. A click is defined as a mousedown and mouseup over the same screen location. The sequence of these events is: mousedown, mouseup, click. If multiple clicks occur at the same screen location, the sequence repeats with the detail attribute incrementing with each repetition.

The event is triggered at the point at which the user agent
finishes loading the element and any dependent resources (such
as images, style sheets, or scripts). In the case the element
references a script, the event will be raised only after an
attempt to interpret the script has been made. Dependent
resources that fail to load will not prevent this event from
firing if the element that referenced them is still in the
document tree unless they are designated as
externalResourcesRequired.
The event is independent of the means by which the element was
added to DOM tree.