bugGNU Octave - Bugs: bug #49627, Incompatible...


bug #49627: Incompatible "screenpixelsperinch" property

Submitter:  Pantxo Diribarne <pantxo>
Submitted:  Wed 16 Nov 2016 09:37:41 PM UTC
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  None Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Mon 11 Feb 2019 04:51:41 PM UTC, comment #2: 

A related issue is bug #53056.  In that bug report, the issue is that the linewidth expected by the glLineWidth call is measured in pixels, but the graphics property LineWidth is measured in points.  The conversion is

pixelwidth = Monitor_Pixels_Per_Inch / Points_Per_Inch * LineWidth_Points

Points_Per_Inch is a fixed constant of 72.  If we follow Matlab, then the Monitor_Pixels_Per_inch is always 96 and the overall factor is 96/72 == 4/3.

I don't fully understand all the implications of moving to a fixed PPI, however, so I can't recommend Octave do this until it is fully understood.

Rik <rik5>
Group administrator
Wed 16 Nov 2016 09:55:14 PM UTC, comment #1: 

(also copied over from bug #45600:)

I have just realized (see bug #49612, comment #2) that also the "plain" pixelnumbers (wd and ht in commment #12 of bug #45600) will be "un-real" on modern Windows systems. The factor between the real physical pixel number, and the pixel number given by VERTZRES and HORZRES seems to get scaled by Windows via the High-DPI setting (a scaling of 200% in the case of bug #49612 under Win10). Only on my very old WinXP machine the wd and ht values are returned correctly.

In this light, I think the Matlab decision is not so bad (for Windows): to go for a fixed "dpi" resolution of 96, and let the user decide (via his Windows high-dpi setting / scaling) how "big" he wants to have his pixels.

Hartmut <hardy>
Wed 16 Nov 2016 09:37:41 PM UTC, original submission:  

Copying a post from bug #45600:

Matlab seems to have adopted a fixed value of the "screenpixelsperinch" property (see [1]) for Windows and Mac platforms. Note that this makes this "pixels" unit device independent (an absolute unit).

The only reason I can see is Matlab has made the (unfortunate?) choice of fixing the default figure size in pixel units. Having pixels an absolute unit is thus a way to fix the absolute size of figures across different displays.
This also means that for ML compatibility we should follow the same route. Another good reason to do so is that, at least for Mac, Qt5 also chose device independent pixels [2].

The drawback of this approach is that it is not WYSIWYG: a figure onscreen will never have the expected physical size in inches (which is the default unit for "paperposition"). There are complaints about this regression on Matlabcentral [3].

Marking OS "any" even if on linux Matlab and Octave are compatible.

[1] https://fr.mathworks.com/help/matlab/ref/root-properties.html
[2] http://blog.qt.io/blog/2013/04/25/retina-display-support-for-mac-os-ios-and-x11/
[3] https://fr.mathworks.com/matlabcentral/newsreader/view_thread/344106

Pantxo Diribarne <pantxo>
Group Member


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

Attach Files:

No files currently attached


Depends on the following items: None found

   bug dependencies.


Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by hardy (Posted a comment)
  • -email is unavailable- added by pantxo (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.


    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-02-11 rik5 Dependencies- bugs #53056 is dependent

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code