gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Want to contribute in gnuplot

[Ethan A M. <sf...@us...>]

On Sunday, April 22, 2012 01:31:54 pm Aman (neshu) Agarwal wrote:
> I installed the x11-devel library using yum and it start working :D
> 
> Apart from that I need a small favour from you guys actually, I wrote a
> small patch on
> http://sourceforge.net/mailarchive/forum.php?thread_name=Pine.LNX.4.64.1006132254080.2528%40tesla&forum_name=gnuplot-beta
> 
>  and I am asking you for the guideline and process for submitting the patch
> in gnuplot.PFA of current patch related to the story and kindly 

It is better to submit patches using the Tracker system at
   https://sourceforge.net/tracker/?group_id=2055&atid=302055
Patches attached to Email can get lost or forgotten, and it is not so
obvious how to find out if there is an updated version.

It is not strictly necessary, but it would be useful to also provide
a test case or example script that demonstrates the new feature.
If the patch corrects a weakness in the existing code, either an
actual bug or just a non-optimal behaviour, it would be good to 
provide an example that fails on the CVS code but works (or works
better) after applying your patch.

> suggest me the changes  I need to made.

coding style:

1) If the new routine quantize_tics() is used only in axis.c, it should
be declared as static and a prototype declaration should be added at the
head of the file.  If it is called from other places, the prototype
declaration should be placed instead in axis.h.

2) FLT_EPSILON is not guaranteed to be defined. If you really need this,
then the code defining MACHEPS that is currently in specfun.c should be
moved to specfun.h so that other files can share it.

3) It is not necessary to modify the date in version.c.
The build script will fill that in automatically.


	Ethan

Re: gd & fontpath (could not find/open font)

[m s. <mw...@us...>]

On 4/19/2012 9:09 AM, gnu...@li... wrote:
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 18 Apr 2012 17:55:02 -0400 (EDT)
> From: Allin Cottrell<cot...@wf...>
> Subject: Re: gd&  fontpath (could not find/open font)
> To: Mojca Miklavec<moj...@gm...>
> Cc: gnuplot-beta<gnu...@li...>
> Message-ID:<alpine.LFD.2.01.1204181753140.2726@myrtle>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>
> On Wed, 18 Apr 2012, Mojca Miklavec wrote:
>
>> I'm still experiencing a problem with
>>
>>> set term png
>>     Terminal type set to 'png'
>>     Could not find/open font when opening font "arial", using internal
>> non-scalable font
> Urgh. Why on earth are you using libgd (whose font handling is
> beyond redemption) rather than the cairo-based PNG terminal?
>
> Allin Cottrell
>
>
>
I use the libgd png/gif exclusively for output files.  We write plotting 
tools that have to run on Linux, Solaris and Windows.  Libgd was the 
simplest solution.  It gives us PNG and animated GIF.  Not all our users 
have the system privileges to install all the required packages for 
Cairo.  One other benefit is that we distribute some TTF fonts required 
for our toolset.   The text created by libgd when using TTF fonts is 
nearly indistinguishable than those created by pngcairo.

I have personally created graphs created with libgd and put them in 
presentations to very high level decision makers.  My charts look like 
they were created using Excel or Matlab depending who the target 
audience is.

My experience with libgd has been a positive one.

Mike S

Re: Want to contribute in gnuplot

[Aman (n. A. <nes...@gm...>]

? share/Gnuplot
? src/beos/Makefile
? src/qtterminal/Makefile
? src/qtterminal/Makefile.in
? src/wxterminal/Makefile
Index: src/axis.c
===================================================================
RCS file: /cvsroot/gnuplot/gnuplot/src/axis.c,v
retrieving revision 1.102
diff -u -a -r1.102 axis.c
--- src/axis.c	3 Apr 2012 16:57:47 -0000	1.102
+++ src/axis.c	22 Apr 2012 19:34:42 -0000
@@ -143,6 +143,9 @@
 struct lp_style_type mgrid_lp  = DEFAULT_GRID_LP;
 int grid_layer = -1;
 double polar_grid_angle = 0;	/* nonzero means a polar grid */
+double tic_quant[] = {5.0, 2.0, 1.0};
+int tic_min = 5;
+int tic_max = 10;
 TBOOLEAN raxis = TRUE;
 
 /* Length of the longest tics label, set by widest_tic_callback(): */
@@ -582,6 +585,27 @@
     return (tics * power);
 }
 
