% not escaped in legend title

[matlab2tikz]

% not escaped in legend title

[burkart]

Could it be that you're using an old version of matlab2tikz? Presumably this was fixed by commit d959845. If the bug still persists in an up-to-date version, please let us know.

[purem]

Definitely not an old version, checked out master this morning.

Minimum Example:
x = 0:pi/100:2*pi;
y = sin(x);
plot(x,y);
legend('Coupon=6%');
matlab2tikz('sin.tikz', 'height', '\figureheight', 'width', '\figurewidth');

produces

...
\addlegendentry{Coupon=6%};
...

[burkart]

With a recent version of m2t that should definitely not happen. Unfortunately I can't look into this right now. Unless Nico does I'll have a closer look at it in the near future.

One last question, are you using MATLAB or Octave?

[purem]

Matlab R2011b.

Not to worry, Ill just change it manually for now. I'd try fixing it myself but I only began using matlab last week.

[nschloe]

I just checked it out and the issue is real: parseTexString() doesn't escape '%'. I'll look into it. Thanks, purem!

[burkart]

Disclaimer: I did not run MATLAB and/or Octave to find out how they handle things that go against general TeX practice and I also didn't try out the following suggestion. With that in mind, the following should at least serve as a starting point to fix this issue:

There are some strrep(...) calls in prettyPrint() for Interpreter=='none'. I assume that the characters there are problematic for Interpreter=='tex' as well. Out of those, the following should already be handled correctly by parseTexSubstring():

• '' -> '\textbackslash'
• '^' -> '\textasciicircum'
• '^' -> this should not be escaped but used in math mode to allow things like 'x^2' for x squared which IIRC is how MATLAB handles this
• '_' -> remains as-is ('_')
• '_' -> this should not be escaped but used in math mode to allow things like 'a_i' for a index i which IIRC is how MATLAB handles this

Solutions for the following set are probably to replicate the strrep(...) calls from Interpreter=='none' and put them behind string = strrep(string, '\textbackslash{}\textasciicircum', '\textasciicircum');. That is assuming MATLAB's brand of TeX treats all of them as literal as opposed to true-TeX's way of giving them special meaning.

• '$': string = strrep(string, '$', '\$'); for '$' -> '$'
• '%': analogously for '%' -> '%'
• '#': analogously for '#' -> '#'
• '&': analogously for '&' -> '&'

If, however, MATLAB does honor TeX conventions at least with some of the above, an approach similar to '_' should be used, i.e. instead of the above, add the following:

• '$': string = strrep(string, '\textbackslash{}$', '\$'); for '$' -> '$'
• '%': analogously for '%' -> '%'
• '#': analogously for '#' -> '#'
• '&': analogously for '&' -> '&'

Finally the braces:

• '{' and '}': those two could be problematic if MATLAB's TeX interpreter is actually so broken as to allow them to be literal characters even if they are not preceded by a backslash. Even if MATLAB only interprets '{' and '}' as opening and closing braces, respectively, this one might be a little tricky. It would probably require something like string = strrep(string, '\textbackslash{}{', '\{'); and string = strrep(string, '\textbackslash{}}', '\}'); as possibly some of the last operations in parseTexSubstring(). It might also be necessary to make adjustments to parseTexString() to exclude braces from segmentation if they are preceded by a backslash. Then again, this one definitely requires some tests.

I'll try and get MATLAB and Octave running today so that I can fix the bug.

[nschloe]

I just submitted a service request at MathWorks to inquire about their {TeX, LaTeX, none} handling. If we get more concise info, I'll post it here.

[burkart]

I did some tests on Octave 3.6.0 but I don't have a MATLAB installation available right now, so could someone please verify the following on MATLAB for me:

figure
plot(5, 5, 'b+')
title('Benjamin: $100, not \$100')   % yields "Benjamin: $100, not \$100"
pause
title('Everything: 100%, not 100\%') % yields "Everything: 100%, not 100\%"
pause
title('Music: C#, not C\#')          % yields "Music: C#, not C\#"
pause
title('Ben \& Jerry''s needs the & in the middle')
                          % yields "Ben & Jerry's needs the  in the middle"
pause
title('braces {work} perfectly')     % yields "braces work perfectly"
pause
title('}even unbalanced{')           % yields "even unbalanced"
                                     % but gives a warning: ignoring spurious }
pause
title('braces \{ are \} curly')      % yields "braces { are } curly"

Assuming that Octave handles TeX strings exactly like MATLAB does, this means that "$", "%", and "#" must not be escaped according to MATLAB TeX whereas "&" must be escaped. Braces "{" and "}" serve their usual function even in MATLAB TeX and to print them they need to be escaped. What's particularly odd is that ampersands without a preceding backslash are simply erased from the output. I'm very interested in how this comes out on MATLAB.

I'll work on a fix based on the findings from Octave now.

---

Updated: Unmatched braces give a warning, not an error

[nschloe]

title('Ben \& Jerry''s needs the & in the middle')
yields
Ben \& Jerry's needs the & in the middle

title('braces {work} perfectly')
yields
title('braces work perfectly')

