Menu
▾
▴
#1799 Backslash escaping is broken in enhanced text, gnuplot 5.0
gnuplot> plot '-' using 1:2 title "some\_plain\_text" with lines dt 1
input data ('e' ends) > 0 0
input data ('e' ends) > 1 1
input data ('e' ends) > e
gnuplot>
WIth an enhanced text terminal (specifically, I have tested qt, wxt, and x11 under MacOS X), the resulting plot has 'p' and 't' subscripted.
Using double backslashes instead of normal backslashes produces a correct title.
Related
Diff:
Heh. I had to add second backslashes to make Sourceforge render this correctly. The title string in question should have a single backslash followed by an underscore, in two places.
This a feature, not a bug. If you use single quotes, you get your expected behaviour, see
help quotes.The "noenhanced" attribute works with both single and double quotes.
Thanks, Ethan, for your tireless work!
Of course, that (the noenhanced attribute) doesn’t help folks who want to mix
enhanced subscripting and underscore characters.
I was pretty surprised by the behavior, because it implies two independent layers
of backslash stripping are happening: one for double-quote interpretation, and a
separate one for enhanced text interpretation.
From the standpoint of PDL::Graphics::Gnuplot, it is no big deal. We always
use double quotes for string transmission, so we can support multiline strings
via the \n escape. We can work around the double backslash issue by
just escaping all backslashes as we assemble the quoted string to emit.
Cheers,
Craig
Related
Bugs:
#1799"it implies two independent layers of backslash stripping are happening: one for double-quote interpretation, and a eparate one for enhanced text interpretation."
Yes. This is explicitly true and is documented as such. So far as I know it has always been this way, although enhanced text mode did not used to be enabled by default.
From "help quote": Backslash processing of special characters like \n (newline) and
\345 (octal character code) is performed for double-quoted strings. In
single-quoted strings, backslashes are just ordinary characters.
From "help enhanced": You can escape control characters using \, e.g., \, {, and so on.
Actually, it's worse than that because for some terminal types (e.g. PostScript, SVG) the text goes through an additional layer of special character interpretation later on.
I get it, and I understand why it might be this way. As a relatively savvy user, I did not “get” the dual processing from the documentation. It might be useful to be more explicit — perhaps a sentence added to the “help quote” text could be:
“In addition to normal dual quote processing, enhanced text processing is an additional step that separately interprets backslashes to escape markup characters. This means, for example, that to include an underscore in a label with enhanced text you must precede it with a double backslash “\_ <smb: _="">”. </smb:>
Related
Bugs:
#1799