I know the argument for live fonts in banners. Easier to make client changes. Less file size. Crisp readabilty.
But unless specifically told to do so, I will never use live fonts for the following reasons:
1) Images are much faster to code. Live fonts require a while bunch of CSS to get it looking correct. Imagine a price point, with a small $, different size dollars and cents, and a few dividing lines for good measure. Not difficult CSS, but takes way longer that just saving an image in Photoshop. Just set up an action in Photoshop to turn a layer or selection into a transparent PNG, and thats your image. And as long as you keep the PSD, it's easy to make changes. The one thing I'll give live fonts in this area is its easier for a new developer to take over as you don't need to worry about passing along the PSD as well.
2) Images are much easier to QA. An image is an image in every modern browser and platform. No way can you say the same thing about live fonts. It will looks slightly different all over the place.
3) Unless you have a web font licensed, you will need to resort to Google fonts, or something else not quite what the AD wanted. And even if you do have a proper font to upload with the zip, it will never look exactly the same as the PSD. Sometimes very close, but never exact. And the AD worked hard at all those kerning and letting settings which will be tossed.
4) Custom fonts can be huge, thus offsetting the file size you saved from using fonts instead of images. Maybe even putting you over the file size limit. And you will usually have to load it from the cloud, which is still a grey area for many ad servers.
5) Using tinypng.com with retina sized PNGs is surprisingly efficient for file size and quality. Thus quality with images will not be compromised.
Overall, the thing about banners is that they are temporary venues for advertising. They will typically be handled by one dev only, and only be around for a limited time. There is no need for easy editing or ease of transfer. File size, image quality, and speed of development are the three key aspects. File size/quality is debatable depending on the design and fonts, but usually can be done with images no problem considering what banners are usually designed like. But speed of development, there is no argument at all. Images are way easier. And will always get you exactly what the AD (and client) is expecting without having to resort to "Well, it's HTML text so it will look a bit different than the PDF."
You know that new feature of the Mac OS called Versions? Its the thing that automatically saves multiple version of whatever file you are working on in TextEdit, Pages, Numbers, and other Mac Apps so you can revert back at any time to any previous state of the file. It's great for things like writing screenplays or shopping lists, when you might want to see what you previously did, or accidentally deleted something. But I've discovered that there is a possible security hole.
Whenever the operating system saves a version, it puts the data into an invisible database on your harddrive called DocumentRevisions-V100. This database is not encrypted. Which means that if you have ever made a text file that contains passwords or bank information on it, this database has a copy.
Now any smart person wouldn't make such a text file without saving it onto an encrypted DNG file or something like that. However, even if on an encrypted disk image, Versions still makes copies of it into the unencrypted database. So even though it seems secure sitting on that disk image, you actually have unencrypted versions of it hanging around.
Now this is only technically a problem if you have FileVault turned off for your hard drive. If you have FileVault turned on, it's not "really" an issue because your entire hard drive is encrypted.
But say you take your encrypted DNG file and stick it on a memory stick. Safe right? But then say you are at the library (that uses Macs) or at a friends place, and decide you need a password. You stick it in, temporarily decrypt the DNG file to get at your password file, and then close the file and eject the disk. Sounds reasonable. The file is still safely encrypted on your memory stick. But Versions has now created a copy of it on your friends computer in the database. Even if your friend has no intention of hacking you, there is still a copy of your password file sitting unencrypted out there.
People could be passing their secure documents around without knowing. Any thief who gets a hold of a computer could easily just browse the database looking for unintentional saves.
One should be able to turn Versions off on particular documents if they desire, and/or the database should be encrypted.
Hopefully Apple addresses this. If you agree, send them a suggestion, and warn your friends: https://www.apple.com/feedback/macosx.html
Recenly I had to export an FLA file to a Quicktime movie, and found that it just hung around saying "Recording Flash Content". I though this was due to the high res FLV I had embedded in the timeline. But afte waiting an hour, I realized something was wrong. I restarted the computer, tried reducing the rez on the FLV, but nothing helped. I realized that it was because there was a stop() frame on the main timeline, and the Quicktime was se to stop when the last frame was reached. Thus the last frame was never reached, and Flash went into a loop. Removing the stop() frame fixed the issue immediately
No idea why, but when I published a full screen projector file with a small video player on the stage, the video player suddenly jumped to full screen as well. _flvPlayer.fullScreenTakeOver = false didn't work on it's own. It needed to be added to each and every instance the FLV was added to the stage. Not a big bug but haven't had a post in a while, so just wanted to share.
I have yet to find a fix for this, but seemingly without reason, sometimes when I open an FLA file, I find that a few jpgs that were previously imported and then updated with another file, have reverted back to the original imported state.
If anyone else has had this happen, or has a fix, please let me know. I cannot find another instance of someone else experiencing this online, so it would be good to know I'm not the only one.
I've noticed recently that sometimes the arrow button KeyEvents are not firing, and that sounds place twice for no apparent reason. It only seems to happen in the beta Flash Player 10.2. Small rant here, but this far into the game, I would think that these sort of bugs would be fixed by now.
Why does every ad server still state in their specs to write the clickTag code like this:
Any developer worth more than $7/hr would only write code this way if they were working in Flash 6, and it was back in 2007. Writing directly on MovieClips is a horrible habit to get into, and makes it very difficult to find and edit code.
In the past, I have completely ignored this requirement, and just written it in my pseudo AS2 Document Class, or directly on the timeline if it's a simple enough banner to not require a Document Class. However, 50% of the time I would get pushback from some project manager at the ad server who knows nothing about code, saying that it was done wrong. I would then spend 2 or 3 hours going back and forth explaining why it is correct, and convincing them to just test it before they pass judgment.
Lately, I've just given in and done it the crappy old fashioned way, because I'm tired of having this argument with them.
So I'm writing here to Ad Servers as a last plea - PLEASE UPDATE YOUR SPECS TO ALLOW FOR PROPER CODING!
Thanks to an anonymous comment, I have found out that Adobe has released a hack to fix the "Error opening URL" error in CS5.
It was determined that FileVault was indeed causing this issue. Turning it off was the easy fix, but for those of us who can't do that, we were stuck without CS5. Adobe didn't release a patch, but did release a file to replace in the Commons folder. See link for instructions.
Seems to have worked for me, and that makes me somewhat happy.
...In other words, a Floating Point Error, or so my web research says.
Apparently, in all coding languages (not just Flash), a decimal does not have an exact representation in binary. So, for example, 5.100000000000000001 is seen as close enough to 5.1. This is fine when doing other things, such as moving a Movie Clip to an x position, but if you are coding something such as a calculator when you need to display the exact number, it can be frustrating.
I found a method online that corrects this by comparing a few numbers, and estimating. Seems to do the trick in my case.
I haven't officially confirmed this yet, but I think I've found the reason why my Flash Video was frequently pausing and skipping mid-stream. I thought it was just the Mac-doesn't-like-Flash-Video thing, but I think it was actually mostly due to Firebug. After disabling it, video seemed to work much better.