+
+double 
+quantize_tics(double val_axis_min, double val_axis_max)
+{
+	
+    double log_normal, tic_val;
+    int i, tics, diff_tic_val;
+
+    log_normal = log10((val_axis_max - val_axis_min)/tic_max);
+    for (i = 0; i < sizeof(tic_quant)/sizeof(tic_quant[0]); i++) {
+     	tics = ceil(log_normal - log10(tic_quant[i]) - FLT_EPSILON);
+     	tic_val = tic_quant[i]*pow(10, tics);
+     	diff_tic_val = ceil(val_axis_max/tic_val) - floor(val_axis_min/tic_val);
+     	if (diff_tic_val >= tic_min)
+        	break;
+    }  
+    return tic_val;
+}
+
+
+
 /* }}} */
 
 /* {{{ make_tics() */
@@ -599,7 +623,9 @@
     if (xr >= VERYLARGE)
 	int_error(NO_CARET,"%s axis range undefined or overflow",
 		axis_defaults[axis].name);
-    tic = quantize_normal_tics(xr, guide);
+	
+    //tic = quantize_normal_tics(xr, guide);
+	tic = quantize_tics(axis_array[axis].min, axis_array[axis].max);
     /* FIXME HBB 20010831: disabling this might allow short log axis
      * to receive better ticking... */
     if (axis_array[axis].log && tic < 1.0)
Index: src/version.c
===================================================================
RCS file: /cvsroot/gnuplot/gnuplot/src/version.c,v
retrieving revision 1.104
diff -u -a -r1.104 version.c
--- src/version.c	9 Mar 2012 18:26:39 -0000	1.104
+++ src/version.c	22 Apr 2012 19:34:42 -0000
@@ -41,7 +41,7 @@
 
 const char gnuplot_version[] = "4.7";
 const char gnuplot_patchlevel[] = "0";
-const char gnuplot_date[] = "2012-03-02 ";
+const char gnuplot_date[] = "2012-04-20 ";
 const char gnuplot_copyright[] = "Copyright (C) 1986-1993, 1998, 2004, 2007-2012";
 
 const char faq_location[] = FAQ_LOCATION;

Re: Want to contribute in gnuplot

[Hans-Bernhard B. <HBB...@t-...>]

On 22.04.2012 18:48, Aman (neshu) Agarwal wrote:
> Hi,
>
> I am building gnuplot on fedora 15 but I am unable to see the window of
> plot ? anybody know why ?

Hmmm... looks like you already found yourself the first small job to 
tackle:

1) find out why your build doesn't seem to contain any GUI terminal 
drivers.  I'll drop you a hint: 'configure' writes a whole lot of 
messages, both on screen and into 'config.log'.  You may want to have a 
look at that.

2) determine where in the build instructions (both the one on the web 
you used, and the one contained in the source itself) the information 
about this should have been, so you wouldn't have missed it.

3) submit a patch to any document involved.

Re: Want to contribute in gnuplot

[Daniel J S. <dan...@ie...>]

On 04/22/2012 11:48 AM, Aman (neshu) Agarwal wrote:
> Hi,
>
> I am building gnuplot on fedora 15 but I am unable to see the window of
> plot ? anybody know why ?
>
> I am following this for the building the gnuplot package
> http://www.gnuplot.info/development/index.html#BuildingFromCVS

Aman,

You're not giving enough information for any of us to even guess.  I'm 
guessing you are able to launch gnuplot and type at the command line. 
When you attempt to plot something, is there a message that shows up in 
the terminal window?  When you launch gnuplot is there a "Terminal type 
set to 'x11'" message, or something else?  When you are building the 
program, during the configure step, are there any messages indicating 
that some package is missing?  At the end of the configure should be a 
summary of what libraries and so on are available.

