Hmm, how would you intend to simplify it?

The texvc filter could be rewritten in PHP, eliminating the ocaml & gmake compilation dependencies.

The LaTeX/ghostscript/dvips/imagemagick dependencies are what do all the actual work of math rendering, though. I can't think of much to eliminate this other than, say, creating a public web service that does <math> -> image rasterization, and allowing third parties to call out to it instead of installing the software locally.

http://www.forkosh.com/mimetex.html also looks pretty nifty -- alternate TeX-like renderer. Not as pretty, and not necessarily fully compatible, but has no external dependencies and compiles from standard C.

physik wrote:

There is a partial solution for that:

You can use the MathML (LaTeXML) rendering mode.
The downside is that users that have browsers that are not support HTML5 fully (i.e. MathML) have to use enabling technology like MathJaX or MathPlayer to display math correctly.
But it's even worth. The browsers don't even know that they can not display MathML reasonably well and just output the text elements. cf http://html5test.com/compare/feature/parsing-mathml.html
So it's hard to filter browsers that support reasonably well MathML rendering and those that don't.

We tried to convert the texvc output via pdflatex to svg. For most cases that works fine. However there are lot of corner cases and issues and it seems not to be a very elegant solution.
Our main idea for the future, is to convert MathML to SVG to overcome the browsers weaknesses at the server side. However at the moment we are not aware of a tool that can do the job correctly.

physik wrote:

The documentation on the Extension:Math page was improved. Now it should be possible to enable Math support in less than one minute.