4 ms·
I'm sorry but Latex is an inconsistent touring-complete mess. Latex commands are far from intuitive, otherwise Detexify wouldn't be so popular. It's a million m
by felixfbecker 8y ago
I'm sorry but Latex is an inconsistent touring-complete mess. Latex commands are far from intuitive, otherwise Detexify wouldn't be so popular. It's a million macros held together with duct type with no consistency in naming and syntax, and always dependent on which age-old package you're referencing. It's good at outputting pixel-perfect printable, non-accessible PDFs, and that's it.
I'm excited by this because I hope that with a proper widely-supported system for math in HTML we can eventually write more papers to be digital-first. An HTML document is so much more accessible, searchable, semantically analysable and flexible than Latex and its PDF output. I dream of a world where the standard for papers is not Latex .pdf but .mhtml or .maff.
- MiroF 8y agoIf Latex can be rendered in HTMl, than the world you dream of could become reality. Nobody wants to learn a new type setting language. Latex is much less hard to learn and use than you imply I mean just look at MathML https://en.wikipedia.org/wiki/MathML#Example_and_comparison_to_other_formats https://en.wikipedia.org/wiki/MathML#Example_and_comparison_...
- felixfbecker 8y agoI think it can be, it's just nobody does it. I don't know what formulas get compiled to though - I would guess PNGs, at which point you lose the benefits over a PDF (at least for equations). With proper browser support for MathML it could always be MathML though, which would render sharp and be readable by a screen reader. It is unfortunate that MathML is not easily hand-written like the rest of HTML. What I find interesting in the link you posted though is that they embed the Latex or StarMath representation inside the MathML. It should be possible have tooling in text editors such that you only edit that Latex representation and on save the MathML representation is updated automatically.
- pvorb 8y agoWhile LaTeX might be hard to learn and inconsistent in its entirety, the formula is quite consistent and a lot easier to write by hand than MathML.
- svat 8y agoIt is true that the LaTeX ecosystem as a whole is a mess of packages and macros. But most of its mathematical typesetting comes from the underlying TeX (and a set of macros maintained by the AMS), and it's fairly small and consistent. The Detexify you mention is only for looking up specific symbols provided by various fonts (packages), and has nothing to do with mathematical typesetting or LaTeX macros in general: TeX/LaTeX engines support Opentype fonts now and if you want to use one of them, you can just type ∞ instead of \infty or ℝ instead of \mathbb{R} (actually you can do this regardless with unicode-math), bypassing the need for looking up symbols-a4 or Detexify. Encoding the aesthetics of good mathematical typesetting is not trivial, and Knuth and others have spent decades on it based on studying and absorbing all the tricks that hot-metal typesetters had come up with over centuries. It would be foolish to throw away all that hard-won knowledge and implement half-baked solutions from scratch: those working in the field understand this (though the original MathML proponents perhaps did not), which is why the linked post mentions “math rendering based on TeXbook’s appendix G”. More generally, in this conversation (and in any discussion about MathML), several things get conflated: 1. What syntax the user types to get their mathematics. I think it's beyond dispute here that no one wants to type MathML by hand (and even the MathML advocates do not propose it AFAIK). Also, so many people are familiar with TeX/LaTeX syntax that it must be supported by any complete solution, though alternatives like AsciiMath or some interactive input are still worth exploring. 2. How the mathematics is actually encoded in the HTML file, or delivered to the browser. Frankly I don't think this one matters much because it's invisible to the user; any of raw TeX syntax, or MathML syntax, or fully-positioned HTML+CSS, or SVG, will probably do. 3. Who does the rendering and typesetting / layout. The promise/dream of MathML is that a standard will be specified and all browsers will implement it; though this is yet to become reality. Meanwhile, typesetting can already be done server-side (someone runs TeX/MathJax/KaTeX/etc before sending it to the browser) or client-side (MathJax/KaTeX running in the user's browser) instead of being done in the browser's native code. 4. The quality of the typesetting/the algorithms used. I already mentioned this in the second paragraph above so I won't reiterate it, but this has been mostly underestimated/ignored by those advocating MathML. The decisions made by TeX reflected the best journals of the early 20th century and have in turn become the shared aesthetics of the mathematical community; “so-so” typesetting will not do. 5. What the result/output of all this rendering/typesetting/layout will be, in the web page's DOM. This affects things like usability (being able to copy-paste), scaling/zooming, styling individual parts of formulas, etc. Again, already (La)TeX+dvisvgm supports SVG for this, and MathJax supports HTML+CSS, MathML or whatever. Anything other than raster (PNG etc) images is probably fine here. The main new/useful thing I can see with MathML is with (3); the browser doing the typesetting. But that's hard, and it has a lot of other challenges to overcome too. And as MathJax/KaTeX/dvisvgm demonstrate, the facilities provided by the browser for layout (HTML+CSS for example) are already sufficient for print-quality typesetting.