Dan

Re: Want to contribute in gnuplot

[Aman (n. A. <nes...@gm...>]

Hi,

I am building gnuplot on fedora 15 but I am unable to see the window of
plot ? anybody know why ?

I am following this for the building the gnuplot package
http://www.gnuplot.info/development/index.html#BuildingFromCVS

Thanks
Aman



On Sun, Apr 22, 2012 at 7:30 PM, Aman (neshu) Agarwal <
nes...@gm...> wrote:

> Hi,
>
> myself Aman Agarwal I am using  gnuplot from last 3 years, it always help
> me in critical situations during my asignment and data analysis.
>
> After taking so much from you guys I want to give my some time to
> community for making gnuplot better program. Hope you guys will assign me
> some small task for the starter.
>
> Thank
>
> --
>

Re: Want to contribute in gnuplot

[Marek P. <ma...@du...>]

Dear Aman,

> After taking so much from you guys I want to give my some time to community
> for making gnuplot better program. Hope you guys will assign me some small
> task for the starter.

very nice to hear. I am by no means a Gnuplot developer, but what about 
trying my former proposal:
http://sourceforge.net/mailarchive/forum.php?thread_name=Pine.LNX.4.64.1006132254080.2528%40tesla&forum_name=gnuplot-beta

Anybody against that idea? Currently, I assume no one is interested 
until a proper patch is made. And personally, I am still too lazy to write 
it, I admit.


Regards,
Marek

Want to contribute in gnuplot

[Aman (n. A. <nes...@gm...>]

Hi,

myself Aman Agarwal I am using  gnuplot from last 3 years, it always help
me in critical situations during my asignment and data analysis.

After taking so much from you guys I want to give my some time to community
for making gnuplot better program. Hope you guys will assign me some small
task for the starter.

Thank

-- 
Aman A.
Amazon.com | Software Development Engineer | TAM - Technology

"If you want to follow you should follow it 100%"

Re: new transparent colors

[Ethan A M. <sf...@us...>]

On Thursday, April 19, 2012 06:09:27 am Mojca Miklavec wrote:
> Dear developers,
> 
> are other terminals (apart from svg, wxwidgets, qt) supposed to
> implement new transparent colors now, 

Sure. Feel free to contribute a patch for aquaterm or whatever.
I had a look at lua.trm, but frankly I don't understand how it 
works so I left it alone.

> What should terminal do if it gets instructions:
>     set_color(r,g,b,a=0.5)
> and then
>    fill(...)
> with FS_TRANSPARENT_SOLID and fillpar 30 for example?

From the user's perspective, the two commands below should produce
the same result:
   set style fill solid fillcolor "#7FRRGGBB"
   set style fill transparent solid 0.5 fillcolor "RRGGBB"

The latter command cannot be deprecated yet because as you point out
some terminals do not yet recognize the alpha component of a RGB color.

Consider FS_TRANSPARENT_SOLID as a backwards-compatibility feature.
Since no existing script that uses it could be relying on the high
bits of the RGB color to hold alpha, the backwards compatible way
of handling them is to ignore them.

> See also pdfcairo's result of the new demo, attachmed. To me it seems
> at least a tiny bit problematic that each line of the arrow is drawn
> separately.

See also Bug #3514186.
It may be worth revisiting how arrows are drawn.
In particular it may be desirable to offer an arrow style that treats
the entire arrow as a single filled polygon, with or without a separate
bounding stroke.

	Ethan

Re: gd & fontpath (could not find/open font)

[Mojca M. <moj...@gm...>]

On Thu, Apr 19, 2012 at 18:10, Ethan A Merritt wrote:
>
> It is possible to embed a font in the PostScript output if you want to,
> using the "fontfile" option. See the "fontfile.dem" demo.
> But this is not the default.

Thank you I was actually looking for exactly this topic:
    help post fontfile

I'll test and ask in case that I will have any more questions left.

Mojca

Re: gd & fontpath (could not find/open font)

[Ethan A M. <sf...@us...>]

On Thursday, April 19, 2012 07:12:16 am Allin Cottrell wrote:
> On Thu, 19 Apr 2012, Mojca Miklavec wrote:
> 
> > On Thu, Apr 19, 2012 at 01:23, Allin Cottrell <cot...@wf...> wrote:
> >
> >> PostScript is a page description language, and as such it knows absolutely
> >> nothing about font-searching.
> >
> > Oh, thanks for clarifying. I see now that it only writes the font name
> > into file, no matter whether that font exists anywhere. It doesn't try
> > to do any embedding of fonts. I thought that PostScript terminal would
> > also embed fonts, but I was apparently wrong.
> 
> I guess by "it" you mean the traditional gnuplot postscript 
> terminal. Yes, it just passes through any font request given 
> by the user, without any check on the availablility of the 
> font. It's then up to the PostScript interpreter to find the 
> font or substitute a default.

It is possible to embed a font in the PostScript output if you want to, 
using the "fontfile" option. See the "fontfile.dem" demo.
But this is not the default.

Re: gd & fontpath (could not find/open font)

[Mojca M. <moj...@gm...>]

On Thu, Apr 19, 2012 at 16:12, Allin Cottrell <cot...@wf...> wrote:
> On Thu, 19 Apr 2012, Mojca Miklavec wrote:
>
> You say that the epscairo terminal
>
>> ... creates bitmap images embded inside PostScript which is not
>>
>> why one would want to use PostScript in the first place.
>
>
> Eh? Could you give an example of that? Some EPS files contain a bitmapped
> "preview" but I'm not seeing that with files generated by epscairo, and the
> PS content itself is in pure vector form. For example

It might be that I have accidentally tried an example with
transparency and cairo automatically generates a bitmap when
transparency is involved. I was testing with the latest demo file
which draws transparent arrows.

Mojca

Re: gd & fontpath (could not find/open font)

[Allin C. <cot...@wf...>]

On Thu, 19 Apr 2012, Mojca Miklavec wrote:

> On Thu, Apr 19, 2012 at 01:23, Allin Cottrell <cot...@wf...> wrote:
>
>> PostScript is a page description language, and as such it knows absolutely
>> nothing about font-searching.
>
> Oh, thanks for clarifying. I see now that it only writes the font name
> into file, no matter whether that font exists anywhere. It doesn't try
> to do any embedding of fonts. I thought that PostScript terminal would
> also embed fonts, but I was apparently wrong.

I guess by "it" you mean the traditional gnuplot postscript 
terminal. Yes, it just passes through any font request given 
by the user, without any check on the availablility of the 
font. It's then up to the PostScript interpreter to find the 
font or substitute a default.

By contrast, the epscairo terminal does check for a specified 
font via fontconfig. If it's found, the font is embedded 
(subsetted); if not, a default font is embedded instead. 
(There's no error message or warning if the specified font is 
not found and the default is used -- maybe there should be?)

You say that the epscairo terminal

> ... creates bitmap images embded inside PostScript which is not
> why one would want to use PostScript in the first place.

Eh? Could you give an example of that? Some EPS files contain 
a bitmapped "preview" but I'm not seeing that with files 
generated by epscairo, and the PS content itself is in pure 
vector form. For example

set term epscairo font "cmr10,12"
set output 'test.eps'
plot sin(x)

Allin Cottrell

Re: gd & fontpath (could not find/open font)

[Mojca M. <moj...@gm...>]

On Thu, Apr 19, 2012 at 01:23, Allin Cottrell <cot...@wf...> wrote:
> On Thu, 19 Apr 2012, Mojca Miklavec wrote:
>
>> On Wed, Apr 18, 2012 at 23:55, Allin Cottrell wrote:
>>>
>>> On Wed, 18 Apr 2012, Mojca Miklavec wrote:
>>>
>>>> I'm still experiencing a problem with
>>>>
>>>>> set term png
>>>>
>>>>
>>>>   Terminal type set to 'png'
>>>>   Could not find/open font when opening font "arial", using internal
>>>> non-scalable font
>>>
>>>
>>> Urgh. Why on earth are you using libgd (whose font handling is beyond
>>> redemption) rather than the cairo-based PNG terminal?
>>
>> I'm not. I'm just annoyed by the error and I would like to fix it.

... but I'm still curious how exactly the fonts are searched, more
precisely, if there is any way to convince gd2 to search recursively.

> I don't have the status of a gnuplot developer, but as a gnuplot user and
> occasional patch-submitter I would strongly recommend treating libgd as
> "legacy" and concentrating on the cairo-based terminals.

Thank you. I guess that others are sharing the same view?

> PostScript is a page description language, and as such it knows absolutely
> nothing about font-searching.

Oh, thanks for clarifying. I see now that it only writes the font name
into file, no matter whether that font exists anywhere. It doesn't try
to do any embedding of fonts. I thought that PostScript terminal would
also embed fonts, but I was apparently wrong.

> The latest gnuplot has an "epscairo" terminal which presumably combines
> fontconfig font-searching (cairo and fontconfig being linked) with
> PostScript generation.

... and creates bitmap images embded inside PostScript which is not
why one would want to use PostScript in the first place. (Most
probably the image is composed out of multiple smaller bitmap images
since I see some ugly artifacts all over the place.)

Mojca

new transparent colors

[Mojca M. <moj...@gm...>]

Dear developers,

are other terminals (apart from svg, wxwidgets, qt) supposed to
implement new transparent colors now, or is the feature still
experimental, and might be better to wait a bit?

What should terminal do if it gets instructions:
    set_color(r,g,b,a=0.5)
and then
   fill(...)
with FS_TRANSPARENT_SOLID and fillpar 30 for example?

See also pdfcairo's result of the new demo, attachmed. To me it seems
at least a tiny bit problematic that each line of the arrow is drawn
separately.

Mojca

Re: canvas term needed for SVG ??

[Ethan A M. <sf...@us...>]

On Wednesday, April 18, 2012 05:15:57 pm pl...@pi... wrote:

> 
> If anyone's interested, a minimal gnuplot for embedded is still under a 
> meg when stripped.
> 
>   ARCH=arm  ./configure --host=arm-unknown-linux-gnueabi --without-x 
> --without-pdf \
> --without-cairo --disable-wxwidgets --without-x --without-tutorial \
> --prefix=/root_image/usr   --without-lua --disable-h3d-quadtree 
> --disable-stats  --disable-history-file
> 
> 
> ls -ail src/gnuplot
> 17869545 -rwxr-xr-x 1 user users 966600 Apr 19 02:09 src/gnuplot
> 
> regards, Peter.

If you are desparate for spare kilobytes, changing the macro
STORE_WITH_LOG_AND_UPDATE_RANGE
into a subroutine reduces the total size of the default executable
by about 2%.  I would guess the effect on your minimal executable
would be correspondingly larger.

	Ethan

Re: canvas term needed for SVG ??

[Ethan M. <merritt@u.washington.edu>]

On Wednesday, April 18, 2012 05:15:57 pm pl...@pi... wrote:
> Hi Ethan,
> 
> I am trying to update my 4.4.3 minimalistic ARM build to 4.6.0 and get a 
> failure.
> 
> ../term/svg.trm: In function 'SVG_text':
> ../term/svg.trm:1046: error: 'CANVAS_OVERSAMPLE' undeclared (first use 
> in this function)
> 
> 
> I have edited term.h down to bare min as before but it looks like a need 
> to add in canvas for svg now ??
> 
> A quick look at the source seems it's just a tweaked constant (increased 
> coord accuracy?).
> 
> in term/canvas.trm:
> #define CANVAS_OVERSAMPLE       10.
> 
> I hacked this line into svg.trm and it build OK. Perhaps the two should 
> be separated.

Oops!
The dangers of cut-and-paste.
That should clearly be SVG_SCALE rather than CANVAS_OVERSAMPLE.
Fortunately they are both equal to 10 :-)

	Ethan


