[BUG] Making sure label display is predictable

[bkamins]

It would be great to achieve two goals when passing xlabel, title, etc. kwargs:

• that all backends display the passed values in the same way
• if this is not possible to be able to signal to treat the passed value "verbatim" (without any post-processing on plotting backend side e.g. interpreting it as LaTeX or pseudo-LaTeX)

For example to set $ as xaxis you need to do with GR backend plot(1:10, xlabel="\$\$"), but this is GR specific.

x-ref #3991 for a specific case
x-ref #3122

---

Why does it start to matter currently. The reason is that with addition of metadata support to tables I (and maybe other people) start to generate things like xlabel, title etc. programmatically (getting the required strings from metadata and this metadata is read-in along with the data to be displayed e.g. from a Parquet file) and then automatically generate e.g. a report. In such pipelines the string to be displayed does not even show up in the source code. The problem is that you need to be sure that what you try to display actually gets displayed.

[t-bltg]

My opinion on this is that we need unification of preprocessing strings so that this cannot error out.
After all, you should be able to switch backends without modifying your input data / commands.

This seems to be GR specific, so maybe just a GR - sciapp/gr setting to toggle:

julia> using Plots
julia> plot(1:10, xlabel="\$")

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

cc @jheinen.

[t-bltg]

In https://github.com/JuliaPlots/Plots.jl/blob/master/src/backends/gr.jl#L257-L263:

julia> GR.textext(..., "\$")  # produces a '$' char, but also "ERROR: syntax error"
julia> GR.text(..., "\$")  # no character appears, and "ERROR: syntax error" shown

[t-bltg]

I don't understand 19b70c0: shouldn't match(...) === nothing be negated ?

[bkamins]

I think the intention is to return false if $ is present there (as then it is math not normal), but @jheinen will know best (I do not know the logic of this code at all)

[t-bltg]

This is a bit obscure, a bit more clearer in #4515.

But @jheinen comments on this problem are welcome.

[BeastyBlacksmith]

They way I think this should work (and that is how it is implemented in the pgfplotsx-backend) is that if you pass a plain string, you should get the characters displayed that are in the string and if you want LaTeX-like strings you need to pass LaTeXStrings.

So the processing in the gr-backend would need to substitute every $ with \$\$ in order to achieve that. The issue is, that we can't do that (unconditionally) prior to 2.0 because that would break everyones code that currently uses e.g. xlabel = "a $\LaTeX$ variable".

[t-bltg]

Can't at least GR do something trivial like count the numbers of $, and not choke if they're odd ?

Why are people keeping up with the archaic $ ... $ TeX syntax and not moving to the modern \(...\) LaTeX syntax ?

At least that would be easier to parse and less error prone:

julia> plot(1:2, title=raw"I have \(\sqrt{2}\) $ in my pocket")

[jheinen]

I'm currently out of office - I will take care of it this afternoon.

[jheinen]

The "archaic" $ ... $ has its origin in LaTeX. So you prefer \( ... \)? To be honest, this is the first time I've seen this syntax.

[t-bltg]

According to https://tex.stackexchange.com/a/513/75098, no.

And no it's pretty common: https://overleaf.com/learn/latex/Mathematical_expressions (LaTeX is 30 years old).
Although $...$ is still supported for assumed compatibility reasons.

In our context where parsing occurs (and obviously because it chokes on a singleton $), and also because $ denotes interpolation syntax in julia, it would in my opinion make sense to use \(...\) instead of $...$.

At least the example in #4514 (comment) would be un-ambiguously parsed.

Side note: I'm not talking about display math mode \[...\] vs $$...$$, which makes no sense in this context.

[jheinen]

Thanks for the clarification. I will have to change things in the GR tun-time, too. It's not just about GR.jl.

[jheinen]

The above mentioned problems are fixed in the GR run-time development tree. A new release is expected soon.

It's now possible to use the LaTeX math text syntax (\(...\)) and the old TeX Syntax ($..$). I could not remove the latter as it would break things for C/C++ and Python users. But the parser now does the trivial Python check (odd number of $).

However, in Plots.jl we could conditionally use the GR.textx() and GR.inqtextx() functions which provide a bit mask argument to explicitly set text options:

• TEXT_USE_WC - interpret the text position as world coordinates
• TEXT_ENABLE_INLINE_MATH - enable inline math text

[t-bltg]

Fixed by sciapp/gr@f37dfaa.