Hi random Stackoverflow visitor- Thanks for reading my question!
Here is a minimal page that demonstrates my problem: http://lisperati.com/text_bug/text_bug.html
If you visit that page with Chrome/Chromium it will calculate the width of a div containing text, both immediately and after 1 second. On my machines I get two very different answers as to the width. Any chance you know the reason for why these two width calculations give different results?
My uneducated guess is that there is some weird delay in rendering font-face items, either because of the delay for loading the file or otherwise (Though my tests show evidence that this problem is not related to fetching the font file) As a rule, my understanding is that dynamic elements inserted into the DOM will be correctly laid out as soon as the insertion is complete and control is returned to the javascript code.
More important for me than understanding "why" this happens is to understand how to properly adjust for this issue. As you probably know, IMG elements have an "onload" event that can be used to find accurate dimensions of an image after it has been loaded. Is there some similar event that can be used for when a font-face element has been fully laid out, in order to adjust for this issue? Do you have any other advice for how to get an accurate width of an element styled with font-face without simply having an arbitrary 1 second delay?
Thanks so much for any tips on this glitch that's holding up my work, fellow StackOverflow reader!
BTW- I asked a related question recently (http://stackoverflow.com/questions/4636079) but have narrowed down the issue much more, leading to this new, more specific question.
Have you tried document.ready, window onload?
Also if it's related to refresh (F5) then it looks like a network issue, because a rendering issue would cause problems on every page load.
This is definitely a problem and it can't be solved with Google's font loader
http://code.google.com/apis/webfonts/docs/webfont_loader.html
Because it doesn't work in Safari. It would be nice to figure out why, because at the moment there seems to be no accurate way of reading a container's width and height when combined with @font-face other than adding a delay after the document.ready event. But adding a delay is still guessing and is ultimately a bad solution.
I found out a partial answer by doing some more research...
The key here is to figure out when a font-face font is %100 percent active and loaded before creating the dynamic elements and checking their width. One way to do this that seems to work well is to use the Google Webfont Loader (http://code.google.com/apis/webfonts/docs/webfont_loader.html) and to place the dynamic generation code in the "fontactive" event. When done in that way it appears the text width is reliably correct in any browsers I have every time, without an arbitrary delay.
I have not found a way to do this without this font loader (though of course it must be possible, since the font loader is just a javascript library)
Had the same issue, was going nuts trying to figure out why my div width values were off. Google font loader did the trick, just called all my div measuring functions after the loader's "fontactive" event popped. Worked perfect.
Had also the same issue.Tested the Google Webfont Loader like previous posters mentioned.
But i found 2 issues:
- Kinda irritating that it needs to wait until the font is loaded cause
it causing a "poping/jumping" when you load the page and do the
font-switch.
- It worked on every browser (Latest Chrome, Firefox, IE9, Opera) except Safari. Don't know why.
