Going Mobile With SVG: Standards
June 16, 2004
It has been a long while since I last indulged in sharing my precious affection for SVG with you, dear reader. Time has passed and things have evolved in the SVG world. In fact, things have evolved so much that I come back to you all charged up for what I hope will be many more strolls through the versatile SVG landscape. In my last report I was hinting at the emergence of two specifications that are coming into the public light today: one was SVG 1.2 and the other was SVG Mobile. While SVG 1.2 is heading soon to the W3C Last Call phase (more on this in the upcoming weeks and months), SVG Mobile has been a focus point for the mobile industry lately; and with such a major breakthrough just around the corner, I felt it was only right to give you a heads-up on the magnificent piece of technology that is SVG Mobile.
The Making of the Great SVG Pyramid
In the beginning, there was one recommendation issued by the W3C in September 2001: Scalable Vector Graphics 1.0. It isn't abusive to call it a big fat spec, since it truly is. The point is that SVG had to cater to quite a few different types of desktop-oriented two-dimensional graphics use cases, and this called for a complex piece of work. But believe it or not, by the time SVG 1.0 was finished there was already talk about using SVG for something else than your good old desktop-type machine. Various Mobile Industry heavy-weights actually figured SVG would be a good match for a new breed of mobile services and they decided to do things the right way and join the W3C Working Group to make sure that, conversely, the members of the W3C SVG Working Group would do things right too when it comes to mobile solutions.
Obviously, there was no way that mobile devices, even the higher-end PDAs of the time, could offer support for anything as rich as SVG 1.0. The feedback was that a smaller version of SVG would be much preferable to the big one. Given the sheer size of the SVG 1.0 recommendation, breaking the big piece into smaller modules was definitely in order, and it was decided that SVG 1.1 would be a modularized version of SVG 1.0 and that using this modular architecture, two new SVG sub-profiles would see the light of day. Why two? Well, the mobile market is divided into three main categories: laptop computers, PDAs, and mobile phones. Today's laptop computers' capabilities approach more and more those of the desktop computers, and SVG 1.0 is perfectly suited to laptops. However, PDAs and mobile phones do need something smaller, yet these two types of devices truly belong to two distinct worlds of computing and graphics power and a profile targeting each terminal type accordingly was preferable. Work started on the SVG Basic and SVG Tiny profiles. The names could have been more specific ("SVG Mobile Phone" and "SVG PDA"), but, by using more abstract names, the W3C didn't lock the door to usage outside of the original target devices.
The computing power relationship between those three types of devices looks pretty similar to a pyramid. The top of the pyramid is the theoretical feature set of a mobile phone. These features are all available in a PDA and are actually augmented. A PDA's features are themselves all available in a desktop or laptop computer and augmented too. So everything a mobile phone could do is doable by a PDA, and everything doable by a PDA is doable by a computer. Hence, it was decided that SVG Tiny would be a strict subset of SVG Basic, itself a strict subset of SVG Full. Here's a pretty picture of this pyramid:
So now that we have a better idea of the rationale behind the two SVG Mobile profiles, what exactly can you do with SVG Basic and SVG Tiny? Let's take a look at the common features and restrictions of SVG Mobile and then look closer to the respective feature sets of both profiles.
Basic, meet Tiny
On the foundation level, you can group elements via the <g> element. In
coordination with grouping, or on an element's local scope, you can use all the
transformation primitives from SVG Full such as scale, rotate, skew, translate and
matrix
transforms. Definition of re-usable assets can be done with the support of the
<defs> element. These assets can then be placed in your document with
the <use> element. Simple hyperlinking only is possible with the
<a> element, the more advanced type of linking with views not being
permitted.
On the 2D-drawing side of things, the basics are all there. All basic shapes are available -- you can draw vector shapes like rectangles, ellipses, circles, lines, polygons, etc. On top of those basic shapes, SVG Tiny offers full support for Bezier-type curves, with only the elliptical arc commands not available (this command is actually a shorthand for a combination of other supported commands). The second most basic set of features that you'll be looking at in SVG Tiny will probably be text. SVG Tiny delivers by allowing for most text operations from SVG Full, apart from text on a path and text fragments. Still in the text area, SVG Tiny supports simple SVG fonts definitions so that you can ensure your types design will be respected across all devices and most importantly scale well (as opposed to system fonts). Raster images are also supported, with the two mandated formats being PNG and JPEG.
So how can you style these vector graphics primitives? First of all, not with CSS, only XML presentation attributes are supported for styling. SVG Tiny supports solid fills and strokes on paths and basic shapes. On the other hand, gradients and pattern fills are not available; they were thought to be too computing-intensive for the SVG Tiny 1.1 timeframe. Opacity, masks and clips are not there either for the same reasons. Given this, you can safely bet that filter effects are not supported either. Damn, that seems to be a lot taken out of SVG. So besides drawing and transforming simple shapes and text, what's left in SVG Tiny?
One of the main design goals of SVG Tiny was to provide a solution for the new generation
of messaging services. In order to cater to this requirement, SVG Tiny was designed
to offer
the full spectrum of what SVG Full offers in terms of animation capabilities. All
the
elements and attributes supported by SVG Tiny can be animated, using either discrete,
paced,
or finely-tuned interpolations, or even motion paths. All of this allows for the creation
of
SVG cartoons and gimmicky animations that you know teens are going to love to send
each
other. SVG Animation allows for simple interactivity like roll-overs with the
<set> element. More advanced conditional interactivity through
scripting is not supported in SVG Tiny 1.1 and there is no DOM available.
As explained above, SVG Basic 1.1 supports all of these features. It would be too long to list the feature differences starting from SVG Tiny, as SVG Basic is actually closer to the feature set of SVG Full. The main things taken out of SVG Basic are markers and cursors. Some filter effects are supported, including the most commonly used ones like drop shadows. The DOM also was a little stripped, with mainly the SVG-specific interfaces allowing access to typed and animated values being taken out. CSS (Mobile profile) styling is optional. Given those light restrictions, some have dubbed SVG Basic as the "right" feature set for SVG offering what's most useful and pertinent for most usage scenarios.
Going back to the idea of the SVG Profiles Pyramid, this design offers the possibility
to
have contents authored with SVG Tiny as a target profile to be viewed with the exact
same
rendering in an SVG Basic or SVG Full implementation. Authors can specifically say
what
profile they are targeting by using the baseProfile attribute on the root
<svg> element. Another interesting feature of SVG that is particularly useful for
Mobile SVG authoring is conditional processing. Using the <switch>
element, available in both the Tiny and Basic profiles, you can test the implementation's
support for given SVG modules using feature strings. Thus you can define within the
same
document different content based on the features, or profile, your implementation
supports.
For instance, you might have simple solid fills on a rectangle for SVG Tiny user agents,
but
allow for a gradient fill and a drop shadow filter if the user agent implements SVG
Basic or
SVG Full. Using feature strings based on modules as opposed to profiles allows for
your
documents to be adapted also to any forthcoming SVG profile based on the SVG 1.1
modularization, such as newer versions of SVG Tiny or SVG Basic, or possible new profiles
for set-top boxes, CAD, GIS, etc.
The Road Ahead: SVG Tiny 1.2
The requirements documents for SVG Tiny 1.1 were created more than two years ago. In these two years, mobile phones have progressed a great deal in computing power, color depth and size of displays and are thus expected by consumers and service providers alike to offer richer graphics experience. In that spirit, the W3C SVG Working Group took the opportunity to use the new work being done on SVG 1.2 to update the SVG Tiny profile (SVG Basic might be upgraded too).
As you saw while I was going through the features supported in SVG Tiny 1.1, the number one feature that was stripped was scripting. SVG Tiny 1.2 remedies that issue and allows for scripting using a new subset of the SVG DOM called the MicroDOM. This subset was designed with the processing and memory constraints of mobile phones, avoiding the usage of strings la Core DOM and focusing on typed access as the SVG DOM offers, although in a much simplified manner. The graphics capabilities of SVG Tiny 1.2 were also beefed up, and simple linear and radial gradients as well as fill and stroke opacity are all supported now.
But SVG Tiny 1.2 doesn't just add features from the SVG 1.1 days, but also picks
from new
SVG 1.2 features. For instance, text-wrapping is now available for rectangular regions,
as
are non-scaling strokes. New multimedia capabilities of recent phones also made possible
the
inclusion in SVG Tiny 1.2 of the <audio> element for playback of sound
synchronized in the SMIL timing model of SVG, while support for the
<video> element is being discussed too. The notion of pages from SVG
1.2 are also leveraged in SVG Tiny 1.2 for creating scenes in animation. You can consult
the
latest SVG Mobile 1.2 draft for a complete
list of evolutions.
Industry Adoption
While I won't talk about market adoption here (see the second Mobile SVG article on this), I would like to highlight the success that Mobile SVG has encountered in adoption by other standards bodies. The first organization to embrace Mobile SVG was 3GPP (3rd Generation Partnership Project) where all the leading mobile vendors gather to define the new generation industry standards in that area. 3GPP selected Mobile SVG as the mandatory vector graphics media format in MMS (Multimedia Messaging Service) and PSS (Packet-Switched Streaming Service) in their Release 5 version. For both these specs, SVG Tiny 1.1 is required and SVG Basic 1.1 is optional, allowing for higher-end mobile devices to get the most out of SVG. 3GPP has also been watching recent Mobile SVG 1.2 developments closely, and we can expect new versions of both these specs to rely on Mobile SVG 1.2 profiles.
Another organization has recently been conducting work showing more signs of Mobile SVG's widening appeal. The Java Community Process (JCP) have created a Java Specifications Request (JSR) expert group lead by Nokia and Sun working on creating a standard SVG Tiny Java API for J2ME. The JSR-226 expert group has been advancing steadily during the last 12 months and the current draft is in Public Review so it's time for you to go check it out and send your feedback. We can expect from this work at JCP that SVG Tiny will soon be a core component of the J2ME platform, thus promoting further usage of Mobile SVG. I should also note the recent MPEG Call for Proposals on Lightweight Application Scene Representation, commanding work on a binary format to represent scenes for use in a mobile environment, compatible with SVG Tiny. This is another thing to keep track of in the next few months.
Adoption
I'm pretty sure that you will agree that this all sounds pretty good. But the true value of these mobile profiles will only be truly proven in the resonance that service providers leveraging new SVG-introduced graphics and multimedia capabilities for powerful new services will find in the consumer world. To find out the first answers to this wondering, tune in next week to read my next Mobile SVG feature focusing on the market happenings of SVG Tiny.