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

Hi,

I want to make a multi line legend with MATLAB 2017b:

plot([1:100;1:5:500]');
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.

[dpb]

>> plot([1:100;1:5:500]');
legend({['test 1' char(10) 'done'],['test 2' char(10) 'done']});
>> ver
-----------------------------------------------------------------------------------------------------
MATLAB Version: 9.3.0.713579 (R2017b)
MATLAB License Number: xxxxx
Operating System: Microsoft Windows 7 Professional ...
...

What is the default renderer and what is the 'Interpreter' property for the legend object (probably the latter being much more likely the candidate problem of the two)?

[Jan]

See: https://www.mathworks.com/matlabcentral/answers/393980-multi-line-legend-strings . One user was affected in R2017a already by the same problem, but on another machine it worked. Do you get a warning inthe command window?

[Chris]

Thanks for the quick reply. These are the warnings I am getting:

Warning: Error updating Legend.

Character vector must have valid interpreter syntax:

test 1\ndone

My default figure renderer is opengl. I got this info like this:

get(groot,'defaultFigureRenderer')
ans='opengl'

my interpreter is tex. which I get like this:

l=legend({['test 1' char(10) 'done'],['test 2' char(10) 'done']});
l.Interpreter
ans ='tex'

[dpb]

I didn't notice it in the beginning, but see if there's any difference in symptom if you try

hL=legend(['test 1' char(10) 'done'],['test 2' char(10) 'done']);

instead. That's two strings, one for each label as opposed to the cellstr array. Shouldn't matter; is documented as valid syntax, but we're looking for what broke it here...

Another idea to try would be to write the label strings as

hL=legend(sprintf('%s\n%s','test 1','done'),sprintf('%s\n%s','test 1','done'));

Again, really shouldn't be any different, but again looking to see if can change symptoms...

[Jan]

Does the problem occur with 1 legend entry also?

figure;
plot(1:10);
legend(['test 1' char(10) 'done'])

[Chris]

Hi dpd and Jan,

Thanks a lot for your help. Unfortunatly none of your susggestions fixed the problem.

I tried:

hL=legend(['test 1' char(10) 'done'],['test 2' char(10) 'done']);

and

hL=legend(sprintf('%s\n%s','test 1','done'),sprintf('%s\n%s','test 1','done'));

and

figure;
plot(1:10);
legend(['test 1' char(10) 'done'])

When I have only a string with a line break such as:

['test 1' char(10) 'done']

this works fine. Only when the the line break is in the legend I have problems.

[dpb]

Yes, the issue is in the legend interpreter; not actually in the string. I was poking around to see if how that string were created might change the internal behavior any.

All of those work correctly on this system which says it is somehow system-related.

Have you installed any patches to the base distribution? What is the OS?

What about

opengl info

to see what there might be that could possibly be unusual with the hardware were to show up.

Have you changed renderers or interpreters to see if can change symptoms that way again with the idea of poking around to see what might give clues that indicate just what is failing.

Unfortunately, TMW has turned legend into a .p file so extensive debugging isn't possible any more since can't see the code.

[Chris]

thanks for your reply. Her are the answers to your question:

1. Have you installed any patches to the base distribution?

- Not that I know of.

2. What is the OS?

- Windows 7 64 bit

3. Opengl info gives:

Version: '4.4.0'
Vendor: 'NVIDIA Corporation'
Renderer: 'Quadro K1100M/PCIe/SSE2'
RendererDriverVersion: '9.18.13.4075'
RendererDriverReleaseDate: '26-Aug-2014'
MaxTextureSize: 16384
Visual: 'Visual 0x07, (RGBA 32 bits (8 8 8 8), Z depth 16 bits, Hardware acceleration, Double buffer, Antialias 8 samples)'
Software: 'false'
HardwareSupportLevel: 'full'
SupportsGraphicsSmoothing: 1
SupportsDepthPeelTransparency: 1
SupportsAlignVertexCenters: 1
Extensions: {299×1 cell}
MaxFrameBufferSize: 16384

the opengl software is:

Version: '1.1.0'
Vendor: 'Microsoft Corporation'
Renderer: 'GDI Generic'
MaxTextureSize: 1024
Visual: 'Visual 0x17c, (RGB 24 bits (8 8 8), Z depth 16 bits, Software, Single buffer, Antialias 0 samples)'
Software: 'true'
HardwareSupportLevel: 'none'
SupportsGraphicsSmoothing: 0
SupportsDepthPeelTransparency: 0
SupportsAlignVertexCenters: 0
Extensions: {3×1 cell}
MaxFrameBufferSize: 0

4. Have you changed renderers or interpreters?

- I have changed the interpreter to latex but that did not have an effect. How do i change the rederer?

[dpb]

Have you tried the legend command both after

opengl hardware
legend(...)

and

opengl software
legend(...)

to see if that has any effect whether trying to use the video card driver or the software emulation?

Just to isolate, you can turn off OpenGL for a given figure by

figure
hF=gcf; hF.Renderer='painters';

and then try legend

[Chris]

Hi dpd all three suggestions did not have an effect. The problem persists.

[dpb]

Figures... :(

Since this is system-dependent I think your only recourse will be to file a Bug Report through official TMW channels (via "Contact Us" link at top of each page) as they're the only ones who can now get into the internals of the legend function deeply enough to figure out what might be happening.

The only other thing I can think of trying would be to see if, after the legend is already created with a string that does work, whether you can modify the property of that element. This probably won't work, either, but it's one level deeper into the bowels than just passing the string at the top level.

I'm not sure without more "handle-diving" than I have time to undertake at the moment whether with the rewritten legend one even has access to that without resorting to further tricks of finding hidden objects.

In my opinion, TMW has done the user a real disservice in many of the changes they have made in this function that make it much more opaque than had been previously such that both debugging when there is a problem is near impossible plus special usages are more difficult than previously. Wish I had better news/ideas...

[dpb]

Oh, related Q? that _might_ (or might not) shed some light on the issue...can you write text with an embedded \n and have it interpreted correctly, or does it also fail? If the latter, that would indicate something in the installation of the behind-the-scenes TeX support stuff, maybe, that is a very dark gray (if not completely black) almost undocumented box.

[Chris]

Thanks for you reply dpb.

I tired these suggestions:

1. " The only other thing I can think of trying would be to see if, after the legend is already created with a string that does work, whether you can modify the property of that element. This probably won't work, either, but it's one level deeper into the bowels than just passing the string at the top level."

This did not solve the problem.

2. "Oh, related Q? that _might_ (or might not) shed some light on the issue...can you write text with an embedded \n and have it interpreted correctly, or does it also fail?"

I can make multiple lines with the "text" command and and embedded \n also in figures. Its only with legends where I am having problems.

Manyt thanks for your help! I will contact TMW

[dpb]

Both of those results are what I expected...it tends to confirm TMW did something inside legend uniquely different than the interpreter with text -- if it were down to the same, identical code in the deepest bowels, you would expect both to fail on the rendering. That one does, the other doesn't indicates that isn't so.

OTOH, that it is somehow system-dependent in that the same nominal OS/ML release doesn't fail here, may mean that perhaps only someone with the particular graphics card can figure out what's going on...oh! which makes one think of something else--have you checked on firmware updates for the video driver and are MS updates on?

[Jan]

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]

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]

I reinstalled matlab which solved the problem....

Thanks everyone for their help!

Answer 1

[Yair Altman]

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

[Jan]

The problem occurred for this also:

figure;
plot(1:10);
legend(['test 1' char(10) 'done'])

So it was not the '\n', but the provided char(10) has been converted inside legend to '\n' in the displayed string.

[Yair Altman]

Jan - your code works perfectly fine on my 19aPR - which release are you using?

[Jan]

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]

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.