Mon 21 Nov 2016 03:26:50 AM UTC, comment #13:
Closing as a duplicate of bug #49216 as suggested, much more discussion and analysis being done there.
|
Sat 19 Nov 2016 11:13:24 AM UTC, comment #12:
This might be a duplicate (or vice versa) of an issue mentioned in bug #49216 (commment #42). Under Windows OS texts with Calibri font look scrambled in qt plots, see example in file #38698.
|
Sun 16 Feb 2014 09:37:18 PM UTC, comment #11:
Summary of sub-issues so far:
- FLTK can't do certain font sizes (confirmed only on Win 7)
- FLTK and gnuplot default font type is serif and sans, respectively
- FLTK and gnuplot interpret font size inconsistently; consequently, default font size may be too small in FLTK.
|
Sun 16 Feb 2014 12:47:16 AM UTC, comment #10:
OK, here's a new set of pngs.
it seems the fltk font is serif (Times?) while gnuplot uses a sans serif (Arial?).
(file #30568, file #30569)
|
Sun 16 Feb 2014 12:14:57 AM UTC, comment #9:
The freetype-based rendered is using anti-aliasing. Glyphs are rendered using FT_RENDER_MODE_NORMAL, which is anti-aliasing, as described here [1].
If you want to compare to gnuplot, you should make sure you use the same font and the same size in both cases. Note that at the moment, octave always interpret font size as being a pixel size, which usually ends up with smaller text on screen, because gnuplot will interpret is as a point size (and today's screens use dpi > 72).
[1] http://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_Render_Mode
|
Sat 15 Feb 2014 11:49:39 PM UTC, comment #8:
I think the following issue is related: the fonts used in fltk -- whatever size -- don't seem anti-aliased, compared to gnuplot.
I could submit a separate bug report or maybe the current title could be generalized.
(file #30563, file #30564)
|
Thu 23 Jan 2014 04:29:42 PM UTC, comment #7:
Anyone with access to Windows 8 to test there? It is at least a good start that it is localized to certain Windows distributions.
|
Thu 23 Jan 2014 03:35:46 PM UTC, comment #6:
OK I can confirm this on (native) Win7, with 3.8.0 and a 4.1.0+ from a week ago.
It struck me that the script you gave to reproduce the issue hangs for a while during, or after, the first subplot line when run from the editor with F9 (I can't assess the exact moment). Did you also see that?
But this behavior (delay) is not very well reproducable..... didn't happen anymore after two or three trials. The garbled font however is very reliably reproduced.
As this is dependent on Windows version, I'm afraid sorting this one out might be hard & time consuming. Do you have a workaround?
Can you copy a font over from XP and try again? maybe it is just a Windows font issue.
<title adapted / release set to "dev">
|
Wed 22 Jan 2014 10:56:15 PM UTC, comment #5:
the problem remains with other text, rotated or not.
the original font name returned "*".
setting it to "arial", "helvetica", etc. didn't help.
mysterious...
this is Win 7, if that matters.
|
Wed 22 Jan 2014 10:34:27 PM UTC, comment #4:
Can't reproduce the OP's problem with my 3.8.0 MXE-built octave on Windows XP.
Screenshot attached.
What font did you use, Felipe?
(file #30351)
|
Wed 22 Jan 2014 09:44:34 PM UTC, comment #3:
Another thing to test is whether the problem is with ylabel, or with any text in general.
For example, does the following work?
|
Wed 22 Jan 2014 09:16:16 PM UTC, comment #2:
neither resizing the window nor changing the font name helped... let's wait and see if others can replicated.
|
Wed 22 Jan 2014 06:49:06 PM UTC, comment #1:
This works for me on Linux and Windows.
What happens if you resize the window by dragging a corner? This forces a redraw which might be the problem.
Also, it might be the font that is used has bad metrics for the 20 point size. What happens if you execute the following?
|
Wed 22 Jan 2014 05:51:52 PM UTC, original submission:
pls see screenshot attached.
|