The alignment may seem to be off by a pixel in some of the fractions, but I believe that is because of the limitations of the PNG format. If the images are saved using the SVG format, it is clear (upon zooming in) that the alignment is correct.

Here's the test code.

import matplotlib as mpl
import matplotlib.pyplot as plt

for font in ['dejavusans', 'cm']:
    mpl.rcParams['mathtext.fontset'] = font
    fig, ax = plt.subplots()
    ax.axis('off')
    for size in range(10, 101, 10):
        ax.text(0, size / 20, r'$a=-\dfrac{b}{c}=-\dfrac{c}{b}=-\dfrac{.}{.}=-\dfrac{W}{.}=-\dfrac{.}{W}$', size=size)
    plt.savefig(f'sizes_{font}.png')

@timhoffm I wasn't sure if I'd be able to describe it properly, so I attached an image. Here, vlist.shift_amount has been set to zero. As a result, the fraction sits on the same line the rest of the text does.

shift is to be determined.

The first thing I noticed was that the space between the numerator and the vinculum is not the same as the space between the denominator and the vinculum. According to the source code (lines 2768 to 2770), both should be 2 * thickness. Surprisingly, the rendered spaces are 3 * thickness and thickness respectively! (This is true irrespective of the font used.)

With that in mind, shift can be deduced from the figure.

shift = cden.height + 1.5 * thickness - (metrics.ymax + metrics.ymin) / 2

Latex gives us:

which is substantially different than what we have currently, or with this change. Note that the b and c are aligned at their baseline. I think the fundamental problem with the minus sign is that the offsets are not being applied properly between the numerator and the denominator.

I'm not sure if half fixing this is worth breaking so many images?

The true algorithm is in the TeX book linked here. I tried a few things that didn't quite get all the way there, but maybe with this it would work?

Lets pop this to draft: @tfpf not sure how feasible it is for you to look into a more holistic approach here? If not, then it seems maybe we should get it right rather than whack-a-mole with different alignments?

That makes sense. I'll see if I can come up with a better solution.

Tried to study the algorithm LaTeX uses to draw fractions, and also made some observations independently. It looks like the numerator and denominator are shifted upwards and downwards respectively from the baseline. The shift amounts are font parameters, stored in font_info (an array).

Once the numerators and denominators have been shifted, LaTeX checks whether the actual clearance between them and the line is less than the minimum clearance. If so, LaTeX is happy to push them up or down to honour said minimum clearance (even if it means that all numerators and all denominators won't be on the same baseline), as seen below.

\dfrac{x}{x^2}\dfrac{x_{Hy}}{x}

However, since Matplotlib packs the elements of a fraction into a Vlist, I figured it might better to follow the same approach, but with spaces inserted wherever required.

This is what I got (red lines added by me using Paint).

The minimum clearance used here is half of what is mentioned in the LaTeX book. I couldn't figure out any alternative to the hard-coded multipliers (3/5 and 4/3), so I just let them be (for now).

That sure looks better. Thanks for looking at this so carefully - very much appreciated, as this was a lot more work than a quick change at this point.

Lets see how the tests shake out, and then hopefully there aren't any edge cases that this is not working on.

Almost all image comparison tests involving fractions will fail, though. Won't they?

Also, in hindsight, I guess vlist could probably be created directly instead of repeatedly appending items to vlist_builder.

For sure it will break the image tests. I just meant that hopefully it breaks them correctly ;-)

@tfpf When you get the new images, please include them as part of the PR (usually by copying from result_images into matplotlib/lib/tests/baseline_images)

I skimmed through a few image miscompares. For stix, stixsans, dejavusans and dejavuserif, the results aren't too bad. But cm doesn't behave well. An egregious example:

mathtext_cm_19.png	mathtext_cm_19-expected.png

The alignment of \frac{5}{2} in the numerator appears to be wrong, and the reference image seems to have got it right. However, if I try to generate the same fraction with a minus sign immediately after it:

it immediately becomes clear that the problem isn't the alignment of the fraction, but the alignment (or perhaps the rendering) of the plus sign. It's off by just one pixel, but looks like a big change because of the font size.

I think this will significantly affect the image comparison tests: even if we get the alignment right, it'll look wrong at small font sizes.

ETA: @jklymak Apologies, I didn't see your comment. What do you think about this? Should I include the images in the PR in spite of this rendering problem?

