[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #50496] Legend and object 'interpreter' proper
From: |
Dan Sebald |
Subject: |
[Octave-bug-tracker] [bug #50496] Legend and object 'interpreter' property disagree |
Date: |
Wed, 8 Mar 2017 14:19:20 -0500 (EST) |
User-agent: |
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0 |
URL:
<http://savannah.gnu.org/bugs/?50496>
Summary: Legend and object 'interpreter' property disagree
Project: GNU Octave
Submitted by: sebald
Submitted on: Wed 08 Mar 2017 07:19:18 PM UTC
Category: Plotting
Severity: 3 - Normal
Priority: 5 - Normal
Item Group: Incorrect Result
Status: None
Assigned to: None
Originator Name:
Originator Email:
Open/Closed: Open
Discussion Lock: Any
Release: dev
Operating System: GNU/Linux
_______________________________________________________
Details:
(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.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?50496>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
- [Octave-bug-tracker] [bug #50496] Legend and object 'interpreter' property disagree,
Dan Sebald <=
- [Octave-bug-tracker] [bug #50496] Legend and object 'interpreter' property disagree, Dan Sebald, 2017/03/08
- [Octave-bug-tracker] [bug #50496] Legend and object 'interpreter' property disagree, Rik, 2017/03/09
- [Octave-bug-tracker] [bug #50496] Legend and object 'interpreter' property disagree, Dan Sebald, 2017/03/09
- [Octave-bug-tracker] [bug #50496] Legend and object 'interpreter' property disagree, Dan Sebald, 2017/03/09
- [Octave-bug-tracker] [bug #50496] Legend and object 'interpreter' property disagree, Rik, 2017/03/09
- [Octave-bug-tracker] [bug #50496] Legend and object 'interpreter' property disagree, Dan Sebald, 2017/03/10
- [Octave-bug-tracker] [bug #50496] Legend and object 'interpreter' property disagree, John W. Eaton, 2017/03/10
- [Octave-bug-tracker] [bug #50496] Legend and object 'interpreter' property disagree, Dan Sebald, 2017/03/10
- [Octave-bug-tracker] [bug #50496] Legend and object 'interpreter' property disagree, John W. Eaton, 2017/03/10
- [Octave-bug-tracker] [bug #50496] Legend and object 'interpreter' property disagree, Rik, 2017/03/10