We tried using KaTeX for https://www.arxiv-vanity.com but unfortunately it doesn’t support a lot of commonly used stuff. I forget what most of that was now... over/underbrace is one I recall.
I like the idea of arXiv vanity, but ... I decided to try it on my own paper from a few years back and the page just tells me that the render failed, no details given, and either click the PDF or "go back home".
I am of the opinion that scientists (the most likely users of this tool) should be treated with a bit more respect -- maybe provide technical details and/or a place where they can submit a report?
I have opened a Github Issue about the UI being too brief: https://github.com/arxiv-vanity/arxiv-vanity/issues/381 . Additionally, if there is any place I can submit a bugreport/query on my own paper failing, I would love to know.
---
As any true scientist (understand: self-absorbed), I can only recommend it once my own papers are rendering. :-)
Wow, TIL about arxiv-vanity. On a first glance, it's awesome. Not saying that I particularly dislike PDF files, but it's still good to have choice. Already the ability to extract images from PDF files is incredibly valuable to me. I wasn't aware how to do it properly. Screenshots are limited at the display size and when you are zooming you don't know when upsampling algos of the PDF reader set in and PDF readers often have maximum zoom levels and if the actual resolution of the image is above that, you still won't get the full resolution. Now I can extract images at the full resolution via browser tools... I hope it's actually the full resolution, isn't it? It's kinda not what arxiv vanity was made for but still, thank you for that!
If you want to extract figures/images from PDFs, the best way to do it is to use Adobe Illustrator (or equivalent... Inkscape maybe?). That’ll let you extract full sized bitmapped graphics or arbitrary parts of the PDF as SVG vector images.
We use KaTeX for https://cocalc.com (source here https://github.com/sagemathinc/cocalc) because it is dramatically faster than MathJax. When KaTeX fails due to an error (e.g., something missing) our code falls back to MathJax, so we still get full MathJax support when needed, but with all the benefits of KaTeX. The code that John Jeng and I wrote to do this is tangled up with the rest of cocalc's code; I hope somebody else writes a standalone library that accomplishes that same thing. It wasn't too difficult to write this, though a couple of subtle issues arose in production, which we had to sort out.
Arxiv vanity is very nice!
FWIW I believe KaTeX’s coverage is always growing. I found out it can do everything I wanted in https://introtcs.org , though there were a couple of times I had to reformulate some macros after looking at the documentation.
For rendering arbitrary arxiv papers, that's understandable, but KaTeX supports enough features to be no issue for 99% of applications. Although, I've noticed that MathJax is much more "modern" and faster than it was 4 years ago. It feels almost as buttery as rendering KaTeX now.
What's cool about KaTeX is that you can integrate it nicely with static website generators so that you can skip the latex parsing on the client side; the client only has to load a font and some CSS, no JS required. I've used that in a blog here: http://stoppels.blog/posts/gsoc-2017-summary
A huge amount of the speed problem in MathJax is just the default configuration, which does the math typesetting in a deferred callback and throttles the work, basically guaranteeing that the browser will go through a full relayout and repaint many times if there are lots of math on the page. It's possible to change this, but I don't think many people do.
My limited understanding of MathJax is that it uses the browser to measure glyphs. KaTeX on the other hand includes metrics for many of its glyphs. Where things get a little tricky is i18n. There are many languages which our current fonts don't cover and thus we have no metrics for them (we make some educated guess about some unicode ranges). It would be really nice if browsers implemented a Font Metrics API, unfortunately efforts to do so appear stalled at the moment.
Can you please elaborate a bit more on that? How can you configure it to be faster? I'm considering leaving MathJax for pre-rendered png because it is unusably slow (with the default configuration at least). My use case is a whole book of math on a single html page. Pdf viewers have no problem with that. Yet, firefox+mathjax cannot cope.
I have been using MathJax since before it was called MathJax (it used to be jsMath), and I've never found any synchronous rendering option to speed it up. You can minimize the page updates by not showing anything until mathjax is done, but that is disturbing to users (who either see nothing for an unknown amount of time, or see raw latex formulas), and it's frankly not much faster in my testing. If there really is such a MathJax option to synchronously render faster, then this page [1] should in fairness mention it.
We've been really happy using KaTeX as the LaTeX rendering engine for Zulip; it's super fast, and the fact that you can do the rendering on the backend (and just serve HTML + CSS at display time) is really nice.
Just because they are both open source does not mean they share a common goal or methodology. My guess is that KaTeX was written to overcome the deficiencies of mathjax.
I used KaTeX for a project of mine a couple of years back. It's fantastic! It's vastly faster than MathJax. Also, and maybe more important: It has a render('latex-string') function. At least way back, MathJax did't have that, and was very opposed to adding one, making it a pain to work with.
I would love to see a Macro system on top of TeX which has non-fixed-width page as it's base. And generate dvi's that I can convert to epub.
It won't directly be on top of TeX because TeX itself assumes fixed width but except for the width related directives, all directives would be shared with TeX. Basically everything would be such that existing TeX documents can be converted with little work.
This is cool. I just hope he ultimately has a pathway from HINT to epub so that this gains universal use, like how regular TeX sees because it can be made into a pdf
I am very impressed by the speed, but the typographic quality is notoriously ugly. Does it need to be that way? Does it happen only for the interactive demo? The screenshots look a bit better.
KaTeX strives to match LaTeX's behavior so it may actual be an issue with the screen readability of LaTeX. We're currently discussing ways to improve this in https://github.com/KaTeX/KaTeX/issues/1848. If you're seeing other issues please file a bug report.
I am a heavy TeX user and great fan of TeX, just Knuth's TeX with just his Plain.tex macro package, just as in his The TeXBook. Great fan.
No, I don't use LaTeX -- (a) I would no longer know how to write macros, (b) there is more to learn, (c) there is much more documentation to read, and (d) IMHO the LaTeX documentation is not written nearly as well as Knuth's The TeXBook. So, net, I don't use LaTeX.
Sorry, guys, there's no law saying I should get to TeX with a graphical user interface (GUI) with "what you see is what you get".
In fact, one of the things I like most about TeX is that I don't have to use a GUI. Instead, I type into TeX the same way I type as much of my writing as I can, into my favorite programmable text editor KEdit for which I have 200+ macros, many to help with typing TeX.
I'm happy as a clam. KEdit's functionality with my macros lets me get my work done with blinding speed, much faster than with any GUI which is "what you see is all you've got" and direct manual manipulation with no hope of automation -- bummer.
If I had to use TeX only via a GUI, I'd scream bloody murder loudly enough to blow off the roof of my house and the other houses in the neighborhood.
To each his own. A good GUI for TeX could be a lot of work. Sorry, guys, I just want to type into KEdit.
Are you replying to the wrong post? This is about a JS library for typesetting a small subset of the TeX formula macro's for inclusion in a webpage.
And besides, you say one of the reasons why you aren't writing LaTeX is because you like to work in a plain text editor without any extra graphical capabilities. I'm not saying you must use LaTeX -- far from it, but I do want to say that it's not an argument to use plain TeX: I'm happily writing my LaTeX documents in Vim, no problems whatsoever.
Okay, it's only for a small subset of TeX for output on a Web page. My guess was that it was a GUI for all of TeX with output a Web page.
Then that would be a GUI for typing in TeX for math, and I prefer to type in TeX for math with just a good text editor. I'm on Windows, using my favorite text editor KEdit, close to IBM's old editor XEDIT, done by an IBM guy in Paris WITHOUT support of IBM's management, instead of Linux, but I've heard that VIM and Emacs are really good text editors.
At times I've included TeX output in some Web pages: I just format the TeX with a lot of magnification in TeX (e.g., \magnification=1800), have TeX format the TeX input that I typed, have my favorite program for displaying a TeX output DVI file put the results from TeX on the screen, capture the screen, use the old Microsoft PhotoDraw to crop the screen capture and make a GIF file, and use the GIF file in a blog post and, thus, a Web page.
BUT!!!! There is much more to TeX than just a displayed expression for, say, the inverse Fourier transform in display mode, and I see no hope getting HTML, CSS, and JavaScript to do well with all or even nearly all of TeX.
But PDF can do well with TeX output. So, net, if want to put TeX formatted math on the Internet, then it seems there are just two main approaches: (1) Just do something clumsy, slow, and small scale like I do and just described, i.e., a screen capture or (2) use PDF, displayed by code in the Web browser or Adobe's Acrobat or whatever -- just send PDF. Okay, so the OP here is for a nicer approach to what I do with (1). Okay.
On LaTeX, for your
> And besides, you say one of the reasons why you aren't writing LaTeX is because you like to work in a plain text editor without any extra graphical capabilities. I'm not saying you must use LaTeX -- far from it, but I do want to say that it's not an argument to use plain TeX: I'm happily writing my LaTeX documents in Vim, no problems whatsoever.
No. A GUI editor would not motivate me to use LaTeX either. Instead, I don't use LaTeX because:
> (a) I would no longer know how to write macros, (b) there is more to learn, (c) there is much more documentation to read, and (d) IMHO the LaTeX documentation is not written nearly as well as Knuth's The TeXBook.
For (a) I would no longer know how to write macros for TeX because I would not know how to coexist peacefully with the tweaks to TeX that permitted the extra features of LaTeX. E.g., I was in the TeX Users Group, TUG, from the beginning of TeX, way back there, and recall the remarks of Knuth on the tweaks to TeX to permit good mathematician Leslie Lamport to do LaTeX.
My take on LaTeX versus TeX: In TeX, often must essentially write software, code, must program, to get what want. E.g., with an analogy, can program in C, and the program can automate the baking of cookies, but there is nothing in the documentation of C from Kernighan and Ritchie about baking cookies and instead have to program the cookie part. Looking at the C code without the comments, won't see much of anything about cookies unless have used lots of identifiers, e.g., variable names, with mnemonics about cookies. So, have to write C code while thinking about cookies.
With this analogy, LaTeX is closer to a language about automating making cookies. E.g., some of my TeX macros have to do with tables of contents, cross references, numbering sections and subsections, references to entries in the bibliography, annotation of figures (bring in a BMP file but overlay TeX output on the figure), various cases of boxes, e.g., for foils, etc. Looking at my corresponding TeX macros, it just looks like code. E.g., I've implemented a push down stack for automatic storage, etc. TeX has some nice block structure features, something like in Algol or PL/I -- at the end of the execution of the block, as in Vegas, what happened in the block stays in the block or is just forgotten.
Well, I can believe that LaTeX has macros, commands, keywords, functions, features, whatever for the LaTeX version of all of those TeX macros I wrote. There is likely some variety and flexibility for the LaTeX versions.
So, with the analogy, with LaTeX, if I want cookies, then I get to type in LaTeX commands obviously about cookies and not just code that doesn't mention cookies.
AND I will have to read and understand the big books, at least two, on LaTeX, each book much bigger than Knuth's The TeXBook. Read more big books on software ....
But if I want very different cookies, or pizza, then I might have to write TeX macros as I've always done: THEN I might have to understand how early on Knuth tweaked LaTeX in ways done after The TeXBook; there I see big chances of software mud wrestling. I didn't have to mud wrestle with TeX: Knuth was very clear and precise; all I had to do was understand The TeXBook, and I did.
Or LaTeX does me a lot of favors, likely its way, how it believes I should do things. No doubt for nearly all new users of TeX, LaTeX is much easier than the TeX macros I wrote.
But maybe in some cases how LaTeX does things is not how I want to do things.
Besides, just with TeX can write not just math papers but whole books, books that look nice in all respects. And for big, technical books, will want cross references, and my TeX macros have those, too.
So, for me, TeX is plenty good enough, solves the problem, has excellent documentation, is essentially totally free of bugs, and, did I mention, I'm happy as a clam.
So, I love TeX but don't use LaTeX, and don't want a GUI for TeX.
I can understand that for just some start on getting math into HTML pages, the OP, MathJax, or whatever, is a big help.
I have a friend who for years tried to get me to write software to generate HTML code from TeX input. I told him, TeX is a programming language, complete with if-then-else, do-while, expressions, assignment statements, etc. and HTML is not and is just a markup language. So in principle can't translate TeX input to HTML. But there is something that can be done: Just generate the TeX output as graphics, that is, BMP, GIF, PNG, or TIF files, put those in HTML as just images, and call it done. Or better yet, put the TeX output in a PDF file and call it done.
Broadly I'm sorry: As best I can tell, it looks like Tim Berners-Lee when he designed HTML had seen and understood TeX and other markup languages. Soooooo, why didn't he design HTML to be as good for math as TeX? Heck, he was at CERN with lots of physics and math. Well, a guess is that he wanted HTML to be much simpler than TeX, that the extra difficulties of TeX would be of interest to less than 1% of his target users of HTML. So HTML took over the world, maybe trillions of HTML Web pages out there. Then, now so many years later, that 1% wants some math in HTML. Uh, sorry 'bout that! Sounds like they have been happy with a Toyota Camry for 20+ years and suddenly now want something different, maybe either a Lamborghini or a Chevy 3500 Silverado. Sorry 'bout that.
So, to summarize, for some math in a Web page, can:
(1) Can do what I do with screen captures of TeX output and get some displayed equations but still are a long way from getting all of TeX.
(2) Get a GUI for much of what I do with (1) and have the work easier.
(3) Send a PDF file of the output of essentially anything from TeX or LaTeX.
But really doing math in HTML and as good as TeX, not so easy. And for a GUI for TeX, people have tried that, but personally I don't want a GUI for TeX.
In the end we used MathJax pre-rendered on the server, which is the same speed as pre-rendered KaTeX: https://github.com/mathjax/MathJax-node
We’ve also done lots of tweaking to make it support as much stuff on the arXiv as possible. Our MathJax config is a fun read: https://github.com/arxiv-vanity/engrafo/blob/master/src/conv...