Skip to content

Slightly better positioning of subscripts and superscripts of fractions #21850

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 3 commits into from

Conversation

tfpf
Copy link
Contributor

@tfpf tfpf commented Dec 3, 2021

PR Summary

Tries to improve the positioning of sub- and superscripts attached to fractions (fix #18086).

PR Checklist

Tests and Styling

  • Has pytest style unit tests (and pytest passes).
  • Is Flake 8 compliant (install flake8-docstrings and run flake8 --docstring-convention=all).

Documentation

  • [N/A] New features are documented, with examples if plot related.
  • [N/A] New features have an entry in doc/users/next_whats_new/ (follow instructions in README.rst there).
  • [N/A] API changes documented in doc/api/next_api_changes/ (follow instructions in README.rst there).
  • [N/A] Documentation is sphinx and numpydoc compliant (the docs should build without error).

Details

import matplotlib.pyplot as plt
s = r'$\left(\dfrac{n}{d}\right)_p^q$ $\left(\dfrac{n}{d}\right)^q$ $\left(\dfrac{n}{d}\right)_p$'
fig = plt.figure()
fig.text(0.1, 0.5, s)
plt.show()

Before

before

After

after

Notes

I added a new production rule for the tokenisation of expressions containing subscripts and superscripts.

        p.subsuper      <<= Group(
            (Optional(p.placeable)
             + OneOrMore(p.subsuperop - p.placeable)
             + Optional(p.apostrophe))
            | (p.placeable + Optional(p.apostrophe))
            | p.apostrophe
            | (p.auto_delim + OneOrMore(p.subsuperop - p.placeable))
        )

This should be considered suboptimal, but with my extremely limited knowledge of languages, grammars and parsing, this is the best idea I could come up with. This addition has the effect of making the nucleus (i.e. the expression to which a subscript and/or superscript are/is attached) available for the calculation of shift_up and shift_down.

I hate magic constants (0.4 and 1.4) as much as the next person, but can't think of anything better to differentiate nuclei which are and aren't fractions. This works for Dejavu Sans, but not for Computer Modern or STIX or Dejavu Serif. So, I'll leave this as a draft. Would appreciate experts weighing in.

LaTeX uses a wide assortment of font parameters (stored in font_info, an array) to calculate shift_up and shift_down, so the results of this will not exactly match what LaTeX gives us, but it will be close. Nevertheless, this will have to be tested extensively.

Needless to say, sub- and superscripts can be nested.

import matplotlib.pyplot as plt
s = r'$\left(\dfrac{\mathrm{Numerator}}{\mathrm{Denominator}}\right)_{y_{i^2}}^{\frac{y_k^{2^w}}{4^3}}$'
fig = plt.figure()
fig.text(0.1, 0.5, s, size=50)
plt.show()

nesting

Another point to note is that this will be affected by #20627, so a rebase may be required later.

@QuLogic QuLogic added the status: needs workflow approval For PRs from new contributors, from which GitHub blocks workflows by default. label Dec 7, 2021
@tfpf
Copy link
Contributor Author

tfpf commented Dec 7, 2021

There are a total of 14 mathtext image miscompares, all due to test_mathtext_rendering[*-mathtext-*-81] i.e. the tests for \left(X\right)_a^b.

The reason is that cm and stixsans do not expand brackets the way stix, dejavusans and dejavuserif do.
typeface-irregularities
The brackets are not high enough in case of stixsans, and not low enough in case of cm. So, the shifts calculated for one font may not look good when used on another.

I used shifts which (I hope) would make fractions more closely resemble what LaTeX does. I think the result is reasonable.
typeface-irregularities-2

Would love to know what experts think.

@tfpf tfpf marked this pull request as ready for review December 16, 2021 16:24
@jklymak
Copy link
Member

jklymak commented Feb 1, 2022

This looks like really good work, bt I feel un-able to properly review it. Who is our resident expert in mathtext?

Copy link
Member

@QuLogic QuLogic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Were you able to check this against the texbook that @anntzer suggested in the issue? I think sub/superscripts are defined around program 756 on page 280 there. This might be difficult to use though if the nucleus is not accessible.

@tfpf tfpf marked this pull request as draft May 6, 2022 16:49
No point running the tests if we are absolutely sure they are going to fail.
@tfpf
Copy link
Contributor Author

tfpf commented Jun 11, 2022

I thought I'd revive this, since I now have a better understanding of TeX's algorithm. I implemented the calculations described in the book (with a few shortcuts). However, the CM font behaves weirdly: it reports a wrong x-height, which throws off the calculations.

import matplotlib.pyplot as plt
(fig, ax) = plt.subplots()
ax.text(.1, .5, r'$\mathrm{x}\alpha_{i+1}^j$', size=50)
plt.rc('mathtext', fontset='cm')
ax.text(.5, .5, r'$\mathrm{x}\alpha_{i+1}^j$', size=50)
plt.show()

DejaVu Sans correctly reports the x-height as 38 (I verified this by counting the pixels 😅), whereas CM reports it as 59, which is clearly wrong, as this image shows.
wrong-_x-height
(The icons are missing because I am using a WSL installation of Matplotlib on Linux.)

Which means that even though the algorithm is correct, the alignment is incorrect for CM. Should we just shelve this?

@tfpf
Copy link
Contributor Author

tfpf commented Jun 11, 2022

I found the problem. DejaVu Sans does not store the x-height, so it is actually calculated in the get_xheight function. Whereas CM does, but the value it provides is incorrect.

If I force the "poor man's x-height" calculation for CM, the result is reasonably good.
poor_mans_x-height

However, making that change on the main branch breaks 126 Mathtext tests (incidentally, all of them are CM rendering tests).

@tfpf
Copy link
Contributor Author

tfpf commented Jun 11, 2022

Shortcuts I took for the algorithm

  • The default values of shift_up and shift_down depend on two font constants, supdrop and subdrop, respectively. However, Mathtext uses subdrop for both (as the comment in the FontConstantsBase class mentions), so I did the same.
  • The actual value of shift_up depends on the current style (display, text, script or script-script), and may be calculated using sup1, sup2 or sup3. However, superscripts and subscripts in Mathtext do not know about the current style (Mathtext only has the sup1 constant); they are simply one size smaller than the nucleus. I've also used only sup1.

@tfpf
Copy link
Contributor Author

tfpf commented Jul 17, 2022

Closing. Superseded by #22852.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: needs workflow approval For PRs from new contributors, from which GitHub blocks workflows by default. topic: text/mathtext
Projects
None yet
Development

Successfully merging this pull request may close these issues.

sub/superscripts should be moved further from the baseline following large delimiters
5 participants