bugGNU Octave - Bugs: bug #41938, Terminal fonts do not scale...

 
 

bug #41938: Terminal fonts do not scale properly with a display scaling of 150% and more

Submitted by:  john guin <jg42>
Submitted on:  Sun 23 Mar 2014 02:29:26 AM UTC  
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  dev Operating System:  Microsoft Windows

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)

Tue 10 Mar 2015 08:35:24 PM UTC, comment #21: 

Closing this report. It can be reopened if new issues are showing up.

Torsten Lilge <ttl>
Project Member
Sat 07 Mar 2015 05:58:56 PM UTC, comment #20: 

Thanks for clarifying. I am preparing a patch for adapting the dock-/undock- and close-icons to the font size.

Torsten Lilge <ttl>
Project Member
Sat 07 Mar 2015 04:42:33 PM UTC, comment #19: 

By "min/max" control,I mean the control to lhe left of the X control that closes the window.  Image here: https://onedrive.live.com/redir?resid=BB012C7F4B815C00!93987&authkey=!ALj8LrpfPz75AX8&v=3&ithint=photo%2cpng
Note: this is the same behavior as 3.8

Yes, terminal fonts are OK now.  Any confusion with this is due to my not knowing the correct terminology.

john guin <jg42>
Sat 07 Mar 2015 06:50:52 AM UTC, comment #18: 

Thanks for testing.

(Regression) The X to close widgets does not draw at all (but functions if you mouse click where it should be)

Fixed with changeset http://hg.savannah.gnu.org/hgweb/octave/rev/2b5cbea8f442

The min/max control is still the small size as before

What exactly do you mean by min/max-control?

The default text in the editor window does not overlap as 3.8

I thought the terminal fonts were the problem? Are these also okay now?

The Preferences dialog starts "too small" but once resized appears as expected

The very first time the preferences dialog is shown with a fixed size. I will prepare a changeset for this.

Torsten Lilge <ttl>
Project Member
Sat 07 Mar 2015 02:23:26 AM UTC, comment #17: 

The 4_O RC is slightly better. 

(Regression) The X to close widgets does not draw at all (but functions if you mouse click where it should be). 
The min/max control is still the small size as before.
The default text in the editor window does not overlap as 3.8.

The Preferences dialog starts "too small" but once resized appears as expected.

I can share screenshots if needed.

john guin <jg42>
Fri 06 Mar 2015 04:43:27 PM UTC, comment #16: 

Could one of the original reporters test with the new 4.0 release candidate?  It is available at ftp://alpha.gnu.org/gnu/octave/octave-4.0.0-rc1-installer.exe.

Rik <rik5>
Project Administrator
Tue 24 Feb 2015 06:29:15 PM UTC, comment #15: 

Okay, apparently I missed the right use of the numbered list markup ...

Torsten Lilge <ttl>
Project Member
Tue 24 Feb 2015 06:27:47 PM UTC, comment #14: 

Thank for the information. I have pushed a couple of changesets that address the issues of this report:

  1. http://hg.savannah.gnu.org/hgweb/octave/rev/29692bc97899 fixes the terminal font for scalings of 150% and more
  1. http://hg.savannah.gnu.org/hgweb/octave/rev/72fe9df87fe8 removes fixed size objects (e.g. in the settings dialog) and determines the sizes depending of the font size
  1. http://hg.savannah.gnu.org/hgweb/octave/rev/597fc0fd8e54 uses the actual qt pixel metrics for the size of the toolbar icons in order to make the icon sizes depending on the actual scaling

I have tested the changesets on a Windows 8.1 system and would be happy about feedback whether the font issue is fixed on other windows platforms, too.

Torsten Lilge <ttl>
Project Member
Mon 23 Feb 2015 02:09:36 PM UTC, comment #13: 

