sIFR 3 r436, thoughts on font embedding, presentations

posted October 29th, 2008, 45 comments, tagged ,

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:

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!

45 responses

  1. Erwin Heiser says:
    October 30, 2008 at 18:19

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

  2. Mark Wubben says:
    October 30, 2008 at 22:43

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

  3. Jarkko Laine says:
    October 31, 2008 at 08:37

    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.

  4. Brenley Dueck says:
    November 4, 2008 at 21:21

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

  5. Bruno says:
    November 5, 2008 at 12:11

    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!

  6. Bruno says:
    November 5, 2008 at 14:52

    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?

  7. Mark Wubben says:
    November 5, 2008 at 17:22

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

  8. Prem Prakash says:
    November 17, 2008 at 16:09

    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.

  9. Mark Wubben says:
    November 17, 2008 at 16:58

    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.

  10. Shane Kramer says:
    November 23, 2008 at 14:57

    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

  11. Mark Wubben says:
    November 25, 2008 at 20:50

    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.

  12. Mike D. says:
    November 25, 2008 at 21:07

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

  13. David T. says:
    December 8, 2008 at 16:52

    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?

  14. Mark Wubben says:
    December 8, 2008 at 20:37

    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.

  15. Giedrius Kudzinskas says:
    December 18, 2008 at 12:20

    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

  16. Cory Mawhorter says:
    December 18, 2008 at 22:24

    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?

  17. Mark Wubben says:
    December 22, 2008 at 10:29

    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?

  18. Cory says:
    December 23, 2008 at 21:13

    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.

  19. Dino Seelig says:
    December 30, 2008 at 11:47

    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

  20. Erin says:
    December 30, 2008 at 18:59

    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?

  21. Mark Wubben says:
    January 1, 2009 at 20:33

    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?

  22. Bobbink - 11 Internet says:
    January 5, 2009 at 10:07

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

  23. George says:
    January 14, 2009 at 10: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?

  24. Mark Wubben says:
    January 15, 2009 at 22:42

    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.

  25. Rune Skjoldborg Madsen says:
    May 22, 2009 at 17:28

    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

  26. Mark Wubben says:
    May 23, 2009 at 14:13

    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.

  27. Jerome says:
    July 9, 2009 at 23:19

    Thank you for putting all that work into this. I still have a problem though. I managed to get sIFR3 working the way I want it to. However, whenever I try to inspect the page through Firebug in FF 3.5, the sIFR text disappears and reverts to the browser text. It doesn’t seem to be an issue with Firebug in FF 3.5, as the official sIFR3 demo page works fine with Firebug. I did notice that one of the sample sites for sIFR3 has the same behavior. The site http://lightweb.pl does the same thing.

    To reproduce: 1. Open http://lightweb.pl 2. Open up Firebug and do either: a. Click on the inspect button, and hover over the page, or b. Open up the HTML tree and click on an element to target it.

    The headlines for the site will switch.

    Thank you

  28. Mark Wubben says:
    July 10, 2009 at 21:36

    That’s odd! Try loading the sifr.css file from r436, it’s a bit different from the files you’re loading currently. If the problem persists try narrowing it down by removing as much HTML and CSS as possible. And of course there’s always the possibility that this is a Firebug bug.

  29. Emir says:
    July 23, 2009 at 13:09

    First of all, thank you for all these good news. However, I have an issue with the new release 436.

    I cannot give a style to my links in r436’s sifr-config.js like that as I did before in old versions:

    sIFR.replace(MyFont, { selector: ‘h2’ ,css: [ ‘.sIFR-root { font-size: 24px; color: #003366; }’ ,’a { text-align:center; text-decoration:none; }’ ,’a:link { color: #000000; }’ ,’a:hover { color: #333333; }’ ] ,wmode: ‘transparent’ });

    If I write this code in r436’s sifr-config.js nothing is viewed in my browser. How can I give a style to my links in the newest release?

    Thanks, Emir.

  30. Mark Wubben says:
    July 23, 2009 at 21:56

    Nothing has changed that would influence that, so I suspect it’s something else. Don’t immediately see anything wrong with the syntax though, aside perhaps from using a:link rather than a.

  31. Alex says:
    July 27, 2009 at 10:58

    I’m having an issue with sifr placed next to a floated img, Opera 9.6 is forcing the text to clear the image and display on one line. Firefox is also forcing the text to clear the first time the page is loaded, although a refresh fix’s this and the problem will never occur again, only to return if cache is cleared and the browser restarted.

    Also strangley with firefox, if the bug occurs and then i load up firebug, this shoots the text up to the correct position inline with the image, very strange as i did not think firebug caused the dom to reload.

  32. Mark Wubben says:
    July 27, 2009 at 20:57

    Hey Alex, if you could post at Stack Overflow that’d be awesome. I have a good answer for you but I’d prefer to share it at a spot where it’s easier to find. Thanks.

  33. Alex says:
    July 29, 2009 at 10:19

    Hey Mark, thanks for the respone, i have posted the issue to Stack Overflow, you can find it here:

    http://stackoverflow.com/questions/1199186/sifr-3-r436-opera-firefox-float-issue

  34. Anders Gressli says:
    August 7, 2009 at 22:04

    Hi!

    I have a little problem. I want to use Helvetica Neue 75 Bold in sIFR, but I can’t manage to make a working sifr-file. It works perfectly with Helvetica Neue Ultra Light, and Black, but not Bold. I guess it is because bold is an option in css, and so on, but I’ve tried that. I also tried to convert it to ttf, and then export it via sIFR Generator. but then the font got a cut in the top. I tried several times, and several fonts, and it happend on all. It never happens when I make the sifr-file from flash.

    I’ve also tried Coffeecup sIFR Font Maker, but because they haven’t updated they’re programme (it doesn’t support the r436), i don’t want to use that either.

    any solution?

    is there a way to make Helvetica Neue 75 Bold as a “normal” font and not as a font-weight?

  35. Mark Wubben says:
    August 8, 2009 at 18:15

    Hi Anders, if you could ask at Stack Overflow that’d be grand.

  36. Aaron says:
    August 14, 2009 at 13:48

    Hi,

    I’m using an OTF font, DIN-Medium to be exact, and I can’t seem to get it to work properly. If I use a font generator I get a mess of Characters and if I use Flash Pro to create the file, I get a message ( in the correct font ) that says “Please update the Flash movie to version 436” I’m using version 436 obliviously. Any suggestions on what is going on or how to fix it?

    Thanks.

    Aaron

  37. Mark Wubben says:
    August 16, 2009 at 13:18

    Hi Aaron, the JavaScript and Flash movie need to be based off the same sIFR version. In your case it looks like you’re using r436 for the JavaScript, but the generated Flash movie is not based on r436.

  38. Már says:
    August 19, 2009 at 11:40

    Hi. I’ve run into problems with sIFR’s use of document.write(), and made a quick pass at replacing it with proper DOM methods.

    Here’s the .diff for /js/source/sifr.js:

    601c601,604

    < document.write('');

    > var script = document.createElement('script'); > script.type = 'sifr/prefetch'; > script.src = args[i].src; > document.getElementsByTagName('head')[0].appendChild(script);

  39. Már says:
    August 19, 2009 at 11:43

    ok, your content filter stripped out most of the document.write string… but you’ll know where to look (line #601 :)

  40. Mark Wubben says:
    August 19, 2009 at 11:57

    The DOM method can cause IE to stop loading the page, hence the document.write(). What problems are you running into?

  41. Takashi says:
    August 23, 2009 at 18:07

    Hello, I would like to override setting that already defined with selecting parent selector but I don’t know how. Say, there are 2 pages on a website like the following…

    -Home page-

    Home

    -About page-

    About

    then, I have these in sirf-config.js…

    sIFR.replace(fontname, { selector: ‘h1.sifr’, css: ‘.sIFR-root { color: #666666; font-size:29px; }’ });

    sIFR.replace(fontname, { selector: ‘body.about h1.sifr’, css: ‘.sIFR-root { color: #FFFFFF; font-size:29px; }’ });

    but it doesn’t work… If you can help me how I should do to achieve this, I would really appreciated.

    Thanks in advance.

  42. Mark Wubben says:
    August 23, 2009 at 20:05

    Takashi, if you could post the question to Stack Overflow that’d be grand.

  43. Takashi says:
    August 23, 2009 at 21:43

    Thank you for your responce, I have post the question at StackOverflow and if you guide me I would really appreciate. Thank you.

    http://stackoverflow.com/questions/1319634/sifr3-is-it-possible-to-override-css-styling-with-parent-selector

  44. Scott Reed says:
    September 29, 2009 at 13:58

    Please update the Flash movie to version 436 – I am getting this message in both IE and FF. The same issue was raised in an earlier post but the response was that the Flash and Javascript versions must be different. That is not the case. They are both from the r436 download. The demo works fine as-is, but when the swf is published through the Flash CS3 IDE, it displays this error. When republished through the Flash 8 IDE, it again works fine.

  45. Mark Wubben says:
    September 30, 2009 at 20:30

    Hi Scott, that sounds really odd. You could try and open the Flash movie directly in your browser to see if it’s r436. Also try and double-check the JavaScript you’re using. For further discussion, it’d be great if you could post to Stack Overflow instead.