I see something similar on linux. For SVGs, MathJax emits sizes and offsets in ex, which is the x-height of the CSS font. This ensures that the math scales relative to the CSS font. However, exactly matching the size of the text might not be desirable, as small parts like indices might get hard to read.

There are some parameters we can tweak: http://docs.mathjax.org/en/latest/options/SVG.html

It is possible that the increased size is caused by minScaleAdjust, which aims to ensure that small indices remain legible. Another setting to look into is matchFontHeight. We'll have to experiment a bit.

@GABRIEL in case it's not clear, those options refer to MathJax not MathJax-node. To make these work in MathJax-node you'd have to load a richer page template and use not just a DOM simulator like jsdom but a full HTML/CSS engine.

Long story short, you can specify ex height in MathJax-node https://github.com/mathjax/MathJax-node/blob/master/lib/mj-single.js#L42

However, assuming Wikipedia's CSS has several font options, there's a good chance somebody will always see sub-optimal results. No way around this with static images.

@Pkra this basically means that it can't be fixed?

@Physikerwelt I don't have enough information.

BTW the "boldness" in the OP is due to the fact that SVGs don't get subpixel rendering. There's a "blacker" configuration option to control stroke width but SVG browser implementations vary quite a bit. This effect is less prominent if the surrounding font size is larger.

In T74553#762349, @Pkra wrote:

However, assuming Wikipedia's CSS has several font options, there's a good chance somebody will always see sub-optimal results. No way around this with static images.

@Pkra, if all measurements are relative to ex (and afaik currently only the margins remain px-based?), shouldn't at least the size scale well relative to whatever the CSS fonts specify?

https://en.wikipedia.org/wiki/X-height#Use_in_web_design might also be relevant:

The use of ex in dimensioning objects, however, is less stable than use of the em across browsers. Internet Explorer, for example, dimensions ex at exactly one half of em, whereas Mozilla Firefox dimensions ex closer to the actual x-height of the font, rounded relative to the font's current pixel height. Thus, the exact ratio of ex to em can also vary by font size within a browser if the determined values are rounded to the nearest whole unit. For example, a browser calculating an x-height of 45% on a font 10 pixels tall may round ex to either 4 pixels or 5 pixels or leave it at 4.5 pixels.

shouldn't at least the size scale well relative to whatever the CSS fonts specify?

My comment was referring to a situation where mathoid overrides this.

@GWicke Just FYI. I've recently looked into "boldness" problem of the SVG output. It seems cross-browser/platform problems with blacker have resolved and blacker: 1 now yields consistent results that are closer to font rendering. We'll be looking into this in more detail after v2.5 is out of beta.

Any progress on this? Just had another report on this issue (OTRS ticket 2017030910017821). Screenshot attached.