Skip to content
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

Complex LaTeX expressions in long_names aren't rendered correctly when plotting #5681

Closed
tomchor opened this issue Aug 6, 2021 · 5 comments · Fixed by #5682
Closed

Complex LaTeX expressions in long_names aren't rendered correctly when plotting #5681

tomchor opened this issue Aug 6, 2021 · 5 comments · Fixed by #5682

Comments

@tomchor
Copy link
Contributor

tomchor commented Aug 6, 2021

What happened:

When I try to give a variable a long_name that's a complex latex expression and then plot that variable the expression doesn't get rendered by latex

What you expected to happen:

I expected the name to get rendered by latex

Minimal Complete Verifiable Example:

In the example below I'm plotting a variable with a complex long_name via xarray and then plotting it again (in a separate figure) using only matplotlib and manually setting xlabel(). The matplotlib-only version works fine (right), but the xarray version doesn't render (left).

import numpy as np
from matplotlib import pyplot as plt
import xarray as xr
da = xr.DataArray(range(5), dims="x", coords = dict(x=range(5)))
name = r"$Ra_s = \mathrm{mean}(\epsilon_k) / \mu M^2_\infty$"
da.x.attrs = dict(long_name = name)
da.plot()

plt.figure()
plt.plot(range(5))
plt.xlabel(name)

Screenshot from 2021-08-06 15-50-08

Anything else we need to know?:

Environment:

Output of xr.show_versions()

INSTALLED VERSIONS

commit: None
python: 3.9.2 (default, Mar 3 2021, 20:02:32)
[GCC 7.3.0]
python-bits: 64
OS: Linux
OS-release: 5.10.53-1-MANJARO
machine: x86_64
processor:
byteorder: little
LC_ALL: None
LANG: en_US.UTF-8
LOCALE: en_US.UTF-8
libhdf5: 1.10.6
libnetcdf: 4.6.1

xarray: 0.17.0
pandas: 1.2.3
numpy: 1.19.2
scipy: 1.5.3
netCDF4: 1.5.6
pydap: None
h5netcdf: None
h5py: None
Nio: None
zarr: None
cftime: 1.2.1
nc_time_axis: None
PseudoNetCDF: None
rasterio: None
cfgrib: None
iris: None
bottleneck: 1.3.2
dask: 2021.04.0
distributed: 2021.04.0
matplotlib: 3.3.4
cartopy: 0.18.0
seaborn: None
numbagg: None
pint: 0.17
setuptools: 52.0.0.post20210125
pip: 21.0.1
conda: None
pytest: None
IPython: 7.22.0
sphinx: None

@tomchor
Copy link
Contributor Author

tomchor commented Aug 6, 2021

Note that for simple latex expressions xarray appears to work fine. For example name = r"$\mathrm{mean}(\epsilon_k)$" works in both figures in the example above.

@dcherian
Copy link
Contributor

dcherian commented Aug 6, 2021

I agree this is annoying but there is no good solution AFAIK.

We use textwrap here:

return "\n".join(textwrap.wrap(name + extra + units, 30))

I guess we could skip it if the first character in name is $?

@tomchor
Copy link
Contributor Author

tomchor commented Aug 6, 2021

I'm not entirely sure why that would make the LaTeX renderer fail. But if that's the case and skipping it is an option, I'd test that both the first and last characters are $ before skipping.

@Illviljan
Copy link
Contributor

It's the newline join that's the problem. You can get the latex working as textwrap intends by using "$\n$".join

import numpy as np
from matplotlib import pyplot as plt
import xarray as xr
da = xr.DataArray(range(5), dims="x", coords = dict(x=range(5)))
name = r"$Ra_s = \mathrm{mean}(\epsilon_k) / \mu M^2_\infty$"
name = "$\n$".join(textwrap.wrap(name, 30))
da.x.attrs = dict(long_name = name)
da.plot()

plt.figure()
plt.plot(range(5))
plt.xlabel(name)

But that looks worse than the original, checking if the string is latex-able seems a good idea.

@keewis
Copy link
Collaborator

keewis commented Nov 28, 2021

should have been closed by #5682

@keewis keewis closed this as completed Nov 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants