Thank you @rajnisht7 for the contribution! It would be great to fix this bug.

However I'm not totally confident that we can count on the viewBox attribute to get the correct width and height. If you think this approach is reliable, could you provide a bit more explanation?

If you can provide steps for reproducing and verifying the fix, that would also be helpful.

Also, we have recently updated the MathJax handling to support MathJax v4. Any approach used here will need to work with the new MathJax logic and support MathJax v3 and v4. Those changes are on the v4.0 branch, which will be merged into master on the release of the 4.0 version. So I would recommend that you either rebase these changes onto the v4.0 branch, or wait until v4.0 has been merged into master and verify whether the fix still works with the latest MathJax changes.

Thanks for your work so far!

@emilykl Thank you for the review, MathJax draw its math using its own internal units wherer 1000units =1em which was confirmed by a MathJax member on this issue mathjax/MathJax#2003 (comment)

The viewbox on the svg that MathJax creates already contains the exact size info, and we also know the real font size of text, we can turn that into real pixel size with

pixelWidth = (viewBoxWidth / 1000) * fontSizeInPixels

and it works better than Drawing.bBox() because it never use math. getBoundingClientRect(), it just reads an attribute and does math. getBoundingClientRect() is the part that gives wrong answer in some browser for this kind of element

and if anything about this is missing or doesn't give a proper number,the code falls back to the old Drawing.bBox() behavior, so worst case, nothing changes from before.

it can be tested using: open this file in firefox test/image/mocks/legend_mathjax_title_and_items.json and test with fix and without fix

also applied the same fix to the v4.0 branch. That branch still has th exact same line (Drawing.bBox(mathjaxNode)), so the same problem exists there too.