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

Re: where is doc for --host option ?

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

On Sat, 9 May 2009, Ethan Merritt (sfream) wrote:

> On Saturday 09 May 2009, Allin Cottrell wrote:
> > On Sat, 9 May 2009, Ethan Merritt (sfream) wrote:
> >
> > > On Friday 08 May 2009, Allin Cottrell wrote:
> > > > I think one benefit of using AC_PROG_CC is simply that it displays
> > > > help for such compiler-related options in response to configure
> > > > --help.
> > >
> > > It turns out we already have AC_PROG_CC in the gnuplot
> > > configure.in, yet it doesn't display any information about
> > > cross-compiling in the help message.  So scratch that theory.
> >
> > OK, it was a guess, and a wrong one.  My second attempt is that
> > the provision of the the "host and build" configuration info is a
> > libtool thing.  I tried the experiment of adding
> >
> > AC_PROG_LIBTOOL
> >
> > to gnuplot's configure.in and re-running ./prepare.  This gave the
> > error "required file `./ltmain.sh' not found".  So I copied
> > ltmain.sh into place and re-ran ./prepare.  I then got a
> > configure script that gave the help output, inter alia:
> >
> > System types:
> >   --build=BUILD     configure for building on BUILD [guessed]
> >   --host=HOST       cross-compile to build programs to run on HOST [BUILD]
>
> Huh.
> But I don't think we really want to require libtool, do we?
> We are not building any libraries.

Agreed.  It seems like overkill if no libraries are being built.

But it would be nice if one could build a libgnuplot one day ;-)

Allin Cottrell

Re: where is doc for --host option ?

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

On Sat, 9 May 2009, Ethan Merritt (sfream) wrote:

> On Friday 08 May 2009, Allin Cottrell wrote:
> > I think one benefit of using AC_PROG_CC is simply that it displays
> > help for such compiler-related options in response to configure
> > --help.
>
> It turns out we already have AC_PROG_CC in the gnuplot
> configure.in, yet it doesn't display any information about
> cross-compiling in the help message.  So scratch that theory.

OK, it was a guess, and a wrong one.  My second attempt is that
the provision of the the "host and build" configuration info is a
libtool thing.  I tried the experiment of adding

AC_PROG_LIBTOOL

to gnuplot's configure.in and re-running ./prepare.  This gave the
error "required file `./ltmain.sh' not found".  So I copied
ltmain.sh into place and re-ran ./prepare.  I then got a
configure script that gave the help output, inter alia:

System types:
  --build=BUILD     configure for building on BUILD [guessed]
  --host=HOST       cross-compile to build programs to run on HOST [BUILD]

FWIW.

Allin Cottrell

Re: where is doc for --host option ?

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

On Fri, 8 May 2009, Ethan Merritt wrote:

> On Friday 08 May 2009 15:00:15 Allin Cottrell wrote:
> > plotter does have a point.  I just checked the configure script
> > for my program, gretl, and part of the boiler-plate output from
> > ./configure --help is:
> >
> > System types:
> >   --build=BUILD     configure for building on BUILD [guessed]
> >   --host=HOST       cross-compile to build programs to run on HOST [BUILD]
> >
> > I certainly didn't add that explicitly; it's the output from some
> > standard autoconf macro (not sure which; maybe AC_PROG_CC?).
> > It's a bit surprising that it's not present in gnuplot's
> > "configure --help" output.
>
> I have not done cross-compilation, so take this with a grain of salt,
> but as I read the autoconf man pages, the idea is that if you use one of
> the cross-compilation macros like AC_PROG_CC in the ./configure script
> two things happen.  First, it tests for successful use of the CC=foo
> compiler flags.  Second, if the test succeeds it allows you to define
> conditional code options based on the knowledge that this is a
> cross-compiled build.
>
> So far as I know, the gnuplot source has no conditional code that would
> be triggered by AC_PROG_CC.  So I would have expected that setting
> CC to "--host=arm-linux" explicitly was sufficient; i.e. you wouldn't
> have to do it via the AC_PROG_CC macro.

I think one benefit of using AC_PROG_CC is simply that it displays
help for such compiler-related options in response to configure
--help.

Also -- though I'm on less firm ground here -- it's possible that
autoconf is in some ways cleverer than we think (although
sometimes it can seem inordinately stupid).  That is, using
AC_PROG_CC _may_ cause some things to work out correctly for
cross-compilation without requiring any intervention by the
writer of configure.in or Makefile.*  But, as with your comment,
apply a grain of salt.

Allin Cottrell

Re: where is doc for --host option ?

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

