Last modified: 2014-11-17 10:35:56 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 32694 - Use baseline shift when positioning inline math PNGs or SVGs
Use baseline shift when positioning inline math PNGs or SVGs
Product: MediaWiki extensions
Classification: Unclassified
Math (Other open bugs)
All All
: Normal normal with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-reviewed
: 6636 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2011-11-28 21:56 UTC by Brion Vibber
Modified: 2014-11-17 10:35 UTC (History)
12 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---

Patch in progress (8.39 KB, patch)
2011-12-05 23:21 UTC, Brion Vibber

Description Brion Vibber 2011-11-28 21:56:29 UTC
This is a feature that blahtex has which is very nice, and was suggested from <> 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.
Comment 1 Brion Vibber 2011-11-30 00:04:07 UTC
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.
Comment 2 Brion Vibber 2011-12-05 23:21:13 UTC
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...
Comment 3 Brion Vibber 2011-12-05 23:21:59 UTC
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.
Comment 4 Brion Vibber 2012-03-02 00:42:46 UTC
*** Bug 6636 has been marked as a duplicate of this bug. ***
Comment 5 Derk-Jan Hartman 2012-03-24 15:46:27 UTC
"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.
Comment 6 Andre Klapper 2013-01-09 13:34:09 UTC
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!
Comment 7 Bawolff (Brian Wolff) 2013-01-09 21:12:44 UTC
(In reply to comment #6)
> Brian:

Wrong brian :-P
Comment 8 Andre Klapper 2013-01-10 10:02:26 UTC
Yeah, I realized when submitting and could at least still 1 out of 5 of my comments. Sorry, Brion. :)
Comment 9 Andre Klapper 2013-07-24 12:43:29 UTC
Anybody willing to rework / put that patch into Gerrit?
Comment 10 physikerwelt 2013-11-30 17:05:04 UTC
mh... I'm wondering if this is still an issue? We have SVG rendering now... I suggest to close this ticket.
Comment 11 Andre Klapper 2013-12-02 10:23:50 UTC
Closing as per comment 10
Comment 12 Richard Morris 2014-10-24 06:22:01 UTC
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

An example can be found at 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.
Comment 13 Frédéric Wang 2014-10-24 06:44:20 UTC
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).
Comment 14 Peter Krautzberger 2014-10-24 08:02:05 UTC
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;

Comment 15 Gabriel Wicke 2014-10-26 18:44:37 UTC
@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.
Comment 16 Peter Krautzberger 2014-10-26 19:15:04 UTC
@Gabriel I'll look into it.
Comment 17 Gabriel Wicke 2014-10-27 18:00:01 UTC
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 =;
-          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.

Note You need to log in before you can comment on or make changes to this bug.