4 ms·

There is another problem. Some time ago, I thought about integrating LaTeX into user-facing software, not to render an entire web page but to generate a few fo

There is another problem. Some time ago, I thought about integrating LaTeX into user-facing software, not to render an entire web page but to generate a few formulas and images containing formulas in real-time or close to real-time. It breaks my heart to say that it seems impossible to do so, because LaTex is soooo slow. The codebase is written in an obscure language (that Knuth created for the purpose?) and would have to be converted to something optimizable such as C in order to become faster. Since I won't be re-implementing LaTex soon, I'll stick with MathJax for simple formulas and must look for something else if I want to create a complicated formula-containing image.

Crito 13y ago
Web2c is typically used these days. The issue is not as simple as "It needs to be written in C".
- sentenza 13y ago
  Well, I gave up when I saw that it wasn't written in anything I could work with, so this is news to me. Also, having had some bad experiences with to-C translated code (looking at you, Matlab), I'd say that knowing that Web2C exists doesn't cause me great optimism.
  - maxerickson 13y ago
    There is recent work on a TeX engine with a Lua interface: http://tex.stackexchange.com/questions/36/differences-between-luatex-context-and-xetex http://tex.stackexchange.com/questions/36/differences-betwee... But still LaTeX sits on top of that, so it probably doesn't move you along very much.
ErsatzVerkehr 13y ago
TeX is written in WEB, a "literate programming" language designed by Knuth, which a pre-processor turns into Pascal. There should be nothing inherently slow about Pascal. In practice, it's compiled using "web2c" which does generate C code. http://en.wikipedia.org/wiki/WEB http://en.wikipedia.org/wiki/WEB
dpwm 13y ago
A lot of the time overheads with LaTeX are in the initial starting up. If you look into, for example, the preview environment, you can look at processing multiple snippets of LaTeX much quicker. Of course, such batching doesn't help achieve the goal of real-time LaTeX. If you're willing to eschew the luxuries that PDFTeX provides (microtype and pdf output) and drop back to DVI, it is possible to interpret the DVI yourself in real time using the IPC hack (which allows dumping of dvi on each page flush). The file format is specified in the dvitype manual[1]. Unfortunately, once you've processed the DVI output, you'll discover that many modern TeX fonts do not render, because they are virtual fonts and you will need to implement these. You'll also have to process the TeX font metric files. Once you've done all this, you can easily get TeX to produce in excess of 1000 snippets per second. The rest is up to your rendering backend, but you'd have to be doing a lot wrong to end up with less than 100 per second. [1] http://texdoc.net/texmf-dist/doc/generic/knuth/texware/dvitype.pdf‎ http://texdoc.net/texmf-dist/doc/generic/knuth/texware/dvity...

Crito 13y ago

Web2c is typically used these days. The issue is not as simple as "It needs to be written in C".

sentenza 13y ago
Well, I gave up when I saw that it wasn't written in anything I could work with, so this is news to me. Also, having had some bad experiences with to-C translated code (looking at you, Matlab), I'd say that knowing that Web2C exists doesn't cause me great optimism.
- maxerickson 13y ago
  There is recent work on a TeX engine with a Lua interface: http://tex.stackexchange.com/questions/36/differences-between-luatex-context-and-xetex http://tex.stackexchange.com/questions/36/differences-betwee... But still LaTeX sits on top of that, so it probably doesn't move you along very much.

ErsatzVerkehr 13y ago

TeX is written in WEB, a "literate programming" language designed by Knuth, which a pre-processor turns into Pascal. There should be nothing inherently slow about Pascal. In practice, it's compiled using "web2c" which does generate C code. http://en.wikipedia.org/wiki/WEB http://en.wikipedia.org/wiki/WEB

dpwm 13y ago

A lot of the time overheads with LaTeX are in the initial starting up. If you look into, for example, the preview environment, you can look at processing multiple snippets of LaTeX much quicker. Of course, such batching doesn't help achieve the goal of real-time LaTeX. If you're willing to eschew the luxuries that PDFTeX provides (microtype and pdf output) and drop back to DVI, it is possible to interpret the DVI yourself in real time using the IPC hack (which allows dumping of dvi on each page flush). The file format is specified in the dvitype manual[1]. Unfortunately, once you've processed the DVI output, you'll discover that many modern TeX fonts do not render, because they are virtual fonts and you will need to implement these. You'll also have to process the TeX font metric files. Once you've done all this, you can easily get TeX to produce in excess of 1000 snippets per second. The rest is up to your rendering backend, but you'd have to be doing a lot wrong to end up with less than 100 per second. [1] http://texdoc.net/texmf-dist/doc/generic/knuth/texware/dvitype.pdf‎ http://texdoc.net/texmf-dist/doc/generic/knuth/texware/dvity...