There was a thread on Adobe’s Fireworks forums recently where a user was asking why Fireworks uses the PNG file format (and extension) for its native editable files (the equivalent to Illustrator’s .ai and Photoshop’s .psd). This is an issue that gets raised from time to time and that thread was just the latest public example of it. This debate resurfaces from time to time and I think it’s worth re-visiting it again especially since Macromedia and now Adobe don’t seem to see it as an issue worth addressing when I think it really warrants concrete action.
Why is this an issue at all?
The fact that Fireworks uses a common graphic extension for its editable native format causes very real problems for a number of users who sometimes accidentally erase editable files while exporting flattened optimized ones destined for Web site viewing. Although most experienced users have developed work flows that virtually eliminate those risks, anyone can make a mistake and overwrite an important editable file. Unless you have a backup, that file is gone for good at that point. The thing is, there is no way to know how often users loose work this way as only a small fraction of any application’s user base posts in public forums to discuss their problems. For me, one thing is certain though and that is that, no matter how rare or widespread this issue is, any application behaviour that can so easily cause loss of work should get addressed and fast.
The other thing is that Fireworks is the only graphic design application I know of that has this problem because it’s the only one that doesn’t use a unique and proprietary file extension (and format) to save its native editable file. You never need to worry about overwriting your editable files when using Photoshop, Illustrator or InDesign as they all have their own native formats and file extensions (.psd, .ai, .indd) that very different from the final exported formats they can export or save to.
The issue may not be as serious if Fireworks was actually any good at remembering where it saves or export files. The folder it defaults to when saving or exporting sometimes seems completely random and although this has gotten better in the last version, why take the chance of users loosing work. After all, when you export or save a PNG file, noting looks more similar to a folder full of graphic files than another…
Why use the PNG format?
As I said, the debate over the merits (sic) and drawbacks of using the PNG file extension and format re- surfaces from time to time because of the potential problems described above and it really begs the question as to why Macromedia decided to use the PNG file format for Fireworks’ native and editable files in the first place.
I believe that one of the primary reasons Macromedia chose PNG was to ride the PNG buzz which was really something in the Web design business for those who have been at it long enough to witness it in the late ’90s. This is all speculation from my end though as I was not part of the first beta testers/advisors group that tested the initial Fireworks 1.0 release. I only started using Fireworks at version 2.0 and I only became a beta tester much later.
Whether the primary reason was marketing or not, the technical reason that the PNG format was usable at all —as it is much better known as an optimized and flattened Web publishing format like GIF an JPEG— is that the PNG file format specification allows for a special data chunk for proprietary “extensions” and this is what Fireworks uses to store its editable information (vector objects data, effects, slices, optimization settings, etc). This is explained in the last paragraph on this page (part of an old Macromedia era tutorial) which is probably the most sensible explanation for choosing PNG for Fireworks that I’ve read about the issue so far.
That article claims that PNG was used because it is an open source format and other graphic applications and browsers can open or at least view the file. It also mentions that those other applications can only see the graphical or bitmap part of the file and not the proprietary info. In short, it works like an .eps with a bitmap preview in other applications.
Was that a compelling enough reason to choose PNG? Not even close in my opinion. The fact that the proprietary information remains proprietary within a Fireworks PNG file pretty much blows the already very weak open-source argument out of the water. A real open-source document format like the OpenDocument Format for example takes all document data into account, not just its bitmap “preview”. Open-source usually means better interoperability between applications that can EDIT the file. Are we getting that with a Fireworks PNG? Not at all. Being able to view a file in multiple applications doesn’t make it open-source, editing it in multiple application does, and none but Fireworks can get at the real editable data within a native Fireworks PNG file.
What then does remain as a real practical advantage to using the PNG file format? Is the ability to drag and drop a native Fireworks PNG in IE or Firefox and see what it looks like the only one? It seems so. Is that really worth the loss of work many users experienced already and the potential for future such mistakes. Not to me. Again, not even close.
In all fairness, if you put aside the dubious “open-source” argument, there is also no technical drawbacks to using the PNG format. Nothing limits what can be put in the proprietary data chunk and the format has served users well inside of Fireworks.
So what can be done to solve the loss of work issue?
The distinction between the format and the extension
There is one simple thing that can be done to solve the issue once and for all with minimal impact on existing files or work flows. Adobe should just change the file “extension” of native and editable files saved from Fireworks. Underneath, the file format can remain a PNG but changing the extension would eliminate the potential for loss of work as regular exported PNG files could no longer overwrite editable ones.
So what about the ability to see an editable file in a browser or open native files in applications like IrFanView, XnView and others then? Well, nothing. Try it. Take one of your existing native Fireworks file and simply change its file extension to anything, use myFWPNG.xyz for all I care. Your OS may warn you about the danger of changing the extension. Do it anyway and drag that file in your browser’s window. It should show up the same as before. It at least does on Windows. Even Windows Explorer will preview the file correctly if your folder view option is set to one of the icons views.
I also tested it in IrFanView. It recognizes the file as a PNG but warns that it has the “wrong” extension and gives the option to rename it. If you cancel that it still opens the file and displays it just fine anyway.
Finally, if an application does not recognize your PNG file with a different extension, you could always rename it to whatever.png before trying to open it in that application. I doubt you would have to do that often if at all.
So why not make the change?
If the change doesn’t disrupt the single advantage of the status quo that its proponents seem to be able to conjure up, for me the real question becomes, why NOT make the change? When an application’s behaviour causes people to loose work, I call it a bug, and in this case, a very destructive one. Adobe can still tout the use of the PNG format as a “feature” if they want to even if I never met anyone who was “impressed” by the fact that Fireworks uses the PNG format. To me it was a ridiculous marketing trick in the beginning and now, the madness has to stop, especially when the change seems so easy to make…
