The environment under which the tool was developed simulated the various situations under which a tool may be created in the future.

The majority of development was carried out on a computer running RISC OS. This provided native support for Draw files, but there were few suitable applications capable of rendering WMF files.

Because of this the Draw modules were easy to implement - and more importantly, test. The available documentation was generally comprehensive and accurate. In cases where assumptions could not be made about the format, or where parts of the documentation were vague, the original applications could be used to find a solution. Each application handled the test files in a consistent way. The ability to test files with confidence that inaccuracies or errors in the output were the fault of the migration tool was advantageous.

This demonstrates that it is useful to develop support for a format when there is access to its current platform.

Implementing the WMF modules was a less straight-forward task. WMFs are pretty much alien to the RISC OS platform - from the 16 bit number systems to the different units used to represent values. There are few applications that support the WMF format - and those that do (such as WMF->Draw, ImageFS) typically work by migrating the file to another format - so another migration step was performed to render the files. Thus it was sometimes difficult to be confident about whether problems with a file were due to the viewer application containing bugs or not supporting particular features, or the migration tool producing incorrect output; different applications could produce different problems when presented with the same test file. An opposite situation also occurred, where the RISC OS applications could handle an output WMF perfectly - leading to the conclusion that the migration was successful. Subsequent tests, when the same file was presented to a Windows application (MS Word), the size, orientation or visible area would be wrong - but it relied on the original software/platform for this mistake to be noticed. These problems, combined with documentation that was sometimes inaccurate and sometimes confusing, made the development fairly difficult - and led to some long term bugs in the tool.

Of course, if development was carried out on a Windows machine, producing Draw modules would have been much harder and producing WMF modules would have been easier. Either way, it shows that development of a format is much harder without access to its original platform.

The SVG format is a modern and still developing format. It is well documented online. It is very easy to output files in SVG format, but rather more difficult to read them in - the price paid for readability and flexibility. SVG does not have a native platform as such, but there are clearly defined protocols and requirements that rendering applications must follow. Many SVG renderers are written in the cross-platform Java language. The developer of a migration tool to be more confident about testing any output files using these standards-compliant applications.

What is important in this case is that the original rendering software is accessible. It is less important about which operating system or machine architecture is used, because a lot of the rendering software is (currently) cross-platform, written in Java. If software longevity techniques are applied to the renderer to allow it to run on future machines it could be possible to easily develop migration tools for the format after it becomes obsolete.

These experiences demonstrate that access (perhaps through emulation) to the original platform and/or applications that treat the formats natively is an important and necessary requirement. Without this ability it is hard to generate compliant, compatible files - especially if there is only poor documentation about the format.

It is easiest, therefore, to implement the migration tool while the formats are still current. The timeliness of the implementation is paramount.

The vector graphic Migration on Request tool has been compiled and tested using a range of development tools and operating systems.

• Linux (x86): gcc
• Windows: Visual C++ 6.0, gcc
• RISC OS: Norcroft C, Easy C/C++, gcc