bugGNU Octave - Bugs: bug #52752, "paperposition" property...

 
 

bug #52752: "paperposition" property messes with legend size

Submitter:  Etienne Dechamps <edechamps>
Submitted:  Thu 28 Dec 2017 12:49:41 PM UTC
   
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
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

Tue 19 Nov 2019 10:58:01 PM UTC, comment #11: 

I think Verdana has nothing to do with this: I see weird results with other fonts. There is something wrong with how the opengl renderer resizes fonts and graphics prior to printing. If I use the painters renderer instead together with the -svgconvert option, I can render properly to pdf with whatever font I choose. But again this is a separate issue.

Pantxo Diribarne <pantxo>
Group Member
Tue 19 Nov 2019 07:30:26 PM UTC, comment #10: 

Verdan does not do aliasing very well. 
Now days I usually recommend Roboto (or just Noto if one needs a
wider selection of special symbols).

Dmitri.
--



Dmitri A. Sergatskov <dasergatskov>
Tue 19 Nov 2019 05:48:54 PM UTC, comment #9: 

The issue is that I use a non-standard font.  In my .octaverc file I have


set (0, "DefaultAxesFontname", "Verdana");


which is generally good for displaying on screen as that is specifically what Verdana is adapted to.  But, the metrics for it must be bad for printing.

If I start octave with 'run-octave -f' then I don't see any issue with the resulting printout.

This isn't an Octave issue so no need to fix.

Rik <rik5>
Group administrator
Tue 19 Nov 2019 05:38:23 PM UTC, comment #8: 

I can't reproduce your latest observation. Attaching what I get:




Pantxo Diribarne <pantxo>
Group Member
Tue 19 Nov 2019 05:29:05 PM UTC, comment #7: 

Thanks Pantxo.  The regression has been fixed so I'm re-closing the report.

This is a separate issue, but during printing the the Qt toolkit seems to calculate the size of the legend box incorrectly and there are characters that extend outside the box.  The code was


graphics_toolkit('qt');
fplot(@(x) sin(x*pi*2+[0:3]*pi/2), [0, 2]);
set(gcf(), 'paperposition', [ 0 0 10 3 ]);
print tst.png


Attaching file tst.png for reference.



Rik <rik5>
Group administrator
Tue 19 Nov 2019 05:05:19 PM UTC, comment #6: 

The problem is that, with fltk, changing the unit property of a figure provokes the execution of "position" listeners (while the position hasn't actually changed). I pushed the following cset which fixes the issue for me:

http://hg.savannah.gnu.org/hgweb/octave/rev/6eb7491a8794

Pantxo Diribarne <pantxo>
Group Member
Mon 18 Nov 2019 10:13:57 PM UTC, comment #5: 

Unfortunately with the new legend code for version 6.1 there are now callback errors.  This only occurs with the FLTK toolkit.  The code tst_legprint.m is attached.


graphics_toolkit('fltk');
#graphics_toolkit('qt');
fplot(@(x) sin(x*pi*2+[0:3]*pi/2), [0, 2]);
set(gcf(), 'paperposition', [ 0 0 10 3 ]);
print tst.png




(file #47885)

Rik <rik5>
Group administrator
Fri 29 Dec 2017 04:30:17 PM UTC, comment #4: 

Okay, this is a variant of a longstanding bug which is that legend does not have a listener on the axes position property.  When the axes changes size for any reason, such as during printing, the legend doesn't realize it needs to also update itself.  I have cleaned up legend and colorbar a lot on the development branch, but that is the last remaining task.

I'm going to close this as a duplicate.

Rik <rik5>
Group administrator
Fri 29 Dec 2017 01:32:45 PM UTC, comment #3: 

Looks like my last comment was botched. What I meant was:

--

Yes, I guess I should have mentioned that. My steps to reproduce should have included:

  print('legendtest.png', '-dpng');

That said, there is a similar behaviour when one plots to a window, and then resizes that window. Everything will resize fine, except for the legend. Then, if fplot() is called again after the window is resized, everything goes back to its normal layout.

Etienne Dechamps <edechamps>
Fri 29 Dec 2017 01:29:35 PM UTC, comment #2: 

Yes, I guess I should have mentioned that. My steps to reproduce should have included:


print('legendtest.png', '-dpng');
+verbatim+

That said, the behaviour is similar if you first display the plot in a window, and then resize that window. Everything will resize fine, *except* for the legend. Then, if you call fplot() again after resizing, everything is fine once again.

Etienne Dechamps <edechamps>
Thu 28 Dec 2017 06:14:32 PM UTC, comment #1: 

I don't see a problem when I execute your three commands.  Do you also have to print the figure to have a problem?

Rik <rik5>
Group administrator
Thu 28 Dec 2017 12:49:41 PM UTC, original submission:  

On Debian Unstable, Octave 4.2.1:


graphics_toolkit('fltk');
fplot(@(x) sin(x*pi*2+[0:3]*pi/2), [0, 2]);
set(gcf(), 'paperposition', [ 0 0 10 3 ]);


See attached PNG file for the visual result. The legend is too small vertically, leading to overlapping and overflowing text. It is also too wide, leading to wasted horizontal space.

If the paperposition property is left alone, the output is fine. Basically, the legend does not react correctly when the paperposition property is changed.

Etienne Dechamps <edechamps>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #47900:  tst.png added by pantxo (35KiB - image/png)
file #47899:  tst.png added by rik5 (35KiB - image/png)
file #47885:  tst_legprint.m added by rik5 (152B - text/x-matlab)
file #42746:  legendtest.png added by edechamps (36KiB - 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 dasergatskov (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by edechamps (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 15 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-11-19 pantxo Attached File- Added tst.png, #47900
    2019-11-19 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2019-11-19 rik5 Attached File- Added tst.png, #47899
    2019-11-19 pantxo StatusConfirmed Ready For Test
    2019-11-18 rik5 Attached File- Added tst_legprint.m, #47885
        Item GroupIncorrect Result Regression
        StatusDuplicate Confirmed
        Open/ClosedClosed Open
        Carbon-Copy- Added pantxo
    2017-12-29 rik5 StatusNeed Info Duplicate
        Open/ClosedOpen Closed
        Release4.2.1 dev
    2017-12-28 rik5 StatusNone Need Info
    2017-12-28 edechamps Attached File- Added legendtest.png, #42746

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code