TickLabel handling

[matlab2tikz]

TickLabel handling

[burkart]

Could you create your own fork and then apply your changes to that? This would make it a lot easier for others to see what exactly you changed and where. See http://help.github.com/fork-a-repo/ for help.

[CapsLocker]

Hi burkart,

I tried to commit to my branch. My Fork commit is: bfa3ae2
shall I push it to the main repository?

[nschloe]

Hi Tobias,

you wouldn't be able to push to master, but send a pull request.
Anyways, I just looked at the commit, and I gotta say I wouldn't wanna pull it this way. Obviously MATLAB(R) does something here which nobody understands (why oh WHY don't they interpret tick labels as "TeX"?), but it's up to us to fix this. After all, if somebody would want to have the label "\pi" (backslash-p-i), we have to support this (and we currently do).
Now, obviously this is not the best situation. Maybe we could introduce another options "interpretTickLabelsAsTex", have it false by default, and insert something like

if interpretTickLabelsAsTex
labelInterpreter = 'tex';
else
labelInterpreter = 'none';

That'd do away with the cellstrings too.

What do you think?

[CapsLocker]

I introduced the new option in my build 34f0384. Sadly I had to stick to the cell stuff. I wasn't able to figure out how to get it working without even if you have i.e. a cell formatted xTickLabel list and a cnoncell formatted y-axis...

I hope to be compliant to the overall programming style ;)

[burkart]

I'm not too sure about the cell strings as I rarely use them, but shouldn't it be
xTickLabel{k} = prettyPrint( m2t, xTickLabel{k}, labelInterpreter);
that is, use curly braces instead of parentheses around the `k'?

As for the general question, I personally tend to think that the output of matlab2tikz should try to replicate that of the same figure in MATLAB as closely as possible. So if MATLAB doesn't support it (see http://www.mathworks.com/help/techdoc/ref/axes_props.html#XTickLabel) maybe m2t shouldn't, either. They actually propose to use TEXT objects instead (see http://www.mathworks.com/support/solutions/en/data/1-5HAF0I/index.html?solution=1-5HAF0I). I haven't tried that out, though.

Since that workaround is quite clumsy, though, I do like the introduction of the new `interpretTickLabelsAsTeX' option, especially as it's quite unintrusive.

[CapsLocker]

The curly barces are not neccessary in matlab as long as you stick completely to cell type variables. Actually I'm not sure about octave.

In principle I'm with you on the idea to do a conversion "as close as possible". Even the fact that you get something other plotted than you get after latexIng the result...

nevertheless this new option offers quite better usability I think.

BTW thanks for your support!

[nschloe]

I understand the cellstr problem now, and again, it's a MATLAB(R) weirdness.

a = { 'a'; 'b'; 'c' };
a(1) % return 'a'
a(1) = 'z'; % FAIL
a{1} = 'z'; % success

We can't always use curly brackets though as sometimes, the tick labels are just an array (e.g., when it's only numbers).

Why don't we have that problem for interpreter=='none'? Apparently, in this case, prettyPrint returns always returns a cell for which is all works fine. I'll investigate.

[nschloe]

Okay, there was a bit of a mess in the handling of strings vs. cellstrings. prettyPrint() would sometimes return the one, sometimes the other.
I committed a cleanup of that (prettyPrint() now always returns a proper string), and added cell-brackets {} around the function call where necessary (ticks handling). Should work now, please test.