Nice, but this constantly crashes Safari when the content goes below the fold. The whole page goes white and then the browser dies.
I ported LaTeX to Javascript
51–60 of 73 posts
Re: I ported LaTeX to Javascript
#52Pointlessly awesome. Care to describe why it would make sense to run LaTeX on JS?
Re: I ported LaTeX to Javascript
#53I don't like TeX. I use it and i like the output, but I have never realy understood the language and therefore I don't like it. The syntax for optional arguments([]) seems very odd to me, aswell as the separation between mouth and the rest. The support for named parameters is IMO very hacky.
Wouldn't be a Tcl based macro processor with the tex-Backend nice? Or is this silly?
Re: I ported LaTeX to Javascript
#54Nice, but this constantly crashes Safari when the content goes below the fold. The whole page goes white and then the browser dies.
Sad to hear that. I don't use Safari, but maybe it cannot compete with the JS engines of Firefox and Chrome's version of the Webkit engine. This script reqiures a lot of computation in JS and communication between the website and the webworker (~300kb). Maybe Safari is unable to cope with this in a decent amount of time.
Re: I ported LaTeX to Javascript
#55Something completely off-toppic: I don't like TeX. I use it and i like the output, but I have never realy understood the language and therefore I don't like it. The syntax for optional arguments([]) seems very odd to me, aswell as the separation between mouth and the rest. The support for named parameters is IMO very hacky. Wouldn't be a Tcl based macro processor with the tex-Backend nice? Or is this silly?
Re: I ported LaTeX to Javascript
#56Something completely off-toppic: I don't like TeX. I use it and i like the output, but I have never realy understood the language and therefore I don't like it. The syntax for optional arguments([]) seems very odd to me, aswell as the separation between mouth and the rest. The support for named parameters is IMO very hacky. Wouldn't be a Tcl based macro processor with the tex-Backend nice? Or is this silly?
The "programming language" is horrible. It's a clear example of a turing tarpit. For example you don't have arrays, so you must fake them. You don't have function, so you have to return the value in a glob@l. Monkey patching is considered an art, but this makes many of the different packages slightly incompatible.
The "printing library" is amazing. If you only want to do a standard thing (and someone else had programmed it) the result is nice.
The other advantage is that everyone knows it, so if you make a package correctly it is easy to use by mathematicians that can't program in LaTeX.
Re: I ported LaTeX to Javascript
#57Something completely off-toppic: I don't like TeX. I use it and i like the output, but I have never realy understood the language and therefore I don't like it. The syntax for optional arguments([]) seems very odd to me, aswell as the separation between mouth and the rest. The support for named parameters is IMO very hacky. Wouldn't be a Tcl based macro processor with the tex-Backend nice? Or is this silly?
The syntax for optional argument and the lack of support of named parameters are limitations of LaTeX, not TeX. For example, see ConTeXt, which is a macro package on top of TeX, that has much more consistent syntax and all macros accept named arguments.
But TeX has a extremely flexible macro system, so it is possible to fake optional arguments. That's what LaTeX do. LaTeX defines a standard way to have optional parameters and make easy to define and use them. It has some strange optional parameters like in \newtheorem, because they are really fake optional parameters. The starred versions of the command also are fake, and have to be defined using a trick. But if you are lucky and don't look under the hood everything works quite well.
I don't know enough about ConTeXt, but I hope that it has a better system for optional arguments.
In some way, this is similar to what happens with some features of high level languages and assembler. For example, the exceptions in C# or Java are translated sooner or later to assembler, but assembler doesn't have exceptions.
Re: I ported LaTeX to Javascript
#58I want to generate a bunch of bytes programmatically, then have the user click on a button, and allow the user to save a file containing the generated bytes. This should run entirely client-side, with no talking to the server (except for static loading of the HTML page, JS files, images, css, etc). I've been wanting to do this since I wrote my first Java applet way back in the 1990's, and haven't been able to find a way; it's a personal long-standing unscratched itch for me.
Apparently with HTML5 it's possible to do this, since this project does it! I wasn't able to find where in the code the downloading happens, and I'm not sure what this concept is called, which makes searching difficult. Thanks!
EDIT: Browsing commits instead of the source tree was fruitful [1]. What I'm looking for is called Data URI [2]. The inverse operation -- programmatically processing uploads on the client side -- can be achieved with the File API [3]. Now I need a few days to think about what startups will become possible with these capabilities!
[1] https://github.com/manuels/texlive.js/commit/b7b7eef27846473...
[2] http://en.wikipedia.org/wiki/Data_URI_scheme
[3] https://developer.mozilla.org/en-US/docs/Using_files_from_we...
Re: I ported LaTeX to Javascript
#59Thanks for your hints! I added a 'Open PDF' button to circumvent popup blockers. Yes, I used emscripten to port it to Javascript. It was not that hard. Emscripten had three bugs I had to fix (the hardest was to find that the %g format was not supported by emscripten's sscanf). But it was compiled almost like for x86: first convert the pdftex 'web' souce code to c using web2c, then compile it to LLVM bytecode and the…
Re: I ported LaTeX to Javascript
#60Earlier quoted context omitted.
Just tried it, crashes in the exact same way: 1. Hitting "Compile" does whatever it should do successfully. 2. Then hitting "Open PDF" opens a new tab which stalls out and crashes I would almost say its actually a PDF thing that is crashing Safari vs a JS thing. At least, that's what has happened consistently on my machine with latest Safari and WebKit nightly. Edit: However, taking the generated PDF from Chrome and…
Yup, that is for sure it. I took the Chrome generated PDF, turned it into a data URL, then copy-pasted the data URL into Safari's URL bar. Crash. Drag and dropping the file itself into Safari, works fine.