Keywords: SVG, slide, animation
Casado is currently a Ph. D. student. He is researching in graphics issues and working for the Grupo de Graficos de Granada.
Torres is the lead of the Grupo de Graficos de Granada
SVG is a well known format for being able to represent vector graphics. At the moment, there are works on a new draft to improve several SVG's features. This fact shows us that the standard is healthy and moving forward.
Nowadays we can find SVG's implementations in different platforms: Windows, Macintosh, mobiles, GNU/Linux. But SVG is not only graphics. Another very interesting SVG aspect is the capability to represent animations. This format is able to add movement to the objects so we can interact with them. These are the basis in every interactive graphic system. During the last few years we have developed a tool to edit slide presentation using SVG as native format. This tool was presented at SVGOpen'2004.
Even though SVG was born as an standard, no one can boast about having 100% standard implementation. There are several partial implementations and there is only one that makes possible the interaction with SVG documents. This situation is not similar in every case, it depends on the platform you are working with, and has a great effect on the usability of the slide presentation tool.
2. From SVG 1.1 to SVG 1.2 in the presentations field
2.1 Page element
2.3 Multimedia features
2.4 Other features
3. SVG viewers
3.1 Adobe SVG Viewer (plugin)
3.2 Apache Batik
3.3 Mozilla SVG
3.4 Other SVG implementations
4. Development options
4.1 Wait for viewers improvement
4.2 Viewer implementation
4.3 Joint to an ongoing project
4.4 A subset of the language
SVG is a Standard that was born to satisfy the necessity for representing 2D graphics in the Web without raster graphics limitations. Representing graphic information by using a descriptive language, that means defining object's geometric features, has several advantages. For instance, avoid the zoom problems that you face with visualization of raster images. Also, it allows us to have our scene objects identified. It is possible to edit such scene at any moment since the scene is drawn from this geometric description. We can also re-draw it after, and show the changes made. Any geometric transformation can be applied since the language describes the elements from their geometric characteristics.
But SVG is much more than a language to represent vector graphics. It is a language that provides mechanisms to actively change objects attributes, and bring them to live. In order to get it, SVG has two different ways. There is a group of well defined tags known as animations. They allow us to modify object's quality they belong to. Furthermore, we can insert 'script' functions within a SVG document. They have got access through DOM to the attributes of the objects, and can change them.
Finally, some mechanisms to interact with graphics elements have been added to the Standard. It is possible to react to different events happened in an object at the moment it is being visualized.
We know that SVG is much wider than that but these three elements are basic for the purpose of this job: the implementation of a presentation system by using SVG. In [Casado04] a SVG document structure for slides presentations was proposed. This system was used to prepare the presentation of this paper.
The proposal of using SVG as a format to do presentations is not new[ST][JACK]. We can find several tools or toolkits that give us the opportunity to generate presentations in SVG. But they have the following restrictions:
The format proposed in [Casado04] covered mainly the aspect related to the union of all elements under only one file. Also, we presented the development of a tool that enables us the edition of the presentation in a native way.
The project has been making progress in the same way that SVG has been moving forward. So now, in a more mature stage for SVG, we will see how this development involves the presentations: things that are contributed, existing limitations and what are the tendencies of this work in order to make progress.
The SVG Standard is being checked at the moment. This draft has got new possibilities that can be used when making presentations. Along this section we will see in what way can we integrate the new tags in the proposed format to edit presentations and what advantages we get.
According to SVG 1.1, in order to represent each slide we need to use a trick. This is defining a group to be able to put together every element that belongs to the slide. In that way, we do transformations on the group we have mentioned to change from one slide to another. Everything goes unnoticed for the user. The user believes the presentatio to be composed by slides. This approach is enough and valid for the presentations but it has got a serious disadvantage. It is not possible to print the whole presentation at once. It has to be printed slide by slide.
The version 1.2 draft specifies a new element: page. This element allows us to define pages inside a SVG document. Its use for the presentations is clear. We define page for each slide composing our document. In that way, to print them will be an easy task for the user agent.
The advantages are enormous. Having an element page to identify pages, the agents do not need any additional logical process to detect the slides. That means that the edition process is now more independent from the visualization process.
Adding the element page to the Standard has clear consequences on to the proposed format: the way of drawing is different. When we use groups to represent each slide, we have to show and hide the slides to cause a transition feeling.
The 1.2 version considers this aspect and add a new element called transiton. This new element allows to define a transition based on SMIL 2.0. This transition can be associated to an object through the attributes transIn and transOut as long as the object is animatable. In that way, we can define transitions, not only for the slides but for the presentation elements.
This approach is a double-edged weapon. On the one hand it presents some advantages. First of all we can mention that the transition is defined in an abstract manner. That makes the transition applicable to any element whatever its position is. There is a group of predefined transitions and we can choose from them which one to use. Another advantage obtained from the one above mentioned is the simplification of the document contents. We only need to define the transition and then use it with the elements we like. All these results in a smaller size file. Finally, we have a very interesting facility: it is easy to change the kind of transition. If we want to change the animation of an object, we only have to define a new transition, or reuse an existing one and reassign it to the object. The amount of defined transitions in SMIL 2.0 is so wide that the possibilities are enormous.
On the other hand, as a big disadvantage we can say that the transitions are limited to those specified in the standard or to those having implemented the agent. We do not know what will happen if the viewer has not implemented a specific transition. For example, if we have an agent that only implements a subgroup of transitions we can not assure the behaviour during the viewing. Also, personalization is a problem. although the amount of transitions to represent is great we can only keep to the ones defined in the standard.
With the approach that we have formerly proposed based in SVG 1.1, the problems above mentioned does not exist because it is possible to implement any transition provided that the visualization agent accepts animations. The disadvantage of this approach is obvious: the increase of the size of the file and the necessity to use calculations in each element to adjust the animations to its values.
An interesting solution would be to use a mixed approach. We will use the predetermined transitions where possible and we will use the old approach in a particular transition. The problem of this mixed approach is the way to show the slides. To make the showing of the slides a simple and easy process, the agent can obtain the information about the length of time for each slide from an attribute of the element page. This would not be possible with the mixed approach, or it would be tricky.
Changes made in the document format in order to accomodate the presentation format to the SVG 1.2 features.
Figure 1: Slides from SVG 1.1 to SVG 1.2
Another good point about the 1.2 version is the multimedia characteristics showed in the new draft. The current draft includes elements to manage audio or video contents.
These elements are straight forward applicable in the format and with them we can get presentations much more versatile. Those characteristics allow us to create presentations almost at the same level of similar products.
The problem is that at the moment nobody has been able to implement in a suitable way the animations, and it is not clear how the audio and video decoding can be performed with all the different codecs that exist and with all the different approaches: libraries, APIs, etc. It would be translated in platform related issue.
The main inconvenience to keep adding other characteristics proposed in the draft of the standard 1.2 to the presentation format is the absence of a viewer to implement such standard. Although there are different features that could be interesting to apply in this field, we are waiting to have the final version of the draft and a suitable viewer for that draft to be able to incorporate them.
A viewer with certain functionality is needed to show a presentation developed with any of the existing tools. Most of the viewers are in a partial implementation stage. It is vital for the presentations to either be able to access to animations in order to simulate transitions or to have one of the proposed transitions in the draft of the 1.2 version. Moreover, if we pretend to be accessible to any user, we must look for visualization tools for the different platforms. Having a full screen mode is a desired characteristic.
We have analysed several viewers to check their degree of implementation of the SVG standard (in any of its versions). The reasons for selecting them have been mainly two: popularity and development. Table 1.1 show the characteristics that we have analized in each viewer.
Adobe SVG Viewer 3.02
Adobe SVG Viewer 3.01
Adobe SVG Viewer 6.0 beta
It is the most advanced viewer in the market. It is a plugin installed in the web browser. For the version 3.x implementations exist for windows as well as for linux. The version 3.x implements most of the SVG 1.1 functionality. Although Adobe has done an effort porting the viewer to any operating system, clear inequalities are found. In that way, for GNU/Linux platform we have test that some mouse events are not accurately detected and that some tags are not implemented.
At the moment, a 6.0 version is under development. There is a beta version available for it but only for Windows platform. We suppose that this version will implement the whole SVG 1.2. We do not know if in the future, versions will be published for any other platforms than Windows and if they will have a full functionality.
Among all projects, this is the most interesting and ambitious for our needs. Batik is not only a SVG viewer. The viewer is only a portion of batik possibilities. It has got an API to manipulate SVG documents, classes to represent SVG elements on the screen, the chance to export to other graphic formats etc. It is the swiss blade for SVG.
Nevertheless the project seems to be stuck in the past years and it is incomplete. Some of the functionality that need to be implemented are animations. These are crucial to properly visualize presentations. In the web page project is admitted that for the time being, there is no intentions of implement anything.
This Project is being developed in Java. It would allow the development of SVG based applications in a quicker way. Managing the documents will become very easy. Tools like SVGCanvas or export in PNG format make the project very attractive to anyone that is looking to develop an SVG application to final users.
Currently Mozilla is developing a SVG browser version. This project is moving forward very slowly. As well as Batik project, animations functionality are not yet implemented. There is not an expected deadline for this project to be finished.
Within the Open Source initiatives, the KDE project has opted for a native SVG implementation like Mozilla, allowing the KDE desktop to visualize SVG graphics. However, this implementation does not give support for animations, so that it can only be used as static graphic viewer.
Taking all that into account, we must start saying that the SVG viewers continue to be an unfinished business. With the SVG appearance several initiatives oriented to the SVG agents implementation arose. There were promising projects that have remained stuck and that have not been able to develop a final version, or a version that does not implement 100% of the SVG 1.1 standard.
As we have mentioned above, there are a strong dependency between the editing tools and the SVG viewers. It is not possible to obtain SVG presentations with advanced features without a viewer having a full implementation of the standard or, at least, a subset of the standard that allows certain functionality.
Viewers should advance in a considerable way if we want to get a SVG presentation based system that fits to the requirements proposed in Casado04. There are different ways to achieve this goal. We have the following alternative solutions.
We can suppose that a full standard SVG viewer will be released at any time, and that will be available for the different platforms. So we can wait for this event to happen and then push forward the SVG presentations.
Since our tool works as an editor and it is hoped to be a WYSIWYG tool, it would be possible to use the part related to the visualization in order to create a presentation viewer. The main advantage of this approach is that the basic kernel already exists. We would only have to develop an interface appropriated to the viewer necessities.
As the main disadvantage is that it is a particular solution to the problem. We would create an alternative viewer that is only functional with those features used in the presentation system. At the beginning it would be another viewer that does not fit with the SVG standard but that could be in a compliance with the standard as time goes. This mean a great implementation effort since a new viewer should be created almost from the scratch.
Another solution would be to join to an existing project and to develop the remaining part of the viewer. It seems that the main problem of the other project is the lack of staff, so joining to one of those would mean a good idea. Nowadays, Batik is the most promising project in order to do this: it is developed in Java as well as our project and we could benefit mutually from the extension of its functionality towards the SVG 1.2.
The learning curve is the main con of this approach. We should analyse the existing code in depth in order to be able to add new functionality in a similar way.
SVGTiny has appeared during the last years as a SVG subset for mobile devices. It has been growing up day by day. It has more recent implementation with regard to viewers. One option could be to evaluate the current state of the SVGTiny implementations and which are the features of this subset in order to try to move from SVG to SVGTiny.
The main inconvenient we face to is the problem to analyse and evaluate the required changes by the proposed format in order to adapt it to the SVGTiny features.
One of the SVG applications is to develop slide presentations. Several approaches have been proposed to do it. Our proposal is to store the whole presentation into one SVG file. A tool to do this with the proposed structure for the SVG document was presented at SVGOpen'2004.
It has been argued that the new version of the standard includes new features that can make it easier to represent slide presentations. This paper has discussed some of these new features, studying how they can be applied to slide presentations, concluding that some of these features can simplify part of the SVG documents representing slides presentation, but their use has also some clear drawbacks.
We have also surveyed the development state of SVG viewer that are needed to show the presentations, concluding that any of them cover the whole standard, and only one implementation covered the minimum needed to shows slides presentation using our approach, based on standard 1.1.
Finally, we may conclude that the main problem for developing a real general useful tool is not the limitation of the version 1.1 of the standard, but the lack of viewers that complies with standard. So probably the effort must be put not on the standard enrichment but on the standard implementation. Moreover, perhaps the best way to avoid that someone develops a complete SVG viewer is to continuously incorporate new functionality to it.
XHTML rendition made possible by SchemaSoft's Document Interpreter™ technology.