@pantxo: I did it all. Create and environment variable to point to where I saved fonts.conf file.

Then I ran "fc-cache -fv" from C:\Program Files\GNU Octave\Octave-8.2.0\mingw64\bin.

Restarted Octave and made a new plot. Font display still screwy for Calibri, Cambria and Cambria Math

I can confirm janky Calibri behavior in Windows in Octave 8.2.0.

Cambria and Cambria Math also have similar behavior.

I still do see a totally unreadable text, when using the "Calibri" font on my Win10 machine with Octave 8.0.90 (and a fontsize not equal to 14).

You can reproduce this with the test scripts in this bug report, or simply with:

figure
plot(1:10)
text(3, 8, "hello", "fontname", "Calibri", "fontsize", 15);

@Mike: I marked this bug confirmed because many people were able to show that some fontname/size/weight combinations are rendered jagged or blurry.
The default fontname has changed since this issue was reported (we now consistently use FreeSans by default on all platforms) and this happens to lead to correct rendering by default. This does not change the fact that LibreOffice or Gnuplot can renderer e.g. Calibri and Verdana correctly whatever the weight/size, which Octave can't.

Updating the title to reflect the actual issue

I have done two more fresh mxe-octave builds with Pantxo's patch from comment #52. And at least for my very last build I am very sure that the patch is really applied. (I haven't done any linux tests, I just assume from Pantxo's comments that it does work there...)

Here are my results on three Windows machines:

• I have tested on two real (= not virtual) Win7 machines. They have "real" screen resolutions of 93dpi and 100dpi, see also bug  #45600 comment #2). The result of Octave's "get(0, 'screenpixelsperinch')" is very close to 72 on both those PCs. (This in physically incorrect, and Matlab gives the correct result as well.) Those two monitors are quite different, one is a huge office monitor, the other a tiny netbook screen. Plotting the test script of comment #38 with my patched mxe-octave gives me a NOT CHANGED font size on both machines. Pantxo's patch seems to NOT work on those REAL Windows Win7 PCs. But this is what Pantxo also said in comment #54. (The "only" question here is why Octave returns a wrong value of screenpixelsperinch.)

• I have also tested on a virtual WinXP machine. The result of "get(0, 'screenpixelsperinch')" is very close to 90, here. (The underlying Linux host system gives a value of 96.) Plotting the test script of comment #38 with my patched mxe-octave gives me a significantly BIGGER font size on this virutal machine. So Pantxos patch seems to WORK on this virtual Windows XP machine. I will attach a screenshot of this. (files "WinXP...")

My conclusions:

• The resulting title text in a qt plot with default fontname is even in the one case, where this patch works, still "ugly" in my perception. The texts in the "same" fontsize (14) look better, but texts with the same perceived fontsize still have the very same appearance. So I think this patch does not have any positive influence on this bug here.

• But I would still very much appreciate this patch (in an improved version that always works) as a solution to bug #45600.

@Pantxo: Could we move our discussion about this patch over to bug #45600 accordingly?

I have built mxe-octave with Pantxos patch from comment #52. Running this on my "problematic" Win7 machines with the test script from comment #38 does NOT give me a noticable different appearance of the texts. I will attach two screenshots (unpatched/patched) so that you can have a look yourself.

(A am not 100% sure that my new mxe-octave built really incorporates Pantxos patch. Here is what I did: Rename Pantxos patch file to "octave-1-fontpoints.patch" and save it in the folder "src" of mxe-octave. The I did "./configure --enable-octave=alpha" and afterwards "make zip-dist".)

I have tried option number two of comment #50 (using a local.conf file to switch the antialiasing off for the default Verdana font on Windows systems). Unfortunatelly this did NOT improve anything on my "problematic" Win7 machine. (This is in contrast to Dmitries observation in commment #48, where this improved the appearance of a bold N on Linux.) See also the two attached screenshots: Verdana on Win7 with/without antialiasing.

