xymostech

Are you viewing on a HiDPI monitor? I imagine this is mostly because RaTeX renders to an image whereas KaTeX is rendering HTML, so can scale to arbitrary dpi. I imagine the RaTeX people could have rendered to a higher resolution and it would look better.

What are you struggling with? If you want an image output, there a reason you want to use KaTeX for this, and can't just use actual LaTeX?

KaTeX depends on the browser engine to do most of the layout, so generating an image would require a tool which converts the HTML nodes back into an image. There are some tools that can do that (like html2canvas), but using LaTeX to generate a PDF and then converting that to an image is probably going to be easier.

Oh yes, thank you for the link to that! Looks like that is an instruction set for representing the font glyphs themselves? I was talking about the instruction set in TFM which is for representing meta information, like ligatures and kerning between glyphs, and not for the actual glyphs. The glpyhs for the original TeX fonts are described using Metafont which is an interpreted language.

The original TeX Fonts stored their metrics in TFM (short for TeX font metrics) files, which contains a bytecode interpreter for calculating ligatures and kerning between characters. I learned about that when I tried reading the files myself.

From what I can tell, modern fonts using OpenType just have tables to accomplish something similar now, in the form of the GSUB and GPOS tables?

Documentation for the TFM format here: https://tug.org/TUGboat/Articles/tb02-1/tb02fuchstfm.pdf (search for lig/kern)

My source was also the Lawful Masses stream, but it sounded like the original excuse was made in April, but it took until November for him to actually produce the death certificate to prove that he had lied about when his grandfather had died.

2 days ago (12/27), "Web Hosting Service" was the most common page visited, with <0.1% mobile (compared to >70% for the rest of the top 10). Did something happen that would cause this? Or is this a bot farm that's visiting wikipedia? Odd.

Edit: Looks like there were also around 3m "automated" views to the page based on user agent. Maybe some bot script went awry but used non-bot user agents half the time?

I think by "each system call" she meant it like "every time it calls read()", since it would be read() that was using the AVX registers. Since the example program just calls read() over and over, this could add a significant amount of overhead.

Based on snooping around the javascript, it looks like probably https://en.wikipedia.org/wiki/Gallery_Project

This was such a wonderful read! I've been getting into Rust recently, and the sections on dealing with challenges that are specific to Rust were particularly useful. The way they created a new trait to turn `Fn(&str) -> Result<(&str, T), &str>` into `Parser<T>` was insightful, and the discussion of how they dealt with the growing sizes of types was something that I can imagine myself running into in the future.

Most importantly though, when they started writing `and_then`, my eyes lit up and I said "It's a Monad!" I think this is the first time I've really identified a Monad out in the wild, so I enjoyed that immensely.

I think you should be able to put those settings into your X11 configuration so you don't have to re-configure every time you boot, unless xinput on Ubuntu is different from Arch: https://wiki.archlinux.org/index.php/Libinput#Common_options (Although debugging xorg config files is not a terribly fun exercise :/)

Flow actually explicitly allows this[1] by just /* */ commenting out the flow type signatures. We use this in Aphrodite's code base[2] and it works pretty well.

[1] https://flowtype.org/blog/2015/02/20/Flow-Comments.html

[2] https://github.com/Khan/aphrodite/blob/master/src/generate.j...

You can try them out in your own browser easily by visiting them from rawgit: https://cdn.rawgit.com/pcwalton/webrender-demos/master/moire...

Woah, awesome. I've used the http://dnstunnel.de/ tunneling scripts before, and they're a bit of a pain to setup (mostly because of the perl library requirements).

There's no real "secret sauce", it's mostly just "do things smart". For example, while MathJax tends to do a bunch of calculations about exact positions of where different characters should go, KaTeX manages to get away with offloading most of that into the CSS, so the native CSS renderer can handle it.

MathJax also does strange things involving inserting elements into the DOM to look at metrics that it uses in its calculations, then removing them, which takes a lot of time. We make sure that the same input is rendered the same every time, and try to make sure it looks good everywhere (there are a couple cases where we aren't the best at this, mostly because browser font rendering isn't great).

We also support less environments than MathJax, for example we only support HTML+CSS output (for now, though MathML is in the works for accessibility reasons), whereas MathJax supports HTML+CSS, SVG, MathML, and older browsers like IE 6. This means it can't rely on things like good CSS rendering like we do. It's a worthwhile tradeoff for us, because we can make ours so much faster, but it is a tradeoff.

