[BUG] labels are too close with LaTeXStrings

[lmiq]

Details

The labels get overlapped here:

using Plots, LaTeXStrings
plot(rand(10),label=L"2\pi")
plot!(rand(10),label=L"2\pi")

It is not a GR issue (alone), as with GR alone it works:

julia> using GR

julia> plot(randn(10,2),labels=(L"2\pi", L"2\pi"))

Backends

This bug occurs on ( insert x below )

Backend	yes	no	untested
gr (default)	x
pyplot
plotlyjs
pgfplotsx		x
unicodeplots
inspectdr
gaston

Versions

Plots.jl version:
Backend version (]st -m <backend(s)>):

(@v1.6) pkg> st -m Plots
      Status `~/.julia/environments/v1.6/Manifest.toml`
  [91a5bcdd] Plots v1.22.6

(@v1.6) pkg> st -m GR
      Status `~/.julia/environments/v1.6/Manifest.toml`
  [28b8d3ca] GR v0.61.0

Output of versioninfo():

julia> versioninfo()
Julia Version 1.6.3
Commit ae8452a9e0 (2021-09-23 17:34 UTC)
Platform Info:
  OS: Linux (x86_64-pc-linux-gnu)
  CPU: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-11.0.1 (ORCJIT, skylake)

[t-bltg]

Haven't I explained to use legend_hfactor in #3598 (comment) ?

There is no spacing (that's why legend_hfactor is for), but the labels do not overlap.

Here with dpi=300:

[lmiq]

This is related: #3598

Yet I wander if the default spacing should not be larger already (getting overlapping labels is not acceptable, while getting a larger spacing is about taste. With default spacing:

julia> plot(rand(10),label="2π")

julia> plot!(rand(10),label="2π")

And with legend_hfactor=1.5:

julia> plot!(rand(10),label="2π",legend_hfactor=1.5,extra_kwargs=:subplot)

[t-bltg]

getting overlapping labels is not acceptable

Yes, but in your mwe, I don't see any overlap.

[lmiq]

Ok, in the MWE they do not overlap, they are very, very close, such that with normal resolutions they seem to overlap.

The legend_hfactor works, but it is somewhat inconsistent, because this does not work:

julia> plot(rand(10),label=L"2\pi")

julia> plot!(rand(10),label=L"2\pi")

julia> plot!(legend_hfactor=1.5,extra_kwargs=:subplot)

It is not completely clear where/when the keywords should work. Also, the extra_kwargs=:subplot is sort of a hack, and backend dependent. The main issue I see here is that this is a bad for first-impressions, and very inconvenient when using Plots for teaching. I would have never found this solutions except by searching for the bug itself.

[lmiq]

Just a side comment:

If you or anyone else feels that this is not a bug, or the same bug, than any other, please feel free to close it. I just don't think that the alternatives we have are good enough for the time being.

[t-bltg]

The issue with adding some spacing is that it is subjective. That's why we do not add extra space as there is no consensus on what amount of default space to add (instead with GR we measure the maxima of all text heights, and use it to create the legend box). We provide backend dependent ways to add spacing and I think that this is the way to make everyone happy. To me this looks like a won't fix, but I'll leave this open if a majority wants to change this.

[lmiq]

I agree that "how much" space is subjective. But the current status for legends which use LaTeXStrings is clearly not acceptable. See this, for example:

From: https://discourse.julialang.org/t/plots-jl-labels-overlap-if-using-latexstrings/69936

Since it is subjective, having "more" is probably safer than having "less" (with the possible complication that you can tell me that legend_hfactor < 1 would not be possible to use to reduce the spacing in that case).

[lmiq]

Also note that the default is not working with LaTeXStrings. Without it, even with the same fonts, it works fine:

julia> plot([rand(10) rand(10)],labels=["ABC" "DEF"],fontfamily="Computer Modern")

While with LaTeXStrings, we get:

julia> plot([rand(10) rand(10)],labels=[L"\textrm{ABC}" L"\textrm{DEF}"])

Maybe the problem is somewhere else, in the recognition of the font height when using LaTeXStrings to apply the default label box size.

[t-bltg]

(with the possible complication that you can tell me that legend_hfactor < 1 would not be possible to use to reduce the spacing in that case).

I haven't checked it, but it should work (just a multiplicative factor of dy).