As you may have heard, Adobe recently released the first beta of Flash Player 10. It looks like unFocus.FlashPlayerInfo has been checking for single version digits, rather than multiple:

_versionRaw.match(/Shockwave Flash (d).(d)/);

The fix is easy enough (I could swear I actually fixed this at one point too):

_versionRaw.match(/Shockwave Flash (d+).(d+)/);

This problem doesn’t seem to be limited to just the unFocus Flash Detection script. I’ve seen other claims of failed Flash detection in other corners as well. I’d bet most of the problems are with the plugin detection scripts (Mozilla Firefox, Opera, Safari, etc.) and not with the ActiveX detection scripts (Internet Explorer), since most of the plugin detection scripts out there are using string parsing techniques, and have probably not tested with multiple digit Flash versions (since there haven’t been any until now).

I’ll see about getting a release out soon. If anyone needs any help updating anything, feel free to leave a comment, or email me.

unFocus.History Keeper 2.0 Beta 2 is now available for download.

Feel free to download, test and use the new beta. Here’s what’s new and fixed:

• History.js - There was an odd error, from a mixed up function, keeping History Keeper from working at all in the last release. It was the first issue reported by someone other than myself (thanks shacky7!) and it’s been fixed.
• FlashPlayerInfo.js - was throwing an error if there was no flash player installed at all in IE. It’s fixed.
• FlashPlayerInfo.js - added more robust Flash Player 6 detection. It is impossible to check for some minor revision versions in Flash Player 6, because they crash IE if you do. It’s now possible, though, to check for 6.0r65, which is the first version to support Express Install.
• FlashPlayerInfo.js - deprecated “.getPluginType()”, and replaced it with “.getPlayerType()” and made it actually work. To practice discipline, I left “.getPluginType()” since it’s improper to change the API after a beta release (it didn’t work before, so I’m sure no one is using it).
• FlashPlayerInfo.js - Fixed beta and MinorRevision errors in ActiveX path.
• SwfHTML.js - was producing a security warning in IE if used over https. It’s fixed.
• Added a bunch of test files for each object, to help make sure stuff doesn’t break (that’s annoying), and more thoroughly test the various methods and features. It is almost, sorta like unit testing, if you kinda look at it sideways, in a mirror.
• Added Object Patent Magic to the package.
• Added SwfShim to the source (under javascript folder), but it’s not ready for prime time yet, and is not in the packed js file.
• Added some example pages - but these are really just there to test to the packed files, at the moment. HistoryKeeper.html is a good place to start if you want to learn how to use History Keeper. I’ll update soon with some Flash examples.

Check out the updated project page for more info, or just skip straight to the download.

Well I guess it’s not really hidden, as much as it’s a tag along to unFocus.History Keeper. I’ve had an interesting (to me anyway) battle in my own head about whether to even continue maintaining SwfHTML and it’s companions SwfCommunicator, and FlashPlayerInfo, since there are many solutions to the problems they address out there already (including ExternalInterface for SwfCommunicator, which is actually built right into Flash Player 8 and up). I even decided a while ago to just stop, and start using SwfObject, UFO, or the new SwfFix (just found that yesterday, looks good!), yet, they are still here and I’m still working on them.

SwfObject, and now SwfFix, are just too integrated for my taste, too monolithic. That is not meant to disparage the work that has gone into those projects, those projects are quite mature, well documented, and widely distributed. It’s just tha tI like my code certain way, and have bent over backwards to keep interdependency down in my scripts, in the name of modularity. This was done originally so that the history portion could be used in combination with other SwfEmbed techniques (like SwfObject) and used with other plugins (Ajax came later, but it works for that too!). Examples of that modularity - History Keeper doesn’t rely on SwfHTML, and SwfCommunicator doesn’t rely on SwfHTML, SwfHTML doesn’t rely on FlashPlayerInfo, which as well as Patent Magic don’t rely on anything. A few of the above rely on unFocus.EventManager, but that’s because the subscriber pattern is just so darn useful.

History Keeper would work nicely right along side SwfFix as well. Wouldn’t complain one bit.

