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?
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.
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.
I do not really want to make this even more off-topic but I could not resist to add my two cents
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
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 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
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: