bugGNU Octave - Bugs: bug #45600, fonts displayed too small in...


bug #45600: fonts displayed too small in gl-based plots

Submitter:  Hartmut <hardy>
Submitted:  Wed 22 Jul 2015 07:21:23 AM UTC
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Inaccurate Result
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * Microsoft Windows
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Sun 05 Dec 2021 09:32:25 AM UTC, comment #19: 

I suppose I have the same problem as described below and found a workaround.
My operating system is Windows 7 + Octave 5.1.

If I save figures by e.g. "print(1,'file.png')" the result looks much different from the figure itself: characters in the png are much enlarged compared to the original figure and the plot itself. I have been searching a long time for a solution. Now, changing the plot size by "print(1,'-S960,720','file.png')" seems to solve that problem. It seems that the default plot size used by Octave is 1200x900 pixels which causes the large characters. Maybe Octave could identify the correct plot size by itself in future versions, so figures and saved figures look the same?
Hope this helps.

Mon 04 Mar 2019 12:05:18 PM UTC, comment #18: 

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

Pantxo Diribarne <pantxo>
Group Member
Mon 04 Mar 2019 02:48:17 AM UTC, comment #17: 

Is this bug still present in current versions of Octave? Does it depend on bug #49627 being fixed?

Mike Miller <mtmiller>
Group Member
Wed 16 Nov 2016 09:48:48 PM UTC, comment #16: 

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

Pantxo Diribarne <pantxo>
Group Member
Wed 16 Nov 2016 09:28:41 PM UTC, comment #15: 

I have just realized (see bug #49612, comment #2) that also the "plain" pixelnumbers (wd and ht in commment #12 of this bug report here) 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: 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:17:12 PM UTC, comment #14: 

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.

Hartmut <hardy>
Wed 16 Nov 2016 09:52:20 AM UTC, comment #13: 

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, Qt 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].

Finally opening a new bug report about this inconsistency is probably the way to go. Harmut can you do it or do you want me to?

[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
Tue 15 Nov 2016 06:59:54 PM UTC, comment #12: 

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":


  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;
    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:

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:

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.)
Hartmut <hardy>
Thu 27 Oct 2016 05:43:37 PM UTC, comment #11: 

Sorry for not remembering the background of this bug. And thanks for working on a way to improve this.

Hartmut <hardy>
Thu 27 Oct 2016 07:47:19 AM UTC, comment #10: 

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

Pantxo Diribarne <pantxo>
Group Member
Wed 26 Oct 2016 07:41:02 PM UTC, comment #9: 

In bug #49216 Pantxo posted a patch (file #38753) that addresses this issue. This patch has the remaining problem that it relies on the output of "get(0, 'screenpixelsperinch')" or something equivalent, and this often gives wrong dpi results around 72dpi under Windows (as reported in comment #2).

Hartmut <hardy>
Fri 28 Aug 2015 03:26:16 PM UTC, comment #8: 

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.

Pantxo Diribarne <pantxo>
Group Member
Mon 27 Jul 2015 09:28:30 AM UTC, comment #7: 

I can't work on this right now, but I am under the impression that the issue is quite simple: the freetype text renderer (see txt-eng-ft.cc) has been entirely written using pixels as base units while we provide it font size in points ...

I'll work on this when I am back from vacations if no one does in the mean time.

Pantxo Diribarne <pantxo>
Group Member
Sat 25 Jul 2015 09:54:22 AM UTC, comment #6: 

The screen-shot mentioned in comment #5

Pantxo Diribarne <pantxo>
Group Member
Sat 25 Jul 2015 09:52:29 AM UTC, comment #5: 

Agreed! I attached a screen-shot in which I superimposed an Octave figure on a LibreOffice document (scale 100%). Here I used "Liberation Serif" 10 pt for comparison, but all the fonts I tried are consistently displayed much smaller in Octave than in LO.

Retitling to better describe the issue.

