Novemberborn, Straight lines circle sometime

sIFR 3 r436, thoughts on font embedding, presentations

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:

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

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:

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!

link | sifr3 | 29 October 2008, 22:25

Comments

  1. I’d love to check out the PDF, but keep getting a file error… Great work on the new version of SIFR!

    Erwin Heiser | 30 October 2008, 19:19 | link

  2. Erwin, that’s odd. Put it at a different address, should work now.

    Mark Wubben | 30 October 2008, 23:43 | link

  3. I can see the merits of EOT but I fail to see how supporting it would be adversarial with the existing embedding support in other browsers. There are already quite a bunch of fonts (both free and not) that explicitly allow web embedding. If someone shares a font that does not allow it, that’s their problem, not the browser’s. They can already share the font via downloading, it’s just that IE isn’t able to embed the font on the pages it displays.

    I think this thing has been dragging on long enough that since we now have a working solution, why not use it. I think it’s wrong to punish web designers (and creators of free fonts that want more exposure) in favor of corporations (or individuals) that stubbornly stick to the old models. I feel this defensiveness is just pushing IE further down to the periphery.

    Jarkko Laine | 31 October 2008, 09:37 | link

  4. Good Article on sIFR. I have to say that sIFR does have the advantage of selectable text in which FLIR does not.

    Brenley Dueck | 4 November 2008, 22:21 | link

  5. I’m having some problem with the visibility on selectors. When javascript is disabled (or even when running the page at localhost) the text is not showing on the default font. So I tried to “force” ‘visibility: visible” on the global stylesheet for thoose selectors, and that would work fine on firefox and safari, but will fail on both IE’s (6 and 7)… any idea of how to solve this?

    I’ve tried to deal with that directly on sifr_screen.css classes but without success.

    Thanks on advance!

    Bruno | 5 November 2008, 13:11 | link

  6. Sorry on my last post I was failing one of the css selector’s.. altough the flash isn’t appearing on both IE’s…everything is ok on firefox and safari, but the flash replacement isn’t happening on IE, any idea of what might be going on?

    Bruno | 5 November 2008, 15:52 | link

  7. Hi Bruno, that’d be a question for the forum. Make sure to add a link to an example page.

    Mark Wubben | 5 November 2008, 18:22 | link

  8. Mark, thanks for the update and your views on the developments about cross-browser font embedding. It does make it clear that in the present times sIFR is the best alternate available.

    One issue that I am facing with release r436 is that the sIFR is just not working in Opera Version 9.50 Build 10063 Platform Win32. I tried opening the demo .html files provided in the download but sIFR is not working at all.

    The sifr (r436) is working fine in IE6, IE7, FF2, Safari 3.1.2 and Chrome.

    Prem Prakash | 17 November 2008, 17:09 | link

  9. Hi Pram. sIFR 3 supports Opera 9.61 and up. This is what I referred to here:

    Now supporting Opera! Playing it safe with Opera 9.61, but there is not much reason to be using older versions.

    Mark Wubben | 17 November 2008, 17:58 | link

  10. Mark,

    First thanks for collaborating and delivering to us a solution to a problem that should never have existed in the first place. You really have given developers a ton of aesthetic freedom with your application.

    I am however, having a devil of a time implementing line-height parameters in sifr.css or sifr-config.jss. I am running sifr (r436) on Firefox 2.0.0.18 and on IE 6. It doesn’t seem that I can do anything to adjust the spacing. I read through various posts on your wiki about how the line-height etc is rendered. The site I am working on is Doogle Letters . I am presently in Afghanistan and wanted a way for my daughter to view random thoughts I have about her over here. I decided to go with a low-fi implementation to give it a more personal feel. The font used is actually my own handwriting. The problem I am having is when I attempt to line up my text on the guide lines of the paper.

    Again thanks for the app. I would appreciate any guidance on the matter. If not I will eventually figure it out.

    Shane Kramer

    Shane Kramer | 23 November 2008, 15:57 | link

  11. Hi Shane. Flash approaches line height differently, naming it ‘leading’. You can configure the leading by setting it as a property for .sIFR-root. It only takes a number (positive or negative), no unit.

    Mark Wubben | 25 November 2008, 21:50 | link

  12. I cast my vote for releasing sIFR 3 at this point. :)

    Mike D. | 25 November 2008, 22:07 | link

  13. I just noticed the following problem: When i visit my companies website (http://www.deherenvan.nl) in Google Analytics’ Site Overlay (an easy way to visibly see the amount of clicks from all the links on your page), the sIFR links are not visible. Which means that Site Overlay doesn’t recognize sIFR links as a normal text links. When i look at Google’s Help pages (http://www.google.com/support/googleanalytics/bin/answer.py?hl=en&answer=66982) the only reason for this ‘bug’ is that they claim Flash links can not be displayed. Fortunately the sIFR links are still visible in the real statistics but not in this little feature called “Site Overlay”.

    Anyone else who had this problem before? Or is there a solution?

    David T. | 8 December 2008, 17:52 | link

  14. David, I guess the Site Overlay feature hooks on to actual HTML links in the page, which get replaced by sIFR. If you can reverse engineer the Google code, you could manually log the clicks using a callback from within sIFR, but that’s perhaps a bit too much effort.

    Mark Wubben | 8 December 2008, 21:37 | link

  15. Hi guys!

    Looking around for line-height solutions, I cant seem to find anything solid explaining how it can be achived….can anyone help? I’m using sifr3-r436….

    cheers

    Giedrius Kudzinskas | 18 December 2008, 13:20 | link

  16. Mark— Thanks for the facelift mention! You’re speaking the truth… these are all horrible, horrible hacks. I don’t see any of them disappearing anytime soon, though…

    IMHO, CSS font-face is severely flawed and even if it gets fixed, you will still be left with the rendering discrepancies brought on by different operating systems and hacks like sIFR, and alternatives to sIFR ;) such as facelift and typeface.js will continue to be necessary.

    I really think that of the three systems… typeface.js is the most promising. The one problem it has, is that you must embed the font in the page and then you have copyright issues.

    The real thing that is holding back fonts on the web is the font creators and their RIAA style of thinking. They need to start looking at websites as another revenue stream and come up with an affordable licensing solution instead of looking at it as another avenue for piracy. And I’ve just gotten off-topic…

    Anyway… Thanks for sIFR and also for the cool new feature that lets you select/highlight the header and the text on the page around it. Very cool! How did you manage that?

    Cory Mawhorter | 18 December 2008, 23:24 | link

  17. Giedrius, in Flash, line-height is defined through the ‘leading’ property. You can specify this in the CSS for .sIFR-root.

    Cory, thanks for dropping by. Typeface.js is promising, but it works by doing a custom implementation of the font rendering, which sounds a bit too crazy for my tastes. And I don’t know anything about a new text highlighting feature… which browser are you using?

    Mark Wubben | 22 December 2008, 11:29 | link

  18. Hmmm… I was using FF3. I started by selecting the plain text above the sIFR item and dragged below to the plaintext paragraphs. The text was accurately selected even in the sIFR item and then copied as expected.

    Oh well… looked good anyway. Here’s to being able to stop developing these tools sometime soon.

    Cory | 23 December 2008, 22:13 | link

  19. Using coffeeCup sIFR font maker, a ttf font is transformed into a swf font. when i use this font in sifr3 beta 2 the text is not rendered, but in the style of the font i get the following message: please update the flasmovie to version 436

    The message is unclear for me, can you explain how i can fix this issue.

    With kind regards

    Dino Seelig | 30 December 2008, 12:47 | link

  20. I’m actually having crashes in the latest build of Opera- if I wait for the page to load completely and then scroll, nothing goes wrong (99% of the time) but if I don’t wait and just start scrolling, it locks up and crashes. Any tips?

    Erin | 30 December 2008, 19:59 | link

  21. Dino, I assume you’re using r436, rather than beta 2? CoffeeCup creates a Flash movie with r419, I believe. You’ll have to use the JavaScript from r419 in order to use that CoffeeCup movie.

    Erin, which build is that?

    Mark Wubben | 1 January 2009, 21:33 | link

  22. Thanks for sharing! It is working great and I will definetely use it on some of my weblogs!

    Bobbink - 11 Internet | 5 January 2009, 11:07 | link

  23. One thing I’ve always wondered about is why you have to set up color declarations (and other styles) for sIFR. The colors (or other styles) should automatically be determined by the style of the fallback headings, with the option of being able to override this by adding the colors (and other style) to the sIFR config.

    This would make it a lot faster/easier to set up sIFR, without needing to do twice the work to set up the style of the headings both in the CSS and in the sIFR config.

    Is there any reason this hasn’t been done?

    George | 14 January 2009, 11:23 | link

  24. Hi George, the problem is that there are a few custom CSS properties used by sIFR, that are translated to Flash properties. There’s also the issue of finding the CSS rules for nested elements. Because of this I believe its better to not support any type of CSS ‘inheritance’ out of the box.

    That said, you can specify a modifyCss method as an argument to sIFR.replace(), which can be used to extract CSS from the page. So it’s definitely possible – to a degree, but simply not included in sIFR itself.

    Mark Wubben | 15 January 2009, 23:42 | link

  25. Hey. Just a quickie… In all of your documentation you write this code when explaining how to implement sIFR 3:

    var futura = { src: ‘/path/to/futura.swf’ };

    I sat for 3 hours trying to find out what I did wrong. The problem was that the first / will make sIFR fail. But when you as a new user look at the code, you expect to do this:

    var futura = { src: ‘/myFolder/futura.swf’ };

    When you really have to do this:

    var futura = { src: ‘myFolder/futura.swf’ }; //without the first slash

    I would really recommend you to write the line like this in your documentation:

    var futura = { src: ‘path/to/futura.swf’ };¨

    Thanks - Rune

    Rune Skjoldborg Madsen | 22 May 2009, 18:28 | link

  26. URLs with the starting slash are absolute URLs, relative to the domain name. This is usually recommended so the URLs work in all pages on your website. I assume in your case you had example.com/mysite/myfolder/futura.swf, with sIFR being used in example.com/mysite/. In this case the URL should be /mysite/myfolder/futura.swf.

    Mark Wubben | 23 May 2009, 15:13 | link

Leave your comment

Please keep it polite and on topic. Yes, your e-mail address is required, but it's kept private. HTML is not allowed in the comments but you can use Markdown. Non-contributing comments run the risk of being removed. Especially if the website seem “fishy”. Spammers, beware.

(required)
(required, kept private)
(optional, but let's share it!)
(required)

Remember my details

Novemberborn: Extra

About the author

Mark Wubben is a European Dutchman and web hacker, based in Copenhagen, Denmark. Supercollider is Mark's freelance alter-ego.

Read more about Mark...

Go to

Jobs (NL)

Xopus zoekt programmeurs! Verbeter de code en win!

Please donate

If you like sIFR, please consider making a donation so I can spend more time on it. Thank you.

sIFR Documentation

See the documentation for sIFR 2 and sIFR 3.

Subscribe