With the upcoming release of Transform SWF 3.0 on Sept 15th it was time to move all the existing Cookbook examples over to use the new code. The process was surprisingly easy, though a little tedious, so that bodes well for anyone upgrading any existing applications.

The major changes in Version 3.0 were essentially structural and general cleanup rather than “semantic”. There is still a one-to-one mapping from the data structures in the Flash File Format Specification to classes in Transform. The classes are still essentially Java Beans that know how to encoded and decode themselves so the new version will be familiar, if not quite identical. Some of the changes, major and minor which affect porting existing code include:

• Shorter class names. The “FS” prefix (a hangover from the original Objective-C code written a very long time ago) is gone and tedious to use names such as SetBackgroundColor, FSPlaceObject2 and FSRemoveObject2 now become the slimmer and fleeter: Background, Place2 and Remove2 respectively.
• Fewer constructors for classes with optional fields. Instead of having constructors for every combination of optional fields, with FSPlaceObject2 being the canonical, bloated and easy to misuse example, now the classes are their own Builders. Typically there is one constructor and the set methods return the object allowing several calls to be chained together. For example, creating a ShapeStyle used to be:new ShapeStyle(1, 1, 0, 0, 0) now it is the much more readable but slightly verbose: new ShapeStyle().setLineStyle(1).setFillStyle(1).setMove(0, 0)
• Movie objects used to maintain a counter used for generating unique identifiers for definitions. This is no longer the case and applications have to maintain the counter themselves. This means that calls such as: DefineMovieClip clip = new DefineMovieClip(movie.newIdentifier(), new ArrayList()); are now replaced by: int uid = 1;
...
DefineMovieClip clip = new DefineMovieClip(uid++, new ArrayList());
• Integer constants are replaced by enums, e.g. the codes representing compound events for movie clip event handlers are now replaced by the Event enum and multiple events are represented with EnumSets.
• Immutable classes make for fast copying of the parent object, so all actions and basic data types such as bounding boxes, coordinate and colour transforms are now immutable. Constructing immutable objects with multiple values, e.g. the Push NewFunction[2] actions and all Filters now employ special Builder classes:Push.Builder builder = new Push.Builder();
builder.add(integer).add(string);
actions.add(builder.build());
• New Factories and Service Providers. The utilities classes that were used to generates the objects representing images, sounds and text were refactored to follow the Service Provider pattern. This was the biggest structural change, though the impact on existing code is relatively minor. For example creating the definition for an image was: FSImageConstructor imageGenerator = new FSImageConstructor(imageFile);
FSDefineObject image = imageGenerator.defineImage(movie.newIdentifier()); In the new version this becomes:final ImageFactory factory = new ImageFactory();
factory.read(new File(imageFile));
final ImageTag image = factory.defineImage(uid++);
• Movie is now strictly a container. The fields such as version, signature, frameSize and frameRate are now part of the new MovieHeader class. This change was designed to make it easier for people to write their own decoders and to be consistent with other meta-data objects such as MovieMetaData and MovieAttributes since it was not practical to move everything into Movie. For example: FSMovie movie = new FSMovie();
movie.setFrameRate(1.0f);
movie.setFrameSize(new FSBounds(-4000, -4000, 4000, 4000)); Now becomes:
  Movie movie = new Movie();
MovieHeader header = new MovieHeader();
header.setFrameRate(1.0f);
header.setFrameSize(new Bounds(-4000, -4000, 4000, 4000));
movie.add(header);


Generally porting was pretty painless. The biggest annoyance was having to changing type declarations for arrays from: ArrayList actions = new ArrayList(); to: List<Action> actions = new ArrayList<Action>();

There was one gotcha that took a little time to figure out (though not long). I ported Translate SWF to use classes in the new version of Transform rather rely on private copies intended to make the library independent of Transform. Now that actions are immutable:List<Object>values = push.getValues(); returned a copy of the array of values rather than a reference, so:List<Object>values = push.getValues();
values.add(literal); has no effect. However once I had figured out / remembered what the problem was the change was trivial:List<Object>values = push.getValues();
values.add(literal);
actions.set(index, new Push(values));