> 
> 
> 
> If anyone's interested, a minimal gnuplot for embedded is still under a 
> meg when stripped.
> 
>   ARCH=arm  ./configure --host=arm-unknown-linux-gnueabi --without-x 
> --without-pdf \
> --without-cairo --disable-wxwidgets --without-x --without-tutorial \
> --prefix=/root_image/usr   --without-lua --disable-h3d-quadtree 
> --disable-stats  --disable-history-file
> 
> 
> ls -ail src/gnuplot
> 17869545 -rwxr-xr-x 1 user users 966600 Apr 19 02:09 src/gnuplot
> 
> regards, Peter.
> 
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742

canvas term needed for SVG ??

[<pl...@pi...>]

Hi Ethan,

I am trying to update my 4.4.3 minimalistic ARM build to 4.6.0 and get a 
failure.

../term/svg.trm: In function 'SVG_text':
../term/svg.trm:1046: error: 'CANVAS_OVERSAMPLE' undeclared (first use 
in this function)


I have edited term.h down to bare min as before but it looks like a need 
to add in canvas for svg now ??

A quick look at the source seems it's just a tweaked constant (increased 
coord accuracy?).

in term/canvas.trm:
#define CANVAS_OVERSAMPLE       10.

I hacked this line into svg.trm and it build OK. Perhaps the two should 
be separated.



