SVG Tiny 1.2 - 20071117

1 Introduction

Contents

1.1 About SVG

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

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

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

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

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

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 programmatic control of SVG (for example, for games or user interfaces) and use with scripting languages, became feasible on the whole range of platforms from cellphones through to desktops. In consequence, there is only a single Mobile profile for SVG 1.2 - SVG Tiny 1.2

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

1.2.1 Profiling the SVG specification

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

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

1.3 Defining an SVG Tiny 1.2 document

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

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

Here is an example of an SVG 1.2 file:

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

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

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

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

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

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

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:

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

1.6 Definitions

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

after-edge
Defined in the XSL Area Model.
animation elements
Using the various animation elements, you can define motion paths, fade-in or fade-out effects, and allow objects to grow, shrink, spin or change color. The following 5 elements are Animation Elements: 'animate', 'set', 'animateMotion', 'animateColor' and 'animateTransform'. Animation Elements are further described in Animation Elements.
basic shape
Standard shapes which are predefined in SVG as a convenience for common graphical operations. Specifically any instance of the following elements: 'rect', 'circle', 'ellipse', 'line', 'polyline', 'polygon'.
before-edge
Defined in the XSL Area Model.
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.
bounding box

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

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

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

	<title>BBox of a Path</title>
	<desc>Illustration of one shape (a 'path' element with a quadratic bézier) with three bounding boxes, only one of which is correct.</desc>
	
	<rect x='-200' y='-200' width='780' height='620' fill='#f5f5f5' />
	<defs>
		<g id="shape">
			<path stroke-width='1' stroke='none' fill='yellow' fill-rule='evenodd'
			   d='M20,50 
			      L35,100 
			      H120 
			      V50
			      Q70,10 20,50'/>
	
			<line x1='120' y1='50' x2='70' y2='10' stroke='gray' stroke-dasharray='1,4' stroke-linecap='round'/>
			<line x1='20' y1='50' x2='70' y2='10' stroke='gray' stroke-dasharray='1,4' stroke-linecap='round'/>
			<circle cx='70' cy='10' r='3' fill='none' stroke='gray' />
		</g>
	</defs>
	
	<g>
		<title>Correct BBox</title>		
		<use xlink:href="#shape"/>
		<rect x='20' y='30' width='100' height='70' fill='none' stroke='lime' stroke-dasharray='6' stroke-linecap='round' />
	</g>
	
	<g transform='translate(120)'>
		<title>Incorrect BBox</title>
		<desc>Bounding Box does not encompass entire shape.</desc>		
		<use xlink:href="#shape"/>
		<rect x='20' y='50' width='100' height='50' fill='none' stroke='red' stroke-dasharray='6' stroke-linecap='round' />
	</g>
	
	<g transform='translate(240)'>
		<title>Incorrect BBox</title>
		<desc>Bounding Box includes control points outside shape.</desc>
		<use xlink:href="#shape"/>
		<rect x='20' y='10' width='100' height='90' fill='none' stroke='red' stroke-dasharray='6' stroke-linecap='round' />
	</g>
	
</svg>
Rendering of bbox01.svg

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

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

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

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

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

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

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 current SVG document fragment of an element is the XML document sub-tree such that:
  1. The sub-tree is a valid SVG document fragment.
  2. The sub-tree contains the element in question.
  3. All ancestors of the element in question in the sub-tree are elements in the SVG language and namespace.
A given element may have no current SVG document fragment.
current transformation matrix (CTM)
Transformation matrices define the mathematical mapping from one coordinate system into another using a 3x3 matrix using the equation [x' y' 1] = [x y 1] * matrix. The current transformation matrix (CTM) defines the mapping from the user coordinate system into the viewport coordinate system. See Coordinate system transformations.
decorated bounding box

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

document begin
The document begin for a given SVG document fragment depends on the value of the 'timelineBegin' attribute. The document begin for:
document end
The document end of an SVG document fragment is the point 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 definition of document time.
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'.
host language
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, an XML framework which defines how XHTML, SVG, MathML, XForms, SMIL, and other syntaxes interact.
in error
A value is 'in error' if it is specifically stated as being 'in error' or 'an error' in the prose of this specification. See Error Processing for more detail on handling errors.
inactive element
An element is inactive when it is outside the active duration or when it is paused. Aural aspects of elements which are inactive (e.g. audio, and the audio track of a video element) are silent. SMIL defines the behavior of inactive elements with respect to timing, events, and hyperlinking. See Timing, Paused Elements and Active Duration, and Event Sensitivity.
IRI reference
An Internationalized Resource Identifier (IRI). Defined in RFC 3987. Serves as a reference to a resource or (with a fragment identifier) to a secondary resource. See References.
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. 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. At the XML parser level, SVGT 1.2 does not have default values; lacunae are part of the SVG application layer, and their values are derived from the UA.

local IRI reference
An Internationalized Resource Identifier (IRI) that references a fragment within the same resource. See References.
non-local IRI reference
An Internationalized Resource Identifier [IRI] that represents a reference to a different document or an element within a different document.
media element
An element which defines its own timeline within its own time container. Specifically: 'audio', 'video' and 'animation'. 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 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.
rendering tree

The set of elements being rendered, aurally or visually using the painters model, on an SVG document fragment. The following elements in the fragment:

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

rootmost svg element

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

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

shape
A graphics element that comprises a defined combination of straight lines and curves. Specifically any instance of the element types: '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 context

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

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

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

SVG document fragment

The XML document sub-tree whose rootmost element is an 'svg' element. (i.e. the rootmost svg element.)

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

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

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

SVG element
An element within the SVG namespace defined by the SVG language specification.
SVG User Agent
A User Agent that is able to retrieve and render SVG content.
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.
Syncbase
Defined in SMIL.
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', 'tspan' and 'textArea'.
text content block element
A text content element that serves as a standalone element for a unit of text, and which may optionally contain certain child text content elements (e.g. 'tspan'). SVG Tiny 1.2's text content block elements are the following: 'text', and 'textArea'.
timed elements
Elements that support the SVG Timing Attributes. They are: animate, animateColor, animateMotion, animateTransform, set, video, audio and animation.
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; used alone or in conjunction with assistive technologies such as screen readers, screen magnifiers, speech synthesizers, onscreen keyboards, and voice input software [UAAG10].



A User Agent may or may not have the ability to retrieve and render SVG content; however, an SVG User Agent must be able to retrieve and render SVG content.
user coordinate system
In general, a coordinate system defines locations and distances on the current canvas. The current user coordinate system is the coordinate system that is currently active and which is used to define how coordinates and lengths are located and computed, respectively, on the current canvas. See initial user coordinate system and Coordinate system transformations.
user space
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.

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

1.7 How to reference this specification

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

SVG Tiny 1.2 - 20071117