bugGNU Octave - Bugs: bug #50496, Legend and object 'interpreter'...

 
 

bug #50496: Legend and object 'interpreter' property disagree

Submitter:  Dan Sebald <sebald>
Submitted:  Wed 08 Mar 2017 07:19:18 PM UTC
   
 
Category:  Plotting with gnuplot Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 16 Mar 2017 04:36:54 PM UTC, comment #21: 

I pushed your patch here http://hg.savannah.gnu.org/hgweb/octave/rev/d5f490eebb47 after changing a set of single quotes to double quotes to match Octave coding conventions.

Another bug bites the dust.

Rik <rik5>
Group administrator
Thu 16 Mar 2017 06:06:57 AM UTC, comment #20: 

"Note that this change means individual legend keys can have different"

Should be "can't have different".

Dan Sebald <sebald>
Thu 16 Mar 2017 05:51:56 AM UTC, comment #19: 

Attached is the change I've been using for a few days.  It adds an additional input variable to _maybe_munge_text_(), placing the decision of what interpreter to use at the point of the function call.  That seems the simplest change.

I've tested that text (which doesn't appear in legends, hence no conflict of interpreter), title, xlabel, ylabel, legend all work independently.  And the following makes sense:


octave:20> set(kids(1), 'interpreter', 'none')
warning: 'interpreter' is deprecated and will be removed from a future version of Octave
octave:21> ht = text(0.5, 0.5, 'e=mc^2')
ht = -80.733
octave:22> set(ht, 'interpreter', 'none')


Do you think it would be worthwhile to add a demo to "text" to show that the text's interpreter property is working?

Note that this change means individual legend keys can have different interpreter settings; obvious I suppose.  But if Octave wanted to supply such capability, perhaps a clearer way would be to add a property "displayinterpreter" to go along with "displayname", e.g.,

'displayinterpreter'  [ latex | none | tex | {legend} ]