Ethan Merritt wrote:
> On Friday 08 May 2009 15:00:15 Allin Cottrell wrote:
>> On Fri, 8 May 2009, Ethan Merritt wrote:
>>
>>> On Friday 08 May 2009 10:34:51 pl...@pi... wrote:
>>>> HI,
>>>>
>>>> I'm trying to cross-compile gnuplot for arm.
>>>>
>>>> I set CC= and CXX= but it got thrown out with a message saying I should
>>>> use --host to cross-compile.
>>>>
>>>> The supposed "complete" list of options in ./configure --help and in
>>>> INSTALL does not mention it or cross-compiling at all
>>> The --host=arm-linux option is not something that is part of
>>> gnuplot, or gnuplot's autoconfigure scripts.  It is an option
>>> for the gcc compiler. So you would need to look in the gcc docs.
>>> I would guess the best source of help would be an arm-linux
>>> forum.
>> plotter does have a point.  I just checked the configure script
>> for my program, gretl, and part of the boiler-plate output from
>> ./configure --help is:
>>
>> System types:
>>   --build=BUILD     configure for building on BUILD [guessed]
>>   --host=HOST       cross-compile to build programs to run on HOST [BUILD]
>>
>> I certainly didn't add that explicitly; it's the output from some
>> standard autoconf macro (not sure which; maybe AC_PROG_CC?).
>> It's a bit surprising that it's not present in gnuplot's
>> "configure --help" output.
> 
> I have not done cross-compilation, so take this with a grain of salt,
> but as I read the autoconf man pages, the idea is that if you use one of
> the cross-compilation macros like AC_PROG_CC in the ./configure script
> two things happen.  First, it tests for successful use of the CC=foo
> compiler flags.  Second, if the test succeeds it allows you to define
> conditional code options based on the knowledge that this is a 
> cross-compiled build.
> 
> So far as I know, the gnuplot source has no conditional code that would
> be triggered by AC_PROG_CC.  So I would have expected that setting
> CC to "--host=arm-linux" explicitly was sufficient; i.e. you wouldn't
> have to do it via the AC_PROG_CC macro.  
> 
> But I haven't tried it.  If someone confirms a benefit of having the
> AC_PROG_CC in the configure script, that's certainly fine with me.
> 
> I have separately acknowledged that there should probably be a top
> level build target that builds only the gnuplot executable.
> Is there a standard name for such a target?
> 
> 
I would have thought that your suggested : make gnuplot  , was best.

as for the cross-compilation the correct setting for my toolchain was
--host=arm-unknown-linux-gnueabi

I posted it earlier but not from the right account for this list. Duh.

I now have a result from the cross-compiler:

$ file gnuplot
gnuplot: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically 
linked (uses shared libs), for GNU/Linux 2.6.29, not stripped

regards, Peter.

Re: where is doc for --host option ?

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

On Friday 08 May 2009 15:00:15 Allin Cottrell wrote:
> On Fri, 8 May 2009, Ethan Merritt wrote:
> 
> > On Friday 08 May 2009 10:34:51 pl...@pi... wrote:
> > > HI,
> > >
> > > I'm trying to cross-compile gnuplot for arm.
> > >
> > > I set CC= and CXX= but it got thrown out with a message saying I should
> > > use --host to cross-compile.
> > >
> > > The supposed "complete" list of options in ./configure --help and in
> > > INSTALL does not mention it or cross-compiling at all
> >
> > The --host=arm-linux option is not something that is part of
> > gnuplot, or gnuplot's autoconfigure scripts.  It is an option
> > for the gcc compiler. So you would need to look in the gcc docs.
> > I would guess the best source of help would be an arm-linux
> > forum.
> 
> plotter does have a point.  I just checked the configure script
> for my program, gretl, and part of the boiler-plate output from
> ./configure --help is:
> 
> System types:
>   --build=BUILD     configure for building on BUILD [guessed]
>   --host=HOST       cross-compile to build programs to run on HOST [BUILD]
> 
> I certainly didn't add that explicitly; it's the output from some
> standard autoconf macro (not sure which; maybe AC_PROG_CC?).
> It's a bit surprising that it's not present in gnuplot's
> "configure --help" output.

I have not done cross-compilation, so take this with a grain of salt,
but as I read the autoconf man pages, the idea is that if you use one of
the cross-compilation macros like AC_PROG_CC in the ./configure script
two things happen.  First, it tests for successful use of the CC=foo
compiler flags.  Second, if the test succeeds it allows you to define
conditional code options based on the knowledge that this is a 
cross-compiled build.

So far as I know, the gnuplot source has no conditional code that would
be triggered by AC_PROG_CC.  So I would have expected that setting
CC to "--host=arm-linux" explicitly was sufficient; i.e. you wouldn't
have to do it via the AC_PROG_CC macro.  

But I haven't tried it.  If someone confirms a benefit of having the
AC_PROG_CC in the configure script, that's certainly fine with me.

I have separately acknowledged that there should probably be a top
level build target that builds only the gnuplot executable.
Is there a standard name for such a target?

Re: where is doc for --host option ?

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

