Fixed a spacing issue involving sizing commands and operators

[kevinbarabash]

This addresses issue #30.

TODO:

• rebase
• add screenshotter tests

[xymostech]

This doesn't really fix the general problem, just a specific case of it. For example, something like 1 + \Huge x still doesn't work. (Perhaps I should have been more clear in my issue, it was mainly meant as a reminder to myself :P)

[kevinbarabash]

I investigate that scenario as well but it looked like it was doing the right thing. There's an mord space to the left the "x". I tried creating an empty mbin as a sibling before the "x", but it added too much space (compared to MathJax's output).

This screenshot compares 1 + \Huge x without and then with the extra mbin.

What would you like me to do?

[xymostech]

Okay, sorry. That was a bad example, because it does what you want, but not for the reason you want. Here's a better example:

{)\Huge x}{)\Huge +x}

In MathJax, it (correctly) puts space to the left of the +, and none next to the x:

This doesn't, because the interaction here is a close-bin interaction:

I'm not sure what the solution to this is. It might be something like "put an empty element of the previous type inside". I'm also not sure whether the want the space to be modified by the \Huge (like it is now), or to be of regular size? Obviously, things completely outside of \Huge should have non-\Huge spaces, and things completely in \Huge should have \Huge spaces, but I'm not sure about the stuff along the border. Also, we need to make sure that if the space at the beginning is \Huge, then the space at the end is also \Huge, or vice versa.

[kevinbarabash]

I looked at the MathJax rendering of this scenario and variations on it. It appears that if there is a space between something \Huge and something non-\Huge then the space is smaller. In order to fix this, I got rid of the empty mord and instead set the <span> containing the \Huge to be a mbin instead of an mord.

Here's MathJax's rendering for comparison:

I also tried {)\Huge x}{)\Huge +}x because I wanted see what spacing would like on the other side of the operator. Here are screenshots of that in KaTeX (with the fix) and MathJax.

[kevinbarabash]

I took the other tests out because the string I would've needed to match would've been quite long making the test prone to failure from unrelated changes. I was thinking about using jQuery in the tests to verify the structure of some of the markup that's being produced. Thoughts?

[xymostech]

I think that this isn't something that should be tested with code, but should probably use a Huxley test instead. Generally, it's not helpful to verify that the code we write produces the structure we tell it to produce, because the test will just ensure that we produce the code tells it to, and not that the produced output is useful. The Huxley tests ensure that the code we write produces something that looks correct.

Did you ever get huxley tests to work?

[kevinbarabash]

I haven't spent much time looking at them. I did install docker though. I'll work on getting them running today. Are you happy with the current solution? If so, I'll create some Huxley tests.

[xymostech]

How are you testing MathJax? If you go here, you should get something that uses the same fonts as KaTeX does, so it's easier to tell the difference.

[xymostech]

This is really just turning in to special casing for all of the different interactions, which is annoying to deal with (and there are a whole lot that aren't captured here). As @spicyj points out, MathJax doesn't actually do spacing with \Huge correctly, and we're not entirely sure how we want to do spacing overall, so maybe we should put this on hold until we can discuss what we want exactly to happen.

[kevinbarabash]

Line 778 is totally wrong. The intent is right, but the implementation is wrong. Ugh. Fix coming shortly then I'll leave it there while we discuss what to do.

[kevinbarabash]

I was using http://www.mathjax.org/demos/scaling-math/. I tried the fiddle, but it's using the same fonts as the MathJax site.