bugGNU Octave - Bugs: bug #40064, Legend "interpreter"...

 
 

bug #40064: Legend "interpreter" property not working correctly

Submitted by:  Rik <rik5>
Submitted on:  Thu 19 Sep 2013 03:06:39 AM UTC  
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  dev Operating System:  Any

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Sun 01 Jun 2014 10:49:07 PM UTC, comment #36: 

Mike,

Thanks, your responses do indeed help to understand better.

Unfortunately time is running out this weekend and won't be able to write up the detailed discussion that I mentioned, but will do so at next opportunity, probably next weekend or so.  As mentioned, I do think there's a higher-level importance to this issue of graphical property inheritance that is missing from the detailed discussion so far of this specific case about the Interpreter property.

But let me briefly address here one point from your previous two posts.  Maybe this will also give you an idea of where I'm going with this and why I'm being such a fussbudget about it.

In Comment #33, you refer to the Matlab legend doc [1], specifically the bullet list of six properties: Location, Orientation, EdgeColor, TextColor, Interpreter, String.  In #35, you say that "... a legend is, by Matlab's definition, an axes object that inherits some of its properties from axes, but explicitly not the Interpreter property."

The above statements seem to lie at the core of debate on this particular property. Here's my take on it:

Unfortunately, the bullet list of "exceptions" in [1] is described in a very confusing way, as a set of properties which are "not shared" with Axes, and which you then interpreted as meaning "not inherited".  But this doc wording is very misleading and fails to make a key point: All of those bulleted "exceptional" properties are properties which Matlab's Axes object doesn't even have [2], so naturally they're not available for "sharing", or "inheritance", or in any other way that has anything to do with mutuality between the two objects.  There isn't any.

Those six properties are simply independent superset properties of a Legend, which, in Matlab, have no relation whatsoever to its parent Axes.  So drawing the readers' attention to them in a way which implies that they "could have been" shared/inherited, but aren't is totally confusing. What they really meant to say is something like "a legend object also has the following additional properties beyond those inherited from the parent Axes."

I'm pretty sure that the actual state of affairs in Matlab's Legend object (and even more generally) is that it does in fact inherit all properties from its parent Axes object.  Quite a few of those properties are entirely irrelevant for a Legend (for example all the 'Camera' properties, and many others) but I believe that all those that are relevant to rendering a Legend are inherited as-is.

Unfortunately, I can't verify this because I no longer have access to a recent version of Matlab. But that's my recollection from a few years back when I was actively using both M and O, and constantly fighting graphical property inheritance/defaulting issues of this type in order to get complex plots with complex legends to render identically on both systems. This interpretation is also supported by the following statement, a few paragraphs earlier in [1]:

    "Legends inherit the properties of axes, although not all of them are relevant to legend objects."

In other words, Mathworks seems to take the straightforward and ordinary view that every property of a parent object that is applicable to its subclassed child is inherited. [3]

So how does this affect the point which you made regarding O/M compatibility?  Your point was that since Matlab doesn't inherit Interpreter from its parent, then even though an Octave Axes has an Interpreter property, it should nevertheless not be inherited by Legend since Matlab's doc explicitly says that that property isn't "shared" with its parent Axes.  No argument that it isn't shared/inherited in Matlab -- it doesn't even exist in Matlab's Axes to be shared or inherited -- but I disagree with your conclusion because it only tells half the compatibility story.

It seems to me that the other half is this: An Octave Axes does have an interpreter property, and an Octave Legend -- analogous to a Matlab Legend -- is also documented as being an Axes object, with no mention of inheritance exceptions (at least in the 3.8.1 doc).  Therefore, one can claim that to be consistent with Matlab's inheritance model (or simply basic "academic" inheritance consistency) an Octave Legend should inherit its interpreter property (and hence it's associated default as well) from the parent Axes.

No argument at all that changing Octave to behave in this way -- inheriting Interpreter -- would introduce a behavioral incompatibility with Matlab, it obviously would. But it's also true that not inheriting it simply substitutes one form of incompatibility for another subtler one.