So out of the options that have already been proposed to fix this issue, the only remaining option seems now to change the default on Windows systems to Arial. (But some people consider Verdana normal text nicer than Arial normal text, see comment #19.)

Alternatively we could hope and wait until someone with a lot of insight into font rendering finds the root cause of this. Or we could eventually fix bug #45600, this would make it unecessary to increase the Verdana fontsize on Windows systems, and maybe help.

So somehow whatever gnome desktop / fontconfig does for my
desktop does not seem to apply directly to qt plot findow.
E.g. attached is the screenshot of the terminal windows with Verdan Bold 9 font set. It does look ugly but mostly due to wrong
kerning. (Who does kerning? i assume it is still freetype.
In any case one should not use proportional font for terminals.)
But individual characters look fine.
I have slight hinting/RGB antialiasing and freetype 2.7.0
on this particular computer.

The issue with Calibri looks to be a different one.

Dmitri.

Trying to summarize:

• I DID see this effect on a Win7 machine with a Nvidia graphics card (original bug report). (I tried to switch off as many graphics hardware accelaration as possible, the effect stayed. But I am unsure if I really succeeded in turning all graphics card features off, this seems to be tricky.)

• Rik and I do NOT see this effect on a WinXP virtual machine (with minimal graphics card emulation).

• Dmitri DID see this effect on a Linux machine (probably with a "proper" graphics card?). Trying to turn the graphics hardware acceleration off, did not eliminate the effect.

• I do NOT see this on my Linux machine with a "slim" on-board graphcis card. But I do not have the Calibri font available on this PC.

Trying to conclude so far:

• There is a problem with the font rendering stack in qt plots of Octave.
• It happens on Windows as well as on Linux machines.
• It is specific to certain fonts, other fonts work fine.
• It might be connected to graphics-card hardware acceleration, but this is not proven, yet.

The font testing script posted by Dan in comment #38 works fine for me, including with the Calibri font.

My testing platform is a Windows XP virtual machine.  This doesn't have HW-based acceleration which might be important for some reason.  Is it possible to switch to software rendering entirely and see if that helps?

Wow!  That makes clear which point sizes are defined and which are scaled.

"Notice a drastic change going from 16 to 17pt."

The same thing appears to happen when going from 9 to 10pt, if looking closely.

@Dmitri: Octave definitely uses kerning information, but I can't say wether it uses it properly.

For a review of the font rendering stack see this article http://behdad.org/text/.

1) When you print the font substituted to "Helvetica".
I kind of understand why it is done for ps/eps based toolchain,
but I am not sure we have to do it for svg or pdf (pdf seems
to go through eps --> gs --> pdf though gl2ps can save to
pdf directly).

So you see "beautiful" results when printed because thay are always done with "Helvetica" fonts (whatever they are on your system).

2) More to the original bug. As Dan S. pointed out a propotional font (Verdana) looks monospaced on qt (and fltk) plots. That hints
that the problem is with kerning. I am not sure how text layout done in Opengl toolkits -- do we rely on freetype to do kerning
for the entire text string, or we just get pixmaps
for individual letters and  string them ourselves?

Sincerely,

Dmitri.

@Dan: to go back to the default fontname, you need to set this property to the asterisk character, i.e. '*'.

verdana is one of the "MS core fonts for the web":

https://en.wikipedia.org/wiki/Core_fonts_for_the_Web

Dmitri.

On top of that OpenGL does not have its own facility
to render TT fonts, so some of the finer points (like hinting)
may be lost. Perhaps we should concider some specialized libraries
for font/text processing. E.g.:

http://ftgl.sourceforge.net/docs/html/

Dmitri.
--

Harmut, I don't think bug #45600 has to do with this bug. Fonts are displayed too small because we intentionally downscale them (we ask freetype, not fontconfig, to render X pixels faces when we should render X points ones). This is the only way to have the text extent approximately right in printout as gl2ps interprets screen pixels as points.

