I also looked into it recently, and Damon from the Gnome project attempted it in 2002 or so. Also Adobe+Google are trying to get it into WebKit. The problem (as far as I can tell) is that people have tried to do it all at once, and pushing such a large thunk of code upstream is very hard. I suspect that if you take it in pieces: first get a decent hyphenation algo into Pango, then get that into FF and WebKit, then wo…
W3C [...] 3 or 4 years; don't hold your breath.
Last I looked the CSS3 working draft included a hyphenate property.
The web is now twenty and browsers are still incapable of something as basic and commonplace as hyphenation and justification. It’s a real shame that this problem has to be solved with JavaScript in 2010. How old is TeX again?
It's not only browsers. Look at Word, for god's sake.
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 br…
Is Internet Explorer’s justification done for whole paragraphs using a reasonable algorithm, or just line by line?
It is the whole paragraph as far as I can tell (I haven't seen the internals, just the output.)
For those who don't know the algorithm, here's a bunch of links about it in Wikipedia: http://en.wikipedia.org/wiki/Word_wrap#Knuth.27s_algorithm
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.
I've been asking for years why browsers do not have this. The only reply I've gotten is for performance considerations, which is a bad answer for several reasons.
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 br…
> The algorithm isn't that expensive.
It's quadratic in length of the paragraph, no? Not a problem for most reasonable text chunks, but browsers have to deal with unreasonable text too. In particular, O(N^2) algorithms in browser layout are generally unacceptable...
The web is now twenty and browsers are still incapable of something as basic and commonplace as hyphenation and justification. It’s a real shame that this problem has to be solved with JavaScript in 2010. How old is TeX again?
It's not only browsers. Look at Word, for god's sake.
Even hyphenation like in Word would be an improvement over the status quo.
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 br…
> The algorithm isn't that expensive. It's quadratic in length of the paragraph, no? Not a problem for most reasonable text chunks, but browsers have to deal with unreasonable text too. In particular, O(N^2) algorithms in browser layout are generally unacceptable...
But it would only apply when the web page author "opted in" with the appropriate CSS, no? Doesn't seem like it should affect performance on pages that don't use the feature.
> The algorithm isn't that expensive. It's quadratic in length of the paragraph, no? Not a problem for most reasonable text chunks, but browsers have to deal with unreasonable text too. In particular, O(N^2) algorithms in browser layout are generally unacceptable...
But it would only apply when the web page author "opted in" with the appropriate CSS, no? Doesn't seem like it should affect performance on pages that don't use the feature.
If you made it an opt-in, that might be doable... though there would still be the danger of pages cargo-culting into the opt-in.
But at that point you're also asking browsers to maintain two separate line-wrapping codepaths, of which one is not used anywhere to a first approximation. Browser vendors seem to be somewhat resistant to doing that sort of thing.
I've been asking for years why browsers do not have this. The only reply I've gotten is for performance considerations, which is a bad answer for several reasons.
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 br…
One other thing. This algorithm, unless I'm missing something, doesn't handle situations in which the available widths are different for different lines in the paragraph, and in particular in which they available width for a line depends on the precise break positions and vertical alignment results of all the earlier lines in the paragraph. Handling this is required to correctly handle CSS floats. Greedy line-breaking does this by the simple expedient of fully laying out all previous lines in the paragraph before considering the next line.