I would like to try to make the larger case (elsewhere, not here/now) that the introduction of inheritance inconsistencies within Octave is potentially a (much) worse side effect than the benefit of present-day script behavioral compatibility. Especially given the pragmatic fact that as developers, you'll probably never be able to achieve the latter; and even more discouraging, in the final analysis, Mathworks has and always will have the ball in determining how Matlab properties work, and can change things at any time.  So seeking a very high level of present-day behavioral compatibility is inherently threading a moving needle, and with the associated frustrations.  And I suspect that it comes at a significant development resource cost in farting around with lots of tiny little code details that perhaps are not worth the trouble and time.

Anyway....  Having already rambled about 5x longer than I intended here, I'll now STFU.  But that's the essence of where I'm going with this issue in the larger view.  I'm not trying to be a smartass about it or even imply that the way it's presently implemented is "wrong", only that it seems worth debating and opening up the broader question of graphical property O/M compatibility vs. side effects in general, rather than just dealing with this particular property in this particular case.

Regards,

Glenn

[1] http://www.mathworks.com/help/matlab/ref/legend.html

[2] http://www.mathworks.com/help/matlab/ref/axes_props.html

[3] http://www.mathworks.com/help/matlab/matlab_oop/defining-properties.html:

     "When you derive one class from another class, the derived (subclass) class inherits all the properties of the superclass. In general, subclasses define only properties that are unique to that particular class."

Glenn Golden <grepfor>
Sun 01 Jun 2014 04:56:10 AM UTC, comment #35: 

> Are there any other text rendering functions aside from legend() which presently obtain their interpreter default via the DefaultLineInterpreter property?


I don't know. But legend no longer obtains its interpreter value from the DefaultLineInterpreter property, this is incorrect behavior in 3.8.1 but is fixed for future releases (as Rik noted in comment #25 and I missed when I posted my last comment).

> Are there presently any other DefaultXxxxInterpreter properties other than Line, Text, and Axes?


As far as I can tell, the following objects have the interpreter property: axes, line, text, patch, and surface. So there is a default interpreter property for each of these object types.

> Are there presently any plans to add any other DefaultXxxxInterpreter properties beside those three?


I don't know. Specifically there will be no DefaultLegendInterpreter, because a legend is, by Matlab's definition, an axes object that inherits some of its properties from axes, but explicitly not the Interpreter property.

Does that answer your questions?

Mike Miller <mtmiller>
Project Administrator
Sat 31 May 2014 04:10:29 PM UTC, comment #34: 

Thanks for your response, Mike. I'm happy to have the opportunity to debate this in some detail to get a good resolution. In my view, it's more important than is perhaps being appreciated.