Not all the change required to port an existing codebase are listed. The best guide would be to perform a diff between the new Cookbook examples when they are released, with the current version for Transform 2.3. That should give a good overview of what needs changing, at least for relatively simple applications.

1. Install MinGW 5.1.6. Make sure you select the following options:
   • MinGW base tools
   • g++ compiler
   • MinGW Make

   Also make sure the name of the directory where you install MinGW does not contain any spaces. C:\MinGW works just fine.

2. Install MSYS 1.0.11. Again the name of the directory where you install MSYS should not contains any spaces. C:\msys works just fine.
3. Install msysDTK-1.0.1.
4. Download and unpack msys bison. Copy the files from the bin, lib and share directories into the same directories in your msys installation.
5. Download and unpack msys flex. Copy the files from the bin, lib, include and share directories into the same directories in your msys installation.
6. Download and unpack msys regex. Copy the dll from the bin directory into the bin directory in your msys installation.
7. Download and unpack ming 0.4.3.
8. Add c:\MSYS\bin, c:\MinGW\bin, in that order, to the PATH environment variable.
9. Open a windows shell, change directory to where you unzipped the ming files and run the following command: bash then at the prompt, run: ./configure --disable-freetype this will configure to build the libraries with c++ bindings.
10. Now edit the file, libtool, in the ming root directory. On line 686 in the function func_extract_an_archive () change: if ($AR t "$f_ex_an_ar_oldlib" | sort | sort -uc >/dev/null 2>&1); then to: if ($AR t "$f_ex_an_ar_oldlib" | sort | sort >/dev/null 2>&1); then Yes, this is subverting the build process and the step will be brittle but all the script is doing is comparing the names of the object files with those stored in the archive. The -uc option is for strict order checking of the file names and there is no obvious reason (at least in the limited time I spent looking) why it does not work.
11. Now compile and install the libraries: make install The libraries and header files will be installed in C:\msys\1.0\local

Issues:

In step 9, support for FreeType was disabled. This means that you will not be able to generate any font definitions from OpenType files. This is a nuisance since that limits the fonts you can use to ones already in Ming’s FDB format. However has FDB files for the Open Source Bitstream Vera fonts so you can get starting albeit with limited typography. I have not tries these fonts so there may be issues if the format changed - it is filed under Really Old Stuff.

The second major issue is another nuisance. The ming library is built without zlib. When the configure script runs it fails to find the compress2 function used by Ming even though the library was available in msys (downloaded and compiled specifically). That means that Ming cannot generate compressed Flash files. This is not too important, but obviously lacking in any code destined for serious use.

Next Steps:

1. Get zlib to be recognised by the configure script.
2. Add FreeType so OpenType fonts can be loaded.
3. Get the build working with the other language wrappers: python, php and perl.

I will post updates as soon as they are available. I also plan on posting the libraries and ported versions of the Cookbook examples over the next few weeks.

So with new versions of Transform and Translate scheduled for release on Sept 15th I started thinking about the C++ versions of the libraries which, although quite useful, have been languishing untouched for quite some time now. Initially I was quite looking forward to getting them freshened up and getting the code to the point where I could say that it was rather nice, or at least it didn’t suck as much. But then, well, I started thinking about what that would take. Getting the code updated to support Flash 10 was not really the hard part - after all at the lowest level, C++ and Java syntax are not that different, especially when reading and writing bytes with streams, so the new Java code could easily be moved over to the C++ version. The harder part was cross-platform support. There are simply too many platform variations to be able to support it effectively. CMake does a good job of reducing the effort by making cross-platform builds easy, but the real issue is answering the “I can’t get it to work” requests. Limiting the set to compiler X on platform Y is too restrictive and does not solve the problem since there are still X * Y * Z versions to deal with.

