:( No hyphenation, kerning or leading. Knuth and Liang solved this problem decades ago. I dislike like having to hack it with Javascript. That lack is what makes web typography ugly, even in this demo.
You really have to remember it’s a demo – it’s not something that Adobe sells to publishers, today; it’s supposed to have the “wow” factor.
Incidentally, that article in the demo includes Adobe’s own glyph shaping&rendering solution, with things like stem darkening, subpixel rendering, linear blending of text. If you show it side-by-side with the “webkit rendering”, it’s relatively obvious that our text looks better. But guess what…. from all the people who see the demo live (because you can’t see this kind of text improvements on youtube) – nobody notices if we don’t explicitly show side-by-side text comparison. And even then, it’s a “meh, yeah, you’re right, it does look slightly better”.
Same for good justification – it’s computationally expensive. If we put better justification in a demo (we tried), the animation doesn’t look “cool”, it’s slower and the picture lags behind your finger. Maybe it wouldn’t matter in real-life because you don’t need to reflow text 10 times/second… but it makes a huge difference in a demo.
FWIW - my personal opinion is that it was a mistake to shoot the demo video on a mobile phone, the screen space is simply too small to render this kind of layouts. It should've been shown on a Galaxy Tab, it looks much better.
(oh, and AFAIK the demo does have hyphenation; it's just that the rendering space is so small, that hyphenation alone cannot solve the layout problems).
The good news is that at least it made a good first impression. As a technology it definitely looks cool and useful even if it doesn't do TeX quality layout at the moment.
I don't understand what you mean. I'm using the original vccv TeX algorithm in my Sweet Justice library and it works decently. There is also Hyphenator which uses Liang's algo and supports dozens of languages. The web case is very similar to the desktop publishing case.
Web/DTP is not the same thing at all. DTP is static. The web is dynamic.
You can envision some paragraphs of text in a blog post being re-flown but the web is more than that. What about interactive text? Text in SVG? Multi-language text in the same paragraph? Various stacks of text in varying z-indexes, css-3 animated? Text manipulated with Ajax? In a mobile browser AND in the desktop. Not so easy anymore when you have to cover all of those --and possibly in a W3C or HTML5 sanctioned way, compatible with concepts like "overflow" and all.
Can you point out some reasons the algorithms in TeX cannot apply to reflowing text in a browser, rather than a static page? It seems like a very similar context to me.
My understanding is that the reason WebKit does not use the TeX layout algorithm is performance. WebKit has a zero-tolerance policy on performance regressions; the only way the TeX layout algorithm will make it in is if it can do so without sacrificing rendering speed.
You tempt me to try submitting a patch. I suspect it's a bikeshed problem, but I could be wrong. There is no technical reason why you couldn't enable it only on elements with a "-webkit-hyphenation" CSS rule. Then it's not a regression, it's an optional feature.
You are right that there are real perf concerns. A web page reflows multiple (sometimes hundreds) of times during pageload, unlike a print document.
TeX was designed to work on computers of the late 1970's. It seems pretty reasonable to think that algorithms that were practical to execute then can be carried out more or less instantaneously on machines available today. If you think you can pull off a port, by all means try.
Web browsers could handle postscript in 1992, they should be able to handle tex now.
http://browser.is/?p=23
Disclaimer: The author of MidasWWW is my boss :)
