Use baseline shift when positioning inline math PNGs or SVGs
OpenPublic

Description

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.


Version: unspecified
Severity: normal
URL: https://www.mediawiki.org/wiki/Requests_for_comment/Reduce_math_rendering_preferences#Issues_5706

bzimport added a project: Math.Via ConduitNov 22 2014, 12:03 AM
bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz32694.
brion created this task.Via LegacyNov 28 2011, 9:56 PM
brion added a comment.Via ConduitNov 30 2011, 12:04 AM

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.

brion added a comment.Via ConduitDec 5 2011, 11:21 PM

Created attachment 9619
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...

Attached: work2

brion added a comment.Via ConduitDec 5 2011, 11:21 PM

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.

brion added a comment.Via ConduitMar 2 2012, 12:42 AM
  • Bug 6636 has been marked as a duplicate of this bug. ***
TheDJ added a comment.Via ConduitMar 24 2012, 3:46 PM

"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.

Aklapper added a comment.Via ConduitJan 9 2013, 1:34 PM

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]

Bawolff added a comment.Via ConduitJan 9 2013, 9:12 PM

(In reply to comment #6)

Brian:

Wrong brian :-P

Aklapper added a comment.Via ConduitJan 10 2013, 10:02 AM

Yeah, I realized when submitting and could at least still 1 out of 5 of my comments. Sorry, Brion. :)

Aklapper added a comment.Via ConduitJul 24 2013, 12:43 PM

Anybody willing to rework / put that patch into Gerrit?

bzimport added a comment.Via ConduitNov 30 2013, 5:05 PM

physik wrote:

mh... I'm wondering if this is still an issue? We have SVG rendering now... I suggest to close this ticket.

Aklapper added a comment.Via ConduitDec 2 2013, 10:23 AM

Closing as per comment 10

SalixAlba added a comment.Via ConduitOct 24 2014, 6:22 AM

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.

fredw added a comment.Via ConduitOct 24 2014, 6:44 AM

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).
Pkra added a comment.Via ConduitOct 24 2014, 8:02 AM

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.

GWicke added a comment.Via ConduitOct 26 2014, 6:44 PM

@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.

Pkra added a comment.Via ConduitOct 26 2014, 7:15 PM

@Gabriel I'll look into it.

GWicke added a comment.EditedVia ConduitOct 27 2014, 6:00 PM

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.

Kulla awarded a token.Via WebNov 24 2014, 7:22 PM
Kulla added a subscriber: Kulla.
Physikerwelt claimed this task.Via WebMay 29 2015, 2:09 PM
Physikerwelt set Security to None.
Physikerwelt added a comment.Via WebJun 6 2015, 2:51 PM

@GWicke. This has already been impemented in the current developmen branch of MathJax https://github.com/mathjax/MathJax/edit/develop/unpacked/jax/output/SVG/jax.js (Line 2074)

GWicke added a comment.EditedVia WebJun 8 2015, 11:09 PM

@Physikerwelt, this code does indeed look like the margins are now ex-based. Would be good to verify this in the new output once the develop branch is released. Do you know when that will be the case?

Physikerwelt added a comment.Via EmailJun 9 2015, 5:22 AM

No. But I created a "bug" asking if that change could be cherry picked
https://github.com/mathjax/MathJax/issues/1201

gerritbot added a subscriber: gerritbot.Via ConduitJul 13 2015, 9:05 PM

Change 218350 had a related patch set uploaded (by Physikerwelt):
Update dependency to mathjax-node 0.2.8

https://gerrit.wikimedia.org/r/218350

gerritbot added a project: Patch-For-Review.Via ConduitJul 13 2015, 9:05 PM
Physikerwelt added a comment.Via WebJul 13 2015, 9:18 PM

There it is... but it's really hard to see difference.

gerritbot added a comment.Via ConduitJul 13 2015, 10:49 PM

Change 218350 merged by Mobrovac:
Update dependency to mathjax-node 0.2.8

https://gerrit.wikimedia.org/r/218350

Prod added a subscriber: Prod.Via WebJul 20 2015, 10:26 PM
Prod removed a subscriber: Prod.Via WebJul 22 2015, 7:03 AM
Jdforrester-WMF moved this task to Next-up on the Math workboard.Via WebWed, Sep 2, 5:39 PM

Add Comment