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

Re: exposing cairo context from gnuplot

[johan47 <jo...@wo...>]

Hi,

I did not try it but it seems to be easy:
http://old.nabble.com/embedding-gnuplot-x-window-into-gtk-app-ts11670440.html#a11670440

cheers
-- 
View this message in context: http://old.nabble.com/exposing-cairo-context-from-gnuplot-tp25331048p26157813.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: df_readline() question

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

On Monday 02 November 2009 08:06:04 Philipp K. Janert wrote:
> 
> Comments at the end.
> 
> On Sunday 01 November 2009 10:38:04 pm Ethan Merritt (sfeam) wrote:
> > On Sunday 01 November 2009, Philipp K. Janert wrote:
> > > > Simple test: feed it a file junk.dat:
> > > >  1
> > > >  2
> > > >  junk
> > > >  3
> > > >  4
> > > >
> > > > gnuplot> plot 'junk.dat' with lp
> > > >               ^
> > > >          Bad data on line 3
> > > > gnuplot>
> > >
> > > Does plot do anything special here?
> > >
> > > I have a situation (stolen from the fit function),
> > > which basically says:
> > >
> > > while( (i = readline(...)) != EOF ) {
> > > 	...
> > >
> > > And now I feed it your data file and it does NOT
> > > return either DF_MISSING or DF_UNDEFINED!
> >
> > No, it returns 0.  But that's not EOF, so it should
> > be catchable.
> 
> No, it doesn't. It does not return anything for the
> line that contains "junk", when run with "using 1".
> 
> It does return -2 (DF_UNDEFINED) for the line
> with "junk", but only when run with "using ($1)".

Hence the entry on my TODO list that I quoted earlier.
You could evaluate the following simple-minded patch:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--- gnuplot/src/datafile.c	2009-10-10 11:43:30.000000000 -0700
+++ gnuplot-cvs/src/datafile.c	2009-11-02 08:53:58.000000000 -0800
@@ -1870,7 +1870,7 @@ df_readascii(double v[], int max)
 			/* line bad only if user explicitly asked
 			 * for this column */
 			if (df_no_use_specs)
-			    line_okay = 0;
+			    return DF_UNDEFINED;
 			break;      /* return or ignore depending on line_okay */
 		    }
 		}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%5




-- 
Ethan A Merritt

Re: df_readline() question

[Philipp K. J. <ja...@ie...>]

Comments at the end.

