This document defines two mobile profiles of SVG. The first profile, SVG Tiny, is defined to be suitable for cellphones and low-end PDAs; and the second profile, SVG Basic, is suitable for PDAs.
This document is the first public draft version of the mobile profiles of SVG 1.1.
It is possible to use this document as a basis for implementation. However, no guarantee is given of stability, and the SVG Working Group will not use the existance of implementations conforming to this draft as a reason for not changing future drafts.
This document has been produced by the W3C SVG Working Group as part of the Graphics Activity within the W3C Document Formats Domain. The goals of the W3C SVG Working Group are discussed in the W3C SVG Charter (W3C members only). The W3C SVG Working Group has maintained a public Web page http://www.w3.org/Graphics/SVG/ which contains further background information. The authors of this document are the SVG Working Group members.
We explicitly invite comments on this document. Please send them
Public discussion of issues related to vector graphics on the Web
and SVG in particular takes place on the public mailing list of the SVG Working
Group (list archives).
To subscribe send an email to
with the word
subscribe in the subject line.
A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/. W3C publications may be updated, replaced, or obsoleted by other documents at any time. In particular it is inappropriate to use W3C Working Drafts as reference material or to cite them as other than work in progress.
There is one area that has been identified as lacking in the SVG 1.0 Specification. It has been established by industry demand, overwhelming support in the SVG working group and requests from the SVG developer community that some form of SVG suited to displaying vector graphics on small devices is required. Moreover, the mission statement of SVG 1.0 specifically addresses small devices as a target area for vector graphics display. In order to meet these demands the SVG Working Group has committed to a concerted effort to create a profile specification that addresses mobile devices.
A single profile is not sufficient to deal with the variety of mobile devices, because each mobile device has different characteristics in terms of CPU speed, memory size, and color support. To address different device families, two profiles are defined. The first low-level profile, SVG Tiny (SVGT) is suitable for highly restricted mobile devices; while the second profile, SVG Basic (SVGB) is targeted for higher level mobile devices.
Because of the low memory, low CPU power and limited display of mobile devices, Mobile SVG profiles introduce constraints on content, attribute types, properties, and user agent behaviour. This section describes these constraints and design rationale behind them.
SVGT and SVGB consist of the following SVG 1.1 modules:
desc, title, metadata, svg, g, defs
rect, circle, line, ellipse, polyline, polygon, path
animate, set, animateMotion, animateTransform, animateColor
font, fontface, glyph, missing-glyph, hkern, vkern
desc, title, metadata, svg, g, defs, use, symbol
rect, circle, line, ellipse, polyline, polygon, path
text, tspan, tref, textPath
animate, set, animateMotion, animateTransform, animateColor, mpath
font, fontface, glyph, missing-glyph, hkern, vkern
linearGradient, radialGradient, stop
|Number||SVGT and SVGB content may contain numbers as defined in SVG1.1, but Mobile SVG implementations are only required to represent numbers by 15.16 fixed point values internally. Scientific notation is not supported.|
|Length||SVGT only supports user units (i.e., CSS units are not supported), with the one exception that the 'width' and 'height' attributes on the outermost 'svg' element can specify values in any of the following CSS units: in, cm, mm, pt, pc, and %. SVGB supports lengths in user coordinate space and in CSS units.|
|Coordinate||SVGT and SVGB support the coordinate data type, represented with a <length> value.|
|List of XXX||(where XXX represents a value of some type): SVGT and SVGB support the list specification.|
|Angle||SVGT only supports angles if specified with no CSS unit identifiers (which means all angles are in degrees). SVGB supports angles with CSS unit identifiers.|
|Color||SVGT and SVGB support <color> in the CSS2-compatible specification for a color in the sRGB color space, and system colors. Additionally, SVGB supports 16 original color keywords from XHTML.|
|Paint||SVGB supports paint specification for fill and stroke operations, as well as linear and radial gradients. SVGT does not support the more general notion of paint specification and thus only supports solid color fills and strokes.|
|Percentage||SVGB supports percentages. SVGT does not support percentage values except for the 'width' and 'height' attributes on the outermost 'svg' element.|
|Transform List||SVGB and SVGT support transform lists.|
|URI||SVGB and SVGT support the URI datatype.|
|Frequency||SVGB and SVGT do not support frequency values.|
|Time||SVGB and SVGT support time values, with unit identifiers (ms, s).;|
SVGB and SVGT content can be in the form of stand-alone SVG Documents or document fragments embedded within a parent XML document. The following is an example of an SVG document fragment embedded within an XHTML Basic document:
<?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html xmlns = "http://www.w3.org/1999/xhtml" xmlns:svg="http://www.w3.org/2000/svg"> <head> <title> An example XHTML Basic document </title> <link type="text/css" rel="stylesheet" href="mystyle.css" /> </head> <body> <svg:svg version="1.1" profile="tiny" width="4cm" height="8cm" viewBox="0 0 4 8"> <svg:ellipse cx="2" cy="4" rx="2" ry="1" /> </svg:svg> </body> </html>
SVGB and SVGT support the 'title', 'desc' and 'metadata' elements as defined in SVG 1.1.
Attributes of 'svg' elements that appear in the middle of SVGT content cannot be specified in CSS unit identifiers.
The 'profile' attribute on the outermost 'svg' element must have the value "tiny" for SVG Tiny content, and "basic" for SVG Basic content. The 'profile' attribute on nested child 'svg' elements is ignored. The SVG 1.1 specification states that the 'version' attribute of the outermost 'svg' element in SVG 1.1 content must have the value "1.1".
SVGB and SVGT support hyperlinking targets using the 'a' element.
For SVGT and SVGB, all referenced objects, except hyperlinking through the 'a' element, must be internal. URI references may be in either of the two XPointer forms (i.e., #<elementID> and #xpointer(id(<elementID>).
In SVGB, for images and fonts, embedding can be accomplished using the data: protocol and base64 encoding. SVGT supports base64 encoding only.
In SVGB and SVGT, symbols cannot define a new viewport, thus 'viewBox' and 'preserveAspectRatio' are not used.
SVGB and SVGT support subsets of SVG 1.1's presentation attributes. SVGB and SVGT allow optional support of a subset of CSS attribute selectors.
SVGB and SVGT introduce constraints on style properties. Allowed values for style properties are listed in Appendix C.
SVGB and SVGT support the 'class' attribute to refer to styles defined within the <defs> element. Specifying multiple classes within the same 'class' attribute is supported.
SVGB and SVGT support SVG 1.1's notion of viewports.
SVGB and SVGT support nesting of transformations. The types of transformations that are allowed are generic transformation matrices, or simple operations such as rotation, scaling, skewing, and translation.
SVGB and SVGT support the transform attribute. The following transform definition types are supported:
SVGB and SVGT support the 'viewBox' attribute.
SVGB and SVGT support the 'preserveAspectRatio' attribute for adapting the content to terminals with different display aspect ratios.
In SVGT, the <align> parameter can only be either 'none' or 'XMidYMid', the <meetOrSlice> parameter can be 'meet'.
In SVGB, the values of this parameter can be the same as in SVG 1.1.
SVGB and SVGT support establishing a new viewport via additional embedded 'svg' elements.
SVGT supports user units only, except for the 'width' and 'height' attributes on the outermost 'svg' element. SVGB supports user units and CSS user identifiers.
SVGB and SVGT do not support bounding box unit specification.
The path element data is animatable, as defined in SVG 1.1 specification. Path data animation is only possible when each path data specification within an animation specification has exactly the same list of path data commands as the d attribute.
SVGB and SVGT support:
SVGB and SVGT do not support the elliptical arc curve command ("A"(absolute) and "a"(relative)).
SVGT and SVGB support the basic shapes (rectangles, circles, ellipses, lines, polylines, and polygons) as defined in SVG1.1.
SVGB and SVGT support representing text with Unicode characters. Mobile SVG user agents are not required to allow text selection and clipboard operations.
SVGT supports only the 'text' element, and does not support text on a path, 'tspan' and 'tref', and 'altGlyph' elements. SVGB does not support 'altGylph'.
SVGB and SVGT support filling and stroking 'path' elements and basic shapes with solid colors.
SVGB supports stroked text for terminal fonts, but SVGT does not.
SVGB and SVGT support colors defined by 'color' property in sRGB color space and color keywords. Specifying colors using an ICC profile is not supported.
SVGB supports solid colors and gradient paints, patterns and custom paints. SVGT only supports solid color painting.
SVGB supports a subset of gradients and does not support patterns. SVGT supports neither gradients nor patterns.
SVGB supports clipping, masking and compositing. SVGB does not support additive clipping paths.
SVGT does not support clipping, masking, group opacity or alpha compositing into the parent.
SVGB supports a subset of filter effects. SVGT does not support filter effects.
SVGB and SVGT support a subset of the SVG 1.1 interactivity feature set. The subset will be defined in the next working draft.
SVGB and SVGT support hyperlink activation from SVG content to other Web resources through the 'a' element.
SVGB supports hyperlink into particular views of SVG content. SVGT does not support this feature.
SVGB includes all of the language features from SVG 1.1 to support scripting. SVGB allows optional support of the EcmaScript, WMLScript languages.
SVGT does not support scripting.
Both SVGB and SVGT support subset of SVG 1.1's declarative animation features. The language features to support animation through scripting and DOM are available in SVGB but not SVGT.
SVGB and SVGT allow targeting only those elements, which belong to the same SVG Document fragment, through 'xlink:href' attribute.
SVGB supports linear, spline, paced and discrete animations. SVGT only supports linear, paced and discrete animations.
The timing of animations must be defined in seconds or milliseconds, and be specified with the unit identifiers.
SVGB and SVGT support a subset of SVG fonts where only the 'd' attribute on the 'glyph' element is available. Arbitrary SVG within a 'glyph' is not supported.
Both SVGB and SVGT support embedded metadata.
SVGB and SVGT allow inclusion of elements and attributes from foreign namespaces within the SVG content.
SVGB allows inclusion of elements and attributes from foreign namespaces within the SVG content. SVGT is not expected to be able to process namespace declarations.
The authors of this specification are the members of the W3C SVG Working Group, whose members are listed:
The next Working Draft will include list of elements in SVGB and SVGT.
The next Working Draft will include the list of attributes in SVGB and SVGT, with limitations on allowed values.
The next Working Draft will include the list of style properties in SVGB and SVGT, with limitations on allowed values.
In order to allow interoperability between SVG content generators and user agents dealing with maps, the SVG Working Group encourages the use of a common metadata definition to describe an SVG file that is a map. The next working draft will describe in more detail how these metadata should be used in the SVG content and how they will allow to describe the Coordinate Reference System used for the coordinates in the SVG file.
The SVG Working Group is investigating the extra requirements of supporting a subset of clipping paths of SVGT. If the extra overhead, in terms of UA size, computational complexity, and memory usage, proves small, the SVG Working Group will consider supporting a subset of clipping paths.
Supporting stroke-width requires additional features than supporting hairwidth lines. Line joins and line caps may require additional computational resources. Additionally, converting stroke of a shape to a path would substantially increase computational overhead for stroking. The next version of this working draft will address this issue.
Some of the system colors, as defined in SVG 1.1, are not applicable to mobile SVG. In order to decrease memory requirements, the SVG Working Group will consider defining a subset of system colors for SVGT.
The next draft of this document will contain normative XML Schemas for SVG Basic and SVG Tiny.
The next draft of this document will contain non-normative DTDs for SVG Basic and SVG Tiny.