Mon 19 Sep 2016 10:40:21 PM UTC, comment #15:
For the moment, things are okay because the default gnuplot built by MXE does not include wxt or pdfcairo terminals. Eventually, the quick test that I used for a "windows" terminal (ispc) will need to be improved. I filed a new bug report about that (bug #49135).
|
Sun 18 Sep 2016 01:47:35 AM UTC, comment #14:
I suggest to make the default font "Noto".
https://www.google.com/get/noto/
In worst case people get the same warnings and the font gets
substituted to "Tahoma" (at least this is what happened
with gnuplot 5.0.4 on Win computer where I tried). If
people do not like warnings they can go and install this font.
It is a decent-looking free font (I think it is derivative of DejaVu), supports many languages etc...
Dmitri.
--
|
Sat 17 Sep 2016 11:50:47 PM UTC, comment #13:
I have built windows binary with you changeset.
Of course, your changeset solves the problem for windows terminal.
However, your patch introduce extra warning for cairo based terminals like wxt, pngcairo and pdfcairo.
*******************************
(The below C:/Programs/gp504-64/bin/gnuplot.exe is full featured
gnuplot from gnuplot official site in my situation.)
Example 1
wxt termimal
Before your pactch
After your patch
Example 2
cairo based print devise
Before your patch
After your patch
But qt terminal does not give warning.
For cairo based terminal, set default is to Helvetica
gives annoying warning.
If I change font specify code from
fnt = "Helvetica";
to
fnt = "Arial";
warnings disappear.
Please keep in mind your patch causes extra warning when
octave uses cairo based terminals.
|
Sat 17 Sep 2016 02:02:06 PM UTC, comment #12:
The important point is not whether the system has the Helvetica font--most systems won't--but that the system knows how to map the name "Helvetica" to a real font that does exist on the system.
For Linux platforms, "Sans" appears to be a name that can always be mapped to a real font. But Windows doesn't always accept that, according to the reports from Avinoam and my own experience with a Windows XP virtual machine.
Try
For me, that issues about 8 warnings of
There are no such warnings if I use "Helvetica" for the default font.
|
Sat 17 Sep 2016 06:47:16 AM UTC, comment #11:
I do not think 'Helvetica' is not good solution for windows platform
because windows does not have 'Helvetica' font.
On gnuplot.exe (not wgbnuplot.exe) 5.0.4 from http://www.gnuplot.info,
gives warning:
Currently gnuplot embedded with octave does not support cairo based
terminal. However, one can use external gnuplot from official site which supports almost all terminals.
In that case, one can use cairo based print devise.
Perhaps this warning appear on octave command windows.
I am trying make tar ball for the snapshot the dev tree and will build windows binary using mxe-octave.
When test result will be gotten, I will report here.
|
Sat 17 Sep 2016 03:41:52 AM UTC, comment #10:
I added support for the new gnuplot 5.0 enhanced text syntax in this cset (http://hg.savannah.gnu.org/hgweb/octave/rev/549f8625a61b). I also changed the default font on Windows to Helvetica. This should fix the issues in this report.
|
Thu 15 Sep 2016 10:10:17 PM UTC, comment #9:
Re-titling this bug report. From looking at the gnuplot documentation it is clear that they changed the syntax that they use.
As a test example, try
This correctly produces Arial font in Bold. It looks like Octave's code needs to be updated to detect whether it is running gnuplot versions less than or greater than 5 and then change the commands it issues. At least for me, "Sans" also works on Windows. But it does seem just as easy to use "Helvetica" which will get mapped to something and is probably has wider usage.
|
Thu 15 Sep 2016 05:30:05 AM UTC, comment #8:
I tried with gnuplot 5.0.4 (gp504-win64-mingw) on win7 and it works
fine (picks up Tahoma Bold font).
Both "Sans Bold" and "Sans:Bold" worked.
I do not know what resolve Sans to Tahoma on windows. Perhaps
this particular version of gnuplot does it.
Dmitri.
(file #38512)
|
Thu 15 Sep 2016 04:53:41 AM UTC, comment #7:
So, I think I was correct in comment #3 that we will have to divide the behavior between Windows platforms and other platforms.
|
Thu 15 Sep 2016 04:49:27 AM UTC, comment #6:
It does not work on Windows:
|
Wed 14 Sep 2016 10:34:31 PM UTC, comment #5:
E.g. in gnuplot:
the "t1.pdf" is attached.
(file #38511)
|
Wed 14 Sep 2016 10:12:08 PM UTC, comment #4:
On linux you can specify font "Sans" and then it would pick up default fontfamyly (I think on most distros it is DejaVu).
I am not sure if that works for Macos and other windows.
Dmitri.
--
|
Wed 14 Sep 2016 09:51:20 PM UTC, comment #3:
I think both things need to be done. First, ":Bold" should be used when the gnuplot version is >= 5.0. Second, the default font, which on Linux can be "", should be set to something like "Helvetica", but only for Windows where this is an issue.
|
Wed 14 Sep 2016 08:28:58 PM UTC, comment #2:
After changing "-bold" with ":Bold" I still get warnings:
Because f is empty before the command
Again, if with do not leave f empty in
there will be no warnings. For example:
|
Wed 14 Sep 2016 06:14:41 PM UTC, comment #1:
I think the warnings are because gnuplot has changed syntax. See this Stack Overflow article (http://stackoverflow.com/questions/16428338/bold-enhanced-text-in-gnuplot#34402420).
Briefly, it seems that the new syntax uses a colon ':' rather than a dash '-'.
I modified _gnuplot_draw_axes_.m on the Windows side to replace instances of
with
and I no longer get warnings.
I'm adding Dan Sebald to the CC list. This looks like another instance where we need to check _gnuplot_has_feature_ and either use the old syntax ("-bold") or the new syntax (":Bold").
|
Fri 09 Sep 2016 09:33:40 PM UTC, original submission:
This is due to:
In _gnuplot_draw_axes_.m
If I set default font to "Helvetica" instead of empty string and "-bold" to " Bold" the result is "Helvetica Bold" which seems to be a decent font name.
|