Fix \pmb

[ronkok]

Fixes issue #1873.

[codecov-io]

Codecov Report

Merging #1924 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master    #1924   +/-   ##
=======================================
  Coverage   93.17%   93.17%           
=======================================
  Files          79       79           
  Lines        4892     4892           
  Branches      861      861           
=======================================
  Hits         4558     4558           
  Misses        294      294           
  Partials       40       40

Flag	Coverage Δ
#screenshotter	88.91% <100%> (ø)	⬆️
#test	86.77% <100%> (ø)	⬆️

Impacted Files	Coverage Δ
src/macros.js	97.63% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3b60aee...6d6fcdf. Read the comment docs.

[edemaine]

Thanks for investigating this! Does this mean that \raisebox is generally broken in Safari? By just a small amount or larger amount? I guess I'm wondering, should we just fix \raisebox/makeVList instead of changing the definition of \pmb?

[ronkok]

I agree that the long term solution is to fix makeVList. I don't know how to do that quickly and I am not positive that I have an idea that works at all. I guess I should describe the problem.

When PR #768 rewrote makeVList, it had to overcome Safari problems. One was that the code needed a zero-width span with which to define depth. Safari refused to render a zero-width span and the work around was to define a span that was 2px wide and then give it margin-right: -2px; to correct the position. That works well until you want to run adjacent very narrow spans next to each other. Then the actual width of the span matters.

It's possible that makeVList can be written with CSS flex as @kevinbarabash proposed in issue #1409. @ylemkimon is of the opinion that before using flex we should first have a major release that deprecates old IE versions. So the flex option is not a quick fix.

And we need to remember why PR #768 was written in the first place. Prior to that PR, in math that contained a tall element, the HTML font ascent and line height distances would occasionally create something that looked like a large margin above the KaTeX rendering. PR #768 fixed that problem by putting the math into a display: inline-table; span. I don't know if CSS flex accomplishes the same thing.

If CSS flex doesn't work, I have one more idea to try. Remember I said that "Safari refused to render a zero-width span". That may be fixable by declaring max-width: 0;. I don't know if it is possible on the relevant span because that span also has some other hacks going on to prevent a Chrome problem. And I'd really like the CSS flex idea to work first. The HTML would be much simpler.

[ylemkimon]

What about MathML output?

[ronkok]

This code produces MathML that also renders as a simulated bold. In the screenshot below, the three versions are from MathJax, KaTeX, and KaTeX-MathML:

[ylemkimon]

@ronkok Currently MathML is used for accessibility, and I think it'd be better to render only once, maybe with \mathbf like before.

[ronkok]

Yes, MathML is currently used only for accessibility, but that will only be true until #1928 is resolved. More importantly, \mathbf is currently ineffective in KaTeX MathML. You can verify this by looking at the entry for \pmb in http://webmathcomparison.net/#p.

I haven't yet investigated why this occurs, but I suspect some sort of bug similar to what I address in PR #1929, which applies classes such as \mathbin in MathML.

[ronkok]

@ylemkimon I have revised the MathML as you requested, using \mathbf. So this PR can be merged. But I consider the larger matter unfinished at least until \mathbf works in MathML.