4 ms·
I fail to understand your point. I see a "pdftex.js" [1] program which seems to compile a TEX file into a PDF file... which I would call writing TeXLive in JS.
by nmc 13y ago
I fail to understand your point.
I see a "pdftex.js" [1] program which seems to compile a TEX file into a PDF file... which I would call writing TeXLive in JS. If I read correctly, this was partly automated by using "emscripten" to convert the original C++ implementation into a JS implementation (which is why some parts "compile to" JS).
I also do not understand what "new assembler language" means in the context of TeXLive. But what I want to understand is: why?
Why would any one want TeXLive in JS? Where is the advantage? (Please do not answer "portability".)
[1] https://github.com/manuels/texlive.js/blob/master/pdftex.js https://github.com/manuels/texlive.js/blob/master/pdftex.js
- JoshTriplett 13y agoOne obvious advantage: a service that supports live TeX document editing could run TeX for previews on the client side rather than the server side, freeing up a huge amount of server resources and making it possible to scale much more easily.
- dbaupp 13y agoWhy is portability a bad answer?
- nmc 13y agoBecause TeXLive is already pre-compiled for any distribution you may want to typeset LaTeX with.
- dbaupp 13y agoNo, it's not compiled to run in the web browser; at least, not until people do things like this project.
- nmc 13y agoHum... if you can run a browser, you can already run executable files (ELF or the Windows-crap-equivalent), including all TeXLive tools. Thus, running in a browser does not bring portability. However, as "JoshTriplett" pointed out, running in a browser brings the possibility of client-side computation triggered from a web host. But this is not what I call portability.