Skip to content

Let pgf backend use bracket delimiters for detecting math mode. #23381

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

painch
Copy link

@painch painch commented Jul 2, 2022

PR Summary

LaTeX (and lualatex/xelatex) allows math mode to be delimited by '\(', '\)', '\[' and '\]'. This PR changes the pgf backend to detect this, so that e.g. '_' and '^' are not inadvertently escaped in math-mode labels etc.

The current behaviour leads to errors when certain label names are used. For example I've put a minimum working example script mwe.py and a tex file mwe.tex below. Running mwe.py show allows the use of non-pgf backends (Qt5Agg in my case), and displays \(x^2\) as $x^2$ correctly, whereas using just plain mwe.py then lualatex mwe.tex shows it as $x2$. This PR fixes this issue.

mwe.py:

#!/usr/bin/env python3

import sys
import matplotlib.pyplot as plt

plt.plot([0,1,2],[0,1,4])
plt.xlabel(r'\(x\)')
plt.ylabel(r'\(x^2\)')

if len(sys.argv)>1 and sys.argv[1]=='show':
    plt.show()
else:
    plt.savefig('mwe.pgf')

mwe.tex:

\documentclass{standalone}
\usepackage{pgf}

\begin{document}
\input{mwe.pgf}
\end{document}

Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

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

Thank you for opening your first PR into Matplotlib!

If you have not heard from us in a while, please feel free to ping @matplotlib/developers or anyone who has commented on the PR. Most of our reviewers are volunteers and sometimes things fall through the cracks.

You can also join us on gitter for real-time discussion.

For details on testing, writing docs, and our review process, please see the developer guide

We strive to be a welcoming and open project. Please follow our Code of Conduct.

@oscargus
Copy link
Member

oscargus commented Jul 4, 2022

I think that this probably makes sense, but please include a test for it. I think something like this could be used as a template:

@check_figures_equal(extensions=["pdf"])
@pytest.mark.parametrize("texsystem", ("pdflatex", "xelatex", "lualatex"))
@pytest.mark.backend("pgf")
def test_minus_signs_with_tex(fig_test, fig_ref, texsystem):
if not _check_for_pgf(texsystem):
pytest.skip(texsystem + ' + pgf is required')
mpl.rcParams["pgf.texsystem"] = texsystem
fig_test.text(.5, .5, "$-1$")
fig_ref.text(.5, .5, "$\N{MINUS SIGN}1$")

Use $ for the reference and the new delimiters for the test.

For me, this still works correctly in the non-TeX backends with text.usetex=True, with or without this change. (And it doesn't work using the mathtext backend with or without it.)

@timhoffm
Copy link
Member

timhoffm commented Jul 4, 2022

I'm hesitant with this inclusion. As far as I understand LaTeX:

  • \[...\] is display math mode, which puts the equation on a dedicated line. - Matplotlib's math mode does not support this. Therefore, I think we should not accept this syntax.
  • \(...\) is equivalent to $...$. So one could argue that we should support this as well. Note however, that due to the asymmetry/symmetry of the delimiters, the matching algorithm would need to be different. $...$ just identifies pairs. However, you cannot simply add \( and \) to the matching regexp, because you would also incorrectly match The \) inverted \( brackets or even mixtures $ between \) syntaxes.
    Getting this right is significant work. I therefore propose not to support \(...\) and instead explicitly document that.

@painch
Copy link
Author

painch commented Jul 4, 2022

* `\[...\]` is display math mode, which puts the equation on a dedicated line. -  Matplotlib's math mode does not support this. Therefore, I think we should not accept this syntax.

That is a good point -- I've now made a change to reflect that.

* `\(...\)` is equivalent to `$...$`. So one could argue that we should support this as well. Note however, that due to the asymmetry/symmetry of the delimiters, the matching algorithm would need to be different. `$...$` just identifies pairs. However, you cannot simply add `\(` and `\)` to the matching regexp, because you would also incorrectly match `The \) inverted \( brackets` or even `mixtures $ between \) syntaxes`.

At least in their TeX Live implementations, lualatex, pdflatex and xelatex don't allow nested \(...\(...\)...\), but do allow mixed \(...$ and $...\), so the matching algorithm should still work on any valid input, without any major changes.

  Getting this right is significant work. I therefore propose not to support `\(...\)` and instead explicitly document that.

That is a very reasonable alternative if this doesn't work out.

@timhoffm
Copy link
Member

timhoffm commented Jul 6, 2022

lualatex, pdflatex and xelatex [...] do allow mixed \(...$ and $...\)

Do the they allow \)...\(?

@painch
Copy link
Author

painch commented Jul 13, 2022

lualatex, pdflatex and xelatex [...] do allow mixed \(...$ and $...\)

Do the they allow \)...\(?

They don't

@painch
Copy link
Author

painch commented Jul 13, 2022

I think that this probably makes sense, but please include a test for it. I think something like this could be used as a template:

I've had a go writing tests (see the last commit to this branch), I've tried them out locally, though I'm unfamiliar with pytest so they might need some checking.

@anntzer
Copy link
Contributor

anntzer commented Jul 13, 2022

It would seem like a more robust(?) solution may be to just completely get rid of _tex_escape and instead configure tex to support _^% in text mode (I'm not really sure we can do anything, or if the current code does anything, about $?). For underscores this is already done in standard usetex via the underscore latex package, and my uneducated guess is that we can implement something similar for ^ and %

@melissawm
Copy link
Member

Hi @painch - let us know if you need any guidance on moving this forward. Thanks!

@anntzer
Copy link
Contributor

anntzer commented Jan 22, 2023

I think this is superseded by #23442.

@jklymak
Copy link
Member

jklymak commented Jan 26, 2023

Let's close in favour of #23442 and lack of response. @painch Thanks for your contribution - it definitely inspired an improvement!

@jklymak jklymak closed this Jan 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

Successfully merging this pull request may close these issues.

6 participants