Archive for May, 2006
I’ve been working on adding support for a few hours tonight, when I ran into the problem that eval() in ActionScript cannot compute anything. That’s right, the only thing it is good for is for referencing variables! Like we couldn’t do that in a better way already!
Anyhow, I needed eval() so you can configure filters on the client side. Therefore, my own implementation:
private static function eval(str) {
var as;
if(str.charAt(0) == '{') { // Ah, we need to create an object
as = {};
str = str.substring(1, str.length - 1);
var $ = str.split(',');
for(var i = 0; i < $.length; i++) {
var $1 = $[i].split(':');
as[$1[0]] = sIFR.eval($1[1]);
}
} else if(str.charAt(0) == '"') { // String
as = str.substring(1, str.length - 1);
} else if(str == 'true' || str == 'false') { // Boolean
as = str == 'true';
} else { // Integer
as = parseInt(str);
}
return as;
}
Eat that, ActionScript!
Oh, and filters seem to be working. Check out the demo and download the latest nightly. Fun!
P.S. I’m going to be in Copenhagen from Wednesday until Sunday for Reboot. If you’re there, say hi!
Over the past few days I’ve fixed a number of bugs in the code and added some more Flash 8 related features. Here’s a quick post on how to stay up to date. An updated version of the demo distributed with the Alpha release is available.
You can download the latest nightly. The nightlies are similar to the alpha distribution, but you’ll have to re-export the Flash movie and you need to compare the configurations (both in JavaScript as in ActionScript) for changes.
Finally, a list of to-do items for the beta (excluding documentation and testing):
Use
ExternalInterfacewhen possible, instead offscommandHandle font and window resizing
Add a way to change the font style after the movies have rendered
(Test?) support for pixel fonts.
Background images inside the Flash.
Flash 8 filters.
IE focus bug with slow page loading, read more.
Have fun!
sIFR 2.0.5 has been released. Please upgrade to sIFR 2.0.5.
I’ve just released sIFR 2.0.2, which is a maintenance release for the problems caused by the “Eolas patch”. JavaScript changes from version 2.0.1 are:
- Problems due to the Eolas related modifications to IE should be solved. Thanks to Christian Welzel for testing!
- A problem where the CSS class name foo-bar would match foo has been solved.
- Problems where the browser reports an alien user agent (like GoogleBot) have been solved.
- Improper detection of Flash transparency support in OmniWeb 5.1 have been solved.
- You should now be able to export sIFR as Flash 8.
CSS (in sIFR-screen.css) changes are:
* No more object tab obscuring the text when AdBlock is being used.
There is still no insight into what is causing these problems, so please deploy this patch to ensure everyone can see the headlines. You’ll only have to replace the JavaScript file (make sure not to override your configuration) and add a CSS rule for the AdBlock workaround.
sIFR 2.0.5 has been released. Please upgrade to sIFR 2.0.5.
The beta is out! Read more.
It’s high time for a release of the new sIFR version, 3.0. With Inman’s Flash Replacement as the original, sIFR 1.0 making it scalabale and sIFR 2.0 bringing it to the masses, this version will really make things rock. Flash 8 has brought a lot of new, cool stuff. Now you can use these features, starting with way better font anti-aliasing and auto-kerning. You’ll also be able to use filters to do shadow effects (in the nightlies).
For those unfamiliar with sIFR, here’s a short description:
sIFR is meant to replace short passages of plain browser text with text rendered in your typeface of choice, regardless of whether or not your users have that font installed on their systems. It accomplishes this by using a combination of javascript, CSS, and Flash.
Furthermore, it degrades gracefully when Flash is not present or the browser not supported.
For sIFR 3, the code has underwent a complete rewrite, making it easier to use and making it work even better. There also is a new way to render the Flash font. No longer are guesses being made as to how big the font should be, the cues are taken from the font size used in the HTML page and the number of lines the text spans. In order to provide better styling you can now use FlashCSS. No matter how many colors or font styles you want to use, now you can.
Additionally, leading is now supported by sIFR. A number of small issues has been fixed, and you can now pre-fetch the movies for Internet Explorer and Safari. This solves a problem where these browsers would request the same sIFR movie again and again until it was cached – instead of waiting for the first request. Huge bandwidth saver here! And for the AdBlock users, using a little bit of CSS the object tab has been hidden. sIFR is not an ad, and you should see the text itself, without obstruction.
Here’s the full feature list:
A new font sizing algorithm, although it needs some attention with regards to padding and wrapping in the Flash element.
FlashCSS, both configurable in ActionScript and in JavaScript.
Support for Flash 8 movies, for real good looking text.
Font resizing in Opera 7+.
Support for leading
Flash movie pre-fetching for Internet Explorer and Safari.
Easier configuration.
No more object tab obscuring the text when AdBlock is being used.
By the grand tradition of alpha (and open source) releases, this version lacks serious testing, actual documentation and a number of features. None the less, it is functional, as you can see by the demo.
As you are probably anxious to get started, here’s a run-down of deploying sIFR 3. Please note though that this is an Alpha release: if you run a high profile website and you really don’t need the new features, sIFR 2 is best for you. If you like playing around with new tech, please give this version a try. The more real life use, the more improvements can be made.
That’s it for this release. I’ll write more about the beta release in another post. Please give the new Alpha a try and let me know what works and what doesn’t. You can also subscribe to the mailing list. Now, without further ado, to the download!
Barring any suprises from the American Consulate, I’ll be doing a summer internship at JotSpot this July and August (Rock!) California, here I come!
Alex’ flight went haywire, so the meeting is off.
Alex Russell is coming to Amsterdam for XTech, so here’s your chance to drink a beer with the guy! Suggestions for locations are welcomed (I hardly know Amsterdam), suggested time is 20:00.
We’re going for dinner at 18:00 on Monday or whereabouts at Café de Jaren, and onwards with the beer from there.
See you there!
P.S. I’m contemplating going to Ajax day, should I?
While working with Microsoft to fix the mentioned problems with sIFR and the Eolas patch (the security updates for Internet Explorer released on April 11th) I’ve also been working on a patch for sIFR itself. But before I get to that, some updates on the problem:
- Everyone who reported the problem and whom I have asked to verify, is using either Flash MX 2004 or the Flash 8 editor.
- This might mean that the problem is related to the editor being installed
- Or only people with the editor take the trouble to contact me.
- Reinstalling Flash fixes the issue.
- Using
<object>instead of<embed>prevents the issue.
It still is not clear what the exact conditions are for the problem to occur, but most likely it’ll be solved when people update their Flash players… in a few years, that is. Therefore, the patch to sIFR.
This patch, bringing sIFR to version 2.0.2 has the following fixes:
- Problems due to the Eolas related modifications to IE should be solved. Thanks to Christian Welzel for testing!
- A problem where the CSS class name
foo-barwould matchfoohas been solved. - Problems where the browser reports an alien user agent (like
GoogleBot) have been solved. - Improper detection of Flash transparency support in OmniWeb 5.1 have been solved.
- You should now be able to export sIFR as Flash 8.
A test version of the patch is available: Download sIFR 2.0.2 TEST.
Please let me know how this version functions. Nothing should be broken in other browsers, but of course you never know. Once I’ve had enough feedback I’ll officially release the patch.
sIFR 2.0.2 is out now
After Microsoft rolled out their Eolas patch I got a few reports about sIFR not working correctly. As sIFR is a script which creates the Flash movies there shouldn’t be any issues, but unfortunately that is not the case.
There are two problems, one is easy to fix and is the result of extra steps taken in the deployement of sIFR. The other seems to be a system issue, and as such is harder to fix.
First, the easy problem. Using the sIFR code in the page itself causes the sIFR Flash movies to require activation:
You cannot write script elements inline with the main HTML page to load your control externally. If the script is written inline programmatically, for example with the writeln function, the loaded control will behave as if it was loaded by the HTML document itself and will require activation.
Using sIFR inline is not advised at all, nor shown in any demos or documentation, so I don’t expect this to be a problem. However, when the sIFR code is evaluated using eval(), IE thinks the code is inline. This causes the need for activation. sIFR is not distributed with eval() evaluation of it’s source code, so if you are using a version which is, please dowload and use the official release.
Testcases for this problem are available.
The other problem is that, for some users, the patch broke sIFR rendering for both the 2.0 version as the sIFR 3 demo. Instead of showing the Flash text, a non-loaded image icon would be shown. I do not know what causes this issue, but I’m in contact with Microsoft about it. I cannot replicate the problem myself, but there have been six reports. If you see this problem, please contact me with the following information about your system: OS, Flash version, used Flash versions in the past, installed IE 7 betas, installed Eolas-patches (aside from the one rolled out in Windows Update).
I have heard that reinstalling the Flash Player fixes the issue. However, I would greatly appreciate it if you could hold off on doing this until Microsoft has more insight in what is causing the problem. Thanks!
Plazes is an extremely cool location awareness service. Recently the first version of the Plazes API was released. Together with the Launcher and WhereAmI APIs there now are three public APIs for the service. As a hobby project I’ve updated the RubyForPlazes project, run by Peter Rukavina, to work with the new API. The new version hasn’t officially been announced yet, as there is still some work to do with regards to testing and examples, but it is already in the repository at Peter’s site. During the development of the new Ruby implementation I’ve run across a number of issues with the API design, which are documented in this article.
Please note that the properties referred to below are as used in the Ruby implementation, not necessarily the Plazes APIs.
Plaze? What Plaze?
One problem is that all three APIs return different information about a Plaze, and with different property names for equal values. The data returned by all APIs, with normalized names:
- key: Identifier for the Plaze
- name: Name of the Plaze
- city: City where the Plaze is located
- country: Country where the Plaze is located
- latitude: Latitude for the Plaze
- longitude: Longitude for the Plaze
- url: URL for the Plaze on Plazes.com
The WhereAmI API doesn’t return more information than this. Actually, it returns even less. The Plaze key is not returned, but it is part of the URL.
The Launcher API returns:
- timezone: Plaze timezone
- feed_url: URL to the RSS2 feed for this Plaze
And finally, the Plazes API:
- street: User entered address for this plaze. Includes street number or other address parts when applicable
- state: User entered US or Australian state for this plaze
- zip: User entered ZIP code for this plaze
- blog_url: User entered URL for this plaze, can be empty
I’d love to see the timezone and feed_url added to the Plazes API. feed_url by itself isn’t enough, as it returns an RSS 2.0 feed while RSS 1.0 and Atom 0.3 (which is deprecated) are available as well. The feed URIs are predictable, though, and the Ruby implementation supports this. And while it is annoying that the property names differ between APIs, it is easy to abstract this away.
Users
User information is slightly different between the three APIs as well. You could say there is a base user, which has:
- key: Identification key of the user on Plazes.com
- name: Name of this user.
This is the minimum of user information returned by the plaze.comments and plaze.photos methods of the Plazes API. The base user is an abstraction, though. The mentioned methods return the values as user_key and user_name properties on the general result.
Then there is a normal user, returned by the plaze.people method of the Plazes API and which properties are shared by the other methods described below:
- thumbnail_url: URL to a thumbnail picture of the user on plazes.com. Always set, can point to a dummy image
- url: URL to the users profile page on plazes.com
- blog_url: URL the user entered as her blog, can be empty
- message_url: URL on plazes.com where internal messages can be sent to that user
user.friends returns:
- plaze: The current plaze of the friend. Only available if the friend is online.
- distance: The distance of the friend to your current plaze. Only available if the friend is online.
Note: The actual result from the API contains a normal user, a Plaze and the distance. Since the distance and Plaze are properties of the friend I’ve implemented the result as one object.
Finally, the Launcher API has a plazes.buddies method which returns a normal user and it’s vicinity to your location.
It’d be great if the result from plaze.people is the same as the result from user.friends, especially with the distance. An online property would be handy too, currently this has to be inferred from the presence of other properties and the way the user object is requested. The plazes.buddies method could return the same information and drop the vicinity, as this can be derived from the distance. In fact, since the Launcher API requires a special API key, this is what’s done in the Ruby implementation already. Furthermore, there should be a user.info method which returns this information for a given user key.
Other data types
There are other data types available in the APIs, which have a good definition. I won’t go into detail about these types but you can find them in the Ruby implementation.
Concluding
The Plazes APIs need some clean-up, especially when it comes to plaze and user information. The API results refer to abstract structs, such as the user and plaze struct, instead of extending from them. Extending makes more sense when you are using the API.
It would be useful if the next version of the Plazes API would supersede all three existing APIs. An updated Launcher API would be welcome as well, looking at the recent Plazer apps it can be concluded that this API already exists, but is private.