Pantxo Diribarne <pantxo>
Group Member
Fri 24 Jul 2015 08:09:16 PM UTC, comment #4: 

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)

Hartmut <hardy>
Fri 24 Jul 2015 07:42:16 AM UTC, comment #3: 

Many thanks H.G. for the extensive investigation. Unfortunately, I am unable to draw conclusions either.
Now don't forget that it doesn't seem to be a linux vs Windows issue : I obtain an on-screen font size on linux that is comparable to what you obtain on Windows.

Any chance that you are using a startup script that forces non default font size on Ubuntu? I use "octave -f" to be sure not to (sorry if once again that is what you do also :-)

Pantxo Diribarne <pantxo>
Group Member
Thu 23 Jul 2015 06:39:28 PM UTC, comment #2: 

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.

Hartmut <hardy>
Wed 22 Jul 2015 01:38:07 PM UTC, comment #1: 

Thanks for your report. We use freetype/fontconfig to draw characters on both platforms so there may be something wrong with those libraries on Windows or it could be related to the screen resolution.
Were all those screenshots produced on the same machine? If so, is the screen resolution used by the graphics system consistent between Win/Linux, Matlab/Octave. You can get it using e.g:

get (0, "screenpixelsperinch")

For me the result is ~95 (on linux mint 17.1) and the on-screen figure looks more like the one you obtain in windows, see attachment.

Anyway, the default fontsize is the same on all platforms so the only way to "change" this is to find the origin of the issue.
The workaround is to change the default fontsize before plotting, e.g.

set (0, "defaultaxesfontsize", 12)
set (0, "defaulttextfontsize", 12)

This is actually what I have in my .octaverc (which I didn't load to produce the screenshot) as even on linux, 10 pts is not big enough for aging eyes.

Pantxo Diribarne <pantxo>
Group Member
Wed 22 Jul 2015 07:21:23 AM UTC, original submission:  

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

clear, close all;
graphics_toolkit qt;
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.)

Hartmut <hardy>


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

Attach Files:

Attached Files
file #34516:  Octave_vs_LO_Fonts.png added by pantxo (46KiB - image/png)
file #34513:  Ubuntu_Plots_nostartupscript.zip added by hardy (35KiB - application/zip)
file #34488:  Mint17.png added by pantxo (17KiB - image/png)
file #34487:  all_fontsize_plots.zip added by hardy (308KiB - application/zip)
file #34486:  Win7+ML2013b.jpg added by hardy (128KiB - image/jpeg)
file #34485:  Win7+Octave400_qt.jpg added by hardy (81KiB - image/jpeg)
file #34484:  Ubuntu+Octave400_qt.png added by hardy (19KiB - image/png)


Depends on the following items: None found

   bug dependencies.


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


    Follow 13 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-06-07 pantxo Dependencies- bugs #65846 is dependent
    2019-03-04 pantxo Release4.0.0 dev
    2016-11-16 pantxo StatusNone Confirmed
    2015-07-25 pantxo Attached File- Added Octave_vs_LO_Fonts.png, #34516
    2015-07-25 pantxo Summaryfontsize in qt plots too small under Windows fonts displayed too small in gl-based plots
    2015-07-24 hardy Attached File- Added Ubuntu+Octave400_qt_nostartupfile.png, #34512
        Attached File- Added Ubuntu_Plots_nostartupscript.zip, #34513
    2015-07-23 hardy Attached File- Added Win7-smallScreen+Oct400+qt.png, #34494
    2015-07-22 pantxo Attached File- Added Mint17.png, #34488
    2015-07-22 hardy Attached File- Added Ubuntu+Octave400_qt.png, #34484
        Attached File- Added Win7+Octave400_qt.jpg, #34485
        Attached File- Added Win7+ML2013b.jpg, #34486
        Attached File- Added all_fontsize_plots.zip, #34487

    Back to the top

    Powered by Savane 3.13-ee12.
    Corresponding source code