If anyone's interested, a minimal gnuplot for embedded is still under a 
meg when stripped.

  ARCH=arm  ./configure --host=arm-unknown-linux-gnueabi --without-x 
--without-pdf \
--without-cairo --disable-wxwidgets --without-x --without-tutorial \
--prefix=/root_image/usr   --without-lua --disable-h3d-quadtree 
--disable-stats  --disable-history-file


ls -ail src/gnuplot
17869545 -rwxr-xr-x 1 user users 966600 Apr 19 02:09 src/gnuplot

regards, Peter.

Re: gd & fontpath (could not find/open font)

[Allin C. <cot...@wf...>]

On Thu, 19 Apr 2012, Mojca Miklavec wrote:

> On Wed, Apr 18, 2012 at 23:55, Allin Cottrell wrote:
>> On Wed, 18 Apr 2012, Mojca Miklavec wrote:
>>
>>> I'm still experiencing a problem with
>>>
>>>> set term png
>>>
>>>   Terminal type set to 'png'
>>>   Could not find/open font when opening font "arial", using internal
>>> non-scalable font
>>
>> Urgh. Why on earth are you using libgd (whose font handling is beyond
>> redemption) rather than the cairo-based PNG terminal?
>
> I'm not. I'm just annoyed by the error and I would like to fix it.
>
> Or - more precisely - macports builds gnuplot with gd2 by default, so
> "set term png" ends up with gd2 instead of cairo. On default gnuplot
> install this would use cairo when available.
>
> Maybe gnuplot on macports should be changed, so that gd2 would not be
> built by default (if that is the preference/recommendation of gnuplot
> developers)?

