Copyright © 2002, 2001 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply.
This document defines two mobile profiles of SVG 1.1. The first profile, SVG Tiny, is defined to be suitable for cellphones; the second profile, SVG Basic, is suitable for PDAs.
This document is the second Working Draft version of the two mobile profiles of SVG 1.1 - SVG Basic and SVG Tiny.
SinceSVG 1.1 is closely related to the SVG 1.0 W3C Recommendation, it is possible to use this document as a basis for experimental 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
to svg-comments@w3.org.
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
www-svg-request@w3.org
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.
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 such 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 the range of 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. For each module, a given profile might contain the Full version, the Basic version, the Tiny version, or no version of that module. For ease of use, the relevant elements in each module are given; in modules other than Full, not all attributes may be supported and there may be restrictions on attribute values. For details, see the module definitions in the SVG 1.1 specification
svg, g, defs, desc, title, metadata, use
style
a
switch
path, rect, circle, line, ellipse, polyline, polygon
image
text
solidColor
font, font-face, glyph, missing-glyph, hkern,
vkern, font-face-src, font-face-name, definition-src
script
view
animate, set, animateMotion, animateTransform,
animateColor, mpath
foreignObject
svg,g,defs,desc,title,metadata,symbol,use
style
a
switch
path, rect, circle, line, ellipse, polyline, polygon
image
text, tspan, tref, textPath
solidColor, color-profile
linearGradient, radialGradient, stop
pattern
clipPath
mask
font, font-face, glyph, missing-glyph, hkern,
vkern, font-face-src, font-face-uri, font-face-format, font-face-name, definition-src
script
cursor
view
filter, feBlend, feColorMatrix, feComponentTransfer, feComposite, feFlood,
feGaussianBlur, feImage, feMerge, feMergeNode,
feOffset, feTile, feFuncR, feFuncG, feFuncB, feFuncA
animate, set, animateMotion, animateTransform,
animateColor, mpath
foreignObject
Data Type | Description |
Number | SVGT and SVGB content may contain numbers as defined in SVG1.1. Scientific notation is also 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, and allows optional support of ICC color profiles. |
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" baseProfile="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 'baseProfile' attribute on the outermost 'svg' element must have the value "tiny" for SVG Tiny content, and "basic" for SVG Basic content. The 'baseProfile' 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".
For SVGT, all referenced objects, except hyperlinking through the 'a' element, must be internal (using the 'data:' URL scheme, and base64 encoding). SVGB does not put extra limitations on external references as defined by SVG 1.1.
In addition to SVGT images embedded using the data: URL scheme, to avoid duplicated base-64-encoded versions of images stored locally, SVGT also allows optional support of local access to images.
SVGT does not support symbols.
Note that, in SVG1.1, animations on a referenced element will cause the instance to be animated. SVGB and SVGT also support this feature.
SVGB and SVGT require support of the JPEG, PNG and SVG formats on the image element.
The following feature set is used:
Need to define what are the allowed feature strings in requiredFeatures
SVGB and SVGT support subsets of SVG 1.1's presentation attributes. SVGB and SVGT allow optional support of CSS Mobile Profile 1.0.
SVGB and SVGT introduce constraints on style properties. Allowed values for style properties are listed in Appendix C.
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 where CSS units are also supported. SVGB supports both user units and CSS user identifiers.
SVGT does not support bounding box unit specification.
SVGB and SVGT support all SVG 1.1 path commands, except the elliptical arc curve command ("A"(absolute) and "a"(relative)).
The path element data is animatable, as defined in the SVG 1.1 specification.
SVGT and SVGB support the basic shapes (rectangles, circles, ellipses, lines, polylines, and polygons) as defined in SVG1.1.
SVGB and SVGT represent 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. SVGT supports the 'rotate' attribute on the 'text' element, but it should be noted that this may cause a slow down of the user agent's rendering speed.
SVGB and SVGT do not support 'altGylph'.
SVGB and SVGT support filling and stroking 'path' elements and basic shapes with solid colors.
SVGB supports stroking on text when using outline fonts, but SVGT does not
SVGB and SVGT support colors defined by 'color' property in sRGB color space, and color keywords.
Should the set of keywords be redued for SVG Tiny and if so, how? All keywords except the system colors can e produced with the explicit RGB values, and the new solidColor element removes some need for large lists of color keywords. on the other hand, remembering which ones are supported in which profile might prove burdensome.
Specifying colors using an ICC profile is not supported in SVGT, and as with SVG 1.1, it is optional in SVGB (the sRGB fallback being used instead).
SVGB supports solid colors, gradient paints, patterns, and custom paints. SVGT only supports solid color painting.
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 the SVG 1.1 events.
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 and SVGT include all of the language features from SVG 1.1 to support scripting. Scripting is optional in SVGB and SVGT . SVG Tiny does not require a default language that has to be supported by all user agents.
Both SVGB and SVGT support a subset of SVG 1.1's declarative animation features. The language features to support animation through scripting and DOM are available in SVGB and SVGT.
SVGB and SVGT allow implicit targeting of parent element, and targeting elements using 'xlink:href' attribute.
SVGB supports linear, spline, paced and discrete animations. SVGT only supports linear, paced and discrete animations.
SVGB and SVGT support a subset of SVG fonts where only the 'd' attribute on the 'glyph' and 'missing-glyph' elements is available. Arbitrary SVG within a 'glyph' is not supported.
As with Full SVG 1.1, SVGB supports downloadable fonts using WebFonts facility defined in the "Cascading Style Sheets (CSS) level 2" specification
Both SVGB and SVGT support embedded metadata.
SVGB and SVGT allow inclusion of elements and attributes from foreign namespaces within the SVG content.
SVGB and SVGT allow inclusion of elements and attributes from foreign namespaces within the SVG content. The SVG renderer is not expected to be able to render content in foreign namespaces, but the foreignObject element allows a subtree in a foreign namespace to be assigned a width and height and passed off to another renderer.
Even though real number values in the Mobile SVG content have the capacity to be represented by at least a single-precision floating point number, some Mobile SVG viewers may not be able to use floating point storage and computation internally. In this case, the Mobile SVG viewers may use a fixed-point representation of numbers internally, possibly with a loss of accuracy.
For stroking shapes, SVGT user agents may utilize methods that require smaller footprint and efficient processing than a higher-end user agent. In this case, SVGT viewers may approximate the visual results of stroking related processing, such as dasharray processing and line join.
The authors of this specification are the members of the W3C SVG Working Group, whose members are listed:
Color code | |
---|---|
Element from Full Module | Yes |
Element from Basic Module | Yes |
Element from Tiny Module | Yes |
Element disallowed | No |
Element | SVG Tiny | SVG Basic |
---|---|---|
a | Yes | Yes |
altGlyph | No | No |
altGlyphDef | No | No |
altGlyphItem | No | No |
animate | Yes | Yes |
animateColor | Yes | Yes |
animateMotion | Yes | Yes |
animateTransform | Yes | Yes |
circle | Yes | Yes |
clipPath | No | Yes |
color-profile | No | Yes |
cursor | No | Yes |
definition-src | Yes | Yes |
defs | Yes | Yes |
desc | Yes | Yes |
ellipse | Yes | Yes |
feBlend | No | Yes |
feColorMatrix | No | Yes |
feComponentTransfer | No | Yes |
feComposite | No | Yes |
feConvolveMatrix | No | No |
feDiffuseLighting | No | No |
feDisplacementMap | No | No |
feDistantLight | No | No |
feFlood | No | Yes |
feFuncA | No | Yes |
feFuncB | No | Yes |
feFuncG | No | Yes |
feFuncR | No | Yes |
feGaussianBlur | No | Yes |
feImage | No | Yes |
feMerge | No | Yes |
feMergeNode | No | Yes |
feMorphology | No | No |
feOffset | No | Yes |
fePointLight | No | No |
feSpecularLighting | No | No |
feSpotLight | No | No |
feTile | No | Yes |
feTurbulence | No | No |
filter | No | Yes |
font | Yes | Yes |
font-face | Yes | Yes |
font-face-format | No | Yes |
font-face-name | No | Yes |
font-face-src | No | Yes |
font-face-uri | No | Yes |
foreignObject | Yes | Yes |
g | Yes | Yes |
glyph | Yes | Yes |
glyphRef | No | Yes |
hkern | Yes | Yes |
image | Yes | Yes |
line | Yes | Yes |
linearGradient | No | Yes |
marker | No | No |
mask | No | Yes |
metadata | Yes | Yes |
missing-glyph | Yes | Yes |
mpath | Yes | Yes |
path | Yes | Yes |
pattern | No | Yes |
polygon | Yes | Yes |
polyline | Yes | Yes |
radialGradient | No | Yes |
rect | Yes | Yes |
script | Yes | Yes |
set | Yes | Yes |
stop | No | Yes |
style | Yes | Yes |
svg | Yes | Yes |
switch | Yes | Yes |
symbol | No | Yes |
text | Yes | Yes |
textPath | No | Yes |
title | Yes | Yes |
tref | No | Yes |
tspan | No | Yes |
use | Yes | Yes |
view | No | Yes |
vkern | Yes | Yes |
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 more features than supporting single pixel lines. Line joins and line caps may require additional computational resources. Additionally, converting the 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 W3C XML Schemas for SVG Basic and SVG Tiny. For this draft, please consult the W3C XML Schema for SVG 1.1
The next draft of this document will contain non-normative DTDs for SVG Basic and SVG Tiny.