MATLAB Answers

New line in legend does not work anymore in MATLAB 2017b

229 views (last 30 days)
Chris on 13 Dec 2018
Edited: dpb on 20 Dec 2018
I want to make a multi line legend with MATLAB 2017b:
legend({['test 1' char(10) 'done'],['test 2' char(10) 'done']});
This results in:
In previous versions of MATLAB this reulted in:
which is what I want.


Jan on 18 Dec 2018
I guess it is a bug, which appears only, if a user has changed the default settings of the text, axes, figure or legend properties. This would explain, why some systems are affected, but others are not.
dpb on 18 Dec 2018
OP could check that hypothesis fairly quickly...doesn't indicate whether has tried from a clean slate minimal test or not...I was presuming that would also fail on his system, but guess it's possible it wouldn't.
Then would be a treat to try to figure out which specific setting may have done the dirty...
Chris on 18 Dec 2018
I reinstalled matlab which solved the problem....
Thanks everyone for their help!

Sign in to comment.

Answers (1)

Yair Altman
Yair Altman on 18 Dec 2018
The reason for the problem is that the default legend Interpreter ('lex') does not know how to interpret the '\n' in the label. \ prefixes are reserved in lex for special commands, but \n is not one of them (reference). Instead, you should use the char(10) or run your string through sprintf():
legend({'test 1\ndone', 'test 2\ndone'}) % not good
legend({sprintf('test 1\ndone'), sprintf('test 2\ndone')}) % good
legend({['test 1' 10 'done'], ['test 2' 10 'done']}) % also good


Show 1 older comment
Yair Altman
Yair Altman on 18 Dec 2018
Jan - your code works perfectly fine on my 19aPR - which release are you using?
Jan on 18 Dec 2018
It works for me also under all Matlab releases I've tested: R6.5, R2009a, R2015a, R2016b. But for the OP it failed in 2017b and in another thread (link) R2017a was concerned. Re-installing 2017b solved (link) the problem for the OP. So I'm afraid we will not find the problem ever.
dpb on 19 Dec 2018
That the char(10) passed to legend was displayed in the error message as \n is, I think, most interesting...was there really a character substitution done in the passed-in string or is it just a fignewton of the error string handling formatting the byte to the string???
As in your tests, all expected-to-work perturbations worked here w/ R2014b, 16b, 17b, 18b
Since a re-install made OP's symptoms disappear, could possibly be related to a behind-the-scenes OS update...but you're right, we'll almost certainly never know for sure.

Sign in to comment.

Sign in to answer this question.

Translated by