So the C++ code is going to be retired - permanently this time. Instead if you need a library for generating Flash files with C and C++ bindings then take a look at Ming. After a dormant period, activity on the project is picking up again. They have support for Flash 8. Platform support is good, though building on Windows is kind of hairy (more on that later). I tried porting some examples from the Cookbook to Ming and the API is quite effective. The basic concepts and actions to generate a Flash file are the same and re-writing the simpler examples such as, BasicShapes, did not take long - the hardest (time-consuming) part was changing ints to doubles.

So over the next few weeks I am going to port the rest of the Cookbook to see, overall, how easy it is to use Ming. I’ll also post the code and ming libraries since there seems to be some demand for windows binaries and not a lot of success at creating them.

The focus of work from now on is to start expanding the unit tests and so lessen the dependence on testing with real-world Flash files. Although these are useful and provide a great way of verifying that the code does really work as opposed to simply passing the tests it is not practical to include them in directly in the project for various reasons - file size and copyright being the two largest issues.

All the planned refactoring has been completed so the API should be considered stable. If there are changes, most likely resulting from feature requests I will send out notification in advance so there are no suprises on the next update.

This version is also available from the Maven Central Repository:

<dependency>
<groupId>com.flagstone</groupId>
<artifactId>transform</artifactId>
<version>3.0-b1</version>
</dependency>

A big thank you to Sonatype for providing a Maven repository for Open Source projects and rapid syncing with Maven Central.

Regular status reports and details of any issues reported will be posted on the transform-swf-updates mailing list.

Although this release has an alpha label it has been extensively tested using a large suite of real world Flash files with only a few minor issues.

The current plan is it keep the release in alpha for a short time - probably up to the end of June - to do some more testing and continue with the polishing and general clean-up of the code then move to a formal beta until the end of August and from there release 3.0 formally in early September once everybody is back from vacation and the reported bugs and issues have been resolved.

Regular status reports and details of any issues reported will be posted on the transform-swf-updates mailing list.

Bug Fixes:

• Using characters with high value character codes causes errors.
• AWT Fonts on Mac OSX are offset.

The release notes, http://www.flagstonesoftware.com/downloads/transform-java-2.3.3.txt has all the details.

java-updates@flagstonesoftware.com
cxx-updates@flagstonesoftware.com

Then there are separate lists for each project:

transform-swf-updates@lists.sourceforge.net
translate-swf-updates@lists.sourceforge.net

transform-cxx-updates@lists.sourceforge.net
translate-cxx-updates@lists.sourceforge.net

All the lists are intended for announcements only. If you have any questions regarding thew projects then post them on the forums or contact Flagstone directly.

Bug Fixes:

• FSMovie does not set the character encoding in FSCoder.
• FSSoundConstructor accepts sounds with any sample rate.
• Extended arrays in FSShapeStyle are encoded as bit fields

The release notes, http://www.flagstonesoftware.com/downloads/transform-java-2.3.2.txt has all the details.

Most of the development work for version 3 is now complete. In addition to supporting Flash 8/9 features, most of the effort (and hence most of the delay) has been in refactoring the code to improve the design and boost performance as well as constructing a comprehensive suite of unit and acceptance tests. The to-do list contains the following:

• Finish support for Flash 8/9 - only filters and font alignment are remaining.
• Refactor the utilities classes to improve the design and make testing easier.
• Replace remaining integer constants with enums.
• Finish the suite of unit and acceptance tests.

You can find more detailed information on the current milestones and tasks at http://apps.sourceforge.net/trac/transform-swf/. I have also created a micro-blog for the project, http://apps.sourceforge.net/laconica/transform-swf/ where I will be posting quick (and frequent) updates of what is being worked on and what is left to do.

The code is now reasonably stable so if you want to browse, http://transform-swf.svn.sourceforge.net/viewvc/transform-swf/ or check it out https://transform-swf.svn.sourceforge.net/svnroot/transform-swf/trunk feel free to do so.

Future updates with contain more detailed recipes on how to display different types of object along with more advanced examples.