Allin Cottrell wrote:
> On Fri, 8 May 2009, Ethan Merritt wrote:
> 
>> On Friday 08 May 2009 10:34:51 pl...@pi... wrote:
>>> HI,
>>>
>>> I'm trying to cross-compile gnuplot for arm.
>>>
>>> I set CC= and CXX= but it got thrown out with a message saying I should
>>> use --host to cross-compile.
>>>
>>> The supposed "complete" list of options in ./configure --help and in
>>> INSTALL does not mention it or cross-compiling at all
>> The --host=arm-linux option is not something that is part of
>> gnuplot, or gnuplot's autoconfigure scripts.  It is an option
>> for the gcc compiler. So you would need to look in the gcc docs.
>> I would guess the best source of help would be an arm-linux
>> forum.
> 
> plotter does have a point.  I just checked the configure script
> for my program, gretl, and part of the boiler-plate output from
> ./configure --help is:
> 
> System types:
>   --build=BUILD     configure for building on BUILD [guessed]
>   --host=HOST       cross-compile to build programs to run on HOST [BUILD]
> 
> I certainly didn't add that explicitly; it's the output from some
> standard autoconf macro (not sure which; maybe AC_PROG_CC?).
> It's a bit surprising that it's not present in gnuplot's
> "configure --help" output.
> 
> Allin Cottrell
> 

yes, that's the sort of thing I was expecting to find. I spent ages 
pouring over the output thinking I must have missed it.

I was not expecting any ARM specific help just that one line explaining 
the usage.

regards, Peter.

Re: where is doc for --host option ?

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

On Fri, 8 May 2009, Ethan Merritt wrote:

> On Friday 08 May 2009 10:34:51 pl...@pi... wrote:
> > HI,
> >
> > I'm trying to cross-compile gnuplot for arm.
> >
> > I set CC= and CXX= but it got thrown out with a message saying I should
> > use --host to cross-compile.
> >
> > The supposed "complete" list of options in ./configure --help and in
> > INSTALL does not mention it or cross-compiling at all
>
> The --host=arm-linux option is not something that is part of
> gnuplot, or gnuplot's autoconfigure scripts.  It is an option
> for the gcc compiler. So you would need to look in the gcc docs.
> I would guess the best source of help would be an arm-linux
> forum.

plotter does have a point.  I just checked the configure script
for my program, gretl, and part of the boiler-plate output from
./configure --help is:

System types:
  --build=BUILD     configure for building on BUILD [guessed]
  --host=HOST       cross-compile to build programs to run on HOST [BUILD]

I certainly didn't add that explicitly; it's the output from some
standard autoconf macro (not sure which; maybe AC_PROG_CC?).
It's a bit surprising that it's not present in gnuplot's
"configure --help" output.

Allin Cottrell

Re: where is doc for --host option ?

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

On Friday 08 May 2009 10:34:51 pl...@pi... wrote:
> HI,
> 
> I'm trying to cross-compile gnuplot for arm.
> 
> I set CC= and CXX= but it got thrown out with a message saying I should 
> use --host to cross-compile.
> 
> The supposed "complete" list of options in ./configure --help and in 
> INSTALL does not mention it or cross-compiling at all

The --host=arm-linux option is not something that is part of gnuplot,
or gnuplot's autoconfigure scripts.  It is an option for the gcc compiler.
So you would need to look in the gcc docs.  I would guess the best
source of help would be an arm-linux forum.

> where's the doc ?
> 
> 
> TIA.


-- 
Ethan A Merritt

Re: demo: src/bf_test blocks cross-compilation

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

On Friday 08 May 2009 13:54:00 pl...@pi... wrote:
> Hi,
> 
> it seems that something is trying to execute during compilation. This is 
> a stopper on a cross build but probably should not be happening anyway.


> Making all in demo
         ^^^

If you only want the gnuplot executable to be built, you should not be
using "make all" as a target.  That builds the binaries, the documentation,
the latex tutorials, the demo collection, etc, etc, etc.

Try "./configure; cd src; make gnuplot"

> Maybe I'm missing it but I can't see a way to skip the demo being built.

You have a good point.  There should probably be a top level make target
that allows you to say "make gnuplot" or "make executable" or something
like that in the top level directory.

> thanks for any help, Peter.

demo: src/bf_test blocks cross-compilation

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

Hi,

it seems that something is trying to execute during compilation. This is 
a stopper on a cross build but probably should not be happening anyway.