I don't have the status of a gnuplot developer, but as a gnuplot 
user and occasional patch-submitter I would strongly recommend 
treating libgd as "legacy" and concentrating on the cairo-based 
terminals.

> (Independent of that I would also like to know how font searching
> works in PostScript, but that has a lower priority.)

PostScript is a page description language, and as such it knows 
absolutely nothing about font-searching. It's happy to use any
compatible font that is fed to it by some other piece of software
that does know about font-searching.

The latest gnuplot has an "epscairo" terminal which presumably 
combines fontconfig font-searching (cairo and fontconfig being 
linked) with PostScript generation. This sounds very nice but I 
haven't yet experimented with it much myself.

Allin Cottrell

Re: gd & fontpath (could not find/open font)

[Mojca M. <moj...@gm...>]

On Wed, Apr 18, 2012 at 23:55, Allin Cottrell wrote:
> On Wed, 18 Apr 2012, Mojca Miklavec wrote:
>
>> I'm still experiencing a problem with
>>
>>> set term png
>>
>>   Terminal type set to 'png'
>>   Could not find/open font when opening font "arial", using internal
>> non-scalable font
>
> Urgh. Why on earth are you using libgd (whose font handling is beyond
> redemption) rather than the cairo-based PNG terminal?

I'm not. I'm just annoyed by the error and I would like to fix it.

