| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
| 'cm': 7227/254, | ||
| 'in': 7227/100, | ||
| 'ex': 35271/8192, | ||
| 'em': 655361/65536, |
There was a problem hiding this comment.
ex and em are probably not fixed values as they should(?) depend on the actual font being used, e.g. whether we're in a mathbf or a mathcal or whatnot. OTOH we don't necessarily need to support them for now?
Sorry, something went wrong.
| 'in': 7227/100, | ||
| 'ex': 35271/8192, | ||
| 'em': 655361/65536, | ||
| 'mu': 7227/2540000, |
There was a problem hiding this comment.
I can't find a ref for mu, nc, nd as standard tex units, perhaps you can link their definition? (as a comment here at least, not in the code)
Sorry, something went wrong.
There was a problem hiding this comment.
I used some stack exchange thread combined with other sources, but cannot seem to find where I got ex and em from now. I agree with that they shouldn't be there though (just added what was there without really thinking about the meaning).
Here are some better sources:
https://en.wikibooks.org/wiki/LaTeX/Lengths
https://latexref.xyz/Units-of-length.html
(And here is a good discussion why ex and em are bad choices: https://tex.stackexchange.com/questions/4239/which-measurement-units-should-one-use-in-latex
)
Sorry, something went wrong.
There was a problem hiding this comment.
And here is for mu: https://sv.overleaf.com/learn/latex/Lengths_in_LaTeX
Sorry, something went wrong.
|
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.) |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
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. |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
Forgot about amsmath... 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). |
Sorry, something went wrong.
| p.int_literal <<= Regex("[-+]?[0-9]+") | ||
| p.unit <<= Regex("(pt|mm|cm|in|em|mu|" | ||
| "sp|bp|dd|pc|nc|nd|cc)") | ||
| p.float_with_wo_unit <<= Group((p.float_literal + p.unit) | |
There was a problem hiding this comment.
what's "wo"?
Sorry, something went wrong.
|
|
||
| p.float_literal <<= Regex(r"[-+]?([0-9]+\.?[0-9]*|\.[0-9]+)") | ||
| p.int_literal <<= Regex("[-+]?[0-9]+") | ||
| p.unit <<= Regex("(pt|mm|cm|in|em|mu|" |
There was a problem hiding this comment.
I think you can get rid of the grouping parentheses, which should be marginally more efficient.
Sorry, something went wrong.
|
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?). |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
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). |
Sorry, something went wrong.
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?) |
Sorry, something went wrong.
|
I don't really think you can change the default behavior here? |
Sorry, something went wrong.
@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). |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
PR Summary
Closes #19001.
This also means that it is rather easy to support units for other things.
One doubt though: I couldn't figure out the standard unit in mathtext. Right now, I have assumed pt, but I suspect it may not be correct. I'll update with a test once I know the answer... However, as I have local test errors on image comparisons (for pdf), I am not convinced that the tests will pass. These are the ones I currently get:
Is there a "better" way to generate test images that are more likely to pass on the CI?
PR Checklist
Tests and Styling
Documentation