v4-beta.3 STIX Two vertical space within square root

[pkra]

Again, this might be intended but I'd like to check.

E.g., $$\sqrt {\log r}$$

With the new default font:

With the new STIX Two

With the "old" STIX Two

same expression with v4

In v4, STIX Two seems to have gained extra space within the root, both below and above the inner expression.

[pkra]

I used the wrong image for "old" stix2 -- I've updated it (with a larger sample).

[pkra]

For completeness, "real" LaTeX seems to give me the tighter spacing as well.

[dpvc]

I will have to look into it. Can you say what the "old" STIX Two refers to? Is that the old stix2 branch, or an earlier v4 beta release?

[pkra]

Thanks, Davide.

Can you say what the "old" STIX Two refers to? Is that the old stix2 branch, or an earlier v4 beta release?

The old stix2 branch.

[dpvc]

OK, here's the situation: TeX's rules for determining the height of the surd to use for a root is that the spacing between the top of the radicand and the rule above it should be at least the default rule thickness plus $\varphi / 4$ where $\varphi$ is the x-height in display mode or the rule thickness in all other modes. So the height of the surd is $h + d + 2\theta +\varphi / 4$, where $h$ and $d$ are the height and depth of the radicand, $\theta$ is the default rule thickness, and $\varphi$ is as above. (Here, we have $2\theta$ because one is for the line above, since the surd must cover that as well, and one for the separation between the rule and the radicand.)

In the old stix2 branch, I hadn't yet set the stix2 font parameters to the correct values for STIX2, so in particular, the x-height was the one from the TeX fonts, which is .442em. In the current beta version of mathjax-stix2 the x-height has been set to the actual height of the "x" in the STIX2 italic font, which is 0.479em. That extra 0.037em is enough to push the surd to the next size in display equations where the radicand contains both an ascender and a descender. (There is also a slight different in the default rule thickness, with stix2 being .008em larger at .068em. We added that to make the rule match the surd a bit better, but removing it is not enough to prevent the size increase.)

The original TeX fonts seem to be set up so that the smaller surd will suffice for a radicand with both ascender and descender in display mode. That doesn't seem to be the case for the STIX2 fonts. It may be that the default rule thickness in the actual STIX2 fonts is smaller, and that due to the relatively low resolution of computer screens, I had to increase the default rule thickness in order to prevent the rule from disappearing at small sizes (or from bumping into the radicand). Setting the rule thickness to .059em prevents the jump in size (but makes fraction rules a little too small).

This is one of many places where TeX puts important details of the layout into the hands of the font itself. It is hard to make sure everything works as needed, sometimes.

[pkra]

Thanks, @dpvc.

I'm not sure what the conclusion is. It sounds like this is not expected but due to the adjustments you made. Is a fix in the card (in the long run)? If so, can I do anything to help?

I'm also not sure if the thickness problem was CSS/webfont or SVG related (or both). I'm happy to experiment with changing the rule thickness on our end if that's a way to work around this.

[dpvc]

It's true that the default rule thickness of .06em is larger than the one used for CM fonts (which should be .04em) in order to avoid it disappearing at small sizes. I've just checked Firefox, Chrome, and Safari, however, and it seems they are better about not letting thin horizontal lines disappear any more, though they can get pretty light at small sizes via antialiasing. With the lighter mathjax-modern font, it might be OK to set this down to .05em or even the original .04em.

Of course, these are font-based settings, so each font could have it set to whatever is best suited to the font. You can use

MathJax = {
  startup: {
    ready() {
      MathJax.startup.defaultReady();
      MathJax.startup.document.outputJax.font.params.rule_thickness  = .04;
    }
  }
}

and see what you think of that.

[pkra]

I finally got around trying this out. Thank you - it looks good client-side.

I'm struggling how to make the adjustment in a "direct" (in the sense of the nodejs demos repo) server-side setup. (I also tried subclassing SvgMsqrt but ran into other trouble - and it didn't seem the right way anyway.)

If you have time for a hint, I'd be grateful.

[dpvc]

It could be added in several places. The easiest might be right after creating the SVG output jax:

const svg = new SVG({...});
svg.font.params.rule_thickness  = .04;

Alternatively, it could come after calling mathjax.document():

const doc = mathjax.document(...);
doc.outputJax.font.params.rule_thickness  = .04;

I don't remember if you are instantiating the STIX font yourself, or just passing the font object in the configuration for the SVG output jax (probably the latter). If you are instantiating it yourself, you could set its params.rule_thickness value directly before passing it to the SVG constructor.

Any of those should do the trick.

[pkra]

Ah! The first example fits our setup. That's much easier then -- thank you!

[pkra]

I finally had time to run a quick test on a small random sample (a few dozen articles).

It looks like changing the rule_thickness has side effects I did not anticipate. From what I've seen so far, super- and overscripts are being placed significantly closer to their bases. While most of that looks ok, it sometimes seems too close (e.g., \hat{\mathbb{Z}} is almost touching the base).

Before testing (and pondering this) further, I was hoping to check if this is actually expected.