Making all in demo
make[2]: Entering directory `/tmpd/arm/nfs/debs/tmpd/gnuplot/demo'
Creating binary data files
../src/bf_test: ../src/bf_test: cannot execute binary file
make[2]: *** [binary1] Error 126


Maybe I'm missing it but I can't see a way to skip the demo being built.

thanks for any help, Peter.

where is doc for --host option ?

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

HI,

I'm trying to cross-compile gnuplot for arm.

I set CC= and CXX= but it got thrown out with a message saying I should 
use --host to cross-compile.

The supposed "complete" list of options in ./configure --help and in 
INSTALL does not mention it or cross-compiling at all

where's the doc ?


TIA.

Re: [GD-DEVEL] Re: gd2 & fontconfig/freetype fail to find fonts on Mac OS X (macports)

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

On Thu, Apr 16, 2009 at 00:53, Manfred Schwarb wrote:
> On Mon, Apr 13, 2009 at 5:56 PM, Ethan Merritt wrote:
>>
>> This looks very promising, and I think we should
>> use it to try both the old (GDFONTPATH) and new (fontconfig) mechanisms
>> when looking for a user-specified font.
>
> Sorry to spoil the party -
>
> Does this mean, not even the ugly work-around to set
> GDFONTPATH=/dev/null to get the builtin fixed fonts of libgd
> will work any more?
>
> I really would like to have a possibility to use the builtin fonts.
>
> The simplest thing would be to treat the libgd font names special?
>
> I.e. if the the font name is one of
> "tiny","small","medium","large","giant" treat them special,
> skip font lookup and directly use the respective libgd builtin fonts?
>
> I.e. the use would then be as
> ...
> set term png font "small"
> ...

Hello,

Enabling fontconfig search by deafault doesn't mean that one should
disable the built-in fonts. At least in my opinion it still makes
sense to allow using them without having to issue an error. The
keywords "tiny" "small" etc. to trigger built in fonts make perfect
sense to me and you don't even need the work-around. When one sets
    font ",15"
this could mean "use true type using fontconfig" while small could
trigger the built-in fonts.

(I didn't have to use the ugly workaround to set GDFONTPATH to
/dev/null since it didn't work anyway and I always get the built-in
fonts. Because neither fonts nor graphics have been anti-aliased and
because setting "arial" didn't work out-of-the-box, I always thought
that I was unable to compile GD library support properly.)

Mojca

Re: [GD-DEVEL] Re: gd2 & fontconfig/freetype fail to find fonts on Mac OS X (macports)

[Manfred S. <man...@gm...>]

> On Monday 13 April 2009 09:10:23 Pierre Joye wrote:
> > On Mon, Apr 13, 2009 at 5:56 PM, Ethan Merritt
> <merritt@u.washington.edu> wrote:
> >> Is it true that libgd now looks for fontconfig?
> > no, only if you tell it to do so.
> 
> I now see that Mojca has pointed out the function gdFTUseFontConfig(),
> which I did not know about.   This looks very promising, and I think we
> should
> use it to try both the old (GDFONTPATH) and new (fontconfig) mechanisms
> when
> looking for a user-specified font.
> 
> However, I coded up a quick test patch for gnuplot's gd driver and ran
> into
> the following problem.  Perhaps I am doing something wrong:
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>         /* First try the old GDFONTPATH mechanism for locating fonts */
>         gdFTUseFontConfig(0);
>         err = gdImageStringFT(NULL, &brect[0], 0,
>                 png_state.ttffont, (double)png_state.default_ttfsize,
>                 0.0, 0, 0, "test");
> 
>         /* If that didn't work, try again using fontconfig mechanism */
>         if (err && gdFTUseFontConfig(1)) {
>             err = gdImageStringFT(NULL, &brect[0], 0,
>                 png_state.ttffont, (double)png_state.default_ttfsize,
>                 0.0, 0, 0, "test");
>             fprintf(stderr,"fontconfig %s font %s\n",
>                 err ? "did not find" : "found",
>                 png_state.ttffont);
>         }
> 
>         /* If we still haven't found the font, punt to the internal
> non-TTF default set */
>         if (err) {
>             fprintf(stderr,"%s when opening font \"%s\", using internal
> non-scalable font\n",
>                         err, png_state.ttffont);
> 	}
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> 


Sorry to spoil the party -

Does this mean, not even the ugly work-around to set 
GDFONTPATH=/dev/null to get the builtin fixed fonts of libgd
will work any more?

I really would like to have a possibility to use the builtin fonts.

The simplest thing would be to treat the libgd font names special?

I.e. if the the font name is one of 
"tiny","small","medium","large","giant" treat them special,
skip font lookup and directly use the respective libgd builtin fonts?

I.e. the use would then be as
...
set term png font "small"
...


Would be great!

Cheers,
Manfred

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

Re: Error messages from "set term png font ..."

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

On Tue, Apr 14, 2009 at 01:00, Ethan Merritt wrote:
> On Monday 13 April 2009 14:20:19 Mojca Miklavec wrote:
>>
>> May I suggest at least something not-so-related? The message
>>    Could not find/open font when opening font "arial", using internal
>> non-scalable font
>> is a bit annoying, pops up everywhere (at the moment) and doesn't tell
>> anything useful to the user. I suggest rewriting the message and
>> stating that one could try to set GDFONTPATH manually. (It took me a
>> while to figure that out.)
>
> We could print an additional message if you like.
> Would that be preferable, or would it be even more annoying?

My opinion doesn't count too much, but I would prefer seing any
pointer that would help me sort the issue. The one you suggest is OK
or there could also be "help term png font" or some other
straightformard pointer.

The original message is annoying enough by itself. If I (would) know
how to get rid of it, that's definitely less annoying at the end. So
better more info than less noise.

>> PS: I agree with the one who mentioned it that there also needs to be
>> a way to request the default (build-in) font even if arial starts
>> working out-of-the-box.
>
> Why?  (just curious)

There might be different reasons:
- One may prefer to have no font antialiasing. I don't know the exact
reason why, but antialiased fonts don't work too well in console for
example. For some special type of usage it might make sense. (Btw: Is
there any way to enable antialiasing of lines in png terminal? I see
that pngcairo does it by default.)
- One might have a big collection of plots and wants to add a few new
ones while preserving the original appearance.

I agree that enabling arial or any truetype font by default is better
than enabling the pixel font, but since it doesn't cost too much
effort to preserve the ability to use the default one, I would vote
for some option that would enable one to "go back".

Mojca

Re: canvas terminal

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

On Tuesday 14 April 2009 05:22:53 Petr Mikulik wrote:
> I have tried the "canvas demo" web page
> 	http://gnuplot.sourceforge.net/demo_canvas/
> 
> by Firefox and Seamonkey. However, only that one "Example of mouse tracking, 
> zoom/unzoom" on this main page is mouseable while others e.g.
> 	http://gnuplot.sourceforge.net/demo_canvas/simple.html
> 
> are static -- they look like a png bitmap. Shouldn't they be mouseable or 
> dynamic as well?

The terminal currently runs in 2 different modes.
It can produce an HTML document containing a single, mouseable, plot.
Or it can produce only a *.js file suitable for embedding in an
externally produced HTML document.   But in that case you have to set up
the mousing yourself at the time of generating the HTML document.
I did that by hand for the top level page of the demo set, but
the webify script is not smart enough to do that automatically for all
the individual demos.

There is a further complication that I haven't had time to sort out.
Help would be welcome.   If there are multiple plots on the same web
page,  how can the mousing code correctly identify which one is
"active" and generate the corresponding coordinate space.
It should be possible to do this based on the id tag of the individual
canvas elements, but for whatever reason I had trouble getting that to
work.

> Further, it there is "reset" written on the bottom of every page, including 
> demos for png and svg. Could webify.pl not print this line?

Yeah, probably.
There's a bigger annoyance, though.  The script always generates one extra
reference to a non-existent plot at the end of each demo.  This is true
for the png and svg versions as well.   The script would need to be 
rewritten to avoid this.  Again, help would be welcome.

 
> Looking for the canvas docs, I have found that "help canvas" shows 
> "Subtopics available for canvas: size" but it gives the same text as "help 
> canvas".

Right.  We already had help for "canvas", meaning the terminal-independent
plot area. 

> Moreover, there is a clash in "help canvas" (drawing area) vs "help term 
> canvas" (terminal). As it works "help png", "help postscript", etc., I think 
> "help canvas" should be equal to "help term canvas". Then "help canvas" 
> should be merged to "help size" or be renamed "help drawing canvas"...(?)

So you propose to change the terminology everywhere so that the plot area
is called something other than "the canvas"?


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

canvas terminal

[Petr M. <mi...@ph...>]

I have tried the "canvas demo" web page
	http://gnuplot.sourceforge.net/demo_canvas/

by Firefox and Seamonkey. However, only that one "Example of mouse tracking, 
zoom/unzoom" on this main page is mouseable while others e.g.
	http://gnuplot.sourceforge.net/demo_canvas/simple.html

are static -- they look like a png bitmap. Shouldn't they be mouseable or 
dynamic as well?

Further, it there is "reset" written on the bottom of every page, including 
demos for png and svg. Could webify.pl not print this line?

Looking for the canvas docs, I have found that "help canvas" shows 
"Subtopics available for canvas: size" but it gives the same text as "help 
canvas".

Moreover, there is a clash in "help canvas" (drawing area) vs "help term 
canvas" (terminal). As it works "help png", "help postscript", etc., I think 
"help canvas" should be equal to "help term canvas". Then "help canvas" 
should be merged to "help size" or be renamed "help drawing canvas"...(?)

---
PM

Re: gnuplot manual misprint (no.28)

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

On Monday 13 April 2009 16:43:54 Shigeharu TAKENO wrote:
> shige 04/14 2009
> ----------------
> 
> In docs/gnuplot.doc of current CVS version
> 
>  RCS $Id: gnuplot.doc,v 1.566 2009/04/12 22:27:04 sfeam Exp $
> 
> and term/canvas.trm
> 
>  $Id: canvas.trm,v 1.21 2009/04/06 03:43:45 sfeam Exp $
> 
> I found some points that seem to be misprints.
> 
> I send the unified diff file for them.
> 
> ----- From here (gnuplot.doc) -----
> --- gnuplot.doc.ORG	2009-04-14 08:30:21.000000000 +0900
> +++ gnuplot.doc	2009-04-14 08:37:03.000000000 +0900
> @@ -254,7 +254,7 @@
>   version 4.0.
>  
>  3 New plot elements
> -=circles
> +=circle
>  =ellipse
>  =polygon
>   The `set object` command can now be used to define fixed circles, ellipses, and

That one is intentional.
The user may ask "help circles", and we should print the help text even
though the object type is "circle".
This is in particular true because there is a command "plot ... with circles"

For the other typos, thank you very much.

	Ethan





> @@ -5598,10 +5598,10 @@
>   be drawn, even if they would normally be obscured by other plot elements.
>  
>   Similarly, the keyword `nocontours` will turn off contouring for an individual
> - plot even if the global property "set contour" is active.
> + plot even if the global property `set contour` is active.
>  
> - Similarly, the keyword `nocontours` will turn off the 3D surface for an
> - individual plot even if the global property "set surface" is active.
> + Similarly, the keyword `nosurface` will turn off the 3D surface for an
> + individual plot even if the global property `set surface` is active.
>  
>   The keywords may be abbreviated as indicated.
>  
> @@ -10024,7 +10024,7 @@
>   appropriate style, data or function.
>  
>   `unset surface` will cause `splot` to not draw points or lines corresponding
> - to any of the function or data file points.  If you want to turn of the surface
> + to any of the function or data file points.  If you want to turn off the surface
>   for an individual function or data file while leaving the others active, use
>   the `nosurface` keyword in the `splot` command.  Contours may still be drawn on
>   the surface, depending on the `set contour` option.  The combination
> @@ -10458,6 +10458,7 @@
>  ?set view equal_axes
>  ?set view equal
>  ?view equal_axes
> +?view equal
>   The command `set view equal xy` forces the unit length of the x and y axes
>   to be on the same scale, and chooses that scale so that the plot will fit on
>   the page.  The command `set view equal xyz` additionally sets the z axis 
> ----- To here (gnuplot.doc) -----
> ----- From here (canvas.trm) -----
> --- canvas.trm.ORG	2009-04-14 08:32:40.000000000 +0900
> +++ canvas.trm	2009-04-14 08:33:05.000000000 +0900
> @@ -1128,7 +1128,7 @@
>  "       <html>",
>  "       <head>",
>  "           <script src=\"canvastext.js\"></script>",
> -"           <script src=\"canvas_common.js\"></script>",
> +"           <script src=\"gnuplot_common.js\"></script>",
>  "       </head>",
>  "       <body onload=\"fishplot();\">",
>  "           <script src=\"fishplot.js\"></script>",
> ----- To here (canvas.trm) -----
> 
> +========================================================+
>  Shigeharu TAKENO     NIigata Institute of Technology
>                        kashiwazaki,Niigata 945-1195 JAPAN
>  sh...@ie...   TEL(&FAX): +81-257-22-8161
> +========================================================+
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

gnuplot manual misprint (no.28)

[Shigeharu T. <sh...@ie...>]

shige 04/14 2009
----------------

In docs/gnuplot.doc of current CVS version

 RCS $Id: gnuplot.doc,v 1.566 2009/04/12 22:27:04 sfeam Exp $

and term/canvas.trm

 $Id: canvas.trm,v 1.21 2009/04/06 03:43:45 sfeam Exp $

I found some points that seem to be misprints.

I send the unified diff file for them.

----- From here (gnuplot.doc) -----
--- gnuplot.doc.ORG	2009-04-14 08:30:21.000000000 +0900
+++ gnuplot.doc	2009-04-14 08:37:03.000000000 +0900
@@ -254,7 +254,7 @@
  version 4.0.
 
 3 New plot elements
-=circles
+=circle
 =ellipse
 =polygon
  The `set object` command can now be used to define fixed circles, ellipses, and
@@ -5598,10 +5598,10 @@
  be drawn, even if they would normally be obscured by other plot elements.
 
  Similarly, the keyword `nocontours` will turn off contouring for an individual
- plot even if the global property "set contour" is active.
+ plot even if the global property `set contour` is active.
 
- Similarly, the keyword `nocontours` will turn off the 3D surface for an
- individual plot even if the global property "set surface" is active.
+ Similarly, the keyword `nosurface` will turn off the 3D surface for an
+ individual plot even if the global property `set surface` is active.
 
  The keywords may be abbreviated as indicated.
 
@@ -10024,7 +10024,7 @@
  appropriate style, data or function.
 
  `unset surface` will cause `splot` to not draw points or lines corresponding
- to any of the function or data file points.  If you want to turn of the surface
+ to any of the function or data file points.  If you want to turn off the surface
  for an individual function or data file while leaving the others active, use
  the `nosurface` keyword in the `splot` command.  Contours may still be drawn on
  the surface, depending on the `set contour` option.  The combination
@@ -10458,6 +10458,7 @@
 ?set view equal_axes
 ?set view equal
 ?view equal_axes
+?view equal
  The command `set view equal xy` forces the unit length of the x and y axes
  to be on the same scale, and chooses that scale so that the plot will fit on
  the page.  The command `set view equal xyz` additionally sets the z axis 
----- To here (gnuplot.doc) -----
----- From here (canvas.trm) -----
--- canvas.trm.ORG	2009-04-14 08:32:40.000000000 +0900
+++ canvas.trm	2009-04-14 08:33:05.000000000 +0900
@@ -1128,7 +1128,7 @@
 "       <html>",
 "       <head>",
 "           <script src=\"canvastext.js\"></script>",
-"           <script src=\"canvas_common.js\"></script>",
+"           <script src=\"gnuplot_common.js\"></script>",
 "       </head>",
 "       <body onload=\"fishplot();\">",
 "           <script src=\"fishplot.js\"></script>",
----- To here (canvas.trm) -----

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Error messages from "set term png font ..."

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

On Monday 13 April 2009 14:20:19 Mojca Miklavec wrote:
> 
> May I suggest at least something not-so-related? The message
>    Could not find/open font when opening font "arial", using internal
> non-scalable font
> is a bit annoying, pops up everywhere (at the moment) and doesn't tell
> anything useful to the user. I suggest rewriting the message and
> stating that one could try to set GDFONTPATH manually. (It took me a
> while to figure that out.)

We could print an additional message if you like.
Would that be preferable, or would it be even more annoying?
Maybe:

  Could not find/open font when opening font "arial", 
  using internal non-scalable font.
  See  GDFONTPATH discussion in "help set term png" 

> (Just saying that "arial" could not be found is far from helpful and
> it's particularly annoying for newbie users since it pops up every
> time "by default" ... well, at least annoying enough that I was ready
> to learn some gd basics :) :)

That part of the message is generated by libgd itself, not by gnuplot.
We just pass it on to the user by saying something like
   if (error) fprintf(stderr, "%s", error)

> PS: I agree with the one who mentioned it that there also needs to be
> a way to request the default (build-in) font even if arial starts
> working out-of-the-box.

Why?  (just curious)

-- 
Ethan A Merritt

Re: gnuplot 4.2 fails to run gretl files

[snvv101 <sn...@gm...>]

On Tuesday 14 April 2009 01:36:12 Ethan Merritt wrote:

> Which suggests that gretl is running in a different environment
> and therefore doesn't see your GDFONTPATH.

I am not sure what do you mean by this and thus I can not test the issue.

Re: gnuplot 4.2 fails to run gretl files

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

On Mon, 13 Apr 2009, Ethan Merritt quoted:

> > Could not find/open font when opening font "arial", using internal non-
> > scalable font
>
> Which suggests that gretl is running in a different environment
> and therefore doesn't see your GDFONTPATH.

Yes, must be.

> > Then I run gretl from command line to get more error messages and here is what
> > I have:
> > gnuplot: using libgd png driver
> > stderr: 'Could not find/open font when opening font "arial", using internal
> > non-scalable font
> > '
> > gretl_errmsg: 'Could not find/open font when opening font "arial", using
> > internal non-scalable font
> > '
> > Failed command: 'gnuplot "/home/snvv101/.gretl/gpttmp.hIR18b"'
> >
> > Finally, I do believe this should be a libgd problem?
>
> I don't think so.  Your first test demonstrates that libgd is able to
> find the font correctly.  Does gretl maybe scrub its environment on entry?

No, gretl respects the environment as it finds it.

Allin Cottrell

Re: gnuplot 4.2 fails to run gretl files

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

On Tue, 14 Apr 2009, snvv101 wrote:

> Some more findings...
>
> What i did:
> export GDFONTPATH="/usr/share/fonts/truetype/msttcorefonts"
> gnuplot> set term png font arial 12
>
> gnuplot> set term png font arial 12
> Terminal type set to 'png'
> Options are 'nocrop font arial 12 '
>
> When I try to create a graph gretl gives:
> Could not find/open font when opening font "arial", using internal non-
> scalable font

Ensure that GDFONTPATH is in the environment when gretl is started
up -- that can't be the case, or you wouldn't get that libgd error
message.

Allin Cottrell

Re: gnuplot 4.2 fails to run gretl files

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

> Hello,
> Some more findings...
> 
> What i did:
> export GDFONTPATH="/usr/share/fonts/truetype/msttcorefonts" 
> gnuplot> set term png font arial 12
> 
> gnuplot> set term png font arial 12
> Terminal type set to 'png'
> Options are 'nocrop font arial 12 '

OK, so it works fine in gnuplot.
That seems to indicate that both gnuplot and libgd are working fine.

> When I try to create a graph gretl gives:
> Could not find/open font when opening font "arial", using internal non-
> scalable font

Which suggests that gretl is running in a different environment
and therefore doesn't see your GDFONTPATH.
 
> Then I run gretl from command line to get more error messages and here is what 
> I have:
> gnuplot: using libgd png driver
> stderr: 'Could not find/open font when opening font "arial", using internal 
> non-scalable font
> '
> gretl_errmsg: 'Could not find/open font when opening font "arial", using 
> internal non-scalable font
> '
> Failed command: 'gnuplot "/home/snvv101/.gretl/gpttmp.hIR18b"'
> 
> Finally, I do believe this should be a libgd problem?

I don't think so.  Your first test demonstrates that libgd is able to
find the font correctly.  Does gretl maybe scrub its environment on entry?


 
> Any suggestion is welcome.
> 
> Thank you.
> snvv

-- 
Ethan A Merritt

Re: gnuplot 4.2 fails to run gretl files

[snvv101 <sn...@gm...>]

On Monday 13 April 2009 02:41:42 Ethan Merritt wrote:
> On Sunday 12 April 2009, Allin Cottrell wrote:
> > On Sun, 12 Apr 2009, snvv wrote:
> > > Problem:
> > > When I try to create a graph it fails
> > >
> > > Operating System:
> > > Operating System Debian sid
> > > gretl ver. 1.8.0
> > > gnuplot ver 4.2 patchlevel 5 ...
> > >
> > > gnuplot: using libgd png driver
> > > stderr: 'Could not find/open font when opening font "arial", using
> > > internal non-scalable font
> > > ' ...
> > > Additional comments
> > > The first line of the created gnuplot file is:
> > >
> > > set term png truecolor small size 680,400
> >
> > This is primarily a bug with the libgd installation, which can't
> > find the arial font.
>
> I wouldn't call that a libgd installation problem.
>
> Gnuplot needs to try some default truetype font; it happens to use Arial
> because that is very common.   The error message is telling you that
> either (a) you don't have Arial installed at all and should pick a
> different defaultfont (environmental variable GNUPLOT_DEFAULT_GDFONT)
> or (b) you do have Arial installed but in a directory that is not part of
> the font search path (environmental variable GDFONTPATH).
>
> libgd can be correctly installed, but still you need to specify where
> your fonts are located.
>
> > However, I think there's a case for saying
> > there's a minor gnuplot bug here: given the terminal setting
> > quoted above, why is gnuplot giving the error message about arial?
> > Isn't "small" a directive to use the libgd internal font?
>
> There was a long thread arguing this point on the usenet group
> recently.   People have old scripts that use the keyword "small".
> When run with a modern gnuplot that supports scalable fonts,
> (i.e. anything since the version 4.0) what should happen by default?
> My perspective is that over the years there were many
> queries/complaints about enhanced text or text rotation not working
> in PNG, caused by a failure to specify a scalable font.  This was
> solved by having gd.trm try to find a scalable font by default, using
> a couple of common font names.  Yes, this makes it harder to explicitly
> request a built-in non-scalable font, but the recent usenet query was
> honestly the first time I've ever seen such a request.
>
> > (Off topic here, but gretl -- a third party caller of gnuplot --
> > is getting confused by that error message; it doesn't expect it
> > because previous gnuplot versions didn't emit it.)
>
> I don't think there has ever been an expectation that error messages
> will not change.  Some of them are emitted by one of the support
> libraries, not by the gnuplot code per se.

Hello,
Some more findings...

What i did:
export GDFONTPATH="/usr/share/fonts/truetype/msttcorefonts" 
gnuplot> set term png font arial 12

gnuplot> set term png font arial 12
Terminal type set to 'png'
Options are 'nocrop font arial 12 '

When I try to create a graph gretl gives:
Could not find/open font when opening font "arial", using internal non-
scalable font

Then I run gretl from command line to get more error messages and here is what 
I have:
gnuplot: using libgd png driver
stderr: 'Could not find/open font when opening font "arial", using internal 
non-scalable font
'
gretl_errmsg: 'Could not find/open font when opening font "arial", using 
internal non-scalable font
'
Failed command: 'gnuplot "/home/snvv101/.gretl/gpttmp.hIR18b"'

Finally, I do believe this should be a libgd problem?

Any suggestion is welcome.

Thank you.
snvv

Re: [GD-DEVEL] Re: gd2 & fontconfig/freetype fail to find fonts on Mac OS X (macports)

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

On Mon, Apr 13, 2009 at 22:46, Ethan Merritt wrote:
> On Monday 13 April 2009 13:21:40 you wrote:
>> What happens if you change the source code in gdft.c inside gd
>> library?
>
> Yes, that works.
> But even if the next libgd release contains this fix, it will take some
> time to propagate to everyone's installed machines.

Though it will take some time before gnuplot propagates to everyone's
machine as well :(

I don't know how you handle dependencies on new versions of libraries,
but I would suggest to fix as soon as the fixed version of gd comes
out. It will take a while before next gnuplot version/patchset comes
out anyway and those who work with cvs version should know how to help
themselves (not always true, but people using cvs version should be
prepared for occasional problems at least).

If I understand it properly, one is unable to use fonts with full path
names if you call the buggy gdFTUseFontConfig at least once? (The bad
news is that this used to be the only method to use any font in past.)

May I suggest at least something not-so-related? The message
   Could not find/open font when opening font "arial", using internal
non-scalable font
is a bit annoying, pops up everywhere (at the moment) and doesn't tell
anything useful to the user. I suggest rewriting the message and
stating that one could try to set GDFONTPATH manually. (It took me a
while to figure that out.)

On the other hand, gnuplot could also provide feedback like "GD
library has no fontconfig support, you can set GDFONTPATH manually.
Using internal non-scalable font."

(Just saying that "arial" could not be found is far from helpful and
it's particularly annoying for newbie users since it pops up every
time "by default" ... well, at least annoying enough that I was ready
to learn some gd basics :) :)

Mojca

PS: I agree with the one who mentioned it that there also needs to be
a way to request the default (build-in) font even if arial starts
working out-of-the-box.