Last modified: 2014-11-17 10:35:56 UTC
This is a feature that blahtex has which is very nice, and was suggested from <https://www.mediawiki.org/wiki/Requests_for_comment/Reduce_math_rendering_preferences> as something that should help make 'always render' a more acceptable default. dvipng has --height and --depth options which can be used to figure out where the text baseline in the image is. This can then be used in inline CSS to position the image relative to the actual text baseline, and should make things match up inline more often. This should not be terribly hard to adapt, though will require some tweaks: * drop dvips support, use dvipng exclusively * include the parameters when texvc calls dvipng -- OR -- move dvipng call to PHP side * capture the data and record it * make use of it in rendering Existing items should be invalidated so they won't conflict.
Sticking this on my assignment list explicitly. While we're looking at MathJax for main rendering, if this can be done easily we still need those fallback images, so it'd be nice to position them properly.
Created attachment 9619 [details] Patch in progress In-progress patch to use dvipng's -depth option to get baseline, and use that for vertical-align on the output image. Adds use of 'preview' package to the latex source which is required for getting proper numbers out of this, supposedly. Unfortunately the baseline depths I'm getting tend to be in the 0-1px range, even for things with 'q' and a longer descender than that, or fractions or square roots where parts will descend down from a generalized baseline. Not sure if I'm doing it wrong, or if the data just isn't good...
Patch also changes texvc to produce only the .dvi file, and does the dvi->PNG rendering from the PHP side so we can more easily do the output processing. Adds a math_baseline field to the 'math' table to store the offset.
*** Bug 6636 has been marked as a duplicate of this bug. ***
"Unfortunately the baseline depths I'm getting tend to be in the 0-1px range, even for things with 'q' and a longer descender than that, or fractions or square roots where parts will descend down from a generalized baseline. Not sure if I'm doing it wrong, or if the data just isn't good..." @Brion I remember I tried implementing the same thing about 3 years ago (quite sure there is another ticket about this topic), with similar result. Haven't looked at it since.
Brian: This report has been in ASSIGNED status for more than one year and you are set as its assignee. In case that you are not actively working on a fix, please reset the bug status to NEW/UNCONFIRMED. In case you do not plan to work on a fix in the near future: Please also edit the "Assigned To" field by clicking "Reset Assignee to default", in order to not prevent potential contributors from working on a fix. Thanks for your help! [assigned>=1y]
(In reply to comment #6) > Brian: Wrong brian :-P
Yeah, I realized when submitting and could at least still 1 out of 5 of my comments. Sorry, Brion. :)
Anybody willing to rework / put that patch into Gerrit?
mh... I'm wondering if this is still an issue? We have SVG rendering now... I suggest to close this ticket.
Closing as per comment 10
This is now an issue with the new "MathML with SVG or PNG fallback" mode. It was brought up by David Eppstein at en:Wikipedia talk:WikiProject Mathematics#MathML rendering available http://en.wikipedia.org/w/index.php?title=Wikipedia_talk:WikiProject_Mathematics&curid=148395&diff=630880880&oldid=630878007 An example can be found at http://en.wikipedia.org/wiki/Mersenne_prime in Chrome the first formula is rendered 1 pixel to low. Things are worse in the PNG mode with font sizes of maths formula too big and the baseline out.
There are several cases here: - For the PNG mode / PNG fallback, we use "vertical-align: middle;". Not sure if this is what was used before (at some point we just dropped the vertical alignment). The real solution is probably what Brion Vibber wanted to do. - For the SVG fallback, we use values provided server-side by MathJax node. I'm not sure we can get something very accurate, given that the font-family / font-size of the surrounding text on the client-side may be different to the one of the SVG. - For the MathML rendering in Gecko, this works well for me (especially if you specify consistent font-family for the text/math in my user stylesheet).
I took a quick look at the first equation in the Mersenne Prime page. The problem seems to be the stripping of the margin values from the SVG. Reinserting the values generated by MathJax-node back into the DOM fixes the baseline. If you want to try it out, they are margin-left: 0ex; margin-right: 0ex; margin-bottom: 1px; margin-top: 1px; Peter.
@Peter: Would it be possible to emit a vertical-align that works without the margins? In this case, something like -0.4ex seems to work better than -0.5ex, and will also consistently scale relative to the x-height of the CSS fonts. The reason for stripping the margins is that we size the container for the fall-back image based on the width & height provided by the SVG. Extra margins on the SVG led to parts of the SVG being cut off. This might no longer be the case after the switch to loading the SVG as a background image (so that it isn't loaded if MathML is supported), but to me it still looks cleaner to directly emit the proper vertical-align in ex.
@Gabriel I'll look into it.
This patch seems to improve the baseline situation: diff --git a/node_modules/mathjax/unpacked/jax/output/SVG/jax.js b/node_modules/mathjax/unpacked/jax/output/SVG/jax.js index 4045a1e..e516a75 100644 --- a/node_modules/mathjax/unpacked/jax/output/SVG/jax.js +++ b/node_modules/mathjax/unpacked/jax/output/SVG/jax.js @@ -2042,11 +2042,11 @@ var style = svg.element.style; svg.element.setAttribute("width",SVG.Ex(l+svg.w+r)); svg.element.setAttribute("height",SVG.Ex(svg.H+svg.D+2*SVG.em)); - style.verticalAlign = SVG.Ex(-svg.D-2*SVG.em); // remove extra pixel added below plus padding from above + style.verticalAlign = SVG.Ex(-svg.D); // remove extra pixel added below plus padding from above style.marginLeft = SVG.Ex(-l); style.marginRight = SVG.Ex(-r); svg.element.setAttribute("viewBox",SVG.Fixed(-l,1)+" "+SVG.Fixed(-svg.H-SVG.em,1)+" "+ SVG.Fixed(l+svg.w+r,1)+" "+SVG.Fixed(svg.H+svg.D+2*SVG.em,1)); - style.marginTop = style.marginBottom = "1px"; // 1px above and below to prevent lines from touching + //style.marginTop = style.marginBottom = "1px"; // 1px above and below to prevent lines from touching // // If there is extra height or depth, hide that // The ex size of the generated SVG is still larger than the surrounding font, and the passed-in ex option does not seem to work.
