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).
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.
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.)
It is quite small and fast, and mostly aimed at integration with other libraries, unlike Hyphenator.js (which comes with a partial DOM library.) An example integration can be seen in the Treesaver library (https://github.com/bramstein/treesaver/tree/hyphenation) where it is used to hyphenate magazine columns.
I had a look at the problem and it seems to be related to the page transition animations (the amount of flicker seems corresponds to the animation steps.) I've created a ticket for this issue: https://github.com/Treesaver/treesaver/issues/issue/148
I would also highly recommend "Digital Typography" by Knuth. It contains a more detailed description of the algorithm as well as many interesting historical and technical chapters on TeX, MetaFont and computer typesetting in general.
As far as I know, this is the only implementation in JavaScript. It might be possible to turn this into a jQuery plugin at some point, but there are probably quite a couple of bugfixes and changes needed to turn this from a tech demo into a drop-in plugin.
Internet Explorer actually has this through the (almost standardized) text-justify CSS property. It still doesn't do hyphenation, but Hyphenator.js (http://code.google.com/p/hyphenator/) fills that gap pretty nicely.
Performance isn't a good argument in my opinion. The algorithm isn't that expensive. The most expensive part right now is retrieving all the text metrics, but you would get that a lot cheaper in the browsers rendering engine.
I briefly looked at hacking it into Webkit, but then gave up due to a lack of time.
I have the same Chrome version, but I'm running Ubuntu. Perhaps it is a font issue. I will check it out later when I have access to a Mac. Thanks for reporting.
You probably could get it working, but the implementation isn't (yet) capable of dealing with arbitrary HTML. It only expects paragraphs and images. This is only a matter of implementation though, the core algorithm should be able to deal with most of the content found on websites.
I'm talking to Filipe Fortes of Treesaver about implementing it as part of his Treesaver technology (demo: http://treesaver.publicintegrity.org/smoke_screen) Perhaps a general implementation will roll out of that.
I honestly hadn't thought about printing it out yet. I had a quick look, and I think the issues you are seeing can probably be fixed. My initial plan was to render PDFs server-side, instead of relying on the browser's print mode.