I should have read my draft comment (#12) before submitting it.  I meant to say that the display resolution issue should be fixed in version 4 for a single monitor application.  Windows 8.1 supports multiple monitors where the application can be displayed on, at the same time.  This increases the complexity of coding if you attempt to fix this so that it runs on multiple monitors.  I don't think it is necessary to support multiple monitors at this time.  Therefore the task to make the application compatible with windows 8 might be significantly easier to implement.

Delbert Johnson <del_johnson>
Mon 23 Feb 2015 01:59:55 PM UTC, comment #12: 

This comment is directed to answer the questions in comments 9 and 11

Comment #9.  I did decrease the screen resolution to 1920x1080 via the display property control.  This reduced the resolutions for all applications and did not correct the problem.

Comment #11. I thought that the Windows Compatibility Center link, in the reference cited in my original comment(#7), would provide additional information that would be useful for developers.  It turns out that it does not.  A better link is:

https://msdn.microsoft.com/library/windows/desktop/dn469266.aspx

The fix is complex if you are trying to make the application work on multiple monitors but.  If possible this problem should be fixed with the release of version 4.  Apparently many of the old applications assumed a 95 DPI screen resolutions.  There are now API's available to detect higher resolution screens. 

The Editor and Documentation frames don't have the problem that is occurs in the Command Window.  John comments in #8 that the editor(tab) in the File-Preferences is not fixed with the solutions that I provided in comment #7.  It did not get fixed for me neither.  However, the other tab-frames in the File-Preferences did get fixed.  Again, the solutions might be to look at how the General, Editor Styles and Terminal frames were written (which display ok) compared to the Editor preference frame that does not display correctly.

I am a c, c++, c# programmer.  I'm not set up to replicated the development environment to fix the code but I would be willing to look at the code written for these frames that work and don't work and, if necessary research Microsoft recommendations on Hi Resolution screens in order to recommend modifications to the code to fix these problems.  It would be up to another programmer to run and test the changes to see if if fixes the problem.

Delbert Johnson <del_johnson>
Sun 22 Feb 2015 08:52:52 PM UTC, comment #11: 

@Delbert: Where is the reference for developers you have mentioned? I haven't found it on the web page.

Torsten Lilge <ttl>
Project Member
Sun 22 Feb 2015 08:38:07 PM UTC, comment #10: 

@John (comment #8): What was the problem with the editor font? So far, you mentioned problems with the terminal font and the settings dialog. The scalability of the settings dialog has improved since 3.8.x. What other issues are you seeing with a scaling of 200%?

Torsten Lilge <ttl>
Project Member
Sun 22 Feb 2015 08:30:19 PM UTC, comment #9: 

@Delbert (comment #7): Did you decrease the screen resolution or the display's scaling? On my windows 8 the effect was depending on the scaling and showed up only for scalings higher than 150%.

Torsten Lilge <ttl>
Project Member
Sun 22 Feb 2015 08:04:11 PM UTC, comment #8: 

This worked for the font in the editor, but the dialogs (File | Preferences) are still not scaled as expected.

But at least the editor is legible.

john guin <jg42>
Sun 22 Feb 2015 07:32:10 PM UTC, comment #7: 

Problem Solved (for me)

I originally added a comment to 44257 and got a response back suggesting this bug #41938 more related to my problem. 

I tried decreasing the screen resolution through changing pc settings but it had no affect.

I stumbled onto this site:  http://www.eightforums.com/tutorials/6832-compatibility-mode-use-windows-8-a.html that talked about old windows software not being compatible and right clicking on the actual application, selecting 'Troubleshoot Compatibility' to fix the problem.  I did that, picking the sub-choices that fit this problem and it worked.  I then clicked on the shortcut and it worked as well.

There is a reference on this web page that provides information for the developers to make their programs compatible so that the users don't have to go through the fix as described.

Delbert Johnson <del_johnson>
Wed 11 Feb 2015 01:25:42 PM UTC, comment #6: 

I am now able to reproduce this on a Windows 8 system with a display scaling of 150% and more (125% is working well). It seems that the spacing in the terminal window does not take care of the actual scaling factor. Even the cursor is only shown in a size related to 100% scaling.
Scaling the text size in Ubuntu by 2.0 works fine, so it is a problem related to the windows terminal only.

I am changing the title since the the display scaling is important.

Torsten Lilge <ttl>
Project Member
Wed 11 Feb 2015 12:13:50 AM UTC, comment #5: 

On my 1920x1080 Windows box everything is OK.  I have not tried on a MacBook with 2560x1600.  Might be interesting to try.

john guin <jg42>
Tue 10 Feb 2015 10:46:34 PM UTC, comment #4: 

Re-opening report.

I wonder how much of the problem is caused by running Qt under a Windows environment.  On Linux using 1920x1080 everything is fine.

Rik <rik5>
Project Administrator
Sun 08 Feb 2015 04:31:03 PM UTC, comment #3: 

Sorry. I must have missed this request for information and never followed up on the web page.

1. I had changed it to many different settings to find a way to at least see what would make the text legible.   I have it at 14 now.
2.  The terminal section is below and I uploaded the entire file at https://onedrive.live.com/redir?resid=BB012C7F4B815C00!90034&authkey=!ANmtLofJGGX6-YY&ithint=file%2ctxt
3. Currently 12.

But this is not just fonts that don't scale at high dpi.  Most of the buttons and other UI do not scale well in dialogs.  I uploaded some screenshots at https://onedrive.live.com/redir?resid=BB012C7F4B815C00!90037&authkey=!AMPBx0NQCliikW0&ithint=folder%2c if you want to see this.  Sometimes a picture is worth 1000 words.

[terminal]
fontSize=14
fontName=Consolas
cursorBlinking=true
cursorType=ibeam
cursorUseForegroundColor=true
color_f=@Variant(\0\0\0\x43\x1\xff\xff\0\0\0\0\0\0\0\0)
color_b=@Variant(\0\0\0\x43\x1\xff\xff\xff\xff\xff\xff\xff\xff\0\0)
color_s=@Variant(\0\0\0\x43\x1\xff\xff\xc0\xc0\xc0\xc0\xc0\xc0\0\0)
color_c=@Variant(\0\0\0\x43\x1\xff\xff\x80\x80\x80\x80\x80\x80\0\0)

john guin <jg42>
Sun 08 Feb 2015 06:35:10 AM UTC, comment #2: 

No response to request for info.  Closing report.

Rik <rik5>
Project Administrator
Thu 27 Mar 2014 11:47:55 AM UTC, comment #1: 

When I start octave 3.8.1 on windows (200% dpi, with or without existing qt-settings file), the console window font size is 10 pt. With this size, the console looks okay compared to the other widgets (although huge on my 1200x800 display).

  • Did you change the font size manually to 20 pt?
  • What is the contents of the [terminal] section of your settings file (c:\users\USER\.config\octave\qt-settings)?
  • What is the size of the editor font?

The issue with the settings dialog size was already reported in bug #41197 and was fixed with changeset http://hg.savannah.gnu.org/hgweb/octave/rev/e8176099889c for the gui-release branch (version 4.0).

Torsten Lilge <ttl>
Project Member
Sun 23 Mar 2014 02:29:26 AM UTC, original submission:  

Upon booting of the GUI, the default font for the cmd window is Courier New 20 point.  This looks very bad on a 3200x1800 screen (200% DPI).  Image attached.  The Preferences dialog which controls this is also not scaled properly.

Changing the terminal font helps a little, as does shrinking the font size, but it remains largely illegible.

john guin <jg42>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #33154:  reset_default_window_layout__octave_3200x1800_250percent.png added by jg42 (111KiB - image/png - adding images of broken ui at 3200x1800x250%)
file #33155:  smallx_octave_3200x1800_250percent.png added by jg42 (31KiB - image/png - adding images of broken ui at 3200x1800x250%)
file #33156:  small_down_arrow_dropdown_octave_3200x1800_250percent.png added by jg42 (11KiB - image/png - adding images of broken ui at 3200x1800x250%)
file #33157:  style_preferences_octave_3200x1800_250percent.png added by jg42 (30KiB - image/png - adding images of broken ui at 3200x1800x250%)
file #31008:  octave3.8.options.png added by jg42 (31KiB - image/png)
file #31009:  octave3.8.png added by jg42 (225KiB - 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 del_johnson (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by jg42 (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 15 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-03-10 ttl StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2015-02-24 ttl StatusConfirmed => Ready For Test
    2015-02-23 jg42 Attached File- => Added reset_default_window_layout__octave_3200x1800_250percent.png, #33154
        Attached File- => Added smallx_octave_3200x1800_250percent.png, #33155
        Attached File- => Added small_down_arrow_dropdown_octave_3200x1800_250percent.png, #33156
        Attached File- => Added style_preferences_octave_3200x1800_250percent.png, #33157
    2015-02-22 ttl StatusNeed Info => Confirmed
    2015-02-11 ttl Release3.8.1 => dev
        SummaryFonts do not scale properly with 3200x1800 monitors => Terminal fonts do not scale properly with a display scaling of 150% and more
    2015-02-10 rik5 Open/ClosedClosed => Open
    2015-02-08 rik5 Open/ClosedOpen => Closed
    2014-03-27 ttl StatusNone => Need Info
    2014-03-23 jg42 Attached File- => Added octave3.8.options.png, #31008
        Attached File- => Added octave3.8.png, #31009

    Back to the top


    Powered by Savane 3.5