About using Arial as the default font: as Dmitri said it is meant to be a substitute for Helvetical which happens to be the only sans serif font our printing sytem currently supports.

All I would add is that open source OpenGL development that I've followed has quite a bit of activity regarding drivers and such.  It certainly has its "bugs", by which I mean a lot of elements in these drivers were written in a fast and inexact way and as time goes on elements of the drivers get refined and improved.  One issue is that they don't have a comprehensive test sweet to evaluate from programmer to programmer.

I should have said "OpenGL rendering issue")

Whatever was used for these

https://savannah.gnu.org/bugs/download.php?file_id=38687
https://savannah.gnu.org/bugs/download.php?file_id=38688

has a lot of space between numbers, e.g., "11" and "14".  But the example here

https://en.wikipedia.org/wiki/Verdana

seems more natural as far as spacing/tracking.  Perhaps the implementation of Verdana is poor in this case, or the font doesn't scale well.

In your comparison, Verdana appears to be a monospaced font, which is widely accepted to not look as nice as variable spaced fonts (Arial).  They have their place, such as lining up text for tables, computer printout, etc.

While I agree with the original post that the quality of the font is not as good as it should be, in my opinion it's the bold weight title that degrades appearance. The bold makes the particular font look worse somehow and looks unnatural compared to the other text on the plot. But this is what Matlab chooses for some reason.

Mathworks misses the mark a bit when it comes to plotting control and appearance. For example, I'm looking at this Position/OuterPosition control that leaves an odd layout for the title position of plots (https://savannah.gnu.org/bugs/?49260). However, following the Matlab definitions, that's almost what the behavior should be like. A discussion about that issue isn't pertinent here; suffice to say I've never been really motivated to strive for 100% compatibility when it comes to plotting. The vagaries of plotting goes back to the dawn of computers, and the only ones who took an initiative to try and address that were the Display PostScript folks, but that never caught on in any large scale I'm aware of.

I'd be just fine with making normal, not bold, text the default for title and making OuterPosition, not Position, the default subplot title.

This really seems to be an aesthetic issue.  "Beauty is in the eye of the beholder" and what looks good to me may not look good to you.

I agree that the Verdana font has something strange going on at the 14 pt. size with the letter 'N', but at the default 11 point size, I find it more readable than Arial.  The kerning (space between letters) is much smaller for Arial than Verdana which leads to a cramped blob of text that is difficult to read.

We want to optimize for the most common case, which is that the FontSize property is 10 and the TitleFontSizeMultiplier is 1.1 resulting in an 11 point, bold font.  In that case, this leads back to having Verdana as the default font.

To further muddy the issue, this seems only to be an artifact of onscreen rendering.  I printed to pdf format and the resulting text is fine.

I've attached examples of title text in 11 point and 14 point in both Arial and Verdana.

I think this issue should be left to individual users.  If they want a particular look they can guarantee it by selecting the fontname and size that they prefer.

