bugGNU Octave - Bugs: bug #49216, Some fontname/size/weight...

 
 

bug #49216: Some fontname/size/weight combinations are rendered jagged/blurry in OpenGL

Submitted by:  Hartmut <hardy>
Submitted on:  Wed 28 Sep 2016 06:42:37 PM 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:  Any

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Mon 04 Mar 2019 09:35:23 AM UTC, comment #57: 

@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

Pantxo Diribarne <pantxo>
Project Member
Mon 04 Mar 2019 02:43:56 AM UTC, comment #56: 

@pantxo You marked this as confirmed a few days ago, is this bug applicable to the current default branch? If so please update the release field.

Mike Miller <mtmiller>
Project Administrator
Fri 21 Oct 2016 09:42:22 PM UTC, comment #55: 

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?


Hartmut <hardy>
Thu 20 Oct 2016 07:01:32 AM UTC, comment #54: 

@Harmut: I don't know the proper way to apply patches prior to building with MXE, but I am pretty sure you didn't apply the patch. You should obtain larger fonts (e.g 1.5 times with a standard 96 dpi screen) with the patch unless your display is 72 dpi.

Pantxo Diribarne <pantxo>
Project Member
Wed 19 Oct 2016 06:39:30 PM UTC, comment #53: 

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


Hartmut <hardy>
Tue 18 Oct 2016 08:16:08 PM UTC, comment #52: 

I have attached a patch for testing the effect of querying the "right" font size (in points, not in pixels) in ft-text-renderer.cc.

The main issue I can see when running Dan's snippet (comment #38) is that both bold and normal fonts (either Verdana or Calibri) look "bolder" above 12 pts. This is the same effect as observed in Dmitri's screenshot from comment #40 except that without the patch it appears above 16 pts.