Anyway, I just wanted to make a quick (re)introduction to these infrequently mentioned tools, even if they are in a bit of rough shape. For simplicity, I’ll lump them all under the category title SwfHTML (even though SwfCommunicator, or FlashPlayerInfo could all be used without the SwfHTML object pretty easily).

Check it out.

I had a planed to replace the use of Prototype.js in the Share This Wordpress plugin, since that was the only plugin using it. Prototype is quite large, and my server isn’t currently set up to gzip javascript files. I started to replace it with jQuery, and add an option to switch between the two. I figured it’d be a good way to help make the blog load more quickly if I make sure all the plugins were using the same (smaller) JavaScript framework.

I found along the way that Share This doesn’t actually use very much of Prototype.js at all. It does a few id based element queries, and uses Prototype’s Position.cumulativeOffset once. So I just converted the dollar sign based id query with DOM standard getElementById, and replaced the cumulativeOffset method call. Then removed the bits that output a prototype.js header link.

That’s it. No more bulky prototype.js dependency!

You can grab the patch from the WP Plugins trac.

While I was at it, I also added gzip support for the js, css and static share-this page, along with a new flag to turn gzip on and off.

Here’s the gzip support patch.

If you’d rather skip all the patching, here is a prepatched share-this.php archive. To use it, download the Share This plugin, and overwrite share-this.php with the new one (patched against the latest from SVN as of this post date).

I just finished four days of trying to install Adobe CS3, and I thought I’d mention what the problem was (or more accurately, what the solution was, since I’m not entirely sure what the root cause was), in case it will save someone else the trouble.

First let me say, Adobe’s technical support is top notch. They stayed on the phone with me for hours grasping at straws until we hit that magic fix. Kudos to the Adobe tech support.

The problem I was having was one where the installer would go through the initialization screen, then would go away - it would just disappear, and sometimes leave the Setup.exe (not the case) in my processes list. There is a tech note for that problem, which the tech support guys pointed out to me, but that didn’t solve the problem in my case (and I very thoroughly hunted and killed every single everything that has ever been even related to Adobe and Macromedia - and that includes all Flash Players - which is what that tech note is about).

As it turns out, the Adobe setup program relies on Internet Explorer and the installed Flash Player (although it does seem to try to upgrade it). It was frankly a bad idea on the part of the installer engineers at Adobe to rely on this third party - easy to screw up by end users - software, and all the possible points of failure that comes with using that. I suppose, in fairness, if those technologies are not working for the installer, they probably will not work for the applications once they are installed either. Still, because of the nature of this installer failure, it was incredibly difficult to pinpoint the exact cause of the failure. It might have been easier to figure out why, say, Dreamweaver would not start. Maybe in the next installer, if Adobe really wants demonstrate that it eats its own dog food in critical places, they’ll use Adobe Air running in Ubuntu, and cut out the reliance on IE, but I digress.

The solution for me was to uninstall IE 7. The theory is that I either had a beta version still installed from way back when, or that some remnants of that beta were still hanging around. Whatever the case, I uninstalled it, and then, finally, after 4 days, the installer worked. A few other hiccups later (like not being able to choose a different drive if you start the install from the hard drive but want to continue from the DVD with disc 2, ugh), I finally have an installed Adobe CS3 Master Collection! And a day later, I now have all the software I tore out of my system in a desperate attempt to get the installer to work (which is cool in an odd way, since I had quite a bit of garbage on my work machine).

Even though downgrading back to IE 6  fixed this particular problem, I’m still not convinced that was the root cause of the problem. It seems that at some point after I started preparing my computer for CS3, I lost the ability to install updates, and to even install the Flash Player ActiveX control. It just wouldn’t work (I wish I would have noticed that earlier - since it was a huge clue). Even after downgrading to IE 6, it still wouldn’t let me install some Windows update or the Flash Player ActiveX control. I traced that to a problem with registry key permissions, and I have no idea what caused that (probably some program that I uninstalled, is my guess). After jumping through hoops to get IE 7 to install (restarting and installing in Safe Mode finally worked), hoping that would fix the problems with IE - which it didn’t, I used Ramesh Srinivasan’s registry permissions reset guide to finally get things working in IE again (thanks!).