I'd be careful with 1-pixel changes. Matplotlib does funny things at pixel resolution like snapping lines to the nearest pixel. It looks possible to me that it is doing that for the fraction lines. Can you turn snapping off for those, at least as a test of the algorithm?

Passing snap=False or snap=True (is that the correct way to disable snapping?) to fig.text results in exactly the same image (the third image in my previous comment). Is that a bad sign?

I'm not familiar enough with the math mode to know. Maybe it's just hard coded in?

Okay, I found something interesting. mpl.rcParams['figure.dpi'] defaults to 100. My screen is rated 96 DPI. If I save that image with dpi=96, everything is perfectly aligned!

And this is despite using the Agg backend.

As for it being hardcoded, I am not sure, either. I haven't studied the source code apart from the _genfrac function.

I get yelled at for this, but I'm not too fussed about 1-pixel offsets - publication quality is 300 dpi or above. As long as it looks good at 200 dpi, I would not block on inconsistencies down at 100 dpi for such tiny fonts. Unless I pixel-peep I can't really see the differences in the above two examples, other than the "expected" looks cramped.

All right, then.

I want to take a look at some more image miscompares. For the next commit, I will add the images along with code changes (if any).

Looks like I accidentally committed all images which changed (1048 out of 1488) instead of just the ones flagged by pytest as mismatches (nearly 200). Should I undo the previous commit and add only the latter?

Yes please.

@matplotlib/developers Could someone take a look at the changes and review them?

@tfpf they are still not passing the tests, so not yet reviewable....

There are some SVG miscompares, but I can't reproduce them on my machine. Pytest skips the SVG comparison tests. I tried installing Matplotlib as mentioned in the contributing guidelines. Even tried supplying tests = True and backend = SVG in setup.cfg during installation.

$ pytest lib/matplotlib/tests/test_mathtext.py::test_mathtext_rendering[svg-mathtext-cm-3]
========================================== test session starts ===========================================
platform linux -- Python 3.8.10, pytest-6.2.4, py-1.10.0, pluggy-0.13.1
rootdir: /home/tfpf/Documents/Code/matplotlib/matplotlib, configfile: pytest.ini
collected 1 item                                                                                         

lib/matplotlib/tests/test_mathtext.py s                                                            [100%]

=========================================== 1 skipped in 0.66s ===========================================

Any suggestions on what I did wrong will be appreciated.

I think svg requires a blessed version of inkscape?

I'm not sure what to do about the pngs that snap the fraction line to the wrong pixel and make the new pngs look worse than the old. There are a lot of these pngs, but it really seems like they should "work" and maybe need to be larger? Not sure what other folks think. Conversely we could drop the pngs altogether (if we think mathtext pngs are adequately tested) and just look at the pdfs and svgs. I guess I'm ignorant as to whether we need all three file types or just pdf would work?

All images have now been added.

Also, the part which chooses between the unicode minus sign and the hyphen has been removed. I believe that this is the right thing to do, because:

• the hyphen is not guaranteed to be at the same y-coordinate as the minus sign.
• all five fonts packaged with Matplotlib have the unicode minus glyph (in mathtext mode).

I thought doing this would fix the code coverage test failure, but (curiously) it didn't, so I wonder if it's due to something else.

Lastly, there's the CircleCI failure. According to the log, an error was encountered after embedding documentation hyperlinks, and I don't see any more info. The pull request guidelines state that

If CircleCI fails, likely you have some reStructuredText style issue in the docs. Search the CircleCI log for WARNING.

but I haven't changed any docs! This is the relevant line.

/home/circleci/project/lib/matplotlib/projections/geo.py:docstring of matplotlib.projections.geo.GeoAxes.set_xlim:47: WARNING: py:obj reference target not found: get_ylim

The pull request guidelines state that

If CircleCI fails, likely you have some reStructuredText style issue in the docs. Search the CircleCI log for WARNING.

but I haven't changed any docs! This is the relevant line.

/home/circleci/project/lib/matplotlib/projections/geo.py:docstring of matplotlib.projections.geo.GeoAxes.set_xlim:47: WARNING: py:obj reference target not found: get_ylim

Any info on this?

Suggest you rebase on master. Maybe there was a temporary bug that snuck into master?