bugGNU Octave - Bugs: bug #39697, legend doesn't change position if...

 
 

bug #39697: legend doesn't change position if title block grows

Submitter:  Rik <rik5>
Submitted:  Mon 05 Aug 2013 05:06:54 AM UTC
   
 
Category:  Plotting 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
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 08 Feb 2020 07:36:23 AM UTC, comment #22: 

I changed the condition as suggested by Rik and pushed here:
http://hg.savannah.gnu.org/hgweb/octave/rev/04b2977952cc

Markus Mützel <mmuetzel>
Group administrator
Mon 03 Feb 2020 11:00:15 PM UTC, comment #21: 

You're correct that this is not applicable to gnuplot.

I think it is fine to skip it if the the toolkit is not qt or fltk.

Rik <rik5>
Group administrator
Sat 01 Feb 2020 10:37:38 AM UTC, comment #20: 

Running the test suite with graphics_toolkit gnuplot, the test marked with this bug number shows up as a regression.
IIUC, this is probably a "won't fix" for the gnuplot graphics toolkit. Is this correct?
Should we skip the test if gnuplot is used?

diff -r 367ab44d18c8 scripts/plot/appearance/legend.m
--- a/scripts/plot/appearance/legend.m        Sat Feb 01 10:57:35 2020 +0100
+++ b/scripts/plot/appearance/legend.m        Sat Feb 01 11:35:49 2020 +0100
@@ -1910,7 +1910,7 @@
 %! end_unwind_protect

 ## Test bugs in previous implementation
-%!test <*39697>
+%!testif ; ! strcmp (graphics_toolkit (), "gnuplot") <*39697>
 %! hf = figure ("visible", "off");
 %! unwind_protect
 %!   axes ("units", "normalized");


Markus Mützel <mmuetzel>
Group administrator
Mon 18 Nov 2019 08:07:37 PM UTC, comment #19: 

Verified with new legend.m.  Marking as fixed and closing report.

Rik <rik5>
Group administrator
Mon 18 Nov 2019 09:43:28 AM UTC, comment #18: 

legend.m has been rewritten for (OpenGL toolkits only). This bug should now be
fixed.

Marking ready for test.

Pantxo Diribarne <pantxo>
Group Member
Thu 17 Nov 2016 10:43:24 AM UTC, comment #17: 

This bug is still present in the current dev 4.3.0 (39f39eb4e476).
 
I filed task #14243 about rewriting legend.m

Pantxo Diribarne <pantxo>
Group Member
Sat 18 Jul 2015 04:56:32 PM UTC, comment #16: 

Very minor point since they both share code to OpenGL,
the documentation use qt instead of fltk. Hopefully,
the fix will be in common code and fix them both.

Michael Godfrey <godfrey>
Group Member
Sat 18 Jul 2015 02:58:26 PM UTC, comment #15: 

FTR, now that fltk is used for generating the documentation we can see that the lack of listener on figure "position" property is also an issue: when printing a figure using a non default size ("paperposition" is changed) the figure position is changed before printing and the legend outline does not fit with the text entries. Simply resizing manually a figure containing a legend shows the issue.
I attached one of the documentation images as generated from a recent build.


Pantxo Diribarne <pantxo>
Group Member
Fri 30 Aug 2013 01:19:42 AM UTC, comment #14: 

Rik,

I've been thinking about how legends and colorbars can be handled with the recent changes to the axes position, and outerposition properties.

When a legend/colorbox is added outside the plot box, its outerposition can be modified to make room for the new object.  The new legend/colorbar object needs to store the original axes position/outerposition value so that when when deleted the axes properties can be restored to their original values.

I think this will be fairly straight forward to implement, but will not be compatible with what Matlab does.  Even so, I think it a good approach.

I thought I mention it while now since I'm not sure when/if I'll have time to work on this, and didn't want to risk forgetiing about it.

Ben Abbott <bpabbott>
Group Member
Thu 29 Aug 2013 10:54:03 PM UTC, comment #13: 

Adding bug #33112 which mentions that legend has no listener on axis position.

Rik <rik5>
Group administrator
Fri 16 Aug 2013 05:17:42 AM UTC, comment #12: 

I'm going to re-open the bug report because the original issue, the legend box not shifting when the title grows, is still present.  The axes is now correctly updated, but there is no listener in legend.m to detect when the axes position has changed and the legend box need to be re-positioned.

