@Mike: Yes this bug is still present in the sense that it is partly "intentional". IMO, in order to properly fix this bug we first need to at least 2 bugs:

• bug #49627: decide wether we want to use a fixed or screen/system dependent definition of a pixel (physical or logical pixel).
• bug #39697: have legend objects adapt smoothly when the fontsize is changed (not only the text but also the box size). The link here is subtle: if the onscreen text objects are drawn with their actual size in points (instead of pixels as currently), at print time we will have to switch all text sizes to be rendered in "pixels" (e.g. 12 pixels instead of 12 points) so that their extent is correct in gl2ps which interprets pixel coordinates as points.

Then only a simple fix such as file #38753 can be applied to cover this particular bug.

I filed bug #49627. Can you add your latest comments there?

In comment #2 Matlab gave me a value of 116 for screenpixelsperinch, but this was probably with a Matlab version  older than V2015b (because the comment is from July 2015).

@Pantxo: If you prefer to deal with this "screenpixelsperinch topic" in a separate bug report, I am fine with that. Could you please file this new bug report yourself, because I think you could explain more precisely what the necessary changes on Octave side could be.

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.)

The patch I provided was just for testing. Sure it will finally be what we need do but there are many things to fix before: as I explained we currently draw figures so that gl2ps, which interprets pixels as points, produces correct size figures.

Until gl2ps can be given the actual resolution of the system (I am working on a patch [1]) I don't think we can do anything on Octave side.

[1] http://www.geuz.org/pipermail/gl2ps/2016/000452.html

Once again I have spoken too soon.
I recently tried to understand our freetype text rendering engine in order to solve bug #45508 and this one. The freetype renderer uses pixels as base units whereas we feed it with font sizes in pixels. The major consequence is that the on-screen size of text objects is screen resolution dependent : a large screen resolution necessarily leads to ridiculously small fonts. This is easily fixed by converting points to pixels but ... this degrades the printed outputs: fonts are too small as compared to e.g legend box.

• What is that trick?

See the excerpt of print.m below

## print() requires figure units to be "pixels"
...
set (opts.figure, "units", "pixels");

## graphics toolkit translates figure position to eps bbox (points)
...
fpos(3:4) = opts.canvas_size;
set (opts.figure, "position", fpos);

We resize the figure windows prior to printing, so far so good, this is necessary to get all objects right in the desired aspect ratio. But we use a size computed in points units to change the position property of a figure which is supposed to be expressed in pixel units.

I am under the impression that gl2ps interprets the pixels coordinates from the opengl viewport/feedback buffer as points. So in order to  obtain an output image that has the expected dimensions the above trick is necessary.

My conclusion is that this bug can be solved only if we find a way to instruct gl2ps how to convert pixels (hardware dependent) to points (hardware independent).
I posted a message on gl2ps mailing list and will report back here.

The screen-shot mentioned in comment #5

Thanks for pointing me to the -f startup option of Octave, Pantxo. What I did previously was to temporary rename my .octaverc file in my user folder. But unfortunatly this didn't do the job properly, there must be another location where I had put a second .octave file a long time ago...

Now I redid all my plots (properly without any startup scripts) on the Ubuntu Linux PC. I will attach the resulting screenshots to his comment.

And now the CONCLUSION is much easier:

• On all my 3 computers, with Windows and with Ubuntu OS, the qt plots have all the same "visible" font size.
• Your Mint computer also produces the same plot.
• But: This "visible font size" in all the qt plots is significantly SMALLER THAN the font size in a MATLAB plot.
• In my personal taste: The Octave default "visible font size" is TOO SMALL. The Matlab one is better. (Even though the Matlab font size might still be slightly too small for aging eyes.)

I know that the "formal font size" in Matlab and in Octave qt plots is the very same, the value is fontsize=10. So the problem seems to be that fontsize 10 produces smaller texts in Octave plots, compared to Matlab plots!

Can we do something about this?

file #34513)

The attached plots in my first posts were produced on TWO different computers, one runs with Ubuntu Linux, the other one with Windows 7. Here are the details:

• The Win7 machine (producing qt plots with "too small" texts) is an office PC with a big monitor attached. The monitor is 525 mm wide and uses 1920 pixels over its width (=93 dpi in reality). The output of Matlab for the screenpixelsperinch is 116.
• On the same Win7 PC, the output of Octave 4.0.0 (as well as Octave 3.8.2-mxe-3) for screenpixelsperinch is only 72.046 .
• The Ubuntu machine (=second computer, producing qt plots with "visually proper" text size) is a laptop with a screen width of 345mm, using 1366 pixels over its width (=100 dpi in reality). The output of Octave for screenpixelsperinch is 96.103 here.
• addition: I have now also tested this on a THIRD laptop , a small netbook, also running Windows 7. Here the screen is only 255mm wide, using 1366 pixels in width. (=136dpi in reality). The output of Octave 4.0.0 for screenpixelsperinch is here 71.983. And the resulting plots are very similar (Win7, qt) to the ones the large Win7 PC with Octave, i.e. they seem to have a too small text font. Those plots seem to even have a very slightly smaller font size on this netbook. I will attach a screenshot from this netbook as well (Win7-smallScreen+Oct400+qt.png)

Summary so far:

• On the first Win7 PC, the value of screenpixelsperinch is very different between Matlab (=116) and Octave (=72.046).
• The values for screenpixelsperinch are always fractional in Octave. They seem to be integer in Matlab (but for Matlab only tested on one single PC).
• Two different computers, both with Windows 7 as OS, but with very different screen sizes (12 inch netbook versus huge office monitor), give nearly the same result for screenpixelsperinch (71.983 @ 1366 pixels, versus 72.046 @ 1920pixels). And they produce very similar qt plots under Octave. The fontsize in the screenshots is very, very similar, but on the small screen (slightly bigger screenpixelsperinch) the text fonts seems to be slightly bigger (but the difference is marginal.)

So far my "data" input. But I cannot judge if this is information connected with the original problem of too small text fonts in qt plots.

PS: Thanks for the hint to work around this via the .octaverc file, Pantxo. That's exactly what I do for myself. But in the long run I would like to see the most commonly used setup (i.e. Octave on Windows with qt plotting) work out of the box. Without the need (for new users) to tweak anything. I hope we can make this happen.

Here is a tiny script that I used to produce the following plots to judge the fontsize:

clear, close all;
graphics_toolkit qt;
plot(1:10);
text(5,5,'hello WORLD');
title('Octave 4.0.0 (Win), qt');

If you run this, you get the following results:

• Ubuntu 14.04 + Octave (4.0.0) + qt     -> text is big enough
• Windows 7 + Octave 4.0.0 + qt plotting -> text is too small
• Windows 7 + Matlab 2013b               -> text is big enough

This judgment "too small" is not only my personal taste. On the attached screenshots of those plot results you can see, that under Windows 7 the fontsize in the qt plots is significantly smaller compared to the "same" plot either under Linux with qt, or under Windows with Matlab.

In my opinion this makes the resulting plots under Windows + qt (the default graphics toolkit) uglier than necessary. Can we change this?

(I am not sure if this is connected to #41308.)