title('}even unbalanced{')
yields
}even unbalanced{

title('braces \{ are \} curly')
yields
braces { are } curly

The rest as you'd expected.

[burkart]

Thanks. I'm not sure whether I should praise Octave for being more faithful to true TeX or curse them for being semi-compatible with MATLAB. Guess I'll file a bug report regarding the "&" escaping.

As for the unbalanced braces, I'd say if a user does that it's really their own fault. After all it might be tricky to find out how exactly MATLAB handles them and then it might be even trickier to mimick that (broken) behavior. Kudos to Octave in this case for warning the user.

[burkart]

Another verification task:

figure
plot(5, 5, 'b+')
title('bla\\\bla')    % yields "bla\\\bla"   % 3+0 -> 3+0
pause
title('bla\\bla')     % yields "bla\\bla"    % 2+0 -> 2+0
pause
title('bla\bla')      % yields "bla\bla"     % 1+0 -> 1+0
pause
title('bla\{bla')     % yields "bla{bla"     % 1+1 -> 0+1
pause
title('bla\\{bla')    % yields "bla\\bla"    % 2+1 -> 2+0
pause
title('bla\\\{bla')   % yields "bla\\{bla"   % 3+1 -> 2+1
pause
title('bla\\\\{bla')  % yields "bla\\\\bla"  % 4+1 -> 4+0
pause
title('bla\\\\\{bla') % yields "bla\\\\{bla" % 5+1 -> 4+1

Results are for Octave 3.6.0. The pattern is quirky but obvious. I wonder if it's the same in MATLAB.

As for the bug fix in general, it's pretty complete except for an Octave oddity regarding "&" and closing braces which are tricky/not tested enough. What's annoying is to develop for MATLAB without the ability to test on that platform. I'm probably gonna upload a commit that I haven't tested with MATLAB and then take a look at it again sometime in the near future when I have access to MATLAB.

[nschloe]

`````` title('bla\\bla')yieldsbla\\bla```

title('bla\\bla')
yields
bla\bla

title('bla\bla')
yields
bla\bla

title('bla\{bla')
yields
bla{bla

title('bla\\{bla')
yields
bla\\{bla

title('bla\\\{bla')
yields
bla\{bla

title('bla\\\\{bla')
yields
bla\\\\{bla

title('bla\\\\\{bla')
yields
bla\\{bla

[burkart]

To sum it up, the output generated by MATLAB (M) and Octave (O) is as follows:

a) 3+0 -> 3+0 (M) / 3+0 (O)
b) 2+0 -> 1+0 (M) / 2+0 (O)
c) 1+0 -> 1+0 (M) / 1+0 (O)
d) 1+1 -> 0+1 (M) / 0+1 (O)
e) 2+1 -> 2+1 (M) / 2+0 (O)
f) 3+1 -> 1+1 (M) / 2+1 (O)
g) 4+1 -> 4+1 (M) / 4+0 (O)
h) 5+1 -> 2+1 (M) / 4+1 (O)

MATLAB expects backslashes in the output to be escaped as double backslashes and gives a warning otherwise (as I could determine thanks to Nico's help). Octave does not know of backslash escaping -- any backslashes in the input are transformed into output ones unchanged (gotta file an Octave bug about that). If MATLAB encounters a number of backslashes that cannot be interpreted as a proper escape sequence (a, c, e, g), it seems to fall back into a sort of panic mode where it also literally translates every input backslash into an output backslash. Oddly enough this even goes for the last backslash in a row that is used to escape e.g. a brace (e, g). On MATLAB that brace is always shown in the output whereas on Octave the backslashes take precedence over the brace (e, g).

I conclude that both interpreters work incorrectly. MATLAB's does so whenever the input is not properly escaped (a, c, e, g) but at least gives a warning. No characters are lost but a few additional backslashes might appear in the output. Octave's interpreter is incompatible to MATLAB's in that it doesn't understand backslash escaping, "swallows" would-be escaped characters after an even number of backslashes (e, g) which doesn't make any sense, considering that it doesn't interpret the backslashes to be escaped themselves, and finally it doesn't even warn the user in such cases. Therefore the fixed matlab2tikz parser will honor the MATLAB convention of expecting backslashes to be escaped and might produce invalid output if the user provided invalid input according to that rule. If it's easy to do I will try to maintain bug compatibility with MATLAB and Octave to keep with the general spirit of m2t's TeX interpreter, but that will be optional.

[burkart]

Okay, so MATLAB's "panic mode" means that it simply formats the output as if its interpreter were 'none'. As far as I can tell it gets invoked whenever MATLAB gives a warning about an invalid TeX string. This could for instance be due to mismatched braces or undefined control sequences, e.g. \alfa instead of \alpha or an un-escaped backslash. Regarding the MATLAB/Octave overview from last comment these are the cases a, c, e, and g. The first two have an odd number of backslashes which means the last one isn't escaped whereas the last two cases have an even number of backslashes which leaves the opening brace un-escaped which in turn means unmatched braces or an "incomplete command" according to the MATLAB warning.

[nschloe]

So what's the status of this?
We haven't released a new version in a long time and I'd like to throw out a new one rather sooner than later. Of course I'd love to have proper text support in there, but we could also postpone it till the next release.

[burkart]

Unfortunately I wasn't able to finish in time before my sister visited me for a couple days. Now that she's gone I'll get back to it. Everything should work, but I'd like to make one improvement to the new test case I created, run that test case a few times and clean up here and there. Unless anything unforeseen comes up I should be done by tomorrow if not today.

[burkart]

The good news is that I think I am finished now, including a serious amount of testing. The bad news is that I'm too tired to write nice commit messages now. Tomorrow.

[jordigh]

Octave doesn't interpret TeX. Gnuplot does. You may have better luck reporting these problems to gnuplot.