I use this technique to great effect, and i would recommend this. Woff i very well supported generally, and then i put a backup to the actual file for the lagging browsers.
There are several hacks. Almost all of them rely on using JavaScript to make a XMLHttpRequest to retrieve font data. This will force the browser to load the fonts earlier by working around the normal @font-face loading mechanism.
Because you already have the font data in JavaScript you can then also store the fonts in localStorage. This way you can avoid making a request for them on the next page load.
I'm generally against this idea because you're basically reimplementing the browsers' caching mechanism. The CSS Font Loading API (http://www.w3.org/TR/css-font-loading/) will let you do this in a much nicer way and it already has pretty decent browser support (Chrome, Opera and Firefox beta).
Yeah, I've looked into this in the past. In fact, it was exactly a year ago that I tweeted that Chrome doesn't support hyphenation. Had to double check today to see if it were still true.
In fact, it seems even more important now that they have Chrome on tablets and phones (this was announced one year ago as well, incidentally).
As mentioned above, Knuth's algorithms are implemented in many professional typesetting and layout applications. I think the people implementing those applications have great respect for Knuth (and Plass.)
My impression is that the users of those programs are unfamiliar with the algorithms used, so I think it is the latter.
Awesome, thanks! I foolishly forgot to see if there were siblings to my post. (I try and keep a handle on discussions I'm in with the "threads" link.) So, yeah, apologies for missing those posts.
I'm not totally sure, but I think the linear time papers I've read sacrifice some of the aspects of the original Knuth and Plass algorithm. I think some of those are going to be necessary to properly implement the Knuth and Plass algorithm in browser (also, floats are going to be interesting.)
The performance isn't actually that bad, I can perform line breaking in JavaScript on some very large documents, with the only performance bottleneck being DOM node creation (which native implementations won't suffer from.) If necessary the linebreaking could also be done incrementally, with a first first-fit pass and then the Knuth and Plass algorithm.
I could be mistaken, but I'm fairly certain Internet Explorer implements the Knuth and Plass algorithm when using `text-justify: newspaper`. Unfortunately, I can't check because it isn't open source. The output however is pretty much identical to what my JavaScript version generates, so I'm inclined to believe it is the Knuth and Plass algorithm.
I'm really excited about this. While it is not the Knuth and Plass algorithm, it takes one of the nice features of it and proposes a simple algorithm to implement it. Implementing it should only be a minor adjustment to the text layout algorithms of browser rendering engines, and if implemented correctly it should not cause any reflows, only a repaint.
Author of the JS implementation here. Let me know if you have any questions about the implementation or problems integrating it. I was hoping someone would pick it up and integrate it with Readability-like service. (I've slowly been working to add support for it to Treesaver http://www.treesaverjs.com/.)
For hyphenation you might also want to check out my Hypher project (https://github.com/bramstein/Hypher) which is a minimal hyphenation engine written in JavaScript. In my benchmarks it is about 4 times faster than Hyphenator.js (and a lot smaller.)
