[Octave-bug-tracker] [bug #45600] fonts displayed too small in gl-based plots

[Hartmut]

Follow-up Comment #12, bug #45600 (project octave):

I have done some research why our 'screenpixelsperinch' property sometimes
gives wrong results under Windows:

We are currently using the following Octave code to calculate the
screenpixelsperinch property:
* in "graphics.cc":

static double
default_screenpixelsperinch (void)
{
  return (display_info::x_dpi () + display_info::y_dpi ()) / 2;
}


* with x_dpi and y_dpi taken from rx and ry in "cdisplay.c":

#if defined (OCTAVE_USE_WINDOWS_API)

  HDC hdc = GetDC (0);

  if (hdc)
    {
      *dp = GetDeviceCaps (hdc, BITSPIXEL);

      *ht = GetDeviceCaps (hdc, VERTRES);
      *wd = GetDeviceCaps (hdc, HORZRES);

      double ht_mm = GetDeviceCaps (hdc, VERTSIZE);
      double wd_mm = GetDeviceCaps (hdc, HORZSIZE);

      *rx = *wd * 25.4 / wd_mm;
      *ry = *ht * 25.4 / ht_mm;

      *dpy_avail = 1;
    }
  else
    msg = "no graphical display found";


The values of wd and ht are just the number of pixels in monitor width (wd)
and height (ht). Those number are generated correctly on all Windows systems.

To calculate the resultion (dpi) from the number of pixels, we additionally
need the physical monitor size (e.g. in millimeters). Those values (ht_mm and
wd_mm) are generated via the call to the VERTZIZE and HORSIZE property in
GetDeviceCaps (seems to be part of the Windows API).

My personal observation (from using Octave on serveral windows machines) is
that the return value of those VERTSIZE and HORSIZE properties in the Windows
API must give WRONG values. Under Windows XP the results seem to still be
quite reasonable. But under Windows 7 you mostly get mm values that are much
too big. As a result Octave then calculates dpi values that are much too small
(see screenpixelsperinch values in comment #2), and as a result fonts in
default fontsize are displayed much too small on Win7 monitors.

I am not alone with this observation. You can find several reports of this
change in behavior between WinXP and Win7 regarding the physical monitor size.
E.g. on those websites:
*
http://forums.codeguru.com/showthread.php?521245-GetDeviceCaps-issue-in-Windows-7-wrong-size
*
https://social.msdn.microsoft.com/Forums/vstudio/en-US/6f06fa5e-1626-4668-b0ee-1f0d07e8d175/getdevicecapshorzsize-is-incorrect-in-windows-7?forum=vcgeneral

As a conclusion: It seems to be quite hard nowadays to get the physical
monitor size in mm under Windows OS, at least with Win7 (and probably later
version like Win10).

There is a lengthy "code snippet" that is cited several times and reported to
work quite well, to exctact the physical monitor size in a reliable way from
the Windows registry. The original code is here: 
*
https://ofekshilon.com/2011/11/13/reading-monitor-physical-dimensions-or-getting-the-edid-the-right-way/

But the Windows API and our use of it in Octave is way beyond my personal
programming skills: Can we just include the necessary header files (atlstr.h,
SetupApi.h) in Octave? Is it GNU compatible to use this code from the given
link at all? How could we reasonably integrate this code into Octave's
graphics.cc?

If someone with the required skills reads this, I would assume that the
following would be a reasonable improvement of Windows Octave:
* Change the calculation of the physical monitor size (at least for Win7 and
probably upwards) to something like the given "code snippet".
* (Maybe keep the calculation of the physical monitor size (wd_mm and ht_mm)
as it currently is, for WinXP.)

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?45600>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/