Archive for October, 2008

Over the past few days I’ve been making some improvements to sIFR 3, resulting in r436. A quick overview of the important changes since r372:

• Now supporting Opera! Playing it safe with Opera 9.61, but there is not much reason to be using older versions.
• sIFR.prefetch() has been merged with sIFR.activate().
• sIFR.callbacks() has been renamed to sIFR.replacements.
• Now using ExternalInterface for Flash – JavaScript communication.
• Improved whitespace filtering before passing on the content HTML to Flash.
• Improved CSS Load detection, which is disabled by default, but helps in making sIFR replace elements faster in Safari and Opera.
• Changed how browser and Flash versions are stored in the sIFR.ua object. Please consult the changelog for r408 for full details.
• Imitating SWFObject behaviour for inserting Flash movies.

Changes since r419 (which saw close to 12.000 downloads):

• Made some improvements to decrease the jumpiness on the page caused by the replacements.
• Dramatically simplified font size calculation, making it more accurate in Internet Explorer, and removing potential issues with IE 8. This also removes the need for specifying line-height: 1em for the elements being replaced.
• Fixed 2 pixel cut-off from the leading property (caused by Flash).
• Fixed ratio calculation when leading is specified. The leading is now removed before doing any ratio calculations.
• Enabled Flash transparency on Linux with Flash 10, Gecko 1.9 and Opera.
• Font size of nested HTML elements can now be configured in pixels.
• Merged sIFR-screen.css and sIFR-print.css into sifr.css, using the @media attribute to distinguish the media types.

There’s still a number of issues left to figure out, although so far I haven’t had any reports of these issues impacting users. For example, I still have questions about how browsers handle Flash movies that are outside of the viewport, I’d like to see if CSS Load detection could be improved, and what’s up with cross-domain Flash movies. These issues all need extensive research and browser testing.

As always, you can get the latest release from the nightlies.

Other useful links:

• sIFR 3 demo.
• Downloads.
• Nightlies RSS feed.
• Twitter.
• Announce mailing list.
• Development mailing list.
• Stack Overflow.
• Documentation Wiki.

These past few months have seen some interesting new developments. Most important of course is the support for Font Linking in Safari 3.1, as well as the upcoming Firefox 3.1 and Opera 10. Finally it’s becoming possible to embed existing fonts on websites, without going through hacks like sIFR or image generation. That said, the current problem with Font Linking is the required redistribution of original font files to web browsers, forbidden by many font licenses. This leaves many typefaces unavailable for embedding. Furthermore, Chris Wilson of Microsoft expressed that Microsoft (and, by proxy, Internet Explorer) should not support Font Linking in it’s current form. Microsoft does have its own EOT format, which it has proposed to the W3C for standardization, and would solve these issues. Mozilla, Apple and Opera however seem opposed to it, mostly out of fears for DRM. I believe these fears are unfounded, for if EOT is DRM, it’s DRM applied by the licensee, not the licensor. It’s like getting an MP3 from Apple and putting DRM on it before you pass it to a friend, instead of getting DRM from Apple preventing you from passing it to a friend. If we want cross-browser, legal font embedding in the short term, EOT is the way to go.

While we wait for cross-browser font embedding, we’re stuck with the alternative hacks. Some new ones have come up recently. FaceLift now seems to be the best way to use images rather than Flash for displaying the font. It uses server-side image generation through PHP, and cleverly provides a hosted service. In the past week Typeface.js came out, which is a devilishly smart way of actually rendering a typeface using <canvas> or VML, though given the complexity of that problem, Typeface.js probably isn’t ready yet for prime-time.

I’d like to point out that these solutions shouldn’t be seen as much as alternative to sIFR – no matter how eager they are to market themselves as such – but as alternative solutions for the real problem: reliable cross-browser font embedding. We’re merely trying to provide the best hack-that-shouldn’t-be-necessary.

That said, I do think that sIFR 3 provides a better solution in being completely client-side, providing actual selectable text, and supporting a subset of HTML and CSS rendering.

I’ve done a few sIFR presentations and workshops in the past few months, most recently at the <head> web conference. Slides are on Slideshare, however the footnotes have gotten lost in an JSON encoding mishap on their end. Therefore, I’ve put up a PDF with notes (17.3 MB). I’m speaking at DrupalCamp CPH, which takes place November 15th and 16th here in Copenhagen.

If you’re interested in a sIFR workshop at your company, or are looking for a weathered web hacker, please get in touch via Supercollider, my freelance alter-ego.

Now, go try out r436, and report back your findings!