214 karma · joined January 10, 2015
What I was wondering - and still am - shouldn't it be possible to get to a "Pleasant" justified layout on the web in general?
The jagged left-aligned paragraphs are some of the first bits people point to when invoking "my PDF looks better". I definitely am not saying I did it perfectly, but shouldn't it be possible to get a good justified scientific article on the web? Why not?
I hope not. The key gain here is that the syntax used for mathematics in HTML needs to be easy to integrate in the web platform of 2021. Can you still use the DOM with MathML? Yes. Can you naturally interleave it with other HTML elements to create multi-modal constructions? Yes. With diagrams? SVG+MathML is possible, yes.
Indeed it is designed for technologists, solving a problem on the world wide web, as well as in other structured formats. And no, no one is asking mathematicians to type XML or HTML by hand in 2021.
An author can keep using latex, asciimath, Word or OpenOffice, MathType, MathQuill, or even Mathematica/Matlab/scipy syntax, as they've done until now. And then have their toolchain of choice prepare MathML to be served on the web, (or epub ebooks, etc), in a uniform manner understood by all vendors. Mere mortals can then finally create web apps that can natively access the math, without writing half-baked tex parsers that have hundreds of awkward and undocumented special cases.
TeX syntax has no path to richer integrations into the web platform and keeps mathematics out of reach for all modern ecosystem trends. I certainly think MathML can still be improved quite a bit - mostly by making it smaller and simpler, so that anyone can pick it up in an hour and write a new app in a day.
Switching to some phonetically adjacent name, say TypeMax or SciMacs or ... could be a friendly invitation to a new generation of users to give the platform a spin.
The increase in both computational power and connectivity has had impact all over the place, but has also transformed science. Even the most analog disciplines now have computational modeling branches, are building datasets, and need best practices for presenting and publishing computational artifacts. From Digital Humanities, to Computational Biophysics.
Printed pages struggle to convey the depth of these results, as do (originally) flat data formats like PDF, which are oriented towards pixels, rather than datatypes.
But I have to disagree strongly about sniping LaTeX as (completely) outdated, because of the need to supplement the printed page with a "content browser". Yes, we most certainly need a computational toolkit for presenting scientific results and aiding peer-review. But no, typesetting is not going away. The human taste for aesthetically pleasing documents is here to stay, and beautifully laid out narratives are instrumental for getting your message across to your audience. Delighting the eye allows the reader to focus on content, rather than struggle with an ugly form.
So my take on my work at Authorea (yep, beware inside bias!) is to transfer our typesetting best practices to the web as the baseline, but then focus and innovate on the "depth" of web-first science articles. To improve academic writing, we need to expose and interact with data, do the well-known social collaboration gig, and embed guarantees for transparency and reproducibility. Machine-assisted quality control and authoring are the two large impact sweet-spots to hit in the coming decade on this front. Time will show if we're in the know or not, but LaTeX is certainly a point of departure that has to be supported, and learning it is a healthy thing to do in 2017. We have a lot of important work ahead of us!
From that point on it's sending very basic RESTful requests. I wouldn't recommend using latexml if you're interested in performance-critical math parsing.
Its best use case is converting entire LaTeX documents/fragments with arbitrarily complex package dependencies, macro definitions and any other power latex techniques.
Indeed, LaTeXML has been producing great presentation MathML, since before MathJaX was created. But it's also a very different tool and the two projects are largely complementary, rather than competing. I'm happy to hear your first experiment went well, and as a note - most components, including and especially the math output, are highly configurable.
I recently counted [1] а 95% success rate by LaTeXML's math parsing on 350 million LaTeX formulas from arXiv.org. That number should be taken with a grain of salt, as it is a self-claimed parsing success, which may not necessarily mean correct+ideal MathML. But it quite often gets the job done great visually, and there is ongoing work to keep improving the coverage.
That said, MathJax has historically (and until very recently) fully embraced MathML itself, as MathML was used for its internal representation. The main problem that had/has to be solved on the web was the lack of displaying MathML support in browsers [2], and MathJax addressed that extremely well, as you know. But if, for example, you create an HTML5+MathML document with LaTeXML, and enable MathJax on it, you will get as good a result as using MathJax on HTM5L+TeX documents.
At Authorea we use both of LaTeXML and MathJax for our formula support, as well as some alternative renderers such as KaTeX and MathQuill. It's sometimes a bit too big of a hassle to do something advanced however (see [3]), so there is still some way to go.
There are certain trade-offs to be considered, but I personally see MathML as an instrumental part of making math accessible, actionable (as a native part of the DOM) and interoperable, and am happy that both LaTeXML and MathJax have embraced it historically. The MathJax team is now officially out of patience with the browser stalemate in displaying MathML, so they're looking for alternatives to move forward. Time will show how that goes I suppose...
[1] http://prodg.org/talks/mnlp_billion_token_corpora#30
In my view, MarkDown is a great kernel for what one could call "structured writing", while LaTeX is a great exploration of, and ecosystem for, the entirety of technical writing. I see both as points of departure to finding the best approach to write 21st century technical documents. More details on that opinion at [1].
This is also part of the fundamental mission of Authorea, where we offer support for writing all of MarkDown, LaTeX and RichText today, while working hard with the larger community to arrive at better tools in the long run.
Anyhow, there are non-trivial trade-offs in making these choices, and I personally find it exciting to see where one can reap the best returns.
[1] "LaTeX is Dead (long live LaTeX)" https://www.authorea.com/19359
2. There are annoying copyright issues with making the datasets available for public use. We're working with arXiv to resolve that, it's out of our control for now. It's a long-lasting frustration of mine that the datasets can't be simply made public.
3.You can omit anything you like from the MathML, there is no inferiority to omitting from TeX. "but maybe it is better than MWS" - prove it, submit to NTCIR, and beat everyone. Also, being better than MWS is not an argument that MWS should be denied the very data it needs to run. At the same time you can still obtain whatever degradation you need from the presentation MathML. Failing to recognize any claim to correctness than your own without any substantive proof is not a reasonable position and I urge you to reconsider.
"I have no idea why I need to read its lengthy spec, and I see no reason to write a MathML parser."
You don't need to write a parser, you can use an off-the-shelf parser for XML/HTML5 and handle the MathML reliably and appropriately. In fact you can reuse that from any open source search engine for math, MWS included. Writing a TeX parser on the other hand is something I will always roll my eyes at, since actual real world TeX is not something you can "parse", or do anything with reliably, unless you have a full TeX implementation underneath. Which is 1000x harder than using a parser to deal with MathML.
Finally, whining about NTCIR's UI being imperfect as a reason not to submit is just childish.
Images are not mathematics, they have nothing to do with mathematics. If you take a look at SVG, you may be shocked to find you can do just as much decomposition of principle components as you can do with any DOM, just the way MathML allows you to.
Please substantiate the "works pretty well" claim about your search engine with some data. Your sense of inconvenience comes far from an objective argument.
How many people write HTML by hand? Generating it from a wide range of tools, richtext editors, markdown inputs, etc etc is much more common. Your analogies are just inaccurate.
If you don't, please don't say no one does. Having a math DOM allows for actual interactivity with mathematics, from highlighting, copying subtrees, embedding links, having on the fly computations/simplifications, etc.
Not to mention add-on services like math indexing and search.
Yes, we need to manipulate and machine-read math expressions, if we want to finally take online math workflows to the 21st century.
I can't but see these as secondary to why MathML isn't supported yet. The current state works already well enough in Firefox, but no one would use it, since why support a single browser? And we've had it working nicely in Chrome before the devs pulled the plug because of lack of manpower. You could try to overrule the cruft from say the upcoming HTML5.1 spec, and find a good alignment with CSS. If it proves annoying or impossible, you could take the process further towards a MathML 4 that offers a CSS-compatible subset, etc. And the W3C Math group could approve of an experimental note much quicker, so that we don't sit around for years waiting for the standardization process.
The web mathematics community is a small one, and most of us have strong opinions on MathML. The way this debate is heading will tear the community in various tinier subfractions and likely continue the "math-on-the web winter" for another decade.
In my eyes, nothing has changed really - we've had browsers silently complicit in ignoring MathML, and a community tiny enough to not be able to move them in any direction. The two important bits for a math-on-the-web developer to have sanity are 1) expose the mathematics content of a page as data (the way we do tables) and 2) do so in a standard cross-browser way. Anything else leads to insane hacks, and tools such as math search engines, clipboards etc. can not be implemented directly.
As someone who has stared at arXiv TeX/LaTeX for years, I can testify you don't want to be looking at TeX math in actual latex documents, there is a lot more that goes in there beyond the toy formula syntax used on the web.
As also someone who has worked on math search engines and math-rich NLP for a few years, complaining that you have a structured machine-parseable representation for mathematics and wanting TeX instead sounds naive. On one hand, the MathML formulas in the datasets already could preserve the source TeX (the TeX annotations may even be there, I can't remember right now), should you need it directly. On the other hand, you can use any structured methods, such as the ones used by content-based search engines such as MathWebSearch, or handpick any relevant information from the MathML tree to feed it back into a statistical algorithm, as done for example by the WebMIAS search engine.
The most fundamental bit to understand if you're doing research on automated processing of human mathematics is that formulas are two dimensional objects best represented as trees, be they layout trees describing the presentation, or operator trees describing the content, or some other hybrid tree that tries doing both (such as LaTeXML's XMath spec).
The details as to why are here: http://prodg.org/blog/mathml_please/2015-09-16/MathML%20on%2...!
As things stand, math handling on the web is inconvenient at best and a nightmare at worst.
Some quick points about the comments here:
- MathML as a spec is akin to SVG, it's meant for the browser/machine first, and not for direct human consumption. You don't read/write SVG by hand, and neither you should MathML.
- Calling MathML a "failed web standard" is fine by me, as long as you continue the remark with "the Chrome and IE browsers have failed mathematicians" and "the math-on-the-web developers have failed as a community".
You would get better mileage with tools such as LaTeXML[1] or TeX4HT[2], which cover very substantial subsets of TeX, if not yet 100% feature-complete.
My own take on "Should LaTeX survive on the web?" is "yes, if it evolves to meet the paradigm shift". I wrote a detailed version of that position at [3].
- [1] https://en.wikipedia.org/wiki/LaTeXML
- [2] https://en.wikipedia.org/wiki/TeX4ht
- [3] http://prodg.org/blog/latex_today/2015-03-16/LaTeX%20is%20De...