FOTD 08: Fireworks 8 – Save to Bitmap

Sometimes small updates can be important ones to note. Have you ever just wanted to open an image up in Fireworks and save it out as another format? If so, you’ve noted this requires an export step in earlier versions of Fireworks- not particularly intuitive for those familiar with other image-editing applications. In Fireworks 8, however, you can simply open an image and select “File > Save As…”?, choose from the variety of export filetypes that Fireworks supports, and you’re done converting the format. Sure, this isn’t exactly a huge new feature, but for adding more options to your image editing workflow, it could be a timesaver nonetheless- and a great example of the strong focus on expanded/improved workflow in Studio 8.

Now this workflow tweak might be a bit confusing to Fireworks old-timers, however- where the Fireworks PNG file was always treated as sacred property- the holy source from which all ‘flat copies’ were created. So how does this new Save As feature actually affect you in practice?Well, if you open a PNG source file, the default Save option still saves back to PNG- no change there. You can still treat your PNGs as your ‘clean source’ files, and export them to other formats if/when needed. If you use Save As… to save the original PNG image as another format, however- your open, working image will then change to the newly-specified format, and any Fireworks-specific edits made since you either opened or last saved the original PNG file will be lost.If you’ve opened a non-PNG format file such as GIF, JPEG, PSD, TIFF (et al), Save As… will default to the image’s original format- not PNG (key change of note from prior versions of Fireworks, which would save any edited non-PNG source file to PNG by default). In case you’re concerned that this new ‘Save As’ functionality could result in losing work, here’s what the ‘Save As’ dialog looks like if your open document is not in the PNG format, and you’ve made changes that aren’t supported by that format:

‘Save As…’ message, when the source is not PNG format

As such, I’d recommend using your existing PNG workflow (exporting) for key asset files in your project (to maintain a clean PNG source to work from), and using the ‘Save As…’ feature to quickly convert and/or flatten a specific image (watch that ‘warning’ section for format mismatch alerts, of course!). Now you may be wondering what happens if you open, for example, a GIF image, make edits and hit command (control)-S to Save the document instead of ‘Save All’. This scenario (which honestly, I find the most frequent in my own day-to-day usage) provides even more verbose feedback before committing anything to disk- you’ll be presented with the following dialog and options:

Save options, when the source file is not PNG format

This makes it reasonably certain that if you’re starting from a non-PNG format and make a bunch of Fireworks-specific edits to it, hitting “command(control) + S” (or choosing “File > Save” won’t assume you want to lose the editability of your changes by saving back to the original format, and gives you the option to choose which format to save back into- select PNG if you want to preserve all your edits, of course. However, for those times where you quickly want to open a file, add a quick change and save it back, you can also cut out that export step here too, if you really want to. Personally I like having source PNG files for everything, this just gives me a few options I didn’t have before in case the extra ‘save as PNG’/export steps aren’t necessary. You choose what’s best for your own workflow.Note that ‘Save As…’ always saves a copy of the currently-opened file- so if you open a PNG file, add some layers and text, then use the new ‘Save As…’ functionality to save the image to JPEG, for example- you won’t have modified anything in your original PNG file, and will have instead saved a flattened, JPEG version of that PNG file reflecting all the changes you’ve made- and losing any chance of editing the newchanges you’ve made. Key point to note- just to be on the safe side.So as with any feature that changes established workflows, I’d recommend stepping carefully into your exploration and use of this new ‘Save As…’ functionality in Fireworks 8 to get a handle on it before diving into complex projects- but for all those instances where you’ve wished Fireworks was as quick at basic image conversion as it is deep for involved design and asset generation, this little v8 feature update could help quite a bit. Although I was a bit apprehensive at first in regards to how it would affect my own workflow (and any potential for data loss), honestly- I’ve grown to rely on this particular FW8 feature much more than I would have expected. Hope you do too!Enjoy!(side note: keep posted to Greg Rewis’ blog for Captivate simulations of these daily features, too- he’s a little backlogged now due to his travel schedule but will be putting more up shortly!)

6 Responses to FOTD 08: Fireworks 8 – Save to Bitmap

  1. Kevin Hoyt says:

    Man, that’s sweet! Now all I need to do is untrain myself from all those years of “Export” keyboard shortcuts (smile). I suppose there could be worse problems to have (wink).

  2. Mark says:

    Hi Scott!Does Fireworks 8 have fixed the justified text view? In MX2004 it isn’t like in web when make text justified in div, table, p where ever…Cheers!

  3. Hi, Mark-I’m not exactly sure what the problem is?Justifying text in any application relies far more on the container the text is within (i.e. what the text is justifying TO) than anything else, and in Fireworks, the container is simply the text area you’ve created (i.e. click-drag the text tool to define the ‘region’, then entering text that will justify itself to that region), and it’s fixed (i.e. you can’t have ‘fluid text’ in an image- once you export a JPG/GIF/etc, it’s finished).In reverse, justifying text in a div/table/p is handled differently because the *container* (div/table/p) in most cases can rescale itself and rejustify the text as needed- and further, the *client browser* is what ultimately determines the font, font metrics, and container width (i.e. the styles you’ve defined along with the width of the browser window in question, the operating system and browser brand/version being used, any custom font settings the user may have specified in that browser, etc.). Justified text will always be handled differently between images from Fireworks (which always appear the same) and HTML/XHTML text (which can be rendered differently based on the client that’s displaying it) in that respect. You can always try to nudge your font metrics via CSS closer to that specified in your Fireworks images, but it’s not an exact science, more one of reasonable compromise.Given the above, do you have a specific example of what you consider to be broken in MX2004? I guess if my comments haven’t answered or explained some of the larger scenario with justified text handling between image-set text and fluid, HTML text, then I’m really not sure where your problem lies- an example would help a lot. Thx!

  4. Mark says:

    I mean this – LinkThanks for answering

  5. Ah- thanks, that makes much more sense. I’m not sure which browser you’re using, but Fireworks renders the text the same now as it did in your test/sample image. Sorry!Have you reported this through the bug/wishlist form? If not, I’d certainly do so:!

  6. Marke says:

    Should be like in browser i think.