Or - more precisely - macports builds gnuplot with gd2 by default, so
"set term png" ends up with gd2 instead of cairo. On default gnuplot
install this would use cairo when available.

Maybe gnuplot on macports should be changed, so that gd2 would not be
built by default (if that is the preference/recommendation of gnuplot
developers)?

(Independent of that I would also like to know how font searching
works in PostScript, but that has a lower priority.)

Mojca

Re: gd & fontpath (could not find/open font)

[Allin C. <cot...@wf...>]

On Wed, 18 Apr 2012, Mojca Miklavec wrote:

> I'm still experiencing a problem with
>
>> set term png
>    Terminal type set to 'png'
>    Could not find/open font when opening font "arial", using internal
> non-scalable font

Urgh. Why on earth are you using libgd (whose font handling is 
beyond redemption) rather than the cairo-based PNG terminal?

Allin Cottrell

Re: gd & fontpath (could not find/open font)

[<pl...@pi...>]

On 18/04/12 22:50, Mojca Miklavec wrote:
> Dear Gnuplot developers,
>
> I'm still experiencing a problem with
>
>> set term png
>      Terminal type set to 'png'
>      Could not find/open font when opening font "arial", using internal
> non-scalable font
>> show fontpath
>      fontpath is
>      system fontpath is "/System/Library/Fonts" "/Library/Fonts"
> "/Users/myusername/Library/Fonts"
>
> on Mac OS X. After some experiments I came to conclusion that the
> reason might have been Microsoft Office which installed the file
>      /Library/Fonts/Microsoft/Arial.ttf
> and removed
>      /Library/Fonts/Arial.ttf
> and I guess that GD2 is unable to search recursively in font
> directories. fc-list finds the font without problems and could be used
> to search for fonts, but last time Ethan had concerns about enabling
> FontConfig:
>
>> There seem to be bugs in the libgd function gdFTUseFontConfig(), in that
>> once you turn it on you can never turn it off again.  Unless that is fixed,
>> it means that gnuplot scripts using a mixture of self-supplied fonts and
>> fontconfig-installed fonts will fail.   That would break most of my
>> web tools, for example, which provide private font files.
>
> Assuming that font-config isn't/won't be enabled (it doesn't look very
> promissing that gd team will release a new version in any reasonable
> time), I have the following questions:
>
> 1.) What is (or should be) the exact algorithm to search for arial?
> How could I convince gnuplot (gd2) to automatically find Arial.ttf
> even when it resides in /Library/Fonts/Microsoft/Arial.ttf, without my
> manual intervention? How should I tell gnuplot (gd2) to search
> recursively through all the three font paths mentioned above?
>
> 2.) What is the difference between "fontpath" and "system fontpath"
> mentioned above?
>
> Thank you,
>      Mojca
>

I've been seeing something similar on x86 linux, but have not looked 
into it.

I build using cairo , so AFAIK that means no gdlib.

Peter.

gd & fontpath (could not find/open font)

[Mojca M. <moj...@gm...>]

Dear Gnuplot developers,

I'm still experiencing a problem with

> set term png
    Terminal type set to 'png'
    Could not find/open font when opening font "arial", using internal
non-scalable font
> show fontpath
    fontpath is
    system fontpath is "/System/Library/Fonts" "/Library/Fonts"
"/Users/myusername/Library/Fonts"

on Mac OS X. After some experiments I came to conclusion that the
reason might have been Microsoft Office which installed the file
    /Library/Fonts/Microsoft/Arial.ttf
and removed
    /Library/Fonts/Arial.ttf
and I guess that GD2 is unable to search recursively in font
directories. fc-list finds the font without problems and could be used
to search for fonts, but last time Ethan had concerns about enabling
FontConfig:

> There seem to be bugs in the libgd function gdFTUseFontConfig(), in that
> once you turn it on you can never turn it off again.  Unless that is fixed,
> it means that gnuplot scripts using a mixture of self-supplied fonts and
> fontconfig-installed fonts will fail.   That would break most of my
> web tools, for example, which provide private font files.

