4 ms·

Yes, they solved it alright. In an entirely different context.

by foljs 16y ago

aristus 16y ago
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.
- foljs 16y ago
  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.
RodgerTheGreat 16y ago
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.
- neild 16y ago
  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.
  - aristus 16y ago
    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.
    - RodgerTheGreat 16y ago
      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.
  - juiceandjuice 16y ago
    Web browsers could handle postscript in 1992, they should be able to handle tex now. http://browser.is/?p=23 http://browser.is/?p=23 Disclaimer: The author of MidasWWW is my boss :)
- Robin_Message 16y ago
  https://bugzilla.mozilla.org/show_bug.cgi?id=67715 https://bugzilla.mozilla.org/show_bug.cgi?id=67715 was filed in 2001 asking for this. https://bugzilla.mozilla.org/show_bug.cgi?id=67715#c13 https://bugzilla.mozilla.org/show_bug.cgi?id=67715#c13 explains the principal reason why it is not done, namely that incremental reflow at the paragraph level and the effects of triggering incremental reflow after initial layout (e.g., by :hover ...). How "jumpy" we'd look.

Yes, they solved it alright. In an entirely different context.

by foljs 16y ago

Yes, they solved it alright. In an entirely different context.

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.

foljs 16y ago
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.

RodgerTheGreat 16y ago

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.

neild 16y ago
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.
- aristus 16y ago
  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.
  - RodgerTheGreat 16y ago
    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.
- juiceandjuice 16y ago
  Web browsers could handle postscript in 1992, they should be able to handle tex now. http://browser.is/?p=23 http://browser.is/?p=23 Disclaimer: The author of MidasWWW is my boss :)
Robin_Message 16y ago
https://bugzilla.mozilla.org/show_bug.cgi?id=67715 https://bugzilla.mozilla.org/show_bug.cgi?id=67715 was filed in 2001 asking for this. https://bugzilla.mozilla.org/show_bug.cgi?id=67715#c13 https://bugzilla.mozilla.org/show_bug.cgi?id=67715#c13 explains the principal reason why it is not done, namely that incremental reflow at the paragraph level and the effects of triggering incremental reflow after initial layout (e.g., by :hover ...). How "jumpy" we'd look.