https://github.com/brucemiller/LaTeXML/issues
It's a pretty deep rabbit hole, but I wholeheartedly agree most standard package support incantations should be easy and few to use.
214 karma · joined January 10, 2015
https://github.com/brucemiller/LaTeXML/issues
It's a pretty deep rabbit hole, but I wholeheartedly agree most standard package support incantations should be easy and few to use.
There used to be another showcase, called arxiv-vanity. They captured what happened pretty well with their farewell post on their homepage:
As a very brief update - we are pending a larger update.
You will spot many (many) issues with our current coverage and fidelity of the paper rendering. When they jump at you, please report them to us. All reports from the last 2 years have landed on github. We have made a bit of progress since, but there are (a lot of) more low-hanging fruit to pick.
Project issues:
https://github.com/arXiv/html_feedback/issues/
The main bottleneck at the moment is developer time. And the main vehicle for improvements on the LaTeX side of things continues to be LaTeXML. Happy to field any questions.
But seeing your plans for Science Stack, all the best with the endeavour!
And I am curious to know if arXiv:2105.10386 works well.
The selection did not get much thought at all, just a Rust rand shuffle over all ids performed at first page visit and then cached: https://docs.rs/rand/latest/rand/seq/trait.SliceRandom.html#...
I had all IDs already computed for the previous/next article navigation feature, so it seemed fun to reuse them.
Just visit:
You can either copy the CSS asset from: https://github.com/dginev/ar5iv-css
and add "--css=ar5iv.css --nodefaultresources" to the command line options for latexmlpost (or latexmlc).
Or alternatively, for people not interested in learning how to install and configure latexml, they can try the self-contained Dockerfile at:
Which also allows us (and generally all contributors of latexml package support) to conveniently maintain various parallel data structures and metadata needed along the way.
Modern HTML is very often helpful to produce higher quality article renderings. Examples:
1. we recently started using flexbox for subfigures, allowing them to reflow.
2. we have started emitting ARIA accessibility annotations (there is now an "alt" key for \includegraphics)
3. MathML Core allowed us to have native web rendering for math expressions in every browser.
As to LaTeX rendering in the browser, there are various other projects out there you could look up with partial support. For latexml the WebAssembly route seems most realistic, as we are undergoing a rewrite in Rust. But there are quite a number of pieces to flesh out before we get there.
Having a two-column theme, or left-aligned vs justified themes, could be workable in the long run. I hope that we get to see some browser extensions modding the pages before too long.
The reason for the current justified text is that it is the default aesthetic for a LaTeX-based article, and a lot of authors expect it.
Getting subfigures emulated via flexbox is one of our more recent LaTeXML enhancements, and still has some ongoing work (working on it today actually). It can be a bit finicky to test - there are easily 20 different ways people can write LaTeX for subfigures in arXiv.
1. My name is Deyan (hi!)
2. ar5iv was the latest frontend incarnation, but our actual work on converting LaTeX to HTML goes back nearly 20 years behind the scenes.
3. I was an undergraduate student when I was introduced to the project back in 2007. It was started "in spirit" by 3 senior co-conspirators back then: Michael Kohlhase, Bruce Miller and Robert Miner. And I am by no means a solitary actor today, even if I may be the chief online presence of the people involved. Bruce is doing the bulk of the hard work on LaTeXML to this day.
I documented some of the history in an invited talk for CICM 2022, which you can find on youtube, or see the slides at:
https://prodg.org/talks/welcome_to_ar5iv
It's really great that the HTML has now reached "home base" in arXiv, and I hope their team gets a lot more of the positive attention going forward - today's achievement is entirely theirs!
You can think of both arxiv-vanity and ar5iv as the "alpha" experiments that lead into the official arXiv "beta" HTML announced today.
Once a few rounds of feedback and improvements are integrated, and the full collection of articles acquires HTML in the main arXiv site, ar5iv will be decommissioned.
The plan is to turn all existing ar5iv links into redirects to the official HTML, and free up the resources for maintaining it. I am not sure what are the plans for maintaining arxiv-vanity, but I suspect they may head down a similar path some time later.
We have a plan in place to meaningfully fall back for unknown packages, but that will take at least another year to put in place, and likely another couple of years to stabilize.
Meanwhile, there is some hope that with arXiv launching the HTML Beta we will get more contributions for package support (LaTeXML is an open source project, with public domain licensing, everybody benefits).
But again the original point is spot on. Coverage will be hit-or-miss for a while longer yet, for an arbitrary arXiv submission. The good news is that authors could work towards better support for their articles, if they wanted to.
Search for "welcome to ar5iv!" on youtube for a talk with the full details.
And feel free to suggest better styling ideas as well. I keep wondering if we should have several themes emphasizing different elements...
If no one uses it, it will eventually get phased out.
I have just about a billion <math> elements in the arXiv preview site I develop: https://ar5iv.labs.arxiv.org/
And that is just one site. PubMed will likely have more than that at some point: https://pubmed.ncbi.nlm.nih.gov/
1. This was first reported to HN 55 days ago, discussion is here: https://news.ycombinator.com/item?id=30163308
2. There is an official arXiv blog announcement with a little bit of extra details here: https://blog.arxiv.org/2022/02/21/arxiv-articles-as-responsi...
---
When I first commented on HN, I mentioned that I really hoped we can find a way for arXiv to officially endorse the project and adopt it, so that we solve the copyright issues and get on a healthy path to full integration with the service. That happened a month ago! More healthy work ahead.
Thanks to everyone on HN for the feedback so far. If/when you see broken renderings (still plenty of examples) do comment with the article link, or (even better) use the "report an issue" button at the bottom of each document page. Cheers!
I can technically implement that, but I really don't want to, as I see it as crossing a certain line. Seeing ar5iv as a limited, constrained, service is a good thing - I think it clearly communicates that I do not want to compete with arXiv.
There's actually multiple "we", since there are two institutions involved, and one foil character - I'm the only one responsible for ar5iv "the website", in a personal capacity.
The fidelity of the generator has the "we" of the team behind LaTeXML, the TeX-to-HTML conversion tool. That is in many ways the most important project to remember here, as that is what we want to actively improve to a point where it is "good enough" in creating HTML over the entirety of arXiv.
The institution hosting the website, and wanting to "serve a community" is KWARC, a research group at the university of FAU-Erlangen in Germany. There are all kinds of projects and services brewing on that end, which have interplay with the HTML data behind ar5iv, but are not directly on the site.
And as to all of us reading HN, I think we are actually interested in arXiv itself being maximally useful. And so is the ar5iv site - it's a temporary deployment, that really is aiming to reintegrate back into the arxiv.org site, and general infrastructure.
If/when that happens is unclear, but in the meantime there is a lot of improvements that can be made, both in what HTML can be generated, deciding what the markup of scientific documents ought to be in the first place, as well as gaining some insights for what new problems arXiv would encounter if they served HTML.
I think I can see that, but it's almost there, which is why it feels like there has to be something I'm missing for it to justify "just right".
But yes, at the least you've convinced me we should have a separate theme that goes left-aligned, and possibly makes a number of other choices that maximize readability.
Since I'd still want the folks that want "as good as PDF", to feel justified for sticking around.
Also, ar5iv may disappear very quickly, since I am unsure if it's more helpful or harmful. But I'll definitely lean on the public attention to keep asking arXiv to integrate an HTML preview for their articles. In the one-and-only arxiv.org itself.
Lastly, one difference that may ignite a curious debate is that ar5iv is committed to being MathML-native. Yes. MathML is the only markup used for math syntax, and you'll see it rendered directly, undisturbed, with Firefox today.
Over 500 million MathML elements in the full dataset too, pretty awe-inspiring.
Indeed - hard problem and a messy solution. I have no easy answers.
The primary aim is to serve the community with the outputs we have, while we improve the coverage and fidelity of our generator.
And yes, using only the official sources arXiv has released for reuse: https://arxiv.org/help/bulk_data_s3
This is indeed a major difference with -vanity