Semantics of Macromedia's Flash (SWF) Format and its Relationship to SVG

Steve Probets

The notes outline the manner in which the SWF specification should be read. Certain parts of the specification are explained and some extra explanations are included where the semantics of the format cannot be explicitly determined from the syntax. Macromedia have realised the advantage of an open vector graphics format (http://www.macromedia.com/software/flash/open/whitepaper/) and have placed the SWF format in the public domain (http://www.macromedia.com/software/flash/open/spec/). When comparing SWF to other vector formats, PostScript is often used in this document, however SVG has similar properties to PostScript, so the comparison also applies equally well to this format.

General Information

Flash files can be stored in two formats - an editable format (.fla) which can be read by Flash tools and the images and animations altered and a final form format (.swf) which is more compact, not editable, and suitable for web graphics. The SWF file format is a comparable format to SVG.

Every SWF Flash file begins with general information about the file. This consists of a 3 byte signature (FWS), version information and length of the file followed by frame information. Each frame in Flash represents an image, these images are displayed at a specified rate to produce the animation. The frame information consists of the frame size, rate and count. Frame size is given in TWIPS, of which there are 1440 to an inch. Therefore in order to convert TWIPS into screen resolution SWF coordinates should be reduced by a factor of 20 (assuming a 72 dpi screen resolution).

Shapes are defined by a series of moveto, lineto and curveto operations with associated fill and stroke colours and patterns. The fill and stroke colours are defined separately to the lines but within the shape. Thus a simple shape definition could consist of:

Define fill 1 to be #ff0000
Define fill 2 to be #0000ff
Define stroke 1 to be #000000
Moveto X,Y
Use Fill 1 and Stroke 1
Lineto X1,Y1
Lineto X2,Y2
Lineto X,Y
Use Fill 2 and no stroke
Lineto X3,Y3
...

Curves in the Flash format are described using quadratic beziers, that is to say they only have one control point. PostScript curves are defined as cubic beziers, with two control points. This must be accounted for when translating Flash to PostScript - the translation, however, is relatively straight forward.

Each line or curve can have 2 fill styles, one of which fills to the left of the line the other to the right. Thus the following shape:

may well be defined as a series of lines with associated properties:

Move to A
Line to B, fill left = blue
Line to D, fill left = blue
Line to C, fill left = blue, fill right = red
Line to E, fill right = red
Line to F, fill right = red
Line to D, fill right = red
Moveto A
Line to C, fill right = blue

The fact that the line from D to C is defined once with two separate fills helps to save space in the file.

Once the shapes are defined a transformation matrix is used in the placement of shapes. This matrix maps the defined shape into the precise location and scale required.

On the surface it appears that Flash shapes should be easy to translate into SVG or PostScript shapes. However the simple figure described above throws up a few problems.

The first anomaly is with paths. Paths in PostScript tend to have a set of parameters such as line thickness, fillcolor etc. Sequences of points (paths?) in SWF are often related solely by their coordinate position, with the fillcolors and other parameters changing as the path is built up. In order to convert SWF paths into PostScript paths, the coordinates of individual lines need to be compared and those with similar attributes, such as a fill color of blue, assigned to a PostScript path. This can occur when the end point of one of the lines matches with the start point of another line. It should be noted that when building up a path for a shape which has a fill color on the left (anti-clockwise) of blue, that lines that have a fill color on the right (clockwise) of blue can be part of the path, however in the this case the starting and ending coordinates of the line with the right fill of blue should be swapped over (this can be seen from the above diagram where the line from A to C with a right fill color of blue should effectively be dealt with as a line from C to A with a left fill color of blue.)

The major problem with mapping this format into a vector format such as SVG or postscript is that the information is stored in SWF as it is created. Thus a square can be created by drawing the left side, then the right side then the top and finally the bottom, this square can then be filled. The shape information for a shape like this may well be:

Define fill 1 to be #ff0000
Moveto X,Y
Lineto X1,Y1
Moveto X2,Y2
Lineto X3,Y3
Moveto X3,Y3
Lineto X1,Y1
Moveto X,Y
Lineto X2,Y2
This means there is a fair processing overhead in generating the SVG paths (or indeed any PostScript-like paths) from the Flash shape information.

Additional Information

A SWF file dump program has been made available by macromedia that gives a textual representation of the SWF file internals. This allows SWF files to be examined and the structures determined.

As part of the Flash package an option is provided to export a Flash (.fla) movie to other formats. Available formats (amongst others) are Encapsulated PostScript (eps) and Adobe Illustrator (ai) format. Utilising these features and comparing the results of the eps produced against the text dump indicates that the Flash package is using similar techniques to those described above to generate eps. In many cases the fill paths are generated and output first, and then the strokes.

Flash to SVG

The SWF dump program has been used as the basis for at least one third party SWF application. This is the swfplayer produced for Linux systems by Olivier Debon (odebon@club-internet.fr). This product was the basis for my investigations into Flash to SVG conversion. The player was modified so that Flash shapes are output as SVG and the Flash matrices examined to map the SVG shapes into the correct position.

The swfplayer creates structures of the shapes and lines making up to shapes and then converts these structures to raster-lines for display on a VDU. In order to do this, the image is decomposed into horizontal lines (which represent a raster line on the output device). The shapes are analysed and any line that intersects with the raster line is analysed. The position where the line intersects the raster line is stored in a structure along with the properties of the line (stroke and right fill colour - note that if the line is being drawn from top to bottom of the display then the colour that will be displayed to the right of the raster line is the left fill colour of the line).

In converting Flash to SVG the raster element of the swfplayer is not needed. However the structures storing the shapes, and the lines they consist of, can be processed to generate SVG output. As outlined above, the start and endpoints of lines and curves are analysed and those that intersect and have the same attributes (such as fillcolor) can be regarded as being part of the same SVG path. Thus SVG graphic elements can be built up. Once the SWF shapes have been translated in to SVG a method for performing the animation can be considered.

Text in SWF

To deal with text elements, SWF defines a font object which defines the character outlines of the font characters. Only those characters which are used in the SWF file are stored in the font definition. Fonts are defined as an offset table followed by a shape table. The glyph definition is stored at a specific offset (given by the offset table), note that the number and order of the glyphs in the shape table and the offsets in the offset table is maintained. A code table is also present which relates a glyph definition to an ASCII code.

Once the font has been defined the text can be defined. A text object specifies the font, height, color and position of each character in the text string. Thus, because of the code table, either the vector description of the character, or the related ASCII code, can be extracted from the SWF file. A translation package therefore has the option of generating vector descriptions of text characters, or the text can be output as strings within the <text> tags.

Images in SWF

Images are stored embedded within the SWF file (they are not linked as they are in SVG). J-PEG images can either be stored as a whole within the SWF file, or, if many images use the same J-PEG tables, the tables are extracted from the data and stored separately within the SWF file. Thus the images have to be reassembled at the time of conversion so that the SVG files can link to them using tags of the form

<img src="jpeg25-10.jpg" x="0" y="39" width="610.00" height="315.00"/>

For further investigation

There are many features in SWF that I have not looked at porting to SVG. Notably gradient fills, metamorphosis, sound and interactivity (buttons and actions). Interactivity in the form of buttons, events and associated actions are probably the most important, and I suspect that these will not prove too problematical to implement ... watch this space ...

Last Updated: 6 January 2000 (Steve Probets)