bugGNU Octave - Bugs: bug #50094, 2 more legend bugs

 
 

bug #50094: 2 more legend bugs

Submitter:  Muhali <muhali>
Submitted:  Thu 19 Jan 2017 12:42:00 PM UTC
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
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)
   

Comment Type & Canned Response:
       

 

( Jump to the original submission )

Thu 19 Dec 2019 04:27:05 PM UTC, comment #18: 

comment #17:

> Intriguing ... could you attach screenshots of your onscreen figures. Can you please also make sure you are not setting other options, e.g. through startup scrips (use "-f" option to start Octave).


both onscreen figures look like my Figure 1 from comment #14. No startup option set.

Muhali <muhali>
Thu 19 Dec 2019 01:27:09 PM UTC, comment #17: 

Intriguing ... could you attach screenshots of your onscreen figures. Can you please also make sure you are not setting other options, e.g. through startup scrips (use "-f" option to start Octave).

The part

... "units", "normalized", "position", [0.682   0.702   0.25   0.25]

is just meant to have the same size for both figures. I just took it from your example in comment #0.

Pantxo Diribarne <pantxo>
Project Member
Thu 19 Dec 2019 10:33:04 AM UTC, comment #16: 

if I use your code I get identical distorted pngs, but the onscreen Figure 2 is correct.

I am unable to understand the part

"units", "normalized", "position", [0.682   0.702   0.25   0.25]

without that, the pixel png is fine as well.

Muhali <muhali>
Wed 18 Dec 2019 02:56:17 PM UTC, comment #15: 

@Muhali: What I am saying is that I couldn't find a situation where it was not the actual size, in screen pixels, that fixed the size of the legend. The following script produces two identically overcrowded figures for me:

n = 30;

hf1 = figure ("units", "normalized", ...
              "position", [0.682   0.702   0.25   0.25])
plot (randn (4, n), "k");
legend(datestr (now + (1:n)), "location", "northoutside", ...
                "numcolumns", 4);
print (hf1, "normalized.png")

hf2 = figure ("units", "normalized", ...
              "position", [0.682   0.702   0.25   0.25], ...
              "units", "pixels")
plot (randn (4, n), "k");
legend(datestr (now + (1:n)), "location", "northoutside", ...
                "numcolumns", 4);
print (hf2, "pixels.png")

Does this produce two different figures for you?

