Sun 26 Feb 2012 03:06:23 AM UTC, comment #15:
Sorry it took so long.
The change below should have been included.
Thanks !
|
Sun 26 Feb 2012 02:53:35 AM UTC, comment #14:
Thanks for pushing my patch.
|
Sun 26 Feb 2012 12:36:27 AM UTC, comment #13:
I'm closing this. It can be reopened if needed.
|
Sun 26 Feb 2012 12:35:42 AM UTC, comment #12:
I ran through the plot demo using Soren's dump_demos script. I didn't detect any regressions.
Since this got dropped (in part) by my hesitation to push it, and since 3.8 is still a ways off, I've pushed the change.
http://hg.savannah.gnu.org/hgweb/octave/rev/4f160344236a
My apologies for goofing up the ChangeLog entry :-(
|
Sat 25 Feb 2012 11:49:45 PM UTC, comment #11:
Opps !
I made an error when manually applying the original. Second version is attached.
(file #25166)
|
Sat 25 Feb 2012 11:01:18 PM UTC, comment #10:
I've updated the changeset and started a build.
I'll run some tests and report back later.
(file #25165)
|
Sat 25 Feb 2012 10:46:34 PM UTC, comment #9:
Looks fine to me.
|
Sat 25 Feb 2012 09:15:52 PM UTC, comment #8:
Hmmm. We seem to have really dropped the ball here.
Ben or Michael, can you look at the patch attached to this bug report and commit it? A quick glance leads me to believe it is fine.
|
Mon 06 Jun 2011 01:05:39 AM UTC, comment #7:
Please forgive a newbie question, but I am wondering whether I dropped the ball somehow. On 4/29, Michael Goffioul suggested he would be happy for my patch to be merged if it improved Matlab compatibility, which Ben Abbott confirmed. There was then a brief discussion about some further possible compatibility improvements, and there the matter rested. Does that mean the ball is back in my court? Or is it simply that everyone with the authority to merge patches is working on more urgent things? If somebody could clarify the etiquette/procedures, I would be much helped. Naturally, I would be happy to perform any further testing or tweaking that is deemed beneficial before this patch can be implemented.
|
Sat 30 Apr 2011 04:27:34 AM UTC, comment #6:
> Matlab's result [depends] upon the text objects "units" property.
Of course. And so does Octave's result with my patch. And, in "normalized" units, it agrees fairly well with Matlab. (It won't be the same, because the font renderer is different.)
|
Sat 30 Apr 2011 03:43:50 AM UTC, comment #5:
Daniel, thanks for the heads-up.
After reading your comment it occurred to me that Matlab's result might depend upon the text objects "units" property.
Which it does. Running the script below ....
... produces the result ...
|
Sat 30 Apr 2011 03:26:59 AM UTC, comment #4:
For full disclosure: there is one remaining known incompatibility with Matlab: in Matlab, the extent property returns all zeros on non-2d axes. I did not implement that feature in my patch.
- Daniel.
|
Fri 29 Apr 2011 10:57:00 PM UTC, comment #3:
Matlab compatibility has been improved.
Without patch
With patch
Matlab
|
Fri 29 Apr 2011 07:50:50 AM UTC, comment #2:
If this is compatible with Matlab, I've no objection to the patch. Can someone apply it?
|
Wed 27 Apr 2011 02:00:42 AM UTC, comment #1:
I've cc'd Michael
|
Tue 26 Apr 2011 04:51:11 AM UTC, original submission:
In either gnuplot or fltk, if I create a simple plot, e.g.,
plot([1:5],[1:5].^2);
annotate it with some text, e.g.,
t = text(2,7,'Hello world');
and request the extent of that text:
ext = get(t,'extent')
I get the wrong answer:
ext =
0.99078 -0.54777 0.48848 0.94946
instead of
ext =
1.99078 6.4522 0.48848 0.94946
As the author of the original "extent" implementation, Michael Goffioul, points out, this is because the (x,y) coordinates of the extent are based on the axis range rather than the "position" of the text object.
I am attaching a patch to correct this problem.
|