Assuming that font-config isn't/won't be enabled (it doesn't look very
promissing that gd team will release a new version in any reasonable
time), I have the following questions:

1.) What is (or should be) the exact algorithm to search for arial?
How could I convince gnuplot (gd2) to automatically find Arial.ttf
even when it resides in /Library/Fonts/Microsoft/Arial.ttf, without my
manual intervention? How should I tell gnuplot (gd2) to search
recursively through all the three font paths mentioned above?

2.) What is the difference between "fontpath" and "system fontpath"
mentioned above?

Thank you,
    Mojca

Re: Discussion: What to do if NaN appears in a non-coordinate field?

[sfeam (E. Merritt) <eam...@gm...>]

On Saturday, 31 March 2012, sfeam (Ethan Merritt) wrote:
> On Saturday, 31 March 2012, pl...@pi... wrote:
> >  > If NaN appears in the x, y, or z coordinate then the point
> >  > is rejected on input.
> > 
> > I thought when I brought this up a couple of months back the point I 
> > raised was that this was NOT happening when NaN was in first column. It 
> > was not being parsed as NaN but "NaN".
> 
> Please refresh my memory.
> I thought the issue there was that some runtime C libraries accept
> the string NaN as a valid numerical input (gcc for one) but others do
> not (MSVC for example). 

Ah, I found the earlier mail.  It all comes back to me now.
That was the start of my list of "Things to break in Gnuplot version 5".

The list so far:

1) Do not reassign column meanings in the middle of reading data from
   a file.  If whatever worked for the first records fails later, 
   that's an error.

2) Change the behavior of "set range [...] reverse to affect only 
   autoscaling.  This change is already in CVS since it fixes a bug
   and matches the suggested use given in the docs, although it
   doesn't match what the program was actually doing up until now.

3) Rationalize the matrix options for ascii and binary modes.
   Right now the defaults and keywords conflict in the two modes.

4) Distinguish between "splot with lines" and "splot with surface".
   I'm not sure what's the best way to do this, but at a minimum
   it should fix the bug that "unset surface" prevents plotting
   lines and points also.
   E.g.
   splot 'silver.dat' using 1:2:1 with points pt 5 ps 6 lc pal z
   unset surface
   replot   # Where's my plot???

5) The X11 terminal should work in true pixel coordinates rather
   than running from [0:4096] regardless of the window aspect ratio.

6) Change the interpretation of the alpha channel component in
   RGBA colors so that any existing 24-bit RGB triple works also if 
   interpreted as a 32-bit Alpha+RGB with leading component A=0.
   That would allow use of RGBA colors everywhere, but breaks all
   the existing RGB image code and "set style fill solid <alpha>".
   I don't like this much, but I haven't come up with a better way.
   I'm still hoping that inspiration strikes.

The idea is that these all fix long-standing problems or limitations,
but will change the behavior of existing scripts.  Since the project
policy is that we try to guarantee backwards compatibility within a 
major version series, this script breakage would only be acceptable
in connection with release of the next major version - 5.0

==
But none of the above has much to do with Bug #3513138.
We don't the program crashing on binary input, so we've got to
fix that one already for 4.6. 


	Ethan

Re: Discussion: What to do if NaN appears in a non-coordinate field?

[sfeam (E. Merritt) <eam...@gm...>]

On Saturday, 31 March 2012, pl...@pi... wrote:
>  > If NaN appears in the x, y, or z coordinate then the point
>  > is rejected on input.
> 
> I thought when I brought this up a couple of months back the point I 
> raised was that this was NOT happening when NaN was in first column. It 
> was not being parsed as NaN but "NaN".

Please refresh my memory.
I thought the issue there was that some runtime C libraries accept
the string NaN as a valid numerical input (gcc for one) but others do
not (MSVC for example).  That is unfortunate, but so far as I can see
is outside the range of things we can fix in gnuplot.
 
> I presume whatever action you decide upon, this will now get corrected. 
> So if anyone sees a problem with such a change (like this is a feature 
> not a bug) please shout now.

I think it's a bug, but the bug is outside of gnuplot.

But maybe I am mis-remembering the details of the problem you encountered.

	Ethan