(file #38753)

Pantxo Diribarne <pantxo>
Project Member
Tue 18 Oct 2016 06:27:14 PM UTC, comment #51: 

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.


Hartmut <hardy>
Wed 12 Oct 2016 08:55:12 PM UTC, comment #50: 

I agree with Dmitri's opinion, that the totally scrambled text with "CALIBRI" font might be a different problem. It is also a not so important problem: On Linux, people normally do not have this font installed (it is non-free). And on Windows, an Octave user would have to explicitly ask for this font in order to use it in plots. It is not used by default.

In contrast, the original problem with "ugly" bold text (used for all plot titles since Octave version 4.2) in "VERDANA" font is more relevant. Because this font will be used as default font on most Windows systems.

Therefore I would like to suggest to fix the original (Verdana) problem, even if we do not yet understand the rest (i.e. the funny Calibri texts).

So far, the following fixes have been proposed:

  • Change the fontconfig settings in mxe-octave such, that a different font will be used as default font. This should be a font that is normally installed on Windows systems, maybe Arial.  (comment #5 and others)
  • Change the fontconfig settings in mxe-octave such, that antialiasing is turned off for Verdana font. (comment #48)

Since our current Windows default font (Verdana) looks alright in default size (comment #19, even though this size is currently too tiny to be read on bigger screens, due to a different bug), I would tend for the second solution (i.e. turn antialiasing off for Verdana).

(But I cannot currently test on a "problematic" Windows system, how "nice" this solution would look in general.)

Hartmut <hardy>
Wed 12 Oct 2016 08:17:49 PM UTC, comment #49: 

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.


Dmitri A. Sergatskov <dasergatskov>
Wed 12 Oct 2016 07:28:32 PM UTC, comment #48: 

I played with "ftview" utility (part of the freetype demos) --
at least some problems with Verdana is resolved
(bold N W look normal) if I turn off antialiasing.

I cannot reproduce the problem with calibri font with this viewer.

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Wed 12 Oct 2016 06:43:30 PM UTC, comment #47: 

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.
Hartmut <hardy>
Tue 11 Oct 2016 10:25:01 PM UTC, comment #46: 

My test was done on linux.
I tried to run:

LIBGL_ALWAYS_SOFTWARE=1 ./run-octave --no-gui

also tried to run through ssh.
Different computers...
It is all the same. 

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Tue 11 Oct 2016 09:47:19 PM UTC, comment #45: 

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?

Rik <rik5>
Project Administrator
Tue 11 Oct 2016 08:42:26 PM UTC, comment #44: 

On my Win7 machine I get the same results as Dmitri in comment #40 and #42, see attached screenshot.

So there seems to be a general problem with the font rendering stack in qt plots under Windows OS. I think this is now more than just a matter of taste.


Hartmut <hardy>
Mon 10 Oct 2016 09:05:34 PM UTC, comment #43: 

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

Dan Sebald <sebald>
Mon 10 Oct 2016 08:51:46 PM UTC, comment #42: 

And this is what it looks with "Calibri" font
(again gnuplot and Libreoffice render it fine).

Dmitri.


Dmitri A. Sergatskov <dasergatskov>
Mon 10 Oct 2016 08:18:01 PM UTC, comment #41: 

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

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

Dan Sebald <sebald>
Mon 10 Oct 2016 08:09:28 PM UTC, comment #40: 

@Dan

I ran a slightly modified test (add "N" in the string).
The attached is what I got. Notice a drastic change going from 16 to 17pt.

It might be fonconfig doing some tricks like using embedded bitmap
for small fonts -- but I thought I disabled this particular option
globally.

Dmitri.


Dmitri A. Sergatskov <dasergatskov>
Mon 10 Oct 2016 07:37:16 PM UTC, comment #39: 

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

Pantxo Diribarne <pantxo>
Project Member
Mon 10 Oct 2016 06:56:12 PM UTC, comment #38: 

gnuplot font seems a bit larger than what I'd typically think of as pointsize (that's an issue for title layout that I'm looking at right now).  To rule out something like gnuplot not scaling and instead use the nearest font size definition, I've tried the following script:

clf;
plot(1:50);
ypos = 5;
for i=9:17
  ht = text(10, ypos, sprintf("This is %dpt",i), "fontsize", i, "fontweight", "normal");
  ht = text(30, ypos, sprintf("This is %dpt",i), "fontsize", i, "fontweight", "bold");
  ypos += i/3;
endfor

Everything seems to scale nicely with gnuplot and OpenGL drivers on my system.  Perhaps someone who is experiencing the poor Verdana rendering could run this and maybe detect something useful.

Dan Sebald <sebald>
Mon 10 Oct 2016 06:31:56 PM UTC, comment #37: 

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.

Dmitri A. Sergatskov <dasergatskov>
Mon 10 Oct 2016 05:59:34 PM UTC, comment #36: 

I think my comment #19 was correct that the "ugly" aspects are essentially unsolvable.  Some people will prefer Verdana and some will prefer Arial based on different combinations of point size and bold/non-bold.  Given that, I don't think it makes sense to change the default globally.  Rather, everyone should choose the font that works best for them and place it in their personal .octaverc or in the system-wide .octaverc for their installation.

Regarding the font renderer, Octave is certainly getting different onscreen results than other programs.  Someone mentioned Libreoffice, for example, produces better results.  I have attached a screenshot of the Verdana Bold font at 14pt size drawn with gnuplot, notepad, and through the qt toolkit (all on MS Windows).  As you can see, gnuplot and notepad produce the same result which looks rather good.  It is only the qt (and fltk toolkit) which produce an ugly onscreen result.  Maybe this bug report should be re-titled to deal specifically with the different rendering issue.

In any case, the printed results seem okay so this is only a problem for onscreen display.  Published papers will have appropriately "beautiful" text.


Rik <rik5>
Project Administrator
Mon 10 Oct 2016 05:52:02 PM UTC, comment #35: 

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

Hartmut <hardy>
Sun 09 Oct 2016 09:22:13 PM UTC, comment #34: 

@Dmitri: Octave, like ftgl, uses freetype to render fonts as pixmaps. So unless you think about using ftgl to render path (tessalated characters) and rewrite the whole text-renderer (tex support ...) this is a no go. 

@Dan: if you don't provide a fontname Octave picks the first font you obtain when running "fc-match sans" in a terminal.

Pantxo Diribarne <pantxo>
Project Member
Sun 09 Oct 2016 08:45:00 PM UTC, comment #33: 

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

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

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Sun 09 Oct 2016 08:37:58 PM UTC, comment #32: 

I too think it could be a font-processing problem.  Placing characters isn't easy.  I can't find verdana in my LibreOffice, but in any case fonts is a main component of such an app and I'd imagine LibreOffice programmers spent a lot of time on the system font tools to make that correct.

As an aside, I notice when I set a 'fontname' that isn't recognized, Octave defaults to some generic font.  On my system it's a mediocre font, but I don't see any kerning/tracking problems with scaling.  The bogus name remains within the property.  Should it do that as opposed to changing the string to empty?

octave:43> set(ht,'fontname', 'asdffdsa')
octave:44> get(ht,'fontname')
ans = asdffdsa

What may be a bug, however, is when I type in an empty string for the font name (thinking that would get me back to the default):

octave:36> set(ht,'fontname', 'courier')
octave:37> set(ht,'fontname', 'times')
octave:38> set(ht,'fontname', 'helvetica')
octave:39> set(ht,'fontname', 'times')
octave:40> set(ht,'fontname', '')
error: ft_text_renderer: invalid bounding box, cannot render
octave:40> set(ht,'fontname', 'fdsasdaf')
octave:41> set(ht,'fontname', '')
error: ft_text_renderer: invalid bounding box, cannot render
octave:41> set(gca, 'xlabel', 'Hi')
octave:42> set(ht,'color','red')
error: ft_text_renderer: invalid bounding box, cannot render

Dan Sebald <sebald>
Sun 09 Oct 2016 08:25:49 PM UTC, comment #31: 

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

Dmitri A. Sergatskov <dasergatskov>
Sun 09 Oct 2016 08:06:30 PM UTC, comment #30: 

Citing English page for TrueType in Wikipedia:

>> Creating a very well-hinted TrueType font remains a significant amount of work, despite the increased user-friendliness of programs for adding hints to fonts. Many TrueType fonts therefore have only rudimentary hints, or have hinting automatically applied by the font editor, with variable end results.


And the french version:

>> En revanche, la conception de polices TrueType utilisant les hints est fastidieuse, et les fontes ne les utilisant pas n'ont pas la même efficacité optique : elles donnent dans certains corps l'impression de « baver ».


As a summary font hinting is complicated, from the font developper pov, and some fonts only have rudimentary support for hints, which may well be the category into which Verdana falls.

Pantxo Diribarne <pantxo>
Project Member
Sun 09 Oct 2016 07:41:56 PM UTC, comment #29: 

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.

Pantxo Diribarne <pantxo>
Project Member
Sun 09 Oct 2016 06:43:30 PM UTC, comment #28: 

"don't have a comprehensive test sweet"

Oy, make that "suite"!  (Had the band Sweet in my mind a little while ago...)

Dan Sebald <sebald>
Sun 09 Oct 2016 06:31:26 PM UTC, comment #27: 

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.

Dan Sebald <sebald>
Sun 09 Oct 2016 06:18:24 PM UTC, comment #26: 

Question: Might the following hypothesis be a possible explanation for this observed behavior?

  • Verdana is a nice font, maybe even nicer than Arial (might be taste, though).
  • Fontconfig is doing everything right, even under Windows OS. We are also using it correctly.
  • Fontconfig is properly doing anti-aliasing, hinting or whatever else is useful to get a nice on screen display of the text  (with 14pt Verdana font).
  • Fontconfig is preparing the 14pt Verdana text for display on a monitor, that is really using the equivalent number of pixels that corresponds to 14pt.
  • BUT now bug #45600 kicks in: On the monitor the text is NOT displayed at the intended size. Somewhere (qt? OpenGL?) it gets scaled down to a smaller size, and only then it gets displayed. This might detoriate or sometimes even destroy all the good work that fontconfig has done before.

I do not know if this is a possible explanation, because I don't have enogh knowledge about the details of how fontconfig, openGL and qt are interacting. Especially concerning pixel sizes and pixel interpolations.

One fact that nicely fits into this hypothesis is, that in pdf printouts the text looks nice (see Riks's comment #19). If I remember bug #45600 right, then also the text size is correct in pdf printouts.

Hartmut <hardy>
Sat 08 Oct 2016 07:17:29 PM UTC, comment #25: 

I should have said "OpenGL rendering issue")

Dmitri A. Sergatskov <dasergatskov>
Sat 08 Oct 2016 07:07:38 PM UTC, comment #24: 

Yes, it looks like Qt font rendering issues.
I tried the same text in LibreOffice and it looks much better.

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Sat 08 Oct 2016 06:43:36 PM UTC, comment #23: 

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.

Dan Sebald <sebald>
Sat 08 Oct 2016 06:22:58 PM UTC, comment #22: 

Verdana is not a monospace font ("i" and "l" definitely takes less
space then "e" or "t"). I think it is just not a very good font.
It was designed for low-resolution media (like computer screens)
which at that time was like 72pdi or something (circa win98).

Aial was designed to be Helvetica substitution and it is a print
font (designed for media with 300dpi and higher).

Try some more modern fonts. I like "Noto" these days.
https://www.google.com/get/noto/

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sat 08 Oct 2016 04:40:37 PM UTC, comment #21: 

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.

Dan Sebald <sebald>
Sat 08 Oct 2016 04:20:47 PM UTC, comment #20: 

The Arial 11pt screenshot that you attached is actually 14.

Mike Miller <mtmiller>
Project Administrator
Sat 08 Oct 2016 02:13:46 PM UTC, comment #19: 

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.


Rik <rik5>
Project Administrator
Tue 04 Oct 2016 08:24:49 PM UTC, comment #18: 

(eventually done with re-posting...)

Hartmut <hardy>
Tue 04 Oct 2016 08:23:59 PM UTC, comment #17: 

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

Hartmut <hardy>
Tue 04 Oct 2016 08:22:10 PM UTC, comment #16: 

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 versioni for Octave results in "nice" texts.

Hartmut <hardy>
Tue 04 Oct 2016 08:21:39 PM UTC, comment #15: 

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.

Hartmut <hardy>
Tue 04 Oct 2016 08:20:45 PM UTC, comment #14: 

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

Hartmut <hardy>
Tue 04 Oct 2016 08:19:09 PM UTC, comment #13: 

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

Hartmut <hardy>
Tue 04 Oct 2016 08:18:00 PM UTC, comment #12: 
  • The bold text in the last comment should be a quoted asterix character, twice.
  • The second half of the last comment was chopped off, here is it again:

==============

Hartmut <hardy>
Tue 04 Oct 2016 08:15:20 PM UTC, comment #11: 

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

Hartmut <hardy>
Thu 29 Sep 2016 10:18:58 PM UTC, comment #10: 

Yes, the FONTCONFIG_PATH is an environment variable, use setenv/getenv in Octave, or add to octave.bat where the PATH environment variable is normally set before running Octave. I don't know if it needs to be set before Octave starts or if it can be changed while running.

FONTCONFIG_PATH is not normally needed on a GNU distribution because the fontconfig library is compiled to know where to look by default, but since the Windows bundle is install-anywhere, it probably needs to be set, and maybe has been overlooked until now, or maybe I'm completely wrong and it's not necessary at all.

Note that it should point to the "etc/fonts" directory, which should contain fonts.conf and conf.d. I don't know which direction it wants its directory separators to lean in.

You can run "fc-match arial" or "fc-match Arial" and that should come back with the actual Arial font name.

If you run "fc-match -s sans", it should list all possible fonts that are installed and configured as "sans" font substitutions, in order of preference. Then if you edit the file etc/fonts/conf.d/60-latin.conf, you should see the order update. I think it takes effect immediately, but as we know file timestamps tend to be a bit weird on Windows filesystems, may not work the way I expect it to on Debian.

Mike Miller <mtmiller>
Project Administrator
Thu 29 Sep 2016 09:34:47 PM UTC, comment #9: 
  • 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?
Hartmut <hardy>
Thu 29 Sep 2016 05:10:18 PM UTC, comment #8: 

The program fc-match.exe in the bin directory should let you query the fontconfig database the same way that Octave's font selection would work.

What does

>> system ("fc-match sans");

come up with?

Maybe FONTCONFIG_PATH needs to be set. Is it set in Octave's environment normally (launching from octave.vbs)? Does anything change if you set FONTCONFIG_PATH to point to the PREFIX/etc/fonts directory?

Mike Miller <mtmiller>
Project Administrator
Thu 29 Sep 2016 05:03:49 PM UTC, comment #7: 

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.

Mike Miller <mtmiller>
Project Administrator
Thu 29 Sep 2016 04:35:36 PM UTC, comment #6: 

Why don't you ask the question on the octave-maintainers list and see what the response is?

Octave ships with a site-wide .octaverc file which is available for sysadmins to configure details just like this.  An obvious solution would be to set the default Axes and Text FontName properties in this file.

Or, if we want to rely on the fact that Linux window managers generally know how to correctly pick a default font then it would only be required for the Windows version of Octave which is produced with MXE.  In that case, I would make the modification in the MXE repository rather than the general Octave repository.

Given that all Windows systems ship with a few core fonts from Microsoft and Arial is one of these, that seems a good default for Windows machines.

Rik <rik5>
Project Administrator
Thu 29 Sep 2016 11:52:53 AM UTC, comment #5: 

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

Hartmut <hardy>
Thu 29 Sep 2016 12:28:29 AM UTC, comment #4: 

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

<<<
JPEG may not be as well suited for line drawings and other textual or iconic graphics, where the sharp contrasts between adjacent pixels can cause noticeable artifacts. Such images may be better saved in a lossless graphics format such as TIFF, GIF, PNG

>>>

Dmitri A. Sergatskov <dasergatskov>
Wed 28 Sep 2016 11:53:50 PM UTC, comment #3: 

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.

Rik <rik5>
Project Administrator
Wed 28 Sep 2016 08:44:47 PM UTC, comment #2: 

The bold font in gnuplot toolkit Qt plots doesn't look real nice either--better than the Windows case as there is no anti-aliasing fuzziness.  Generally, the normal font looks better.

Dan Sebald <sebald>
Wed 28 Sep 2016 07:16:06 PM UTC, comment #1: 

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

Rik <rik5>
Project Administrator
Wed 28 Sep 2016 06:42:37 PM UTC, original submission:  

This happens with qt plots (Octave 4.2.0-rc2, Octave 4.0.3, and before) under Win and Linux OS:

The title text of plots is printed in bold. Once it reaches a readable fontsize this texts looks quite "ugly". There might be missing some anti-aliasing?

Here is a short script to show what I mean:

clear, close all;
plot(1:10);
title('Title-Text: SNR', 'fontsize', 14);

I will attach screenshots of the resulting figures. (The Octave-Linux figure used fonsize 18 instead, to get comparably sized text). Espacially the "N" character in Octave-Windows does not look very nice. I have done the screenshots also with Matlab-Windows and with Octave-Linux (the screenshot program in Linux wasn't quite able to reproduce this "ugliness", it seemd to do some anti-aliasing on its own. I will attach the image anyways.)

Note: This bug report is not about the incorrect fontsize of the displayed text, this already covered in bug #45600.

Hartmut <hardy>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #38753:  fontpoints.patch added by pantxo (1KiB - text/x-diff)
file #38695:  various_renderings.png added by rik5 (25KiB - image/png)
file #38685:  Arial_11pt.png added by rik5 (1KiB - image/png)
file #38686:  Arial_14pt.png added by rik5 (1KiB - image/png)
file #38687:  verdana_11pt.png added by rik5 (1KiB - image/png)
file #38688:  verdana_14pt.png added by rik5 (2KiB - image/png)
file #38618:  ML_Win7_fontsize14.jpg added by hardy (102KiB - image/jpeg)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by hardy
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by hardy (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 25 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-04 pantxo Release4.0.3 => dev
        Summarytitle texts in qt plots are "ugly" => Some fontname/size/weight combinations are rendered jagged/blurry in OpenGL
    2019-02-28 mtmiller Carbon-CopyRemoved 80942 => -
    2019-02-28 pantxo StatusNeed Info => Confirmed
    2016-11-21 mtmiller Dependencies- => bugs #41308 is dependent
    2016-10-21 hardy Attached File- => Added WinXP_patched-Octave430+_Verdana.png, #38791
        Attached File- => Added WinXP_un-patched-Octave420rc2_Verdana.png, #38792
    2016-10-19 hardy Attached File- => Added unpatched_VerdanaArialCalibri.jpg, #38765
        Attached File- => Added patched_VerdanaArialCalibri.jpg, #38766
    2016-10-18 pantxo Attached File- => Added fontpoints.patch, #38753
    2016-10-18 hardy Attached File- => Added Win7_Octave420rc2_Verdana_Defaut=WithAntialiasing.jpg, #38751
        Attached File- => Added Win7_Octave420rc2_Verdana_NoAntialiasing.jpg, #38752
    2016-10-12 dasergatskov Attached File- => Added Screenshot_from_2016-10-12_15-05-57.png, #38715
    2016-10-11 hardy Attached File- => Added Win7_Oct420rc2_Arial+Verdana+Calibri.jpg, #38705
    2016-10-10 dasergatskov Attached File- => Added Screenshot_from_2016-10-10_15-35-55.png, #38698
    2016-10-10 dasergatskov Attached File- => Added Screenshot_from_2016-10-10_15-05-32.png, #38697
    2016-10-10 rik5 Attached File- => Added various_renderings.png, #38695
    2016-10-09 hardy Carbon-Copy- => Added pantxo
    2016-10-08 rik5 Attached File- => Added Arial_11pt.png, #38685
        Attached File- => Added Arial_14pt.png, #38686
        Attached File- => Added verdana_11pt.png, #38687
        Attached File- => Added verdana_14pt.png, #38688
    2016-09-28 rik5 StatusNone => Need Info
    2016-09-28 hardy Attached File- => Added Octave-4.2.0-rc2_Win7_fontsize14.jpg, #38616
        Attached File- => Added Octave-4.0.3_Linux_fontsize18.png, #38617

    Back to the top


    Powered by Savane 3.5