Tutorials, extensions, and source files for ActionScript, Flash, and other Adobe products.


Fireworks, the PNG file format, and the Dilemma

Posted February 12, 2008 by senocular

I've been involved in a few discussions concerning the PNG file format and its use in Fireworks. Quite a few people are pushing for a new native file format or at least a renaming of the current .png to something specific to fireworks. I was even in that camp for a while, but I've since changed my perspective. I explain below.
Fireworks CS3 is a multi-purpose image editing application available from Adobe Systems Inc. It's native file format is the Portable Network Graphics (PNG) format. The PNG file format is an extensible, patent-free format for storing raster (bitmap) image data. Given its often small file sizes, PNG has become one of the more popular image formats for use on the web. But the PNG format is also diverse enough to easily incorporate non-image data into its files. The Fireworks engineers recognized this advantage, and in helping to support the open format, used it as the native source file format for their application.

The Conflict:
Because PNG files work so well on the web, and the fact that they can also be used as source files in an application (Fireworks) that generates compressed web images, creates a conflict. Developers find themselves using images of the same format for both their source files and compressed destination files. It can become hard for anyone to look at a file and determine whether or not it is a source file or compressed output based on its name. Conversely, with Adobe Photoshop and Adobe Illustrator, for example, you have two separate source-only formats (PSD and AI) that would not also be destination formats. If you exported images from those source files, you would end up with something other than a PSD or AI file and could instantly tell them apart as you browse files on your file system.

Additionally, because the formats are the same, one can easily accidentally export a compressed file overtop a source file, losing all of the source data that file originally contained. Because the formats are the same, there's no definite distinction between the files during export, especially if exporting from the source file to a similarly named destination file (which is the default naming convention for exported images).

The Simple Solution:
The easiest and most intuitive solution to this problem is to change Fireworks to support an alternate native file type. Given a new file type, the aforementioned conflict would no longer be a problem as source files could easily be distinguished from destination files. In fact, the format itself wouldn't have to change; Fireworks could continue to use the PNG file format but, instead, change the extension to something unique such as .fng or .fwpng or whatever. With a simple change of the extension, nothing internal would have to change - the application would still be reading and writing to the same kind of data - Fireworks would only have to recognize and load source files with a different naming scheme.

Why the Simple Solution Fails:
As simple as it may seem to change the file extension for Fireworks source files, it does more harm than it does good. While it is true that developers would be able to easily distinguish source files from destination files, and no longer would they need to worry about accidentally overwriting source files during export, the application support (from other applications) for the Fireworks format would be lost. And often, all it takes is a change in the extension since that is how most applications determine file types.

One of the advantages of using a known file type as a source file is that you instantly have support from all other applications that support that same type. Even if those applications don't support the source format, they will at least get the image data or be able to show a preview of the file. The popularity of the PNG format has made it compatible with hundreds of applications meaning every one of those applications have, since the first release of Fireworks, instantly been able to at least display Fireworks source files. Others, like Flash Professional, can even read Fireworks-specific source data. Changing that extension jeopardizes that support and would even break backwards compatibility since Fireworks itself cannot even recognize PNG files without a proper .png extension.

The Workaround:
The real, underlying issue here revolves around user error. It is the developer's error if he or she overwrites a source file with a different, compressed version of the file, or is unable to remember which files are which. One could suggest that developers suck it up and get more organized, but that is, by far, easier said than done.

The alternate solution (or workaround, given that it is a developer-side solution) is to take a "poor man's approach" to the simple solution. An absolute change to the PNG file format will not happen. Fireworks will continue to support PNG and it's natural .png extension. Fireworks does not, however, disallow you from saving files with a double extension. A double extension is a file with two periods (.) in its filename. This approach is often used with viruses to make people think the file type is something other than the actual (i.e. README.TXT.vbs). Double extensions can also be used with Fireworks to help developers escape their source file affliction. For example, by using .fw.png as an extension when saving from Fireworks (and really, all you need is just the .fw as Fireworks will append the .png automatically), you are creating a file that continues to use a valid PNG extension, and thereby making it recognizable to all other applications that support PNG files, but also has an alternate, precursor extension that helps identify it as a source file. Additionally, when you export a PNG image from this source file in Fireworks, the default naming for the new file will be the source file's name without the .fw portion of the [double] extension. This is different from the source file making it much harder to accidentally overwrite source files with destination files and keeps their names separate enough to distinguish between the two.

All this takes is 3 additional key strokes for the first time you save a source file. No Fireworks engineering effort is required, it works for all versions of Fireworks, and Fireworks source files can continue to be easily recognized by other applications - and even, for that matter, humans. Using a .fw.png extension clearly indicates (to developers) that the PNG file is a Fireworks source file.