To “Ping” or not to “Ping”

There was a thread on Adobe’s Fireworks forums recently where a user was ask­ing why Fireworks uses the PNG file for­mat (and exten­sion) for its native editable files (the equiv­a­lent 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 lat­est pub­lic exam­ple of it. This debate resur­faces from time to time and I think it’s worth re-​visiting it again espe­cially since Macromedia and now Adobe don’t seem to see it as an issue worth address­ing when I think it really war­rants con­crete action.

Why is this an issue at all?

The fact that Fireworks uses a com­mon graphic exten­sion for its editable native for­mat causes very real prob­lems for a num­ber of users who some­times acci­den­tally erase editable files while export­ing flat­tened opti­mized ones des­tined for Web site view­ing. Although most expe­ri­enced users have devel­oped work flows that vir­tu­ally elim­i­nate those risks, any­one can make a mis­take and over­write an impor­tant 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 frac­tion of any application’s user base posts in pub­lic forums to dis­cuss their prob­lems. For me, one thing is cer­tain though and that is that, no mat­ter how rare or wide­spread this issue is, any appli­ca­tion behav­iour that can so eas­ily cause loss of work should get addressed and fast.

The other thing is that Fireworks is the only graphic design appli­ca­tion I know of that has this prob­lem because it’s the only one that doesn’t use a unique and pro­pri­etary file exten­sion (and for­mat) to save its native editable file. You never need to worry about over­writ­ing your editable files when using Photoshop, Illustrator or InDesign as they all have their own native for­mats and file exten­sions (.psd, .ai, .indd) that very dif­fer­ent from the final exported for­mats they can export or save to.

The issue may not be as seri­ous if Fireworks was actu­ally any good at remem­ber­ing where it saves or export files. The folder it defaults to when sav­ing or export­ing some­times seems com­pletely ran­dom and although this has got­ten bet­ter in the last ver­sion, why take the chance of users loos­ing work. After all, when you export or save a PNG file, not­ing looks more sim­i­lar to a folder full of graphic files than another…

Why use the PNG format?

As I said, the debate over the mer­its (sic) and draw­backs of using the PNG file exten­sion and for­mat re– sur­faces from time to time because of the poten­tial prob­lems described above and it really begs the ques­tion as to why Macromedia decided to use the PNG file for­mat for Fireworks’ native and editable files in the first place.

I believe that one of the pri­mary rea­sons Macromedia chose PNG was to ride the PNG buzz which was really some­thing in the Web design busi­ness for those who have been at it long enough to wit­ness it in the late ‘90s. This is all spec­u­la­tion from my end though as I was not part of the first beta testers/​advisors group that tested the ini­tial Fireworks 1.0 release. I only started using Fireworks at ver­sion 2.0 and I only became a beta tester much later.

Whether the pri­mary rea­son was mar­ket­ing or not, the tech­ni­cal rea­son that the PNG for­mat was usable at all —as it is much bet­ter known as an opti­mized and flat­tened Web pub­lish­ing for­mat like GIF an JPEG— is that the PNG file for­mat spec­i­fi­ca­tion allows for a spe­cial data chunk for pro­pri­etary “exten­sions” and this is what Fireworks uses to store its editable infor­ma­tion (vec­tor objects data, effects, slices, opti­miza­tion set­tings, etc). This is explained in the last para­graph on this page (part of an old Macromedia era tuto­r­ial) which is prob­a­bly the most sen­si­ble expla­na­tion for choos­ing PNG for Fireworks that I’ve read about the issue so far.

That arti­cle claims that PNG was used because it is an open source for­mat and other graphic appli­ca­tions and browsers can open or at least view the file. It also men­tions that those other appli­ca­tions can only see the graph­i­cal or bitmap part of the file and not the pro­pri­etary info. In short, it works like an .eps with a bitmap pre­view in other applications.

Was that a com­pelling enough rea­son to choose PNG? Not even close in my opin­ion. The fact that the pro­pri­etary infor­ma­tion remains pro­pri­etary within a Fireworks PNG file pretty much blows the already very weak open-​source argu­ment out of the water. A real open-​source doc­u­ment for­mat like the OpenDocument Format for exam­ple takes all doc­u­ment data into account, not just its bitmap “pre­view”. Open-​source usu­ally means bet­ter inter­op­er­abil­ity between appli­ca­tions that can EDIT the file. Are we get­ting that with a Fireworks PNG? Not at all. Being able to view a file in mul­ti­ple appli­ca­tions doesn’t make it open-​source, edit­ing it in mul­ti­ple appli­ca­tion 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 prac­ti­cal advan­tage to using the PNG file for­mat? Is the abil­ity 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 expe­ri­enced already and the poten­tial for future such mis­takes. Not to me. Again, not even close.

In all fair­ness, if you put aside the dubi­ous “open-​source” argu­ment, there is also no tech­ni­cal draw­backs to using the PNG for­mat. Nothing lim­its what can be put in the pro­pri­etary data chunk and the for­mat has served users well inside of Fireworks.

So what can be done to solve the loss of work issue?

The dis­tinc­tion between the for­mat and the extension

There is one sim­ple thing that can be done to solve the issue once and for all with min­i­mal impact on exist­ing files or work flows. Adobe should just change the file “exten­sion” of native and editable files saved from Fireworks. Underneath, the file for­mat can remain a PNG but chang­ing the exten­sion would elim­i­nate the poten­tial for loss of work as reg­u­lar exported PNG files could no longer over­write editable ones.

So what about the abil­ity to see an editable file in a browser or open native files in appli­ca­tions like IrFanView, XnView and oth­ers then? Well, noth­ing. Try it. Take one of your exist­ing native Fireworks file and sim­ply change its file exten­sion to any­thing, use myFWPNG.xyz for all I care. Your OS may warn you about the dan­ger of chang­ing the exten­sion. Do it any­way and drag that file in your browser’s win­dow. It should show up the same as before. It at least does on Windows. Even Windows Explorer will pre­view the file cor­rectly if your folder view option is set to one of the icons views.

I also tested it in IrFanView. It rec­og­nizes the file as a PNG but warns that it has the “wrong” exten­sion and gives the option to rename it. If you can­cel that it still opens the file and dis­plays it just fine anyway.

Finally, if an appli­ca­tion does not rec­og­nize your PNG file with a dif­fer­ent exten­sion, you could always rename it to whatever.png before try­ing to open it in that appli­ca­tion. I doubt you would have to do that often if at all.

So why not make the change?

If the change doesn’t dis­rupt the sin­gle advan­tage of the sta­tus quo that its pro­po­nents seem to be able to con­jure up, for me the real ques­tion becomes, why NOT make the change? When an application’s behav­iour causes peo­ple to loose work, I call it a bug, and in this case, a very destruc­tive one. Adobe can still tout the use of the PNG for­mat as a “fea­ture” if they want to even if I never met any­one who was “impressed” by the fact that Fireworks uses the PNG for­mat. To me it was a ridicu­lous mar­ket­ing trick in the begin­ning and now, the mad­ness has to stop, espe­cially when the change seems so easy to make…