LaTeX strings do not vertically align in Plots

I’ve noticed that strings containing LaTeX do not vertically align when their contents differ:

using Plots
using LaTeXStrings
plot(
	[1 2 3], [1 2 3], 
	label=[L"text $g$" L"text $x$" "text"],
	legendcolumn=-1,
)

results in

The keyword argument legend_font_valign doesn’t change anything. Is there a known workaround, and if not, should I raise a GitHub issue with Plots?

Maybe put some vspace into the LaTeX strings?

Just tried that - I don’t think the command is being recognised. I tried \vphantom too.

Unfortunately, I’ve got plenty of use cases where a horizontal legend makes more visual sense (above is just a MWE).

If my legend is just plaintext (no LaTeX), the baselines do vertically align, where g doesn’t get ‘pushed up’ relative to x. I suppose the question I really should be asking is: why do the baselines not vertically align when LaTeX is present?

Sorry, I misunderstood the question and deleted my reply.

Note that the problem doesn’t seem to occur with the pythonplot() backend.

Thank you for the suggestion. Honestly, the number of plotting backends in Julia overwhelms me somewhat (new to Julia here), and I’d rather not have to switch backends whenever I run into an issue with one particular backend.

Aside: I would’ve thought that the default backend is the one that is regularly developed and maintained, but this is yet again adding to the list of “things that don’t work in the default backend”.

Back on topic: Is this issue worth raising on GitHub? I’m not sure if the lack of baseline alignment is a bug, or a fundamental limitation of the GR backend.

Many people use Plots.jl for its convenience, but more demanding users prefer Makie.jl, which avoids the problems you face.

There should be related issues in github, so please search before creating a new one.

I’ve given Makie.jl a try, it does seem to have better features. Thanks!

Honestly you are likely to.
Being able to change back back-ends is a key feature of Plots.jl
Its why people use Plots.jl and not GR.jl or PythonPlot.jl directly.
It means if you find a big like this (which yes, you should report) you can easily swap to another backend while it gets fix.

There are not so many and its not so hard.
There are fairly well summarised in the docs in the at a glance section
https://docs.juliaplots.org/stable/backends/

But even shorter:

  • The default backend (GR) is the fastest
  • but the PythonPlot backend (i.e. matplotlib) is the most reliable (Its simply been around much longer, and has a bigger team)
  • UnicodePlots is good if you need it in plaintext
  • Plotly/PlotlyJS is good if you want interactivity like zoom, tooltips etc.

You can just ignore the other 3.

I do not really want to make this even more off-topic but I could not resist to add my two cents :wink:

I was a big fan of Plots.jl at the very beginning, many years ago, but more and more I realised that the one-fits-all solution does not cut it. Switching backends just because something did not work in one is not a good workaround. Plots will look different and it’s a mess to maintain a script which deals with different backends in the same process. It also happened multiple times that my plots broke or did look different when something was updated (either one of the backends or Plots.jl itself). That was just annoying…

In my opinion the best plotting library for Julia is PGFPlotsX.jl.

Yes, it has a very steep learning curve because it uses PGF/TikZ (so technically you have to learn that; the Julia package itself is easy!) and is of course very well integrated in TeX, which you use anyways if you are working in a scientific environment.
PGFPlotsX.jl itself is just a very thin wrapper which allows you to use the full PGF/TikZ feature set, which has an awesome documentation with almost 600 page PGFPLOTS Documentation. If you are already a bit familiar with PGF/TikZ/TeX, you will have a fun time and easy start :smiley:
I often use the PGFPlots gallery and once you get used to the PGFPlotsX abstraction logic, you can translate the examples in seconds to Julia code.

One of the biggest benefits of PGFPlots(X) is the amount of (PGF/TikZ/TeX) examples and discussions out there, no matter which language people are using :wink: The [tikz-pgf] tag on tex.stackexchange.com has more than 34000 questions. Compare that to [makie-jl] with slightly more than 52 or [plots.jl] with about 200. This is not a surprise, given that PGF is almost 20 years old; and builds upon even older pillars.

Anwyas, Makie.jl (well, to be exact CairoMakie.jl and GLMakie.jl) is my second choice, mostly when it comes to interactivity or rendered 3D visualisations. Makie is great for teaching and it’s as easy to use as Plots.jl

1 Like

For people who don’t have time, don’t work in research or write scientific publications, but need simple language with short keyword aliases to get some data QC job done, Plots.jl is often perfect.

By the way, the pgfplotsx() backend also has no problems with your example:

1 Like