I attached the resulting png figures, which I obtained on a laptop with a small screen. Those are different from what I see onscreen, even more overcrowded, but this is yet another bug (bug #45600).


Pantxo Diribarne <pantxo>
Project Member
Wed 18 Dec 2019 10:22:02 AM UTC, comment #14: 

comment #13:

> I obtain the very same result with normalized or pixel units:


I may be misunderstanding, but for me I do get very different results. One (normalized units) is Figure 1 from comment 10, the other (pixels) is attached here.


Muhali <muhali>
Tue 17 Dec 2019 05:26:26 PM UTC, comment #13: 

I obtain the very same result with normalized or pixel units:

 set(0, "defaultaxesfontsize", 12) ;
set(0, "defaultfigureunits", "normalized") ;
set(0, "defaultfigureposition", [0.682   0.702   0.25   0.25]) ;

n = 30 ;
plot(randn(4,n), "k") ;
## Set pixels units
set (gcf, "units", "pixels");
legend(datestr(now + (1:n)), "location", "northoutside") ;
legend("boxoff") ;
print foo.png ;

The problem is not the units but the size of the figure: with a small screen, normalized units lead to small figure, too small for the legend and the plot to fit in.

>> The other bug is independent of that, isn't it?


Yes, I don't know if there is a reported bug for this but basically, it boils down to

axes ("position", [0 0 1 1], "xlim", [0 1]);
text (-0.1, 0.5, "A text that should at least partly appear onscreen")
text (0.9, 0.5, "A text that does partly appear onscreen")

The first text object isn't shown at all because its anchor is out of the figure. The second is only partly visible as I would expect.

Pantxo Diribarne <pantxo>
Project Member
Tue 17 Dec 2019 03:59:41 PM UTC, comment #12: 

what's confusing is that everything is fine unless units are normalized. The other bug is independent of that, isn't it? I would assume that switching to normalized is a one-liner.

Muhali <muhali>
Tue 17 Dec 2019 02:48:33 PM UTC, comment #11: 

Yes, that is also what I obtain on a small screen. The reason is that the anchor of text labels (at the left end of the string) gets pushed outside of the figure and then the text is not drawn at all.
This is another independent bug.

In this case you have to make sure the legend fits in the figure. So you'll  change the number of columns or the fontsize or obviously the figure size for such a large number of item.

Closing report as fixed.

Pantxo Diribarne <pantxo>
Project Member
Tue 17 Dec 2019 10:56:49 AM UTC, comment #10: 

The missing legend color is fixed now. But it still produces a weird figure, both onscreen and as printed (attached).


Muhali <muhali>
Mon 16 Dec 2019 05:47:12 PM UTC, comment #9: 

@Muhali: There's been a number of bug fixes on the new legend code. The original example, as is, is not relevant anymore since, like Matlab, Octave now leaves to the user the task of choosing a suitable number of columns for large legends, e.g.:

set(0, "defaultaxesfontsize", 12) ;
set(0, "defaultfigureunits", "normalized") ;
set(0, "defaultfigureposition", [0.682   0.702   0.25   0.25]) ;

n = 30 ;
plot(randn(4,n), "k") ;
legend(datestr(now + (1:n)), "location", "northoutside", "numcolumns", 4) ;
legend("boxoff") ;
print foo.png ;

Can we can close this report?

Pantxo Diribarne <pantxo>
Project Member
Mon 18 Nov 2019 09:02:36 PM UTC, comment #8: 

I just tested the patch on a larger screen, and it does have the expected effect of preventing the legend from compressing the axes too much (which ends up in a corrupted legend possition and making it disappear), so I pushed the patch from comment #6.
But now this is fixed for me, it uncovers another very ugly issue with the legend item layout management:

set(0, "defaultaxesfontsize", 12) ;
set(0, "defaultfigureunits", "normalized") ;
set(0, "defaultfigureposition", [0.682   0.702   0.25   0.25]) ;

n = 30 ;
plot(randn(4,n), "k") ;
legend(datestr(now + (1:n)), "location", "northoutside") ;
## Legend item are arranged in 2 columns
legend boxoff
## Legend item are arranged in 30 columns
legend boxon
## Legend item are arranged in 3 columns

If I prescribe the number of columns using the "numcolumns" property then everything look stable.

Pantxo Diribarne <pantxo>
Project Member
Mon 18 Nov 2019 07:57:24 PM UTC, comment #7: 

that has no effect for me.

Muhali <muhali>
Mon 18 Nov 2019 05:11:18 PM UTC, comment #6: 

Can you test the attached patch?

(file #47882)

Pantxo Diribarne <pantxo>
Project Member
Mon 18 Nov 2019 03:31:08 PM UTC, comment #5: 

the figure should remain as it is after the first legend-command, just without the box. That's what Matlab does.

Muhali <muhali>
Mon 18 Nov 2019 03:18:49 PM UTC, comment #4: 

Yes, I just noticed that as well. The problem is that the legend is much too big with regards to its corresponding axes. If you make the figure taller, this won't happen.

What should be the behavior in this case? throw a meaningful warning about the legend being too big? Letting the legend extend above the figure limits or bellow the top x-axis?

Pantxo Diribarne <pantxo>
Project Member
Mon 18 Nov 2019 01:35:26 PM UTC, comment #3: 

now the whole legend disappears after the legend('boxoff') command.

Muhali <muhali>
Mon 18 Nov 2019 09:46:57 AM UTC, comment #2: 

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

Marking ready for test.

Pantxo Diribarne <pantxo>
Project Member
Thu 19 Jan 2017 03:45:12 PM UTC, comment #1: 

Hi,

I am under the impression this is only a manifestation of bug #39697: since you are using normalized units for the figure position, bug #39697 (legend not resizing correctly at print time) will show up differently depending on the screen size. I attached the png I obtain with a large screen (3280-by-1200 pixels), it is better than yours but still ugly, and the on-screen figure is as expected.

This may even depend on wether you are using qt or fltk since qt figures sometimes also have quirks when it comes to resizing.

Marking the bug as confirmed (even though not as bad as your results) but may be a duplicate as well.


Pantxo Diribarne <pantxo>
Project Member
Thu 19 Jan 2017 12:42:00 PM UTC, original submission:  

The attached file foo.png gives the output of this script

set(0, "defaultaxesfontsize", 12) ;
set(0, "defaultfigureunits", "normalized") ;
set(0, "defaultfigureposition", [0.682   0.702   0.25   0.25]) ;

n = 30 ;
plot(randn(4,n), "k") ;
legend(datestr(now + (1:n)), "location", "northoutside") ;
legend("boxoff") ;
print foo.png ;

I see at least 2 bugs here (which may be added here:

a) the lowest legend row has no colors

b) not all legends show up

Muhali <muhali>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #48083:  normalized.png added by pantxo (26KiB - image/png)
file #48084:  pixels.png added by pantxo (26KiB - image/png)
file #48077:  foo.png added by muhali (66KiB - image/png)
file #47882:  bug50094.patch added by pantxo (3KiB - text/x-patch)
file #39512:  foo.png added by pantxo (53KiB - image/png)
file #39511:  foo.png added by muhali (51KiB - 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 pantxo (Updated the item)
  • -email is unavailable- added by muhali (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 project members can vote.

     

     

     

     

    Follow 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-12-18 pantxo Attached File- Added normalized.png, #48083
        Attached File- Added pixels.png, #48084
    2019-12-18 muhali Attached File- Added Screenshot_2019-12-18_11-07-49.png, #48080
    2019-12-17 pantxo StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2019-12-17 muhali Attached File- Added Screenshot@from@2019-12-17@11-51-14.png, #48076
        Attached File- Added foo.png, #48077
    2019-11-18 pantxo Attached File- Added bug50094.patch, #47882
    2019-11-18 pantxo StatusConfirmed Ready For Test
    2017-01-19 pantxo Attached File- Added foo.png, #39512
        StatusNone Confirmed
    2017-01-19 muhali Attached File- Added foo.png, #39511

    Back to the top


    Powered by Savane 3.9