GeezerVison

I agree that the "reference unit" should be clarified, it's not clear to me either. Also note that TeX basically operates in a world of 72.27dpi (aka 72 "big points per inch") exactly whereas we don't, so I'm not sure if we can have correct physical dimensions (in, cm, mm, etc., e.g. a height of 1cm should occupy half of a figure that is 2cm tall -- by the way this would be a good example to post in this thread to show that the sizes are indeed correct) and correct point-based dimensions (e.g. a height of 12pt should occupy whatever that means wrt. text of font size 12). (I'm not sure I have a good answer, but probably the design choices will need to be made explicit.)

Ooops sorry marked ready for review by accident

WRT em and ex I think they are perfectly reasonable units, particularly for the fraction line which you may think would thicken or thin relative to the font size.

WRT em and ex

Yes, they are reasonable as such. The problem is that they are not static, so one will then need to figure out for each font what the appropriate scale factor is. Unless I find a "simple" solution for that (maybe @anntzer knows how one can query this), I do not think it will be included in this PR.

Reading up a bit more on https://tex.stackexchange.com/questions/4239/which-measurement-units-should-one-use-in-latex it says

 Bringhurst says: (2.1.1) "1 em is a distance equal to the type size", so you can be more certain than "usually consider".

This would make it a bit easier at least by using the font size as the em scale factor.

For ex one may have to measure though.

I have removed ex and added proper support for em (based on pt being used and the statement "1 em is a distance equal to the type size".

Now I have problem generating \genfrac with usetex=True for comparison, but I seem to recall that the results were matching pretty well. Will try to solve that and provide some examples.

Forgot about amsmath...

Here are some examples:

Rendered with mathtext and latex respectively. As far as I can tell, the current scaling matches the LaTeX rendering if nothing else. The size of the bar is stated in numerator and denominator.

Then, the bug in #22172 is manifested. I have a small hack for that leading to:

Not sure if I should include that? It seems like the approach in #20627 is fundamentally better (since it actually considers how LaTeX does it, not just the result of playing around), but that currently doesn't seem to handle wide bars (which may not really be a problem).

#20627 has been replaced by #22852, which does it the same way LaTeX does (i.e. with font constants and with the thickness of the line taken into account).

If I understand correctly, this makes the old "unitless" genfrac use points (= pixels), and then defines units using tex's ratios (1in=72pt, etc.), which means that a 1in thickness will not actually be e.g. 1/3 of a 3in figure unless working at 72dpi: try e.g.

from pylab import *
rcParams["text.latex.preamble"] = r"\usepackage{amsmath}"
figure(figsize=(3, 3), dpi=100).text(.5, .5, r"$\genfrac{}{}{1in}{1}{a}{b}$", size=24, usetex=False)
figure(figsize=(3, 3), dpi=100).text(.5, .5, r"$\genfrac{}{}{1in}{1}{a}{b}$", size=24, usetex=True)

I'm not sure that's really what we want (basically #22171 (comment))? The parser does have dpi information available (get_state().dpi); perhaps it should scale physical units accordingly instead? (I'm not actually sure, but asking for a 1in thick rule and getting something else is a bit annoying?) In any case the behavior we decide on should be documented in the comments, at least.

This also clearly displays the #22172 bug (but I understand that #22852 is working on that) and there's also a vertical alignment problem (which also seems fixed bu #22852?).

But that, somehow, creates a problem already now? I'm not saying that this is the way to go, but I am quite sure that it is not introducing any new issues? Except that maybe one do expect a certain result as one can state the units and the previous "unitless" one, there were really no expectations (except that possibly one would guess it was points).

But you are probably correct that ideally one should take the dpi into consideration.

The new issue is that someone could write \genfrac...{1cm}... and not get what they expected (which I would argue is worse than erroring out -- at least in that case you know the feature is not supported).

and not get what they expected

Fair point.

Assuming that I manage to solve that part, should we also change the default to mean points? (Which I still sort of guess that most people assume it means?)

I don't really think you can change the default behavior here?

@oscargus what is the status here? I've moved to draft, but feel free to move back. If @tfpf is good with this, I can review based on their review, and hopefully @anntzer can provide a second review.

@oscargus what is the status here?

@anntzer made a fair point about dpi-scaling that I have not had time to look into, so moving to draft is a good call.

I think it should be quite straightforward to sort it out though, given time (and inspiration, but that is a bit random).

Since this Pull Request has not been updated in 60 days, it has been marked "inactive." This does not mean that it will be closed, though it may be moved to a "Draft" state. This helps maintainers prioritize their reviewing efforts. You can pick the PR back up anytime - please ping us if you need a review or guidance to move the PR forward! If you do not plan on continuing the work, please let us know so that we can either find someone to take the PR over, or close it.