Rik <rik5>
Group administrator
Thu 15 Aug 2013 11:50:26 PM UTC, comment #11: 
Ben Abbott <bpabbott>
Group Member
Thu 15 Aug 2013 11:09:24 PM UTC, comment #10: 

I thought rundemos() would be enough, but I was obviously wrong.  Well, I would go ahead and commit your changeset since that seems to solve the issue with multi-line titles.

Rik <rik5>
Group administrator
Thu 15 Aug 2013 09:34:10 PM UTC, comment #9: 

Rik, try running tests on graphics.cc.   With the initial position updates removed, I get the failure below.


test graphics.cc
  ***** test
 hf = figure ("visible", "off");
 graphics_toolkit (hf, "fltk");
 fpos = get (hf, "position");
 unwind_protect
   plot (rand (3))
   position = get (gca, "position");
   outerposition = get (gca, "outerposition");
   looseinset = get (gca, "looseinset");
   tightinset = get (gca, "tightinset");
   set (hf, "position", [fpos(1:2), 2*fpos(3:4)])
   set (hf, "position", fpos);
   assert (get (gca, "outerposition"), outerposition, 0.001)
   assert (get (gca, "position"), position, 0.001)
   assert (get (gca, "looseinset"), looseinset, 0.001)
   assert (get (gca, "tightinset"), tightinset, 0.001)
 unwind_protect_cleanup
   close (hf);
 end_unwind_protect
!!!!! test failed
ASSERT errors for:  assert (get (gca, "position"),position,0.001)

  Location  |  Observed  |  Expected  |  Reason
    (2)        0.93285        0.11       Abs err 0.82285 exceeds tol 0.81
    (3)         -0.035       0.775       Abs err 0.82285 exceeds tol 0.001
    (4)       -0.0078502     0.815       Abs err 0.001 exceeds tol 0.001



Ben Abbott <bpabbott>
Group Member
Thu 15 Aug 2013 09:14:18 PM UTC, comment #8: 

Your patch seems to fix things up.  I notice that we are now calling update_position once at the start of sync_positions and again at the end.  I tried commenting out the first instance and then running through the plot demos and I couldn't see any difference.  Perhaps, we don't need the first call anymore?  I'm attaching a diff for this change so you can take a look.

