Flash and SVG

Steve Probets

About this Document

This document discusses the similarities and differences between Scalable Vector Graphics (SVG) and Macromedia's Flash format (SWF). It outlines some techniques that could be used in converting between the two formats. It is not intended as a full report of the findings of the research, but raises some interesting (hopefully!) points, and links to some files that show some of the areas of interest in the different file formats. The purpose of the investigation was to produce a program capable of converting Flash movies into SVG, the standard for vector graphics on the web, i.e. SWF2SVG.

Some sample SWF files and their SVG representations created using SWF2SVG are available here.

Background

Macromedia's Flash format is currently the most widely used vector graphics and animation format on the web today. The recent additions of non-proprietary formats such as SVG may, in time, give web designers a choice of vector graphics and movie formats.

Flash movies are distributed as SWF files, a compact binary file format that requires an additional browser plug-in to be available in order for the movie to be viewed. SVG is an XML-compliant open standards, aimed at the same market.

A document briefly describing the semantics of the SWF file format and its relationship to SVG can be found in the format comparison document. This is a good place to start, particularly if you are unfamiliar with the semantics of the SWF format. I would recommend having at least a quick glance at this document, it also explains very briefly some more details about the conversion process.

File Conversion

An existing public domain Flash player (swfplayer by Olivier Debon, available at: http://www.geocities.com/TimesSquare/Labyrinth/5084/flash.html) is being adapted to output SVG constructs as it plays a Flash movie. There are 2 basic stages in the conversion from SWF to SVG:

The manner in which the second stage is performed has evolved over time. When SVG was in its infancy, there was an absence of a stable animation model, and each frame of the movie was output as a separate SVG file. More information on this early phase of the project will be provided shortly. However as the underlying structure of the Document Object Model (DOM) became apparent, animation could be controlled through manipulation of the DOM, as described in the second document. Both these documents assume knowledge of the generation of SVG shapes from SWF as described in the first document, the format comparisons document.

When complete, the player should compile under most Unix systems running X Windows, and enable SWF files to be converted into SVG. The act of writing the file conversion has thrown up some interesting anomalies and discrepancies in the way in which the SWF format and SVG language deal with certain concepts. Some of these discrepancies are outlined in the format comparisons document mentioned above.

Many difficulties with the conversion, such as generating correct fill paths from the SWF data have now been overcome. In addition text strings are dealt with correctly and certain image types have have been investigated and can be supported in SVG. J-PEG images, for example, can be stored within the SWF file. In order to reduce file sizes within SWF, it is possible for the J-PEG tables to be extracted from the image data so that the tables only need to be stored once, even though several images may use them. In SVG images are referred to by href attributes, therefore each image must be re-assembled as the conversion proceeds.

To Sum Up

SVG has a good enough overlap with SWF files in that, despite the difficulties, Flash shapes, text and images be converted into SVG. These shapes can be defined once and then used later, with transformation matrices and other attributes exported by the DOM being used to manipulate the shapes.

In the early days of SVG there was a limited animation model, therefore individual SVG files were generated for each analogous SWF frame. The next stage, and the current stage of the project, is to generate a single SVG file that defines the shapes and an associated HTML file that uses JavaScript to interact with the DOM to place, manipulate or change the defined shapes. Because each shape only needs to be defined once the SVG produced for this is a lot more compact, and in terms of shape definitions and placement will follow the semantics of a SWF file quite closely.

Using the DOM to manipulate SVG definitions of analogous SWF shapes works fairly well, and is explained further in an associated document. Some original SWF files and the resulting SVG animations are available from the animation document that show how SVG can be created from SWF.

Futures

The SVG specification is being finalised, but until a stable SVG plug-in for IE has been produced, it will be difficult to finalise development on the converter. This is because SVG constructs such as <symbol>, and parts of the DOM, which are not currently implemented in the plug-in, will enable better SVG to be generated. However I see no reason why conversion of a majority of SWF files into SVG should not be possible.

Software

Although the software is not yet available for distribution, The latest beta version of the converter is accessible on-line. This gives you the opportunity to upload a SWF file and be returned a zip file consisting of an SVG file, an HTML wrapper and any associated JPEG files. As mentioned the software is still under development so please send any comments or problems to sgp@cs.nott.ac.uk.

Last Updated: 5 April 2000 (Steve Probets)