4 ms·

For the same reason everything eventually gets rewritten in Javascript: sometimes you want to do it in a browser. In my case, I have a Javascript app that stor

by ef4 11y ago

For the same reason everything eventually gets rewritten in Javascript: sometimes you want to do it in a browser. In my case, I have a Javascript app that stores critical information for offline use, and users want to be able to print that information nicely. So I generate PDFs in Javascript. This could make that much easier.

e12e 11y ago
> For the same reason everything eventually gets rewritten in Javascript: sometimes you want to do it in a browser. Indeed: http://manuels.github.io/texlive.js/ http://manuels.github.io/texlive.js/
- Garlef 11y ago
  Deprecating TeX is long overdue - for example creating non-book layouts (i.e. magazines) is a real pain. So: A a TeX compiler that can be called from JS can only be an intermediate solution. I think http://txtjs.com/ http://txtjs.com/ goes in the right direction.
  - e12e 11y ago
    Actually with css-hyphens[ch], I think html/css has finally taken a leap towards usable text -- something that has been sorely lacking (mostly due to a kind of regression across browsers, where everyone seem to have given up on making html work for text, without a ridiculous amount of css, and maybe even js/canvas/svg. This is related to the avoidance of user style-sheets, and the idea that a bare bones hypertext documents could actually be useful. There's not really anything preventing browsers from presenting an un-styled html-page like how A-list-apart styles their articles -- absent any css-reset/css-styles). I don't really think calling TeX from js is a very good idea, nor do I really think canvas is a good idea either. I do wish Adobe had gained more traction with css regions[cr] -- although I also understand some of the arguments against them[ch]. I still think the idea is good: css for style, semantic html for ... semantics -- and "layout html" for layout. I think pairing semantic markup with css columns is just a bad idea -- and it gives the kind of "half-power" that initially lead people to use tables for layout. So Lie is right in that css regions aren't a great fit for html[ch] -- but I still think they're the best fit for html I've come across. I might be convinced that css regions are the kind of things that fit well with js/poly-fills[pf] -- although I'm sceptical. We know fonts are turing complete and have had security issues -- I don't see why we should need to implement core layout with js. At least I suppose "rogue" software vendors can choose to support css regions[cr] -- For eg an e-book reader based off of a subset of html+css, css regions might be a good fit, while avoiding the complexity of adding js support, and trying to make that secure (including proof against denial of service etc). Thanks for the link to texjs, though -- I'll definitely have a closer look. [ch] http://caniuse.com/css-hyphens http://caniuse.com/css-hyphens [ha] http://alistapart.com/blog/post/css-regions-considered-harmful http://alistapart.com/blog/post/css-regions-considered-harmf... [cr] http://caniuse.com/css-regions http://caniuse.com/css-regions [pf] http://webplatform.adobe.com/css-regions-polyfill/ http://webplatform.adobe.com/css-regions-polyfill/

by ef4 11y ago

e12e 11y ago

> For the same reason everything eventually gets rewritten in Javascript: sometimes you want to do it in a browser. Indeed: http://manuels.github.io/texlive.js/ http://manuels.github.io/texlive.js/

Garlef 11y ago
Deprecating TeX is long overdue - for example creating non-book layouts (i.e. magazines) is a real pain. So: A a TeX compiler that can be called from JS can only be an intermediate solution. I think http://txtjs.com/ http://txtjs.com/ goes in the right direction.
- e12e 11y ago
  Actually with css-hyphens[ch], I think html/css has finally taken a leap towards usable text -- something that has been sorely lacking (mostly due to a kind of regression across browsers, where everyone seem to have given up on making html work for text, without a ridiculous amount of css, and maybe even js/canvas/svg. This is related to the avoidance of user style-sheets, and the idea that a bare bones hypertext documents could actually be useful. There's not really anything preventing browsers from presenting an un-styled html-page like how A-list-apart styles their articles -- absent any css-reset/css-styles). I don't really think calling TeX from js is a very good idea, nor do I really think canvas is a good idea either. I do wish Adobe had gained more traction with css regions[cr] -- although I also understand some of the arguments against them[ch]. I still think the idea is good: css for style, semantic html for ... semantics -- and "layout html" for layout. I think pairing semantic markup with css columns is just a bad idea -- and it gives the kind of "half-power" that initially lead people to use tables for layout. So Lie is right in that css regions aren't a great fit for html[ch] -- but I still think they're the best fit for html I've come across. I might be convinced that css regions are the kind of things that fit well with js/poly-fills[pf] -- although I'm sceptical. We know fonts are turing complete and have had security issues -- I don't see why we should need to implement core layout with js. At least I suppose "rogue" software vendors can choose to support css regions[cr] -- For eg an e-book reader based off of a subset of html+css, css regions might be a good fit, while avoiding the complexity of adding js support, and trying to make that secure (including proof against denial of service etc). Thanks for the link to texjs, though -- I'll definitely have a closer look. [ch] http://caniuse.com/css-hyphens http://caniuse.com/css-hyphens [ha] http://alistapart.com/blog/post/css-regions-considered-harmful http://alistapart.com/blog/post/css-regions-considered-harmf... [cr] http://caniuse.com/css-regions http://caniuse.com/css-regions [pf] http://webplatform.adobe.com/css-regions-polyfill/ http://webplatform.adobe.com/css-regions-polyfill/