(file #40012)

Dan Sebald <sebald>
Sat 11 Mar 2017 08:58:52 PM UTC, comment #18: 

The text object must have an interpreter property (http://www.mathworks.com/help/matlab/ref/text-properties.html); that is Matlab-compatible and one should be able to change how a text string is interpreted.

A line or a patch, however, only has some indirectly associated text in the form of the DisplayName property.  This text doesn't need an interpreter property.  The legend object, which is displaying these strings, decides which interpreter to use.


Rik <rik5>
Group administrator
Sat 11 Mar 2017 07:54:13 PM UTC, comment #17: 

I've made changes to _gnuplot_draw_axes_ but rather than post right away, I'll use the mods for a day to see if there are any inadvertent bugs.

I didn't make a straightforward substitution as described previously.  The thing that has me wondering is that the "text" primitive does have an 'interpreter' property.  So, I'm not sure this is an outright deprecation...unless the 'interpreter' in question is a hidden property, i.e., the "hd" qualifier, and the text 'interpreter' is a visible property which may be two different things.

Dan Sebald <sebald>
Sat 11 Mar 2017 02:33:56 AM UTC, comment #16: 

I changed to a try/catch block and the documentation images now build with gnuplot (http://hg.savannah.gnu.org/hgweb/octave/rev/c3c26f6a7812).

Rik <rik5>
Group administrator
Sat 11 Mar 2017 02:21:50 AM UTC, comment #15: 

Okay.  I'll take a look.  I put everything in an unwind protect block, but maybe it should have been a try/catch.

Rik <rik5>
Group administrator
Sat 11 Mar 2017 02:01:56 AM UTC, comment #14: 

Rik: It's just what happens with the buildbot builds, presumably because they are building without an X session?

Anyway, there is now a different failure:

http://buildbot.octave.org:8010/builders/gcc-6-debian/builds/342/steps/compile/logs/stdio

error: get: unknown hggroup property interpreter

John W. Eaton <jwe>
Group administrator
Sat 11 Mar 2017 12:07:16 AM UTC, comment #13: 

@Dan: Up to you.  You're the lead on all things gnuplot.

Rik <rik5>
Group administrator
Fri 10 Mar 2017 11:59:36 PM UTC, comment #12: 

That changeset may be a simpler way of fixing things given the way the current code is arranged, i.e., since the graphics primitive would no longer have 'interpreter' after deprecating, just set that property at the start of the loop.  However, instead of


+      obj.interpreter = get (h_obj, "interpreter");


it should be something like


      if (! isempty (hlgnd))
        obj.interpreter = hlgnd.interpreter;
      else
        obj.interpreter = 'none';
      endif


It's easier doing that check on hlgnd at one point rather than distributed throughout the file several times.

Dan Sebald <sebald>
Fri 10 Mar 2017 11:32:41 PM UTC, comment #11: 

I pushed a temporary fix for gnuplot here (http://hg.savannah.gnu.org/hgweb/octave/rev/589e4e4548e1).  When Dan cleans things up he should remove this cset.

jwe: Are you really using gnuplot as your default toolkit to build the documentation?  I use qt and osmesa and have for a long time.

Rik <rik5>
Group administrator
Fri 10 Mar 2017 11:00:29 PM UTC, comment #10: 

Let me take a quick look.  I changed the "interpreter" property to be both hidden and deprecated, rather than remove it entirely, so it should still be accessible.

Rik <rik5>
Group administrator
Fri 10 Mar 2017 10:29:31 PM UTC, comment #9: 

Dan: OK, but the build wasn't failing until after this changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/218a49aea031

Rik: any objection to temporarily revert this change?

John W. Eaton <jwe>
Group administrator
Fri 10 Mar 2017 09:44:57 PM UTC, comment #8: 

This is the origin of the original bug report that's failing:


stopped in /home/jwe/src/octave/scripts/plot/util/private/__gnuplot_draw_axes__.m at line 2465
2465:     if (strcmp (obj.interpreter, "tex"))
debug> obj


_gnuplot_draw_axes_.m shouldn't be using 'obj.interpreter', instead it should be using the legend's 'interpreter' property.  The two properties aren't in synch.

I'll write a better patch than #39952 sometime this weekend that should work with Rik's mods.

Dan Sebald <sebald>
Fri 10 Mar 2017 09:26:44 PM UTC, comment #7: 

Rik: Octave compiles OK but there is an error when running doc/interpreter/geometryimages.m to build figures for the docs:

http://buildbot.octave.org:8010/builders/clang-3.9-debian/builds/326/steps/compile/logs/stdio

Since that error message isn't very helpful, I build Octave and ran the command by hand with debug_on_error set and I found


buserror:11> /bin/bash run-octave --norc --silent --no-history --path ~/src/doc/interpreter/ --eval "geometryimages ('doc/interpreter/', 'voronoi', 'eps');"
error: 'geometryimages' undefined near line 1 column 1
buserror:12> pwd
/home/jwe/build/octave
buserror:13> /bin/bash run-octave --norc --silent --no-history --path ~/src/octave/doc/interpreter/ --eval "geometryimages ('doc/interpreter/', 'voronoi', 'eps');"
error: structure has no member 'interpreter'
buserror:14> /bin/bash run-octave --norc --silent --no-history --path ~/src/octave/doc/interpreter/
octave:1> debug_on_error (1)
octave:2> geometryimages ('doc/interpreter/', 'voronoi', 'eps')
error: structure has no member 'interpreter'
error: called from
    __gnuplot_draw_axes__>__maybe_munge_text__ at line 2465 column 5
    __gnuplot_draw_axes__ at line 675 column 15
    __gnuplot_draw_figure__ at line 172 column 17
    __gnuplot_drawnow__ at line 43 column 9
    __gnuplot_print__>local_drawnow at line 226 column 5
    __gnuplot_print__>eps_drawnow at line 214 column 5
    __gnuplot_print__ at line 75 column 9
    print at line 518 column 14
    geometryimages at line 55 column 5
stopped in /home/jwe/src/octave/scripts/plot/util/private/__gnuplot_draw_axes__.m at line 2465
2465:     if (strcmp (obj.interpreter, "tex"))
debug> obj
obj =

  scalar structure containing the fields:

    beingdeleted = off
    busyaction = queue
    buttondownfcn = [](0x0)
    children = [](0x1)
    clipping = on
    createfcn = [](0x0)
    deletefcn = [](0x0)
    handlevisibility = on
    hittest = on
    interruptible = on
    parent = -1.8402
    selected = off
    selectionhighlight = on
    tag =
    type = line


I'm not sure what the proper fix is for this.  If a property is deprecated, shouldn't it still work?  Or is it available with get() but not part of the structure?  I see that the failing code is using a structure element instead of get (obj, "interpreter").  But either way, I guess Octave needs to avoid using this property.

John W. Eaton <jwe>
Group administrator
Fri 10 Mar 2017 06:42:54 AM UTC, comment #6: 

What you said is correct.  In the current gnuplot toolkit, the 'interpreter' property is coming from the primitive.  But the documentation makes no mention of the 'interpreter', just 'displayname'.  That's why I suggested the only way for the documentation to be clear is if primitive graphics objects don't have an 'interpreter' property such that the only alternative is to get that value from the legend.

The attached patch changes the current behavior so that the interpreter setting comes from legend, not the object itself.  But don't use that patch, as it is clumsy and in fact won't work if obj.interpreter is removed.  I'll change things so that calling _maybe_munge_text_() is a little more graceful.

Feel free to make the change removing 'interpreter' from the primitives.  Or post the "hg diff" for your change here for safe keeping.

Dan Sebald <sebald>
Fri 10 Mar 2017 04:55:19 AM UTC, comment #5: 

Can you re-state the problem?  Everything seems to be fine to me.

The "DisplayName" property is text that is used for the label of an object when displayed in a legend.  This property defaults to "".  It can be filled in manually, or will be assigned by legend() if it is empty.

Example 1: Explicit assignment


hl = line ([0 1], [0 1], 'DisplayName', 'MyLineObject');
legend show


Example 1: No assignment


close all
hl = line ([0 1], [0 1]);
legend ('LineObject2')


The "interpreter" property doesn't exist on Matlab primitives like line (http://www.mathworks.com/help/matlab/ref/primitiveline-properties.html) or surface.  The fact that it does in Octave is an artifact of an earlier implementation and should probably be removed from graphics.in.h.  I just tried that and Octave compiles just fine.

Rik <rik5>
Group administrator
Thu 09 Mar 2017 06:34:41 AM UTC, comment #4: 

Attached is a hastily-constructed fix.  Let me know your thoughts.  The change is that sort of clumsy approach of setting the properties of the object to some temporary value and restoring.  It might be nicer to simply expand _maybe_munge_text_() input variables.  If the graphics object isn't supposed to have "interpreter", just "displayname", it doesn't make sense to create such a property, i.e., obj.interpreter, and then remove that field after the call.

(file #39952)

Dan Sebald <sebald>
Thu 09 Mar 2017 05:51:54 AM UTC, comment #3: 

That doesn't quite clear things up, as there is no mention of the source of interpreter.  The doc says legend "Text".  I assume that means both the legend title and the entries' "displayname", but there is no specific mention of that.  What about the line's "interpreter" property?  Is that supposed to be present?  Maybe not.  That would make things clear if that were the case.

Dan Sebald <sebald>
Thu 09 Mar 2017 05:30:28 AM UTC, comment #2: 

The legend interpreter property determines how text appears in the legend.  See http://www.mathworks.com/help/matlab/ref/legend-properties.html.

The original graphics object's interpreter property should not be touched by the legend function.  See http://www.mathworks.com/help/matlab/ref/legend.html for a description of the DisplayName property.


Rik <rik5>
Group administrator
Wed 08 Mar 2017 07:56:54 PM UTC, comment #1: 

It looks like the "displayname" originates from legend.m.  There are three or four lines of code that either set or get "displayname" from a listener.

This doesn't seem like a difficult fix (maybe just add another listener for "interpreter"?), but the question is more how to handle the mods to the graphics object.  Some rules like the following:

1) If the legend's interpreter is set, that changes all the child object interpreters to the same value.

2) If the graphical object's interpreter is set, that should cause the associated text object in the legend's child list to have the same interpreter.  Hmm, but how does the legend know what graphics object is connected to the child in its list?

Really, the better approach is to retain handle/pointer info rather than duplicate text strings without having some form of connection.

Dan Sebald <sebald>
Wed 08 Mar 2017 07:19:18 PM UTC, original submission:  

(I listed as "plotting" rather than "plotting with gnuplot" because I believe this is actually more general.)

Using gnuplot toolkit illustrates that the legend text property 'interpreter' isn't quite in synch with that of the object being plotted:


graphics_toolkit('gnuplot');
hline = plot([1:50])
htitle = title("1_2_3");
set(htitle,'interpreter','none');
hlegend = legend("1_2_3");
set(hlegend,'interpreter','none');


Notice that even though the legend interpreter is 'none', the plot still has some type of enhanced character "@" showing up.  (That gnuplot "@" character code is somewhat strange, but not the core issue for this bug report.)

Where OpenGL drivers might get it's legend information from the legend, gnuplot gets that information from the objects "displayname" because of the way gnuplot constructs titles for keys (they have to be tied to the plot element themselves).  Internal code must link legend and the object's 'displayname' in some way.  Try something like:


set(hline,'displayname','foo');
get(hlegend)


and notice that the legend's string information has been updated.  So, there is a two-way link here in which changing one results in a change in the other.  But that seems to be overlooked for the text's interpreter setting.

Even though the interpreter of the legend has been set to 'none' with the lines line's interpreter is still 'tex':


octave:24> get(hline, 'interpreter')
ans =

tex


If I manually set the line's 'interpreter' property


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


The enhanced text "@" character is gone.

The legend 'text' properties and graphical object 'displayname' property seems sort of redundant to me.  In any case, I would think that some internal code or non-driver-specific plotting code is responsible for keeping the pertinent info in synch.

Dan Sebald <sebald>

 

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

Attach Files:
   
   
Comment:
   

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by sebald (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-03-16 rik5 StatusIn Progress Fixed
        Open/ClosedOpen Closed
    2017-03-16 sebald Attached File- Added octave-legend_or_text_interpreter-djs2017mar16.patch, #40012
    2017-03-10 rik5 CategoryPlotting Plotting with gnuplot
        StatusNone In Progress
    2017-03-09 sebald Attached File- Added octave-legend_interpreter-djs2017mar09.patch, #39952

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code