(file #28858)

Rik <rik5>
Group administrator
Thu 15 Aug 2013 04:12:14 PM UTC, comment #7: 

Rik,

I have a simple fix.  If you don't notice something I've overlooked, I'll push a changeset.



(file #28855)

Ben Abbott <bpabbott>
Group Member
Thu 15 Aug 2013 01:03:13 AM UTC, comment #6: 

Apparently the problem isn't the menubar or statusbar height.  Try the following


title ({'one', 'two', 'three', 'four', 'five', 'six'}(1:6))
title ({'one', 'two', 'three', 'four', 'five', 'six'}(1:5))
title ({'one', 'two', 'three', 'four', 'five', 'six'}(1:4))
title ({'one', 'two', 'three', 'four', 'five', 'six'}(1:3))
title ({'one', 'two', 'three', 'four', 'five', 'six'}(1:2))
title ({'one', 'two', 'three', 'four', 'five', 'six'}(1:1))


It appears that the extents of the title are lagging by one update.  Which may imply there is an easy fix.  Maybe an additional mark_modified () is all that is needed.  For example, the commands below render the desired result.


clf
axes
title ({'one', 'two', 'three', 'four', 'five', 'six'}(1:6))
title ({'one', 'two', 'three', 'four', 'five', 'six'}(1:6))



Ben Abbott <bpabbott>
Group Member
Wed 14 Aug 2013 10:01:06 PM UTC, comment #5: 

Maybe the 20 pixels is due to the status bar?

Ben Abbott <bpabbott>
Group Member
Wed 14 Aug 2013 09:35:16 PM UTC, comment #4: 

I see you're right that the axes position is being shifted to have "two" remain visible.  Interestingly, I switched over to pixel for the units and everything looks right if I bring the axes and title text object down by 20 pixels.  This could, of course, just be a coincidence.  But it might also suggest that we aren't calculating correctly with the menubar height somehow.  I did tests with the menubar turned off though and the title is still being clipped.

Rik <rik5>
Group administrator
Wed 14 Aug 2013 08:50:21 PM UTC, comment #3: 

Yeah, there are plenty of short comings for the legend.  It really needs to be rewritten from scratch.  But before that is done, I hope the updating for the tightinset can be fixed.

The problem with tightinset is that calc_tightbox() doesn't account for changes to the axes fontsize.  In addition there are problems with changes to the title, and {x,y,z}labels.  However, I don't think the problem is a missing mark_modified ().

If you try the following commands, you'll see that "one" will disappear as it moves above the top of the figure, but that "two" is always visible.  So the updating appears to be working.  Perhaps the height or position of the title isn't correct?


title ({'one'})
title ({'one', 'two'})
title ({'one', 'two', 'three'})
title ({'one', 'two', 'three', 'four'})
title ({'one', 'two', 'three', 'four', 'five'})


Ben Abbott <bpabbott>
Group Member
Wed 14 Aug 2013 08:11:35 PM UTC, comment #2: 

The axes position not moving is an issue by itself.  It seems like we are missing a drawnow() or mark_modified() call after adding the multi-line title.  You could file another bug report for that.

But, it doesn't affect this issue which is that there is no listener on the axes position.  If I use the mouse on a corner of the plot window to slightly resize it then the axes is re-drawn with the correct size, but nothing fires to also adjust the legend box position.

Incidentally, "fontunits" only determines how "fontsize" will be interpreted.  To find the extents for the title you need to operate with the "units" property on the title text object.


plot (1:10, ';data;');
ht = title ({'1';'2';'3';'4'});
set (ht, 'units', 'pixels');
get (ht, 'extent')
ans =

   217.32500   357.37500     6.00000    49.00000



Rik <rik5>
Group administrator
Wed 14 Aug 2013 12:11:55 PM UTC, comment #1: 

Rik,

The tightinset support has been improved in the last few weeks.  So, I tried your example to see if there was any improvement.  The first thing I noticed was that the axes position didn't move.  Is that a regression?

Second, it looks to me as if the title's text object's extent isn't being updated properly.


set (gca, "fontunits", "points")
get (get (gca, "title"), "extent")
ans =    4.41244   10.29214    1.17512    1.43149


The title's extent appears to indicate the text object is only one line high.  Which explains why the tightinset isn't being updated correctly?


get (gca, 'tightinset')
ans =   12.83721   10.04896    0.00000   32.93023


Ben Abbott <bpabbott>
Group Member
Mon 05 Aug 2013 05:06:54 AM UTC, original submission:  

There isn't a listener on the the position property of the axis.  If the axis changes position, such as when the title block grows, the legend is left out of position.  This is apparently a known problem.  In the code for legend.m I find:


## TODO - need to add listeners for tighinset and position
##        addlistener (ca, "tightinset", @update????);
##        addlistener (ca, "position", @update????);


I'm adding a %!demo block to legend.m which shows the problem.


plot (1:10);
legend ("Legend Text");
title ({"Multi-line", "titles", "are a", "problem"});



Rik <rik5>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #34460:  splinefit1.png added by pantxo (48KiB - image/png)
file #28858:  graphics2.diff added by rik5 (874B - application/x-download)
file #28855:  graphics.diff added by bpabbott (363B - application/octet-stream)

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by johasixt
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by pantxo (Updated the item)
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by rik5 (Submitted the item)
  • -email is unavailable- added by rik5
  •  

    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 17 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-11-18 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2019-11-18 pantxo StatusConfirmed Ready For Test
    2018-10-08 johasixt Carbon-Copy- Added johasixt
    2016-10-18 pantxo Dependencies- bugs #49382 is dependent
    2015-07-18 pantxo Attached File- Added splinefit1.png, #34460
    2015-04-25 rik5 Dependencies- bugs #43067 is dependent
    2013-08-31 bpabbott Assigned tobpabbott None
    2013-08-29 rik5 Dependencies- Depends on bugs #33112
    2013-08-16 rik5 StatusFixed Confirmed
        Open/ClosedClosed Open
    2013-08-15 bpabbott StatusNone Fixed
        Assigned toNone bpabbott
        Open/ClosedOpen Closed
    2013-08-15 rik5 Attached File- Added graphics2.diff, #28858
    2013-08-15 bpabbott Attached File- Added graphics.diff, #28855
    2013-08-05 rik5 Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code