Welcome to the public beta of FontCard 1.5.
Please tell me if you experience any problems downloading, mounting, or installing from this disk image. We're trying something new to result in much faster downloads. Namely, we're using the Mac OS X 10.4+ only feature to create a disk image using bzip2 compression (this is not the same as a bzip2 compressed disk image) as it offers a substantial size difference. However, there were some problems with Mac OS X thinking it was a bzip2 archive due to "improper" content sniffing in Safari. This made the disk image seem corrupted or prevented all the files from being read.We believe we have fixed this issue server-side by specifying the proper (undocumented) mime-type. If you are curious about the specifics of the issue (or are a developer that serves disk images), see Slava's post.
So far in 1.5b2, FontCard has three new features.
1. FontCard now changes the Font Panel (open TextEdit, hit Command T, that thing). Fonts are shown in WYSIWYG and third party font sets are added to the bottom of the collection list. And there's icons. Please read the new section in the read me for more information.
Font Panel support has some caveats, of course:

2. FontCard now supports FontExplorerâ„¢ X (FEX) sets. In order for FEX sets to appear, the actual FontExplorer application must be running and open. This will change by the next beta.
3. FontCard now supports Suitcase Fusion sets. In order for Suitcase Fusion sets to appear, the actual Suitcase Fusion application must be running and open. This cannot change.
Important Notice: We have not yet acquired Adobe CS3, so therefore FontCard has not been tested with the various applications that are included with Adobe Creative Suite 3. However, the worst that will happen is choosing a font from FontCard's menu won't do anything.
You can always tell whether or not you are running a beta or a final version of FC by the icon in System Preferences. If it is of a Teletubby, it is a beta. If it is the normal FC icon, then it is a final. Unless, of course, you are Canadian. Then the entire thing is flip-flopped around. If you are French Canadian, well... Then hot snow falls up.
When you first start up this version in an app with FAP, FEX, or Suitcase sets enabled and inactive previews on, you should see an unsexy FontCard icon in the menu bar and a progress indicator.
Iif you have any crashing issues or stalls with this beta, please turn on logging in the FC preference pane, make the application crash, and email me the crash log and the console log (/Applications/Utilities/Console).
Version 1.5b2
Version 1.5b1
Get it at: http://www.unsanity.net/beta/fontcard-15b2.dmg (5.95 megs)
Something completely random for the 509th post
This embodies everything I like about Japanese culture. It's nothing specific about the video, it's just the combination of all the typical stereotypes mashed into one music video. Note that this video may be considered NSFW due to violence... and other things.
Today we're ran into a rather obscure situation. Rosyna has created a bz2-compressed DMG image for the new beta of the next major update to FontCard, and when I went to download it, I've noticed that Safari downloads it as "fontcard-xxx.dmg.bz2". Needless to say, it tried to expand the bz2 file upon downloading, and then failed miserably on mounting the expanded DMG file with this error:

"WTF?", I thought. The file name in the URL was ending with "dmg" and not "dmg.bz2". Yes, the data inside of the DMG is compressed using bz2, but nobody should care about that.
So I tried to download the same file using FireFox, and all went just fine: the image downloaded, the file name never changed, and it mounted as it should. I've looked at the response our server been sending, and it was:
Content-Type: application/octet-stream
So what I am guessing is that Safari tries to guess the file type when it's not forcibly defined by the Content-Type; in this particular case, it looked in the file and noticed it is most likely a bz2 archive, so it safely appended the .bz2 extension to the file and continued the download, resulting in the hiatus described above.
So, we've made a tiny change to our .htaccess file, and guess what? Now all DMGs (including the one I just had problems with) download just fine. This also possibly explains why some of our users were having random issues with the DMG images they've downloaded. Perhaps in some cases Safari decided it's a zip archive (since we used to prepare our DMGs compressed with zip), expanding it before passing to the diskutil, making it fail in the end.
So, if you serve DMGs off your hosting, take a note on that. Luckily, the fix is simple (assuming your web host uses Apache):
Open or create a .htaccess file in the root of your Web directory, and put the following line in:
AddType application/x-apple-diskimage dmg
This instructs Apache to forcibly tell the visitors that files ending with "dmg" has a content type of application/x-apple-diskimage, which makes Safari behave as it should: skip the "guessing" part and pass the image where it belongs.
I'd like to say thanks to Mark Rowe for telling us the "right" MIME type. ;)