I disagree with most of your points but would like to address them in detail in an in-depth writeup, rather than superficially one comment at a time. In order to do so, I would like to ask again for answers to the three straightforward questions asked earlier (comment #30). Without that information it is difficult to respond intelligently in depth.

Quickly commenting on your example script though: No disagreement at all that that script has no compatibility issue in either direction (O->M or M->O). But in my view, that example is entirely unrelated to the issue at hand in this ticket, since it explicitly sets the interpreter type for the legend object. The issue in the ticket (regarding both M/O compatibilty and Octave's own documentation) is the behavior in the absence of an explicit interpreter setting for the legend() object, in which the object falls back on either user-supplied or hardwired defaults.

Again, if I can get answers to the three questions asked previously, I'll respond in more depth and address all the points you brought up.

Thanks.

Glenn Golden <grepfor>
Sat 31 May 2014 03:13:57 PM UTC, comment #33: 

Glenn, here is my take on this bug.

I am not sure that there is any Matlab incompatibility right now. Making a change to allow the default interpreter property for legend to inherit from some other object type might actually introduce an incompatibility, so that would be undesirable unless there is a very strong reason to do so.

Here is an example from the Matlab help for legend (http://www.mathworks.com/help/matlab/ref/legend.html) that works perfectly in Octave:

figure
x = -pi:pi/20:pi;
plot(x,cos(x),'-ro',x,sin(x),'-.b')
hleg1 = legend('cos_x','sin_x');
set(hleg1,'Location','NorthWest')
set(hleg1,'Interpreter','none')

And moreover, the following excerpt from the same legend help page:

> The properties that legends do not share with axes are
> * Location
> * Orientation
> * EdgeColor
> * TextColor
> * Interpreter
> * String


So they explicitly say that the interpreter property is not inherited from the default axes property set. Making it do so would introduce unexpected incompatibility.

It may yet be a bug that the legend interpreter does inherit from something else, when in fact it may be that it should inherit from nothing and there simply should be no way to set the default (until Matlab decides that there is, of course).

And it may be a bug that it reports back "tex" when getting the property after setting it to "none". I do not have access to Matlab to test that at the moment.

Mike Miller <mtmiller>
Project Administrator
Sat 31 May 2014 01:17:53 PM UTC, comment #32: 

From the lack of response to the questions in comment #30 I'm assuming there's no interest in persuing this issue further.

Unfortunate, because it seems to me the present state of affairs regarding the various interpreter defaults is not only self-inconsistent within Octave, but also causes (rather than alleviates) Matlab/Octave compatibility and documentation issues.  Imo, cleaning this up and getting it right is worth some time so that it doesn't propagate needlessly into future versions.

Glenn Golden <grepfor>
Sat 24 May 2014 03:46:02 PM UTC, comment #31: 

Hello?

Glenn Golden <grepfor>
Sat 17 May 2014 12:19:11 AM UTC, comment #30: 

This weekend I plan to write up something in detail on this issue. But before doing so, wanted to ask a few questions:

1. Are there any other text rendering functions aside from legend() which presently obtain their interpreter default via the DefaultLineInterpreter property?

2. Are there presently any other DefaultXxxxInterpreter properties other than Line, Text, and Axes?

3. Are there presently any plans to add any other DefaultXxxxInterpreter properties beside those three?

Thanks.

Glenn Golden <grepfor>
Mon 12 May 2014 10:09:22 PM UTC, comment #29: 

Thanks, Rik.

OK, based on your concern here and your example, I would like to try to make the case that introducing this patch would be a Very Bad Idea, for a variety of reasons which span usability, documentation, and the script writer's ease (or lack thereof) in quickly and accurately diagnosing the source of Matlab/Octave incompatibility when it does occur. In my view, a superior solution would be to have legend()s inherit the DefaultAxesInterpreter property, and live with the [somewhat different, but "nicer"] incompatibility that ensues from that.

I'll be glad to document in detail my rationale for this view, but unfortunately will not have time to do so until at least the coming weekend or perhaps even later. So I respectfully request that the patch not be applied until there's some time to debate the underlying issues, either in the ticket here or in the ML. Imo, there's quite a bit at stake in getting this right.

Glenn Golden <grepfor>
Sun 11 May 2014 12:51:46 AM UTC, comment #28: 

The patch for DefaultTextInterpreter was never applied.  I just wrote it to show what could be done if we want to; It will very definitely introduce an incompatibility with Matlab.  However, Octave developers will occasionally deviate from Matlab behavior if we feel it is wildly wrong.

If the patch were introduced, then this would be an example where Octave and Matlab would differ:

set (0, 'DefaultTextInterpreter', 'none');
plot (1:10);
hl = legend ('A^1');
get (hl, 'interpreter')

Rik <rik5>
Project Administrator
Sat 10 May 2014 03:48:17 PM UTC, comment #27: 

Rik, I understand superficially what you wrote regarding Matlab compatibility.  But once I think about it in more detail, I can't see any compatibility issue in either direction (Matlab script running on Octave or the other way 'round) that is going to be improved by the patch which sets the legend default interpreter based on DefaultTextInterpreter.

The further I think it thru, the more it seems that that patch will create quite a few painful side effects, especially in the area of documentation, and will simply move the compatibility issue from one place to another. 

But rather than blabbing about it in detail here though, let me just ask if you could post very briefly about which direction the compatibility issue exists, and perhaps a 2-3 line minimal example that illustrates the issue.  I'll take it from there and try to understand it better, before saying any more.  Probably I'm simply not appreciating some aspect of the compatibility issue, and the example will show it up.

Thanks.

Glenn Golden <grepfor>
Thu 08 May 2014 07:30:34 PM UTC, comment #26: 

Rik, Matlab does return "tex".

Ben Abbott <bpabbott>
Project Member
Thu 08 May 2014 06:02:03 PM UTC, comment #25: 

Issue 1 is the result of the chase for Matlab compatibility.  A legend is an axes object, but it cannot inherit from DefaultAxesInterpreter because Matlab does not have such a property.  Therefore we hardcode the initial value to 'tex' which accords with their documentation.  If they have gotten more sensible about things and changed the default then we can too.  The most sensible value would be DefaultTextInterpreter which is what my quick patch would do.  If someone with Matlab can run the following code we can see whether they have changed things.

set (0, 'DefaultTextInterpreter', 'none');
plot (rand (3, 1));
hl = legend ('A_1');
get (hl, 'interpreter')

If they follow their own documentation this will still return 'tex'.

Issue 2--I hate coding for gnuplot--is resolved by cset e5ab507687ee that I just checked in on the stable branch.

Rik <rik5>
Project Administrator
Thu 08 May 2014 04:02:03 PM UTC, comment #24: 

Agree Mike, it seems to be the DefaultLineInterpreter property that affects legend rendering, not DefaultAxesInterpreter. I was toggling all three at once, and assuming it was the Axes property having the effect, since the documentation explicitly tells the user that a legend is an Axes object.

So there are really multiple issues:

  * Legend is documented as being an Axes object, yet does not hew to the DefaultAxesInterpreter property in any way, neither reporting nor rendering in accordance with that property.

  * Legend perversely hews to the DefaultLineInterpreter property, but only in its functional behavior, not in what it reports as its own 'interpreter' property, which is always reported as 'tex'.

Glenn Golden <grepfor>
Thu 08 May 2014 12:38:14 PM UTC, comment #23: 

I see what Glenn is seeing with 3.8.1. Moreover, I tried setting each of the default interpreter properties independently to "none" in separate Octave sessions, and the only one that affects the way the legend label is rendered is the "defaultlineinterpreter" property.

No matter what I set and no matter how it renders, getting the interpreter property of the legend object always returns "tex".

Mike Miller <mtmiller>
Project Administrator
Thu 08 May 2014 07:05:17 AM UTC, comment #22: 

I understand that the legend object's interpreter property defaults to 'tex'.  But there's still something wrong: It's inconsistent that with DefaultAxesInterpreter set to 'none' the legend object reports its interpreter as 'tex', and yet renders its text as though the interpreter is 'none'.  That's what I reported in the previous comment. Are you seeing that also? Please answer that question first so we can at least figure out whether we're even observing the same behavior.

If you're also seeing this behavior, then I claim that it is nonsensical, because it implies that one of the following unpleasant states of affairs must be the case:

Either:

  1. The function get(h, 'interpreter') on a legend object returns a value ('tex') which is known not to agree with its actual text rendering functionality ('none'),

OR

  2.  The text rendering functionality of a legend object has nothing to do with its reported interpreter value, but only with the value of its parent axes object.

To me, either of the above interpretations seems inconsistent and misleading. A user has the reasonable expectation the text rendering functionality of an object agrees with its reported interpreter property. If you're seeing what I'm seeing, it doesn't.

If this doesn't seem inconsistent to you, can you explain slowly and carefully why? I'm not getting it.

Glenn Golden <grepfor>
Thu 08 May 2014 04:15:26 AM UTC, comment #21: 

@Glenn: I got 4 copies of your e-mail direct from the bug tracker so no need to send me anything.

You are right that for legend objects the default interpreter is 'tex'.  This was done for Matlab compatibility.  Matlab axes objects do not have an "interpreter" property hence a Matlab legend can't inherit from DefaultAxesInterpreter.  With Octave we tried to be as compatible as possible which means legend objects must have an interpreter property and according to the documentation it defaults to 'tex'  (http://www.mathworks.com/help/matlab/ref/legend.html).  It would be quite straightforward to default it to DefaultTextInterpreter.  I've attached a quick patch against the development code which does that.  We could consider making that change if some of the other maintainers think its appropriate.

(file #31333)

Rik <rik5>
Project Administrator
Thu 08 May 2014 03:09:21 AM UTC, comment #20: 

Rik, is there a way to get this comment to you other than via the website? I've tried to enter it four times now, each time it is rendered incorrectly. And without a preview feature I'm just wasting my time and lots of space in the ticket.

Glenn Golden <grepfor>
Thu 08 May 2014 03:05:52 AM UTC, comment #19: 

Thanks, Rik. Still something fishy though:

If I set the extra defaults for each type of object used then your script runs as expected.

I'm not seeing that. With DefaultXxxxInterpreter set to 'none' for Xxxx = Text, Line, and Axes, I still see the last example in the ex2.m script (using legend()) misbehave. On my setup, it reports the interpreter property of the legend as 'tex', even though the text in the actual rendered legend is now formatted according to 'none', i.e. it appears as 'foo_bar', rather than with subscripted 'b'. 

I also tried setting DefaultLegendInterpreter (thinking there might be a specialized interpreter for legends) but it seems there is no such property.

When you tried the example, did you set a DefaultXxxxInterpreter property for any additional values of Xxxx other than Line, Axes, and Text? Also, did you run it with --norc?

Btw, as an aside from the actual behavior: Googling for the terms DefaultAxesInterpreter and DefaultLineInterpreter returned exactly zero matching results (literally, zero.) So I think it's fair to say that these properties are not widely known. Searching for the strings TextInterpreter, LineInterpreter, and AxesInterpreter in Octave's info(1) page also yields nothing.

Section 15.2.7 ("Use of the 'interpreter' Property") is also not helpful in making any distinction. I did read that section prior to filing the prior comment and nevertheless still did not guess that DefaultTextInterpreter applied only to text rendered via the text() function. Why? Because the first sentence of 15.2.7 says

All text objects, including titles, labels, legends, and text, include the property "interpreter", this property determines the manner in which special control sequences in the text are rendered.

Based on the above sentence, I suspect most people would guess that the [undocumented] property DefaultTextIntepreter applies to "all text objects" rather than only to "objects rendered via the text() function".

Based on Googling, it even seems fair to say that the former interpretation -- that it applies to all text -- is the sole existing perception. I was unable to find a single counterexample in several minutes of searching. This may be due to its behavior in Matlab. Not that that is an issue for Octave of course -- Octave isn't Matlab -- just trying to make the case that it is not widely appreciated that DefaultTextInterpreter does not globally apply to all text.

Glenn Golden <grepfor>
Thu 08 May 2014 02:59:48 AM UTC, comment #18: 

Thanks, Rik. Still something fishy though:

Glenn Golden <grepfor>
Thu 08 May 2014 02:52:54 AM UTC, comment #17: 

Thanks, Rik. Still something fishy though:

Glenn Golden <grepfor>
Thu 08 May 2014 02:51:20 AM UTC, comment #16: 

Thanks, Rik. Still something fishy though:

Glenn Golden <grepfor>
Wed 07 May 2014 11:56:02 PM UTC, comment #15: 

I think Octave is behaving correctly.  The assumption in the script that setting the default 'interpreter' property for Text objects will apply to all other graphic primitives, e.g., Line or Axes, is incorrect.  From the script:

# Expectation of the following statement is that the 'interpreter' property
# for all subsequently created graphics objects will be 'none', but this does
# not seem to be the case, as the example show. Was not able to locate
# authoritative documentation on this property in the info(1) pages, but
# cargo-cult usage seems to agree with the above expectation.
#
set(0, 'DefaultTextInterpreter', 'none');

To set the default for another primitive object, such as Line or Axes, you must use another set command.

set(0, 'DefaultLineInterpreter', 'none');
set(0, 'DefaultAxesInterpreter', 'none');

If I set the extra defaults for each type of object used then your script runs as expected.

Rik <rik5>
Project Administrator
Wed 07 May 2014 10:40:08 PM UTC, comment #14: 

The attached example (ex2.m) seems to indicate that this bug has re-appeared in 3.8.1. Explanatory comments therein.

NOTE: This example script is also being attached to Bug #36744, because it demonstrates a problem relevant to that issue as well, and possibly related to this one.

(file #31330)

Glenn Golden <grepfor>
Mon 03 Feb 2014 11:29:29 PM UTC, comment #13: 

This bug report has been closed for several months.  You might have better luck asking your question on the help or maintainers mailing list.  Overall, your strategy seems fine.  I have Mercurial and the Octave code repository installed on my local machine so I usually use 'hg tags' to get the numeric ID of a specific release and then compare that number to the changeset in question.  For example, release-3-8-0 has the numeric ID 18175.  The changeset that is relevant for this report has ID 17503 so it is almost certainly in the 3.8.0 release.  Mercurial branches, however, can mess up this simple strategy.

Rik <rik5>
Project Administrator
Mon 03 Feb 2014 10:18:39 PM UTC, comment #12: 

That link is ok now, thx.

A question though: This is not specific to this bug but I'll ask it here anyway: Not being familiar with Mercurial, I'm wondering what is the "correct" way to determine whether a given commit is present within a specific numbered version of Octave (as reported by version())?  I looked at the "log" view of the commit list

   http://hg.savannah.gnu.org/hgweb/octave/log

but the only thing I see giving a hint about the points in time at which numbered releases were made is entries with descriptive text like "snapshot x.y.z". Such entries can of course be located via search within the list using that "snapshot" keyword, and then the date compared to the date of the commit you're interesting in knowing about. But I'm wondering if there's a more streamlined way to accomplish this?

Glenn Golden <grepfor>
Sun 02 Feb 2014 12:25:39 AM UTC, comment #11: 

The link in Comment #10 appears to be dead.

Glenn Golden <grepfor>
Fri 27 Sep 2013 05:27:09 AM UTC, comment #10: 

I just submitted a changeset which has the text objects inheriting the textcolor, fontsize, and interpreter property from the axis (http://hg.savannah.gnu.org/hgweb/octave/rev/d99785217634).  Now things seem to work.

Rik <rik5>
Project Administrator
Thu 26 Sep 2013 11:48:35 PM UTC, comment #9: 

Rik,  I found the difference. My ~/.octaverc set the default axes interpreter to "TeX".

Ben Abbott <bpabbott>
Project Member
Thu 26 Sep 2013 11:29:27 PM UTC, comment #8: 

I think it's a valid expectation that the default interpreter value is identical for all objects. Although, as tex support is not honoured yet when printing, I'm wondering whether this is a wise choice, at least for the time being.

Michael Goffioul <goffioul>
Thu 26 Sep 2013 11:22:55 PM UTC, comment #7: 

Our e-mails were nearly simultaneous (9 second difference).  Yes, I think you're right.  The text objects should inherit from the legend axis.

But, as a second question, should we default the interpreter property to 'tex' to be in line with the other objects?

Rik <rik5>
Project Administrator
Thu 26 Sep 2013 11:14:15 PM UTC, comment #6: 

If I'm right in my reasoning, changing the default interpreter value of the axes object won't solve everything. You could still create the axes object, then set "interpreter" to "none", then create the legend. The text objects in the legend will still use "tex", while the axes is using "none".

Michael Goffioul <goffioul>
Thu 26 Sep 2013 11:08:36 PM UTC, comment #5: 

I've found the problem.  At least for me, the default axes interpreter property is "none".  The legend object is implemented as an axes with a text and a line child for each entry.  In this case the text object does not inherit the interpreter property from the axis object and the default interpreter for text objects is "tex".

What does the following return for you?

clf;
hax = axes ();
get (hax, 'interpreter')

It really should return 'none'.

And then, how about the following?

clf;
plot (1:10);
hl = legend ('abc');
get (hl, 'interpreter')

It should also return 'none' since the legend is just an axes object.  You might also try

get (0, 'defaultaxesinterpreter')

to see that there is nothing accidentally set.

Since all the other objects which use the interpreter property are defaulting to 'tex', I'm tempted to change the default for axes properties in graphics.in.h.  I just tested that and demo #12 now works for me.

Rik <rik5>
Project Administrator
Thu 26 Sep 2013 11:08:27 PM UTC, comment #4: 

I believe that the problem is due to legend.m not taking into account possible different values for the "interpreter" property for axes and line/text object. When the text objects are created, their "interpreter" is not set, so the default is used, but the test default is "tex" (while the axes's default is "none").

IMO, legend.m should initialize the "interpreter" property of the text objects to the current value of the "interpreter" property of the axes object. In other words, property values of the axes and text objects should be in sync at creation time.

Michael Goffioul <goffioul>
Thu 26 Sep 2013 10:35:45 PM UTC, comment #3: 

Yes.  I meant "demo legend 12".

The default legend interpreter is "TeX" for me.  When I change it to "none" it renderes correctly.

Perhaps this is a timing issue?

Ben Abbott <bpabbott>
Project Member
Thu 26 Sep 2013 10:15:14 PM UTC, comment #2: 

Yes, it's still broken.  You said "demo text 12", did you mean

demo ("legend", 12)

That is the code that shows off the problem.  I've uploaded a screenshot which shows TeX interpreter still on after running the above command.


Rik <rik5>
Project Administrator
Thu 26 Sep 2013 10:06:48 PM UTC, comment #1: 

Rik,

"demo text 12" works for me.   Can you verify it is still broken for you?

Ben Abbott <bpabbott>
Project Member
Thu 19 Sep 2013 03:06:39 AM UTC, original submission:  

The following code is demo #12 from legend.m.

clf;
plot (rand (2));
title ('Labels with TeX interpreter turned off');
h = legend ('Hello_World', 'foo^bar');
set (h, 'interpreter', 'none');

What one should see in the legend box is the actual strings with no TeX markup.  Instead, the TeX parser is on by default and the 'b' in "foo^bar" is superscripted.

The problem seems to be that for a new axes object the default for the "interpreter" property is "none", but the code is defaulting to "tex".  Next, when

set (h, 'interpreter', 'none');

is executed nothing happens because the set() command automatically compares the old property value with the new property value and does nothing if they are the same.  I can force things to work correctly by switching the interpreter away from "none" and back again.  The following generates the correct display.

set (h, 'interpreter', 'latex');
set (h, 'interpreter', 'none');

Rik <rik5>
Project Administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #31333:  legend_interpreter.patch added by rik5 (709B - text/x-diff)
file #31330:  ex2.m added by grepfor (2KiB - text/x-objcsrc)
file #29235:  demo_legend_12.png added by rik5 (16KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by grepfor (Posted a comment)
  • -email is unavailable- added by bpabbott (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-05-24 rik5 Carbon-CopyRemoved 72865 => -
    2014-05-08 rik5 Attached File- => Added legend_interpreter.patch, #31333
    2014-05-07 grepfor Attached File- => Added ex2.m, #31330
    2013-09-27 rik5 StatusNone => Fixed
        Open/ClosedOpen => Closed
    2013-09-26 rik5 Attached File- => Added demo_legend_12.png, #29235

    Back to the top


    Powered by Savane 3.5