bugGNU Octave - Bugs: bug #52878, Tiny plots in Qt/FLTK plotting...

 
 

bug #52878: Tiny plots in Qt/FLTK plotting window on UHD / hidpi display

Submitted by:  None
Submitted on:  Sat 13 Jan 2018 05:42:49 PM UTC  
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Duplicate Assigned to:  None
Originator Name:  Michael Weitzel Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  4.2.1
Operating System:  GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Thu 09 May 2019 07:12:00 AM UTC, comment #9:

I still have the same problem with Octave 5.1 on FreeBSD and it is a blocker for me, since I haven't found any workaround to make my plots look OK.

Please, fix this.

Anonymous
Wed 24 Jan 2018 08:49:27 PM UTC, comment #8:

I'm closing this as a duplicate of bug #49053.

I just tested with Mint 18.1 (Qt 5.6, KDE 5.36) and with the patch from bug #49053 things pass.

Rik <rik5>
Project Administrator
Thu 18 Jan 2018 06:48:09 PM UTC, comment #7:

@mweitzel I would be very interested to see whether my latest patch (https://savannah.gnu.org/bugs/download.php?file_id=42946) works for Linux machines that have retina-scale displays. I know it works on my Mac, but I don't have access to a Linux machine with a retina display.

My hope it that this is a duplicate of bug #49053 (https://savannah.gnu.org/bugs/?49053)

John Swensen <jpswensen>
Thu 18 Jan 2018 06:42:20 AM UTC, comment #6:

Isn't that the same issue as 49053? Linux or Mac should not matter.

@mweitzel have you tried any of the patches, e.g. https://savannah.gnu.org/bugs/download.php?file_id=42946?

Sebastian

Sebastian <sschoeps>
Tue 16 Jan 2018 10:19:30 PM UTC, comment #5:

I'm not completely following the QT_SCREEN_SCALE_FACTORS issue, but it is strange that Octave would use the bottom right corner and left/bottom justification...as opposed to center justification. Or is this QT_SCREEN_SCALE_FACTORS something that Qt does, completely unrelated to Octave? Can you provide some simple bash command that will illustrate for me? I tried

but nothing seems any different with

I know what you mean about plot appearance, and I agree about Qt plot appearance. However, even Matlab isn't always great either. For example, I don't like so much white space around the borders...seems a waste and always causes problems in trimming inside a document. (It's easy to add white space in documents, not take it away.) Whatever the application, whenever I create a figure for publication I end up spending hours adjusting this, changing that.

Dan Sebald <sebald>
Tue 16 Jan 2018 07:40:48 PM UTC, comment #4:

I see, there was a misunderstanding. You're right - my screenshot LOOKS like 'subplot(2,2,3)' - however, I didn't use subplot!

The Qt figure window is scaled by factor 2 because of the environment variable setting (QT_SCREEN_SCALE_FACTORS). The code generating the figure (i.e. the actual bitmap image) ignores the desktop scaling factor as well as the X-server's DPI-setting.

I tried a few combinations: in octave-cli none of the allowed graphics_toolkit settings ("fltk", "gnuplot") results in a scaled figure. In octave-gui graphics_toolkit "qt" results in the subplot-like figure (as shown by my screenshot). "fltk" gives a small window and a small figure. Finally, "graphics_toolkit gnuplot" works fine: I get a scaled windows AND a scaled figure (without using any set(...)-commands). The lines are a bit thin, but that's ok.

Thank you very much for pointing me to gnuplot. I'm happy with the combination octave-gui + gnuplot.

Michael Weitzel <mweitzel>
Mon 15 Jan 2018 11:38:17 PM UTC, comment #3:

I assume that you used the "subplot()" option to create the plot in the lower/left corner of the canvas. Attached are a few screenshots of what I'm seeing:

Yes, the default axis-tic fontsize for qt toolkit is somewhat small:
qt_default_font_size_Screenshot_from_2018-01-15_17-23-24.png

The gnuplot default looks pretty good:
gnuplot_default_fontsize_Screenshot_from_2018-01-15_17-21-37.png

Then there is the ability to enlarge the font size if one wants:
qt_18_fontsize_Screenshot_from_2018-01-15_17-24-47.png

It would be nice to have functioning Qt environment variables and meaningful to-screen-dimension scaling (WYSIWYG, if you like), but this is all detailed work that typically doesn't happen in Octave because of limited resources spread across too many other bugs.

I typically do work by keeping a script in a file and calling that script. In such a case, one can put the set(gca,'fontsize',18) in that script file. I do it this way because if I want to generate a figure for a paper or something I can get fine control and reproduce the figure to a reasonable degree at a later time.

(file #42918, file #42919, file #42920)

Dan Sebald <sebald>
Mon 15 Jan 2018 10:48:10 PM UTC, comment #2:

The problem is not related to any particular graphics toolkit or plot (say, 'plot(1:100)', for example).

My laptop has a 15.6" display but a screen resolution of 3840x2160 pixels - which gives around 282 DPI. Therefore, when a figure window pops up, the size of the generated image on screen is around 5cm by 4cm. The height of the axis labels (fonts) is less than 1mm - simply a bit too small to work with.

The scaling factor of 2 in my KDE settings results in the following environment variable being set:

QT_SCREEN_SCALE_FACTORS='eDP-1=2;DP-1=2;HDMI-1=2;DP-2=2;HDMI-2=2;'

For the Gnome desktop environment this would be "GDK_SCALE=2". Octave ignores the environment variables (at least QT_SCREEN_SCALE_FACTORS should be honored for figures generated with Octave's Qt-GUI, IMO). The attached screenshot shows a figure window generated with graphics_toolkit('qt'): a correctly sized window containing a small 5cm x 4cm image in the lower/left part of the window - please, compare the size of the plot with the size of the window decorations.

On my system, the command "get(0,'screenpixelsperinch')" results in 96.042 (DPI) - which is what Xorg thinks the display resolution is (defaults, nonsense). However, setting the correct screen resolution via "xrandr -dpi 282" does not result in larger Octave plot images - although now "get(0,'screenpixelsperinch')" returns the correct DPI value. It seems, Octave is simply ignoring the DPI setting.

I would be happy with a simple startup script for scaling my figures. However, correct application of the X-server's DPI setting would be most consistent.

Michael Weitzel <mweitzel>
Sun 14 Jan 2018 08:01:17 PM UTC, comment #1:

Font size for appearance in subplots is often an issue. There are a lot of things to take into consideration when scaling. Anyway, there is the gnuplot graphics toolkit, which I think has better default font sizes for subplots. One should also be able to control the font sizes in FLTK/Qt via the usual graphics properties.

Please provide a bit more detail including a simple sample test script that folks can run on their system to see what the issue is.

Dan Sebald <sebald>
Sat 13 Jan 2018 05:42:49 PM UTC, original submission:

Dear Octave developers,

This probably a feature request - at least not a /severe/ bug:

I'm running ArchLinux with KDE Plasma on a 15" UHD laptop display (3840x2160 px). In order to have readable fonts I configured a scaling factor of 2 in the KDE settings.

While Octave's Qt GUI performs great on the HiDPI display, the output generated in the different plotting windows (both, Qt and FLTK) remains unscaled, i.e. tiny/almost unreadable (see attached screenshot). In addition, plot(...) on graphics_toolkit('qt') results in a small plot sitting in the lower/left quarter of the figure window.

The plotting subsystem should adjust line thickness, font sizes, and the overall size of the plot in order to match the display's scaling factor.

Thank you for creating this great software.
Please, let me know if I can help (e.g. by trying out some patches)

Regards, Michael

Anonymous

 

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

Attach Files:
   
   
Comment:
   

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jpswensen (Posted a comment)
  • -email is unavailable- added by sschoeps (Posted a comment)
  • -email is unavailable- added by mweitzel (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-01-24 rik5 StatusNone => Duplicate
        Open/ClosedOpen => Closed
    2018-01-15 sebald Attached File- => Added qt_default_font_size_Screenshot_from_2018-01-15_17-23-24.png, #42918
        Attached File- => Added gnuplot_default_fontsize_Screenshot_from_2018-01-15_17-21-37.png, #42919
        Attached File- => Added qt_18_fontsize_Screenshot_from_2018-01-15_17-24-47.png, #42920
    2018-01-13 None Attached File- => Added qt_plot_uhd_screen.jpeg, #42902

    Back to the top


    Powered by Savane 3.4