Hey! We're planning on adding environments (everything that uses \begin and \end) sometime soon. There's a couple github issues touching on this point; if you want to know how development's going, you can follow one of the issues.

The syntax will be almost entirely interchangable with MathJax; we also have a lot of content in MathJax-flavored-TeX and need it to work. However there are a couple small things that MathJax did strangely that we'd like to fix.

However, there are some features we don't support yet, notably environments (with \begin/\end) and some symbols. If you're using more advanced features, you might hit some snags. If you're trying to do something simple and it's not working, feel free to submit an issue on github, we'll see what we can do for you.

There's a lot of choices. We support a smaller subset of browsers and outputs (only IE8+, only HTML+CSS, no SVG), so we gain some speed there. We also try to push as much of the calculation into CSS as possible, so that the native browser does as much work as possible, instead of the javascript. MathJax does a lot more manual positioning.

This is definitely a goal for the future. Eventually we'd like to support everything that MathJax does (and maybe more!) Equation numbering involves more work than some of the other features (we've managed to get away with never calculating widths of elemnts, but we'd have to do that to get horizontal alignment working, we think), so we're pushing it back for now.

There aren't any plans at the moment. We've struggled with this problem before, and wrote something similar with https://github.com/khan/KAS/ but we've never worked at doing something inline. We use MathQuill in a couple places, which does the input decently (writing works, but typing something like x^2_2 gives you x^{2_2} not x^2_2), but the output doesn't look great. It's hard to do what the user wants, have clickable bits, and still have good looking output.

We never do any unsafe dom manipulations, like using .innerHTML, only createElement and appendChild, so things should be fairly safe. Also, if you do server-side rendering, we escape code that users type in, so that should work well also.

Sounds great! If you have any problems, feel free to report issues on github, or join the #katex room on freenode.

We won't support ASCIIMath yet. There's a lot of content on the web already in LaTeX syntax (and on our own website), and a lot of people already know it. It is difficult to use and read, but it gets the job done. Maybe once we've gotten all of the core LaTeX features done, we'll start looking to this. Thanks for the info, though!

Ah. Yes, the diagram generating libraries are harder to implement. Since we don't actually implement the primitives that TeX uses, we can't just import libraries like xypic or tikz wholesale, we'd have to rewrite them from scratch. Maybe a project for when we've got most of the actual math working.

As for why we didn't work with MathJax, this started out as more of an internal project for making our own math fast, and has slowly built up to what we have today.

We also didn't think that we could get the speed we wanted while still supporting all of the obscure features MathJax does (like SVG rendering).

I've never heard of this before, could you let me know what it is?

We reimplemented the TeX formatting algorithms in JavaScript. Most of them are in https://github.com/Khan/KaTeX/blob/master/src/buildTree.js (there are references to the pages from the TeXbook that the algorithms are on).

Also, we attempt to have relatively good error handling! If you open up the javascript console on the main page and type in a bad expression, you can see what the errors we throw look like. We're not planning on supporting anything other than LaTeX syntax for now though, unfortunately.

We don't use features like this at Khan Academy. However, most of the time the problems with MathJax were with the inital problem load, not with changing expressions later. It might be interesting to support something like that eventually! Let me know how it works for you.

There isn't yet, but we're working on it! We have the fonts ready, just haven't added those functions yet. Could you make an issue on the github page so we make sure we don't forget?

Unfortunately, we're not. We might support that in the future though.

Yep, that's our goal. Khan Academy does a bunch of math rendering, and our exercises were suffereing because of it. Hopefully some time we'll be able to stop using MathJax.

We try to test in lots of different environments, so it should work reasonably in most environments. To get the speed we wanted, we had to ditch much older browsers (we don't support IE 7 and earlier), and we only render to HTML/CSS, not things like MathML. However, we're so far very happy with the look of the math in the environments we've tested.

KaTeX works great in a headless environment. You can even do server side rendering if you want a browserless environment which can serve up straight HTML with no JS.

Both KaTeX and MathJax's biggest slowdown is the font loading. However, since KaTeX's CSS can be included manually (instead of letting MathJax put it in the DOM after load) it should load a little faster.

Also, looks like your use cases are similar to ours at Khan Academy! We've been struggling with MathJax on slow computers and iPads for a while, which is why we made this. Let me know if you want more info!