My CONCLUSION: Could we change this "etc/fonts/conf.d/60-latin.conf" file such that "Arial" is on the first position on Windows systems? (I do not know where this file comes from. Is it just copied from somewhere? I don't see it in the mxe-octave sources. Or is it auto-generated during compilation, or during installation on the Windows system?)

(Note: What about the other font "family" parts in "etc/fonts/conf.d/60-latin.conf" file, or even the other conf files in "etc/fonts"? Is the order of font names here normally useful for Windows?)

Even if I externally create a Windows environment variable called FONTCONFIG_PATH, then this will NOT be visible from inside Octave with the getenv command. When I add the line

wshSystemEnv("FONTCONFIG_PATH") = OctavePath & "\etc\fonts"

to the vbs-script, then this external variable is visible from within Octave. But even in this case the result from fc-match still stays the same as above, and the plots still have the same (ugly) titles.

Result 2: Changing the FONTCONFIG_PATH (only possible via the vbs script) doesn't have any influence on the used fonts for titles.

next try to re-post the second half of comment #11:

Even if I externally create a Windows environment variable called FONTCONFIG_PATH, then this will NOT be visible from inside Octave with the getenv command. When I add the line +verbatim+ wshSystemEnv("FONTCONFIG_PATH") = OctavePath & "\etc\fonts" -verbatim- to the vbs-script, then this external variable is visible from within Octave. But even in this case the result from fc-match still stays the same as above, and the plots still have the same (ugly) titles.

Result 2: Changing the FONTCONFIG_PATH (only possible via the vbs script) doesn't have any influence on the used fonts for titles.

When I change the file ".../etc/fonts/conf.d/60-latin.conf" that normally looks like this (in the "sans-serif" section:

<family>sans-serif</family>
<prefer>
   <family>Bitstream Vera Sans</family>
   <family>DejaVu Sans</family>
   <family>Verdana</family>
   <family>Arial</family>
   <family>Albany AMT</family>
   <family>Luxi Sans</family>
   <family>Nimbus Sans L</family>
   <family>Helvetica</family>
   <family>Lucida Sans Unicode</family>
   <family>BPG Glaho International</family> <!-- lat,cyr,arab,geor -->
   <family>Tahoma</family> <!-- lat,cyr,greek,heb,arab,thai -->
</prefer>

and I change this part of the file by moving "Arial" up to the first position. Then the result is

>> system("fc-match sans")
arial.ttf: "Arial" "Normal"
ans = 0

and I get "nice" plot titles with bold Arial font, when I use the now adapted default fontname "*".

Result 3: Changing "etc/fonts/conf.d/60-latin.conf" does improve this situation very much. Here we can define the order of fonts to be used.

Note: I do not know enough about fonts. The current Octave title default font on this PC is "Verdana". This IS a TrueType font on this PC. But using Verdana's bold version for Octave titles results in "ugly" texts. The "Arial" font is also a TrueType font on this PC. But using Arial's bold version for Octave results in "nice" texts.

My CONCLUSION: Could we change this "etc/fonts/conf.d/60-latin.conf" file such that "Arial" is on the first position on Windows systems? (I do not know where this file comes from. Is it just copied from somewhere? I don't see it in the mxe-octave sources. Or is it auto-generated during compilation, or during installation on the Windows system?)

(Note: What about the other font "family" parts in "etc/fonts/conf.d/60-latin.conf" file, or even the other conf files in "etc/fonts"? Is the order of font names here normally useful for Windows?)

Here are the results of fc-match on the Win7 PC where I originally observed the "ugly" title texts. Octave was properly started via the vbs-script:

>> system("fc-match sans")
verdana.ttf: "Verdana" "Normal"
ans = 0

>> system("fc-match -s sans")
verdana.ttf: "Verdana" "Normal"
arial.ttf: "Arial" "Normal"
l_10646.ttf: "Lucida Sans Unicode" "Normal"
tahoma.ttf: "Tahoma" "Normal"
msgothic.ttc: "MS Gothic" "Regular"
simsun.ttc: "SimSun" "Regular"
mingliu.ttc: "PMingLiU" "Regular"
ARIALUNI.TTF: "Arial Unicode MS" "Normal"
mingliub.ttc: "PMingLiU-ExtB" "Regular"
mingliu.ttc: "MingLiU_HKSCS" "Regular"
malgun.ttf: "Malgun Gothic" "Regular"
msjh.ttf: "Microsoft JhengHei" "Normal"
meiryo.ttc: "Meiryo" "Normal"
swisop2.ttf: "SWIsop2" "Regular"
cambria.ttc: "Cambria Math" "Regular"
simpo.ttf: "Simplified Arabic" "Normal"
msuighur.ttf: "Microsoft Uighur" "Normal"
utsaah.ttf: "Utsaah" "Regular"
vijaya.ttf: "Vijaya" "Regular"
arabtype.ttf: "Arabic Typesetting" "Regular"
Vani.ttf: "Vani" "Regular"
Shonar.ttf: "Shonar Bangla" "Regular"
phagspa.ttf: "Microsoft PhagsPa" "Regular"
iskpota.ttf: "Iskoola Pota" "Normal"
taile.ttf: "Microsoft Tai Le" "Regular"
raavi.ttf: "Raavi" "Regular"
ntailu.ttf: "Microsoft New Tai Lue" "Regular"
kalinga.ttf: "Kalinga" "Regular"
tunga.ttf: "Tunga" "Regular"
kartika.ttf: "Kartika" "Regular"
shruti.ttf: "Shruti" "Regular"
lvnm.ttf: "Levenim MT" "Regular"
frank.ttf: "FrankRuehl" "Regular"
sylfaen.ttf: "Sylfaen" "Normal"
gulim.ttc: "Gulim" "Regular"
mvboli.ttf: "MV Boli" "Normal"
monbaiti.ttf: "Mongolian Baiti" "Normal"
seguisym.ttf: "Segoe UI Symbol" "Normal"
batang.ttc: "BatangChe" "Regular"
plantc.ttf: "Plantagenet Cherokee" "Regular"
ebrima.ttf: "Ebrima" "Normal"
msyi.ttf: "Microsoft Yi Baiti" "Normal"
nyala.ttf: "Nyala" "Normal"
euphemia.ttf: "Euphemia" "Regular"
KhmerUI.ttf: "Khmer UI" "Normal"
estre.ttf: "Estrangelo Edessa" "Normal"
himalaya.ttf: "Microsoft Himalaya" "Normal"
[...one line deleted...]
BKANT.TTF: "Book Antiqua" "Normal"
REFSAN.TTF: "MS Reference Sans Serif" "Normal"
CENTAUR.TTF: "Centaur" "Normal"
CENTURY.TTF: "Century" "Normal"
MathcadUniMathPrime.otf: "Mathcad UniMath Prime" "Regular"
BOOKOSB.TTF: "Bookman Old Style" "Negreta"
ans = 0

Result 1: The default "*" font for plot titles on this PC is "Verdana". I have confirmed this: Using the title command with fontname "*" produces the same (ugly) result as using fontname "Verdana".

I have also played with the FONTCONFIG_PATH: Just starting Octave (via the vbs-script) and not tweaking any Windows variables results in an empty FONTCONFIG_PATH:

>> getenv('FONTCONFIG_PATH')
ans =
>> size(ans)
ans =
   0   0

Even if I externally create a Windows environment variable called FONTCONFIG_PATH, then this will NOT be visible from inside Octave with the getenv command. When I add the line +verbatim+ wshSystemEnv("FONTCONFIG_PATH") = OctavePath & "\etc\fonts" -verbatim- to the vbs-script, then this external variable is visible from within Octave. But even in this case the result from fc-match still stays the same as above, and the plots still have the same (ugly) titles.

Result 2: Changing the FONTCONFIG_PATH (only possible via the vbs script) doesn't have any influence on the used fonts for titles.

When I change the file ".../etc/fonts/conf.d/60-latin.conf" that normally looks like this (in the "sans-serif" section:

<family>sans-serif</family>
<prefer>
   <family>Bitstream Vera Sans</family>
   <family>DejaVu Sans</family>
   <family>Verdana</family>
   <family>Arial</family>
   <family>Albany AMT</family>
   <family>Luxi Sans</family>
   <family>Nimbus Sans L</family>
   <family>Helvetica</family>
   <family>Lucida Sans Unicode</family>
   <family>BPG Glaho International</family> <!-- lat,cyr,arab,geor -->
   <family>Tahoma</family> <!-- lat,cyr,greek,heb,arab,thai -->
</prefer>

and I change this part of the file by moving "Arial" up to the first position. Then the result is

>> system("fc-match sans")
arial.ttf: "Arial" "Normal"
ans = 0

and I get "nice" plot titles with bold Arial font, when I use the now adapted default fontname "*".

Result 3: Changing "etc/fonts/conf.d/60-latin.conf" does improve this situation very much. Here we can define the order of fonts to be used.

Note: I do not know enough about fonts. The current Octave title default font on this PC is "Verdana". This IS a TrueType font on this PC. But using Verdana's bold version for Octave titles results in "ugly" texts. The "Arial" font is also a TrueType font on this PC. But using Arial's bold version for Octave results in "nice" texts.

My CONCLUSION: Could we change this "etc/fonts/conf.d/60-latin.conf" file such that "Arial" is on the first position on Windows systems? (I do not know where this file comes from. Is it just copied from somewhere? I don't see it in the mxe-octave sources. Or is it auto-generated during compilation, or during installation on the Windows system?)

(Note: What about the other font "family" parts in "etc/fonts/conf.d/60-latin.conf" file, or even the other conf files in "etc/fonts"? Is the order of font names here normally useful for Windows?)

• I have currently only access to a Win machine where this "ugly" title does NOT happen. (At least I don't percive it as ugly on its small screen.) On this machine I get:

>> system("fc-match sans")
DejaVuSans.ttf: "DejaVuSans" "Book"
ans = 0

So Arial does not seem to be a choice here. (But plotting text with fontname "Arial" works totally fine from within Octave.) The result of plotting a title with fontname "*" looks totally the same as plotting with fontname "DejaVuSans" on this PC.

• I will let you know the results of fc-match on the original Windows machine (with the "ugly" title font) in a couple of days.
• How do I change the FONTCONFIG_PATH? Is this a Windows environment variable or some Octave startup-parameter?

One could try messing around with the etc/fonts/conf.d/60-latin.conf file, which looks to me like the file in charge of selecting the order in which sans-serif fonts are selected on the system (assuming fontconfig is configured to find that directory in the way it is built for the Windows bundle). Arial is in the list, but not at the top of the list.

You where right, Rik. If I explicitly use the "Arial" font, then the title looks much nicer! It is only the default font "*" that produces this "ugly" non-antialiased bold title texts, this seems to simple be a non-aliasing font-type.

Since inbetween Octave 4.0.3 and 4.2.0-rc2 the title texts in qt plots where changed from "normal" to "bold", it is now much more obvious that the default font is an "ugly" one, not using anti-aliasing.

I know how to work-around this by using

set (0, "DefaultAxesFontName", "Arial")
#maybe also
set (0, "DefaultTextFontName", "Arial")

But I would prefer a solution that produces "nice" plots out of the box for Octave-Windows users. So my question is: Can we pick some (True Type) font on Windows systems for the default fontname?

I am not quite sure what the default fontname on my Windows system really is. I know of no simple way to find out. (This seems to be rather difficult, see bug #43651 ).

If I create a plot windows, then use the GUI button to create the "annotation dialog". Then the default "fontname" that is marked in this very long drop down list is called "MS Shell Dlg2", and this one is NOT TrueType. Maybe this is my default fontname, but I'm not sure.

Would it make sense to change the default fontname from the system default "*" into some very widly spread TrueType font like "Arial" on Windows systems (or on all systems) ?

I set the default font to "Arial" and the title looks fine to me with gnuplot and the Qt terminal, as well as with fltk and qt.  At least for me, this is a question about the default font choice being questionable which is the windowing system's responsibility.

Also, I should say that I'm using the dev branch version which is about to become 4.2.0.

Is this simply a consequence of the default font you are using?  It might not be an anti-aliased font, or it might not have been well-designed to scale beyond the normal reading ranges of 8-12 point.

What happens if you use a well known font with good design properties?

close all;
set (0, "DefaultAxesFontName", "Arial")
plot(1:10);
title('Title-Text: SNR', 'fontsize', 14);