Fix \vec

[ronkok]

For the accent \vec, replace the combining font glyph with an SVG.

[ronkok]

This PR is written to fix issues #735 and #996.

\vec uses a combining character and does not have a character preceding it within its span. Safari, unlike other browsers, does not recognize the negative xMin value for such a character, so it renders \vec too far to the right.

This PR replaces the glyph with an SVG whose path is copied from the glyph. Let’s all just agree that this is an ugly hack. It is defensible only because user agents cannot be trusted to handle combining characters consistently.

The people over at MathJax must have come to the same conclusion. Their approach is also, by their own admission, a hack.

[k4b7]

I missed HorizontalBraces... PR in coming.

[k4b7]

KaTeX is in red, LaTeX is in green. The accent spacing looks really consistent except for over xA, but that's very minor and wouldn't worry about it.

[ronkok]

There was an alternative approach that I examined. If one prepends a non-breaking space before the combining character U+20D7, Safari will then treat it in the same way as the other browsers that I tested.

The problem then shifts to the vertical alignment. When the arrow is so treated, none of the browsers place it in the vertical position consistent with the glyph's yMin value. It's lower. By my eyeball test, it looks to be vertically centered on the x-height. But that is not documented anywhere that I can find. Rather than depend on something so dicey, I wrote the SVG.

[k4b7]

Rather than depend on something so dicey, I wrote the SVG.

Good call. I should be able to review this tomorrow.

[edemaine]

@ronkok Indeed, I'd tried that hack (based on the MathJax hack, which I think you originally pointed me to) in an intermediate version of #802, and also couldn't get it to work. (I think MathJax has the luxury of doing different things depending on the browser. KaTeX can't do that, offline...) Thanks for finding another way! Given that most (long) accents are now drawn in SVG, this seems like a nice fix.

Just to point out: There is an alternative, to modify the font so that it has a non-combining version of the character. This is why \acute and all other accents work (I assume) in Safari. But I have never touched the fonts, so don't know how hard this approach is, or which is preferable.

[ronkok]

There is an alternative, to modify the font so that it has a non-combining version of the character.

That would be better. But fonts are beyond me. Hopefully, someone can make the font modification in some future PR. This PR can be a good enough temporary measure.

[k4b7]

This all looks quite reasonable. Thanks for fixing this issue in a way that works with server side rendering.

[k4b7]

nit: only for space spaces before the //

[k4b7]

I don't think the parens are necessary here. Also, flow can do type inference so you should be able to get away with:

const svgData = {
   vec: ["vec", 0.471, 0.471],
};

And flow will complain about things like: svgData.vec[1].length but will be fine with svgData.vec[0].length.

[marcianx]

I don't think flow will infer a tuple type, but a more type-unsafe heterogeneous array. One could try to check.

My personal bias is to favor explicit typing to make the intention clear and better documented.

[ronkok]

I was following the example set by @marcianx during the conversion of stretchy.js to flow.

[k4b7]

We can totally leave it in. It gets compiled away anyways.

[k4b7]

I restarted the build.