So there it is, if you are having this mysterious problem with the setup disappearing after the initialization window disappears, you might be having a problem with IE7, it’s ability to install Flash and/or problems with registry permissions. I should note, that the problem existed for all CS3 installers, including the trial installers.

For a while I have been creating and sending links to History Keeper to http://www.unfocus.com/projects/HistoryKeeper/. When I moved that page into WordPress the URL became lower case, and case sensitive. This can be a problem for those used to Windows and IIS non-case sensitive URLs. To get around the problem, I added a hack to my 404.php error handler (more on that later) that would detect capitals in the permalink URL, convert it to lowercase, and then forward the user to the new page with a php Location header (http redirect). That seemed like a clunky solution, so I made a WordPress plugin that does pretty much the exact same thing, only it’s in a plugin! So that makes it less clunky. Well whatever.

Here’s the code:

<?php
/*
Plugin Name: unFocus.Insensitivity
Plugin URI: http://www.unfocus.com/projects/
Description: A plugin to make permalinks case insensitive.
Version: 1.0a
Author: Kevin Newman
Author URI: http://www.unfocus.com/projects/
*/
function unFocus_insensitivity() {
	if (preg_match('/[A-Z]/’, $_SERVER['REQUEST_URI'])) {
		$_SERVER['REQUEST_URI'] = strtolower($_SERVER['REQUEST_URI']);
		$_SERVER['PATH_INFO']   = strtolower($_SERVER['PATH_INFO']);
	}
}
add_action(’init’, ‘unFocus_insensitivity’);
?>

Pretty simple really. Honestly, it doesn’t really even need to use a WordPress hook, just the two lines that convert the $_SERVER variables would do it (assuming those aren’t locked down in the php.ini). But I wanted to learn the plugin API anyway. There is an archive download at the end of this post, just unzip the enclosed file, and put it in your plugin directory, upload it and turn it on. No other configuration necessary.

If there is any interest, I was thinking about adding a config option that would allow you to either forward to the all lowercase URL, or to do what it does now, which is to behave pretty much the way IIS does for any other static files it hosts.

Also, if there’s interest, I may try to figure a way to work this WordPress IIS Permalink 404 handler into the plugin, if it’s possible (IIS users would set their custom 404 handler redirect URLs to redirect to /wordpresslocation/index.php instead of /wordpresslocation/404.php, which is how you do it now):

<?php
$_SERVER['REQUEST_URI'] = substr(
	$_SERVER['QUERY_STRING'],
	strpos(
		$_SERVER['QUERY_STRING'],
		‘:80′
	) +3
);
$_SERVER['PATH_INFO'] = $_SERVER['REQUEST_URI'];

include(’index.php’);
?>

The archive - unFocus.Insensitivity

Update: Fixed the download link.

Update: This information applies to Giraffe AJAX Calendar 2.3.1. AJAX Calendar 2.4 was released on September 3, 2007. This information is incompatible with that new version.

Update 2: It seems that this new version is supposed to simply replace the functionality of the old Calendar, without requiring any extra work (so you’d just use the old Calendar Widget, and get the new functionality after the plugin is enabled). So far, I haven’t been able to get the Ajaxy stuff to work, although I can tell that it’s installed, because the calendar is wider in this theme with the new Calendar plugin.

While surfing the web aimlessly, I came across the Urban Giraffe Ajax Calendar plugin for WordPress. It’s not set up to take advantage of WordPress’s built-in Widget support, so I thought I’d add the necessary bits to make it work. Here’s how to do it.

Download the plugin, and add the following code to the bottom of ajax-calendar.php:

function giraffe_ajax_register_widget() {

    if ( !function_exists('register_sidebar_widget') || !function_exists('register_widget_control') )
        return;	register_sidebar_widget('Ajax Calendar', 'ajax_calendar');

}add_action('plugins_loaded', 'giraffe_ajax_register_widget');

Additionally, you can avoid a duplicate prototype.js header link, by replacing these lines:

if ($giraffe_ajax_prototype)
  add_action ('wp_head', 'giraffe_ajax_head');

with these:

if (function_exists('wp_enqueue_script'))
 wp_enqueue_script('prototype');
else if ($giraffe_ajax_prototype)
 add_action ('wp_head', 'giraffe_ajax_head');

You can see it working in my sidebar. And I didn’t even have to modify this theme.

Well, it seems that Object Patent Magic is not without it’s problems. I originally intended for this to be a super tiny drop in patch that could be used on any existing site to solve the click to activate issue in IE. But while it does work on everything that I’ve deployed it with, it doesn’t work on all of everything (like the demo) in IE 6 (IE 7 seems fine). I’m not sure what is causing it, but the problem occurs when you attempt to load a large swf that hasn’t already been cached (meaning the first time someone loads your page).

Just to be sure that there wasn’t some easy solution that I could “borrow” from Karina Steffens, I tested ObjectSwap, and sadly, the problem exists there as well.

There is good news though. I don’t think this problem will turn up much, and the behavior is quite consistent, so it’s easy to test for. To test for it, clear your browser history and cache in IE 6. Then, test load up any pages that use Object Patent Magic or ObjectSwap. If the flash movies loads, you are fine. If you get the space where the movie should load, but it doesn’t load. You’ll have to use a different solution to get around the “click to activate” problem, at least for now.

On the horizon, I do have a new loader swf that I’ve been working on, which could be used to solve this problem. More on that later.

I occasionally come across an argument against the implementation of embedded web fonts in web browsers and I wanted to comment on it.

The argument is that embedding fonts in web pages should not be allowed, because either people don’t have the rights to use fonts that way, or because it’s too easy for users to steal the fonts, or some combination of the two. It’s debilitating for those who hold that position, and they may be missing out on a lot of potential opportunity. Craig Kroeger sells a set of fonts specifically for use in Adobe Flash, and even licensed them for distribution with Adobe Flash CS3. And that’s just for Flash designers. Imagine a market the size of the whole internet.

Without proper web font embedding technology, there are too many hurdles to uses custom type faces on your website. You can use Photoshop created text graphics, and there are some tools to help make using custom typography on the net easier, like sIFR (which relies on the Adobe Flash Player). While these are creative solutions, they are pretty restrictive - limiting the use of fonts to small blocks of text, like headers. They can also be time consuming to set up, and there is no way for web page designers to use these techniques for body copy. So other than some sparse use here and there, web designers don’t even consider using - or licensing - fonts for web sites, and instead stick with the same 10 fonts that most people have on their systems already.

Just as in print, or with photos or body copy, or any other licensable content, it’s on the shoulders of designers to make sure they are abiding by their license agreements. License templates exist that give designers the right to embed fonts in PDFs and other forms of distributable electronic document, and it’s generally well understood that the rights to images found on a web site belong to the owners that web site. When there are violations, friendly notices, or nasty-grams from the layers, seem to do the trick to get things resolved. These same principles undoubtedly apply to embedded fonts, and are no more complicated. Those are the solutions to possible abuse.

If we must though, I would suggest a move to a middle ground, and follow the example of the natural restrictions placed on photos. Since photos are reduced in quality and in size when converted to jpegs, re-use is impractical for high quality output. So browser producers could consider a special, difficult for end users to install font format for embedded web fonts, something based on SVG maybe. This would probably be a good idea for a number of reasons anyway, including smaller file sizes and better cross platform compatibility. Fonts could then be converted and subsetted for use in web pages, in the same way that they are converted and subsetted for use in other web distributable formats, like Adobe Flash, Director, PDF, and Silverlight.

I hope Opera CTO Håkon Wium Lie will stand by his publicly stated desire to see embedded web fonts come to Opera, and that something like that might be the catalyst that gets the other browser makers moving on embedded fonts.

I think the time has long passed for embedded web fonts.

Gah! I’d like to apologize to anyone who received a ping of a very early draft version of this post, or had to suffer through that unfinished thought dump or any of the hurried revisions in between.

I’ll post the finished article in a little while.

I hit the publish button accidentally on my way to click the File menu in Windows Live Writer, and the thing published without warning. Time for a feature request - either warn before posting by default, or move the publish button to a less accident prone location.

Update: I posted the finished article.