On Sunday 01 November 2009 10:38:04 pm Ethan Merritt (sfeam) wrote:
> On Sunday 01 November 2009, Philipp K. Janert wrote:
> > > Simple test: feed it a file junk.dat:
> > >  1
> > >  2
> > >  junk
> > >  3
> > >  4
> > >
> > > gnuplot> plot 'junk.dat' with lp
> > >               ^
> > >          Bad data on line 3
> > > gnuplot>
> >
> > Does plot do anything special here?
> >
> > I have a situation (stolen from the fit function),
> > which basically says:
> >
> > while( (i = readline(...)) != EOF ) {
> > 	...
> >
> > And now I feed it your data file and it does NOT
> > return either DF_MISSING or DF_UNDEFINED!
>
> No, it returns 0.  But that's not EOF, so it should
> be catchable.

No, it doesn't. It does not return anything for the
line that contains "junk", when run with "using 1".

It does return -2 (DF_UNDEFINED) for the line
with "junk", but only when run with "using ($1)".

Re: pngcairo performance on Windows

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

On Mon, 2 Nov 2009, Allin Cottrell wrote:

> It seems there is something not quite right with font-handling
> under the pngcairo terminal on Windows...
>
> The issue is that the extremities of text get clipped in some
> contexts. This is with CVS gnuplot built for win32 with
> pango/cairo support.

Sorry, I should have mentioned: I'm currently using pango 1.26.0
and cairo 1.8.8.  But the problem doesn't seem to be sensitive
to the versions of these DLLs -- I saw the same with pango 1.24.5.

Allin Cottrell

pngcairo performance on Windows

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

It seems there is something not quite right with font-handling
under the pngcairo terminal on Windows.  I suspect the problem
lies somewhere in the pango/cairo stack for Windows but I thought
I'd start here in case anyone has any ideas.

The issue is that the extremities of text get clipped in some
contexts. This is with CVS gnuplot built for win32 with
pango/cairo support.  I haven't seen this using pngcairo on Linux.

I suppose the first thing is to see if others can replicate the
problem.  I've put a simple test file and four examples of PNG
output (v8.png uses the verdana font at 8 points and v9 uses
verdana at 9 points; the others use the default font for
pngcairo).  These PNGs show bits of the letter 'Q' being clipped,
plus, in some cases, bits of the x-axis numerals missing.

Do others see this?

-- 
Allin Cottrell
Department of Economics
Wake Forest University

correction in the web help page

[Ellankavi <ell...@gm...>]

Hello,
             I was looking at the Gnuplot help page. The second line reads '
It this does not help your, you can have a look to gnuplot demos in the
"demo/" directory.'
I think the second line should read ' *If *this does not help *you*, you can
have a look *at* gnuplot demos in the "demo/" directory.'

Thanks


Regards,
-- 

Ellankavi

Re: df_readline() question

[Philipp K. J. <ja...@ie...>]

> >
> > However, this is not how it seems to work. If there are
> > fields in the data file that cannot be transformed to double,
> > df_readline simply skips the line.
>
> That's certainly not true in general, or it wouldn't be able
> to handle files containing text fields.
> Also imageNaN.dem wouldn't provide the output it does.
>
> Simple test: feed it a file junk.dat:
>  1
>  2
>  junk
>  3
>  4
>
> gnuplot> plot 'junk.dat' with lp
>               ^
>          Bad data on line 3
> gnuplot>

Does plot do anything special here?

I have a situation (stolen from the fit function),
which basically says:

while( (i = readline(...)) != EOF ) {
	...

And now I feed it your data file and it does NOT
return either DF_MISSING or DF_UNDEFINED!

So it strikes me as if it is not so much "more 
complicated", but rather "more simple" cases
where it does the unexpected.

>
>
> But you could be right that there are more complicated cases where
> it unexpectedly fails to return a useful error indicator, or fails
> to return good values from a line that happens to contain a bad one.
>
> > I would have expected it
> > to return DF_MISSING or DF_UNDEFINED. But that's not
> > what I observe.
>
> From my personal TODO file:
>  - Sort out handling of junk/NaN/Inf in datafile.c
>    + using 1:2:3 and using ($1):($2):($3) should fill in all the legal
> values before returning an error code due to a single bad value

Based on your comment here, I just discovered that
if I enclose the columns in parens [that is using ($1):($2)]
rather than [using 1:2], then df_readline() DOES indeed
return DF_MISSING and DF_UNDEFINED.

Hm. I guess I knew this, although takes out of context like
this, it is surprising.

>    + new return code DF_INFINITY for Inf
>    + set datafile missing {"keyword"} {NaN} {Inf}
>      would explicitly treat NaN or Inf as a missing value, rather than a
> bad one + blank line should be distinguishable from a non-blank line
> containing junk + consistent treatement of NaN (always set point->type ==
> UNDEFINED)
>

Building Gnuplot on OSX without aquaterm

[Jérémie L. <jer...@gm...>]

Hello,

I am currently trying to build gnuplot on Mac OS X, Snow Leopard.
Aquaterm is obsolete as it does not have a 64 bit version, and so I am
trying to NOT use it, but, apparently that is not planned. I have
removed aquaterm from my system (well, did "sudo port uninstall
aquaterm"), and I have tried using the configure options
--without-aqua or --disable-aqua to no avail, configure keep detecting
aqua. I have tried changing the symbol in config.h, but that hasn't
worked either. Whatever I do, it seems like I end up with a version of
gnuplot which works, but which always complains on startup that "aqua"
does not exist, and sets terminal to "unknown".

I am trying to completely avoid aquaterm, and instead use x11 as
default terminal (and yes, I've tried passing -DDEFAULTTERM=\"x11\" in
the flags, but that doesn't seem to work either). What am I doing
wrong?

Best regards,
Jeremie L.


(Kindly CC' me in any reply.)

Re: "set samples" with two lines

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

On Sun, 1 Nov 2009, Lutz Maibaum wrote:

> On Sun, Nov 1, 2009 at 8:42 AM, Allin Cottrell <cot...@wf...> wrote:
> > I'd like to plot two probability distribution curves together (in
> > a 2D graph), one a continuous pdf (e.g. Gaussian) and the other
> > discrete (e.g. Poisson or binomial).
> >
> > I can get a nice plot of each, separately, by setting a high
> > "samples" value for the continuous distribution and an appropriate
> > low value, corresponding to the number of integer values in the x-
> > or t-range, for the discrete one. But in a 2D plot there's only
> > one "samples" setting available.
>
> Maybe you could downsample inside the evaluation of the discrete
> function, something like this:
>
> rnd(x)=int(x+0.5)
> f(x)=exp(-x)
> g(x)=f(rnd(x))
> plot [0:5] f(x), g(x)
>
> Hope this helps,

Indeed, that's the solution.  Thanks!

Allin Cottrell

Re: "set samples" with two lines

[Lutz M. <lut...@gm...>]

On Sun, Nov 1, 2009 at 8:42 AM, Allin Cottrell <cot...@wf...> wrote:
> I'd like to plot two probability distribution curves together (in
> a 2D graph), one a continuous pdf (e.g. Gaussian) and the other
> discrete (e.g. Poisson or binomial).
>
> I can get a nice plot of each, separately, by setting a high
> "samples" value for the continuous distribution and an appropriate
> low value, corresponding to the number of integer values in the x-
> or t-range, for the discrete one. But in a 2D plot there's only
> one "samples" setting available.

Maybe you could downsample inside the evaluation of the discrete
function, something like this:

rnd(x)=int(x+0.5)
f(x)=exp(-x)
g(x)=f(rnd(x))
plot [0:5] f(x), g(x)

Hope this helps,

  Lutz

"set samples" with two lines

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

I'd be much obliged if anyone has a clever suggestion for solving
this problem:

I'd like to plot two probability distribution curves together (in
a 2D graph), one a continuous pdf (e.g. Gaussian) and the other
discrete (e.g. Poisson or binomial).

I can get a nice plot of each, separately, by setting a high
"samples" value for the continuous distribution and an appropriate
low value, corresponding to the number of integer values in the x-
or t-range, for the discrete one. But in a 2D plot there's only
one "samples" setting available.

I realize that instead of using a formula (as in the continuous
case), I could pre-compute a set of "data points" for the discrete
distribution and treat it as one would empirical data, but that's
not very convenient in context. (I'd like to be able to do this
programmatically, for many sets of distributions with various
parameters, so a formula-based solution is desirable.)

It would be nice if one could attach a "samples" parameter to a
line style specification, as in

set style line 1 samples 200 ...
set style line 2 samples 16 ...

but maybe I'm missing something that makes that unnecessary?

-- 
Allin Cottrell
Department of Economics
Wake Forest University

Re: pdfcairo: arrows in test

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

On Saturday 31 October 2009, Petr Mikulik wrote:
> I've noticed that in
> 
> 	set term pdfcairo
> 	set out 'x.pdf'
> 	test
> 	set out
> 
> the "west" arrow misses its line (xpdf, acroread), see the screenshot. The 
> output by means of pngcairo is correct.

I see the same thing.
But the same driver code is used for both pngcairo and pdfcairo, so where
does that leave us?

pdfcairo: arrows in test

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

I've noticed that in

	set term pdfcairo
	set out 'x.pdf'
	test
	set out

the "west" arrow misses its line (xpdf, acroread), see the screenshot. The 
output by means of pngcairo is correct.

---
PM

Re: gd.trm png_state.default_font

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

> Here's a transcript from a recent CVS:
> 
> 	Terminal type set to 'windows'
> 	gnuplot> set term png
> 	Terminal type set to 'png'
> 	Options are 'nocrop font arial 12 size 640,480 '
> 	gnuplot> set term windows
> 	Terminal type set to 'windows'
> 	Options are 'color noenhanced'
> 	gnuplot> set term png
> 	Terminal type set to 'png'
> 	gd.trm: caught initialization error
> 
> If I attempt to plot after the _first_ "set term png" gnuplot will crash,
> every time. If I wait until after the "caught initialization" error as
> above, plotting works fine -- valid PNG results and no crash. (There are
> certain combinations of options I can give to the PNG terminal to avoid
> this crash, but I haven't narrowed down exactly what they are.)

I've compiled gnuplot with static gd library and it works correctly.

---
PM

Re: gd.trm png_state.default_font

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

On Friday 30 October 2009 05:57:02 Tait wrote:
> 
> Here's a transcript from a recent CVS:
> 
> 	Terminal type set to 'windows'
> 	gnuplot> set term png
> 	Terminal type set to 'png'
> 	Options are 'nocrop font arial 12 size 640,480 '
> 	gnuplot> set term windows
> 	Terminal type set to 'windows'
> 	Options are 'color noenhanced'
> 	gnuplot> set term png
> 	Terminal type set to 'png'
> 	gd.trm: caught initialization error
> 	Options are 'nocrop font arial 12 size 640,480 '

> The initialization error seems to come from term/gd.trm when it discovers
> the default_font pointer is NULL. A FIXME comment just above this
> suggests it should "never happen," from which I surmise this isn't a
> known problem. If I force GD_NEED_LOCAL_FONT_POINTERS to be undefined,
> the gd.trm initialization error goes away and so does the crashing. I'm
> not sure what else, if anything, this breaks.
> 
> What does GD_NEED_LOCAL_FONT_POINTERS do? How are font pointers used 
> and what does it mean for one to be local?

This has to do with linking to a particular windows version of libgd.  
Apparently when building a shared libgd.dll for windows,
there are two different ways to define font pointers.  The conditional
flag GD_NEED_LOCAL_FONT_POINTERS in gnuplot is supposed to signal which
of these two methods the Windows *.dll is using.  My guess is that your
copy of libgd.dll uses one method, while your copy of gnuplot assumes
the other. But that's only a guess. I don't work with Windows, and I'm
hazy on the details.    

On the other hand, these pointers are only used if the terminal falls
back to using a default internal font.  Since you are requesting a specific
external font  "Arial,12", I don't immediately see why this error 
would trigger.  If you can trap a specific source code line number at
which the crash triggers, that might help.


-- 
Ethan A Merritt

gd.trm png_state.default_font

[Tait <gnu...@t4...>]

Here's a transcript from a recent CVS:

	Terminal type set to 'windows'
	gnuplot> set term png
	Terminal type set to 'png'
	Options are 'nocrop font arial 12 size 640,480 '
	gnuplot> set term windows
	Terminal type set to 'windows'
	Options are 'color noenhanced'
	gnuplot> set term png
	Terminal type set to 'png'
	gd.trm: caught initialization error
	Options are 'nocrop font arial 12 size 640,480 '
	gnuplot> set term windows
	Terminal type set to 'windows'
	Options are 'color noenhanced'
	gnuplot> set term png
	Terminal type set to 'png'
	Options are 'nocrop font arial 12 size 640,480 '
	gnuplot> set output 'sinx.png'
	gnuplot> plot sin(x)
	gnuplot> unset output
	gnuplot> set term windows enhanced
	Terminal type set to 'windows'
	Options are 'color enhanced'
	gnuplot>


If I attempt to plot after the _first_ "set term png" gnuplot will crash,
every time. If I wait until after the "caught initialization" error as
above, plotting works fine -- valid PNG results and no crash. (There are
certain combinations of options I can give to the PNG terminal to avoid
this crash, but I haven't narrowed down exactly what they are.)

The initialization error seems to come from term/gd.trm when it discovers
the default_font pointer is NULL. A FIXME comment just above this
suggests it should "never happen," from which I surmise this isn't a
known problem. If I force GD_NEED_LOCAL_FONT_POINTERS to be undefined,
the gd.trm initialization error goes away and so does the crashing. I'm
not sure what else, if anything, this breaks.

What does GD_NEED_LOCAL_FONT_POINTERS do? How are font pointers used 
and what does it mean for one to be local?

Tait

Re: non-interactive usage and color error messages

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

> But what happened to the impetus for the original complaint?
> I understood the problem to be that Octave triggers error messages
> that appear on the user's screen, even though the user has no way
> to do anything about it.  That does seem worth fixing if there is
> a well-defined set of harmless messages that are triggered.
> Of course, that fix may lie on the Octave side rather than the
> gnuplot side :-)  
> 
> I never got an answer to my question of whether gnuplot considered 
> itself to be in "interactive" mode while being driven from Octave.
> Does it?

It uses the popen("gnuplot", ...), thus gnuplot runs in non-interactive 
mode.

---
PM

Re: How to clear screen?

[Thomas S. <t.s...@fz...>]

maybe
system "clear"
?


RemyLeBeau wrote:
> 
> Is there any command in Gnuplot which works as 'cls' on DOS?
> I'm not talkig about 'clear'. I just want to erase the writen command
> lines, not the graphs.
> 

-- 
View this message in context: http://www.nabble.com/How-to-clear-screen--tp26103978p26113805.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: non-interactive usage and color error messages

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

On Wednesday 28 October 2009, Philipp K. Janert wrote:
> 
> You have a point, that works. I even convinced myself
> that I can do redirection of this form when I call gnuplot
> as a subprocess from Perl:
> 
> open GP, "| /usr/bin/gnuplot >& foo.log " or die "Fail: $!";
> $cmd = "set t png; set o 'foo.png'; plot 'foo' u 1:2 w lp\n";
> print GP $cmd;
> close GP;
> 
> Personally, I find it hacky, and would prefer a way for
> gnuplot to take care of its logging destination itself,
> without having to rely on shell redirection.
> 
> But I admit that the shell redirection works.

It also has the advantage that you can use this mechanism from
a cgi script (web server back end) independent of whether the
gnuplot scripts it calls know anything about the redirection.
I use this to create task-specific log files from the web server
even if the various distinct tasks call the same gnuplot script
somewhere along the way.

But what happened to the impetus for the original complaint?
I understood the problem to be that Octave triggers error messages
that appear on the user's screen, even though the user has no way
to do anything about it.  That does seem worth fixing if there is
a well-defined set of harmless messages that are triggered.
Of course, that fix may lie on the Octave side rather than the
gnuplot side :-)  

I never got an answer to my question of whether gnuplot considered 
itself to be in "interactive" mode while being driven from Octave.
Does it?

   Ethan

Re: non-interactive usage and color error messages

[Philipp K. J. <ja...@ie...>]

You have a point, that works. I even convinced myself
that I can do redirection of this form when I call gnuplot
as a subprocess from Perl:

open GP, "| /usr/bin/gnuplot >& foo.log " or die "Fail: $!";
$cmd = "set t png; set o 'foo.png'; plot 'foo' u 1:2 w lp\n";
print GP $cmd;
close GP;

Personally, I find it hacky, and would prefer a way for
gnuplot to take care of its logging destination itself,
without having to rely on shell redirection.

But I admit that the shell redirection works.

Best,

		Ph.


On Tuesday 27 October 2009 01:37:33 pm you wrote:
> Philipp K. Janert wrote:
> > I think it would be highly desirable to be able to
> > switch warnings on or off (or possibly even set
> > where they are sent).
> >
> > I often call gnuplot from scripts, producing many
> > graphs. In such situations, I would like to suppress
> > warnings - or maybe put them into a log file.
>
> IMHO, that's putting the cart before the horse.
>
> > So, if we could support something like this, that
> > would be great:
> >
> > set warnings         # directs to STDERR or terminal
>
> For all practical purposes, the terminal _is_ STDERR.
>
> > set warnings "file" # directs to file
>
> What's wrong with plain and simple redirection from the outside?
>
> 	gnuplot 2>file
>
> > unset warnings     # suppresses output
>
> 	gnuplot 2>/dev/null
>
> > Interactive terminals can then be "smart" to default
> > to direct warnings to STDERR.
>
> Except it isn't the terminal
>
> > But people who use gnuplot in the background have the flexibility to
> > do what they need.
>
> They have that flexibility already, without us having to anything!
>
> > In a similar spirit: would it be possible to include the
> > start-up greeting message in the list of messages
> > that can be redirected in this way?
>
> It already is.

How to clear screen?

[RemyLeBeau <kam...@ho...>]

Is there any command in Gnuplot which works as 'cls' on DOS?
I'm not talkig about 'clear'. I just want to erase the writen command lines,
not the graphs.
-- 
View this message in context: http://www.nabble.com/How-to-clear-screen--tp26103978p26103978.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: non-interactive usage and color error messages

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

Philipp K. Janert wrote:

> I think it would be highly desirable to be able to 
> switch warnings on or off (or possibly even set
> where they are sent).
> 
> I often call gnuplot from scripts, producing many
> graphs. In such situations, I would like to suppress
> warnings - or maybe put them into a log file.

IMHO, that's putting the cart before the horse.

> So, if we could support something like this, that
> would be great:
> 
> set warnings         # directs to STDERR or terminal

For all practical purposes, the terminal _is_ STDERR.

> set warnings "file" # directs to file

What's wrong with plain and simple redirection from the outside?

	gnuplot 2>file

> unset warnings     # suppresses output

	gnuplot 2>/dev/null

> Interactive terminals can then be "smart" to default
> to direct warnings to STDERR.

Except it isn't the terminal

> But people who use gnuplot in the background have the flexibility to
> do what they need.

They have that flexibility already, without us having to anything!

> In a similar spirit: would it be possible to include the
> start-up greeting message in the list of messages
> that can be redirected in this way?

It already is.

help for textcolor and linecolor

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

The following command set colour of line and text

  plot x with line linecolor 3
  set label 1 "HELLO" at 1,0 textcolor lt 3

but it seems they are not documented in
  help textcolor
which is the same as
  help linecolor

I think this change would be sufficient:

 Syntax:

       ... {linecolor | lc} {<colorspec> | <n>}
       ... {textcolor | tc} {<colorspec> | lt <n>}


---
PM

Re: non-interactive usage and color error messages

[Philipp K. J. <ja...@ie...>]

Sorry for stepping into this discussion late. 

I think it would be highly desirable to be able to 
switch warnings on or off (or possibly even set
where they are sent).

I often call gnuplot from scripts, producing many
graphs. In such situations, I would like to suppress
warnings - or maybe put them into a log file.

So, if we could support something like this, that
would be great:

set warnings         # directs to STDERR or terminal
set warnings "file" # directs to file
unset warnings     # suppresses output

Interactive terminals can then be "smart" to default
to direct warnings to STDERR. But people who use
gnuplot in the background have the flexibility to do
what they need.

In a similar spirit: would it be possible to include the
start-up greeting message in the list of messages
that can be redirected in this way?

Best,

		Ph.


On Monday 26 October 2009 11:53:47 am Ethan Merritt wrote:
> On Monday 26 October 2009 07:15:24 Petr Mikulik wrote:
> > > > > Every message that is generated by
> > > > >   fprintf(stderr,ERROR_NOTICE(foo))
> > > > > should be changed to use int_warn() instead.
> > > >
> > > > Good idea. These ERROR_NOTICEs are actually warnings only, not
> > > > errors. I've tried to patch this replacement in color.c and
> > > > graphics.c, it works fine.
> > >
> > > I am inclined to agree that warning "this terminal does not support..."
> > > is not very useful.  Maybe we should jusr remove these altogether.
>
> I have removed them, and changed the remaining ERROR_NOTICE instances
> to call int_warn() instead.  I did the same for the small number of
> warnings sent directly to stderr by term.c and axis.c.
>
> I leave it to you if you want to experiment with making int_warn()
> output condition on    if (interactive)  or some other controlling flag.

Re: non-interactive usage and color error messages

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

On Monday 26 October 2009 07:15:24 Petr Mikulik wrote:
> > > > Every message that is generated by 
> > > >   fprintf(stderr,ERROR_NOTICE(foo))
> > > > should be changed to use int_warn() instead.
> > > 
> > > Good idea. These ERROR_NOTICEs are actually warnings only, not errors. I've 
> > > tried to patch this replacement in color.c and graphics.c, it works fine.
> > 
> > I am inclined to agree that warning "this terminal does not support..."
> > is not very useful.  Maybe we should jusr remove these altogether.

I have removed them, and changed the remaining ERROR_NOTICE instances
to call int_warn() instead.  I did the same for the small number of warnings
sent directly to stderr by term.c and axis.c.

I leave it to you if you want to experiment with making int_warn() 
output condition on    if (interactive)  or some other controlling flag.

-- 
Ethan A Merritt