1 Introduction
1.1 About SVG
SVG is a language for describing two-dimensional graphics in
XML [XML10]. SVG
allows for three types of graphic objects: vector graphic
shapes (e.g., paths consisting of straight lines and curves),
multimedia (such as raster images and video) and text.
Graphical objects can be grouped, styled,
transformed and composited into previously rendered objects.
SVG drawings can be interactive
and dynamic. Animations can be defined and triggered
either declaratively (i.e., by embedding SVG animation elements
in SVG content) or via scripting.
Sophisticated applications of SVG are possible by use of a
supplemental scripting language which accesses the SVG Micro Document Object Model (uDOM), which
provides complete access to all elements, attributes and
properties. A rich set of event handlers
can be assigned to any SVG graphical
object. Because of its compatibility and leveraging
of other Web standards, features like scripting can be done on XHTML and SVG
elements simultaneously within the same Web page.
SVG is a language for rich graphical content. For
accessibility reasons, if there is an original source document
containing higher-level structure and semantics, it is
recommended that the higher-level information be made available
somehow, either by making the original source document
available, or making an alternative version available in a
format which conveys the higher-level information,
or by using SVG's facilities to include the higher-level
information within the SVG content. For suggested techniques in
achieving greater accessibility, see Accessibility.
It is believed that this specification is in conformance with the Web Architecture [AWWW].
1.2 SVG Tiny 1.2
Industry demand, overwhelming support
in the SVG working group and requests from the SVG developer
community established the need for some form of SVG suited to displaying vector
graphics on small devices. Moreover, the mission
statement of SVG 1.0 specifically addressed small devices as a
target area for vector graphics display. In order to meet these
demands the SVG Working Group created a profile specification
that was suitable for use on mobile devices
as well as on desktops.
The SVG Mobile 1.1
specification addressed that requirement and defined two
profiles to deal with the variety of mobile devices having
different characteristics in terms of CPU speed, memory size, and
color support. The SVG Mobile 1.1 specification defined SVG Tiny
(SVGT) 1.1, suitable for highly restricted mobile devices;
it also defined a second profile, SVG Basic (SVGB) 1.1,
targeted for higher level mobile devices. The major difference between SVG Tiny 1.1 and SVG Basic 1.1 was the absence of scripting and styling in SVG 1.1 Tiny, and thus any requirement to maintain a Document Object Model (DOM). This saved a substantial amount of memory in most implementations.
Experience with SVG Tiny 1.1, which was widely adopted in the industry and shipped as standard on a variety of cellphones, indicated that the profile was a little too restrictive in some areas. Features from SVG 1.1 such as gradients and opacity, were seen to have substantial value for creating attractive content, and were shown to be implementable on cellphones. There was also considerable interest in adding audio and video capabilities, building on the SMIL support in SVG Tiny 1.1.
Advances such as DOM Level 3, which introduces namespace support and value normalization, prompted a second look at the use of programming languages and scripting with SVG Tiny. In conjunction with the Java JSR 226 group [JSR226], a lightweight interface called the microDOM, or uDOM, was developed. This could be, but need not be, implemented on top of DOM Level 3. With this advance, lightweight programatic control of SVG (for example, for games or user interfaces) and use with scripting languages, became feasible on the whole range of platforms from cellphones through to desktops. In consequence, there is only a single Mobile profile for SVG 1.2 - SVG Tiny 1.2
This specification defines the features and syntax for Scalable Vector Graphics
(SVG) Tiny 1.2, the core specification and baseline profile of SVG 1.2. Other SVG specifications will extend this baseline functionality to create supersets (for example, SVG 1.2 Full). The SVG Tiny 1.2 specification adds to SVG Tiny 1.1 features requested by SVG
authors, implementors and users; SVG Tiny 1.2 is a superset of SVG Tiny 1.1.
1.2.1 Modularization
This specification describes a
collection of abstract modules that provide specific units of
functionality. These modules may be combined with each other
and with modules defined in other specifications (such as
XHTML) to create SVG subset and extension document types that
qualify as members of the SVG family of document types. See Conformance for a description of SVG
family documents, and [XHTMLplusMathMLplusSVG]
for a profile that combines XHTML, MathML and SVG.
Each major section of the SVG specification produces a
module named after that section, e.g. "Text Module" or "Structure Module".
1.2.2 Element and Attribute collections
Modules define a named collection of either elements or
attributes. These collections are used as a shorthand when
describing the set of attributes allowed on a particular element (eg. the
"Style" attibute collection) or the
set of elements allowed as children of a particular element (eg. the "Shape" element collection). All
collections have names that begin with an uppercase
character.
When defining a profile, it is assumed that all the element and
attribute collections are defined to be empty. That way, a module
can redefine the collection as it is included in the profile,
adding elements or attributes to make them available within the profile.
Therefore, it is not a mistake to refer to an element or attribute
collection from a module that is not included in the profile, it
simply means that collection is empty.
1.2.3 Profiling the SVG specification
The modularization of SVG 1.2 allows profiles to be
described by listing the SVG modules they allow and possibly a
small number of restrictions or extensions on the elements
provided by those modules.
The "Tiny" profile of SVG 1.2 is the collection of all the
modules listed in this specification.
When applied to conformance, the term "SVG Tiny"
refers to the "Tiny" profile of SVG 1.2 defined by this
specification. If an implementation does not implement the Tiny
profile, it must state either the profile to which it conforms,
or that it implements a subset of SVG Tiny.
1.3 Defining an SVG Tiny 1.2 document
SVG Tiny 1.2 is a backwards compatible upgrade to SVG Tiny 1.1 . A few key differences from SVG Tiny 1.1 should be noted:
-
The value of the version attribute on the root-most svg element
must be "1.2".
-
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, 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 is provided by the SVG Tiny 1.2 RelaxNG
schema.
The namespace for SVG Tiny 1.2 is the same as that of SVG 1.0 and 1.1, http://www.w3.org/2000/svg
Here is an example of an SVG 1.2 file:
<?xml version="1.0"?>
<svg xmlns="http://www.w3.org/2000/svg"
version="1.2" baseProfile="tiny"
viewBox="0 0 30 30">
<desc>Example SVG file</desc>
<rect x="10" y="10" width="10" height="10" fill="red"/>
</svg>
Here is an example of defining an entity in the internal DTD subset. Note that in XML, there is no requirement to fetch the external DTD subset and so relying on an external subset reduces interoperability. Also note that the SVG Working Group does not provide a normative DTD for SVG Tiny 1.2 but instead provides a normative RelaxNG schema.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.2 Tiny//EN" [
<!ENTITY Smile "
<rect x='.5' y='.5' width='29' height='39' fill='black' stroke='red'/>
<g transform='translate(0, 5)'>
<circle cx='15' cy='15' r='10' fill='yellow'/>
<circle cx='12' cy='12' r='1.5' fill='black'/>
<circle cx='17' cy='12' r='1.5' fill='black'/>
<path d='M 10 19 L 15 23 20 19' stroke='black' stroke-width='2'/>
</g>
">
]>
<svg xmlns="http://www.w3.org/2000/svg">
<desc>This example shows an entity from a DOCTYPE declaration being used.</desc>
&Smile;
</svg>
1.4 SVG MIME type, file name extension and Macintosh file type
The MIME type for SVG is "image/svg+xml" (see Media Type registration for image/svg+xml).
It is recommended that SVG files have the extension
".svg"
(all lowercase) on all platforms. It is
recommended that gzip-compressed
SVG files have the extension ".svgz"
(all
lowercase) on all platforms.
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).
1.5 Compatibility with Other Standards Efforts
SVG Tiny 1.2 leverages and integrates with other W3C specifications
and standards efforts. By leveraging and conforming to other
standards, SVG becomes more powerful and makes it easier for
users to learn how to incorporate SVG into their Web sites.
The following describes some of the ways in which SVG
maintains compatibility with, leverages and integrates with
other W3C efforts:
- SVG Tiny 1.2 is an application of XML and is compatible with the
"Extensible Markup Language (XML) 1.0" Recommendation [XML10]
- SVG Tiny 1.2 is compatible with the "Namespaces in XML 1.1"
Recommendation [XML-NS]
- SVG Tiny 1.2 utilizes "XML Linking Language (XLink)" [XLINK] for IRI
referencing and requires support for base IRI specifications
defined in "XML Base" [XML-BASE].
- SVG Tiny 1.2 uses the xml:id attribute [XMLID].
- SVG Tiny 1.2 content can be generated by XSLT (see
"XSL Transformations (XSLT) Version 1.0" [XSLT]). (See
Styling with
XSL)
- SVG Tiny 1.2 supports formatting properties drawn from
CSS and XSL. See
SVG's styling
properties.
- SVG Tiny 1.2 includes a compatible subset of the Document Object Model (DOM) and
supports many of the facilities described in "Document
Object Model (DOM) level 3" [DOM3], including
namespace support and event handling.
- SVG Tiny 1.2 incorporates some features from
"Synchronized Multimedia Integration Language
(SMIL) 2.0 Specification" [SMIL2.0], including
the 'switch' element, the systemLanguage attribute,
animation features (see Animation)
and the ability to reference audio and video media
(see Multimedia). SVG's
animation features incorporate and extend the general-purpose
XML animation capabilities described in SMIL 2.0. In addition,
SVG Tiny 1.2 has been designed to allow SMIL 2.0 to
use animated or static SVG content as media components.
- SVG is compatible with W3C work on internationalization.
References (W3C and otherwise) include: [UNICODE], [CHARMOD-RI]
and [CHARMOD].
Also, see Internationalization
Support.
- SVG is compatible with W3C work on Web Accessibility [WAI]. Also, see Accessibility Support.
In environments which support [DOM3] for other
XML grammars (e.g., XHTML [XHTML]) and which also
support SVG and the SVG DOM, a single scripting approach can be
used simultaneously for both XML documents and SVG graphics, in
which case interactive and dynamic effects will be possible on
multiple XML namespaces using the same set of scripts.
1.6 Definitions
- basic shape
- Standard shapes which are predefined in SVG as a
convenience for common graphical operations. Specifically: 'rect', 'circle', 'ellipse', 'line', 'polyline', 'polygon'.
- canvas
- A surface onto which graphics elements are drawn, which
can be real physical media such as a display or paper or an
abstract surface such as a allocated region of computer
memory. See the discussion of the SVG canvas in the chapter on
Coordinate Systems, Transformations and
Units.
- container element
- An element which can have graphics elements and other
container elements as child elements. Specifically: 'svg', 'g', 'defs', 'a' and 'switch'.
- current SVG document
fragment
- The XML document sub-tree which starts with parent
'svg' element of a given SVG
element, with the requirement that all container elements
between the outermost 'svg' and this element are
all elements in the SVG language.
- current transformation matrix
(CTM)
- Transformation matrices define the mathematical mapping
from one coordinate system into another using a 3x3 matrix
using the equation [x' y' 1] = [x
y 1] * matrix. The current transformation
matrix (CTM) defines the mapping from the user
coordinate system into the viewport coordinate system. See Coordinate
system transformations.
- fill
- The operation of painting the interior of a shape or the interior of the
character glyphs in a text string.
- font
- A font represents an organized collection of glyphs in which the various
glyph representations will share a common look or styling
such that, when a string of characters is rendered together,
the result is highly legible, conveys a particular artistic
style and provides consistent inter-character alignment and
spacing.
- glyph
- A glyph represents a unit of rendered content within a font. Often, there is a
one-to-one correspondence between characters to be drawn and
corresponding glyphs (e.g., often, the character "A" is
rendered using a single glyph), but other times multiple
glyphs are used to render a single character (e.g., use of
accents) or a single glyph can be used to render multiple
characters (e.g., ligatures). Typically, a glyph is defined
by one or more shapes such
as a path, possibly with additional
information such as rendering hints that help a font engine
to produce legible text in small sizes.
- graphics element
- One of the element types that can cause graphics to be
drawn onto the target canvas. Specifically: 'path', 'text', 'textArea', 'rect', 'circle', 'ellipse', 'line', 'polyline', 'polygon', 'image', 'use', 'animation' and 'video'.
- graphics referencing
element
- A graphics element which uses a reference to a different
document or element as the source of its graphical content.
Specifically: 'use', 'image', 'animation' and 'video'.
- 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.
- IRI Reference
- An International Resource Identifier [IRI] which
serves as a reference to a resource or (with a fragment identifier)
to a secondary resource. See References.
- local IRI reference
- An International Resource Identifier [IRI] that does
not include an <absoluteIRI> or <relativeIRI> and thus
represents a reference to an element within the current
document. See References.
- non-local IRI reference
- An International Resource Identifier [IRI] that
includes an <absoluteIRI> or <relativeIRI> and thus
(usually) represents a reference to a different document or
an element within a different document. See References and the 'defs' element.
- 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
supports two types of built-in paint: color and gradients.
- presentation attribute
- An XML attribute on an SVG element which specifies a
value for a given property for that element. See Styling.
- property
- A parameter that helps specify how a document should be
rendered. A complete list of SVG's properties can be found in
Property Index. Properties are
assigned to elements in the SVG language by presentation
attributes. See Styling.
- shape
- A graphics element that is defined by some combination of
straight lines and curves. Specifically: 'path', 'rect', 'circle', 'ellipse', 'line', 'polyline', 'polygon'.
- stroke
- The operation of painting the outline of a shape or the outline of
character glyphs in a text string.
- SVG canvas
- The canvas onto which the SVG
content is rendered. See the discussion of the SVG canvas in the chapter on
Coordinate Systems, Transformations and
Units.
- SVG document fragment
- The XML document sub-tree which starts with an 'svg' element. An SVG
document fragment can consist of a stand-alone SVG document,
or a fragment of a parent XML document enclosed by an 'svg' element. When an 'svg' element is a descendant
of another 'svg' element, there are two
SVG document fragments, one for each 'svg' element. (One SVG
document fragment is contained within another SVG document
fragment.)
- SVG viewport
- The viewport within the SVG canvas which defines the
rectangular region into which SVG content is rendered. See
the discussion of the SVG
viewport in the chapter on Coordinate Systems, Transformations and
Units.
- text content element
- One of SVG's elements that can define a text string that
is to be rendered onto the canvas. SVG Tiny 1.2's text content
elements are the following: 'text' and 'tspan'.
- transformation
- A modification of the current
transformation matrix (CTM) by providing a supplemental
transformation in the form of a set of simple transformations
specifications (such as scaling, rotation or translation)
and/or one or more transformation matrices.
See Coordinate
system transformations.
- transformation matrix
- Transformation matrices define the mathematical mapping
from one coordinate system into another using a 3x3 matrix
using the equation [x' y' 1] = [x
y 1] * matrix. See current
transformation matrix (CTM) and Coordinate
system transformations.
- unsupported value
- An unsupported value is a value that does not conform to this specification,
but is not specifically listed as '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, and assistive
technologies such as screen readers, screen magnifiers,
speech synthesizers, onscreen keyboards, and voice input
software.
A "user agent" may or may not have the ability to retrieve
and render SVG content; however, an "SVG user agent"
retrieves and renders SVG content.
- user coordinate system
- In general, a coordinate system defines locations and
distances on the current canvas.
The current user coordinate
system is the coordinate system that is currently
active and which is used to define how coordinates and
lengths are located and computed, respectively, on the
current canvas. See initial
user coordinate system and Coordinate
system transformations.
- user space
- A synonym for user
coordinate system.
- user units
- A coordinate value or length expressed in user units
represents a coordinate value or length in the current user coordinate system.
Thus, 10 user units represents a length of 10 units in the
current user coordinate system.
- viewport
- A rectangular region within the current canvas onto which graphics elements are to be
rendered. See the discussion of the SVG viewport in the
chapter on Coordinate Systems,
Transformations and Units.
- viewport coordinate system
- In general, a coordinate system defines locations and
distances on the current canvas.
The viewport coordinate
system is the coordinate system that is active at the
start of processing of an 'svg' element, before
processing the optional viewBox attribute. In the
case of an SVG document fragment that is embedded within a
parent document which uses CSS to manage its layout, then the
viewport coordinate system will have the same orientation and
lengths as in CSS, with the origin at the top-left on the viewport. See The initial viewport and
Establishing a
new viewport.
- viewport space
- A synonym for viewport coordinate
system.
- viewport units
- A coordinate value or length expressed in viewport units
represents a coordinate value or length in the viewport coordinate
system. Thus, 10 viewport units represents a length of 10
units in the viewport coordinate system.