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

Re: default: x11 or wxt?

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

On Friday 01 September 2006 03:43 am, Richard Henwood wrote:
> I installed wxt out of curiosity.
> These are my general, initial impressions and thoughts:

> I didn't work 'out of the box' for me - fonts are tiny.

I too had font problems. Upgrading the support libraries and installing
fontconfig made it work.  But a user guide to fonts would be a nice
addition to the documentation.  Unfortunately, I myself only definitively
understand fonts for PostScript and libgd.  The other terminal types I
struggle with just as much as the next guy.

> It is slower than x11, am I going to run into 'out of memory' problems as
> well?

Petr has been saying this also, but to me the response seems snappy
enough.  It may be slower than x11, but on my machines the difference
is not enough to matter.  It could again be a question partly of
newer support libraries, and of course how fast is the CPU it runs
on.

> WxWidgets + Cairo + Pango, that's more dependency to maintain.
> I think on balance I'll be using X11 because of my particular font problem,
> and wxt doesn't give anything unique.

Those were my initial concerns, back when Timothee Lecomte first 
introduced the wxt driver.  But once I had it up and working (one operating
system version later) it has become my default standard.  Particularly
because the fonts work so well (UTF-8 and other multibyte fonts
"just work", whereas the mechanism on x11 is quite cumbersome).

> Is wxt driven by the svg term?

The two terminals have nothing in common that I can think of,
other than my not understanding font support on either of therm :-) 

> Does gnuplot support alpha channel?

Up until now it only supports an alpha channel in the sense that
several terminal drivers (png jpeg gif) allow you to specify a
transparent background.

Adding additional support for transparency is high on my list
of post-4.2 projects.  You can see a demo of preliminary support
for transparent fill areas on
    http://skuld.bmsc.washington.edu/people/merritt/gnuplot/

So far I have it working fully for wxt, and partially for svg,
png, jpeg, and pdf.  I will need to tap other people's expertise 
in order to extend support to additional terminal types.

This isn't quite the same as general support for an alpha
channel, though it could probably be extended to include other
plot elements besides filled areas.  In particular it would seem
an obvious extension to the image and rgbimage plot styles.

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

Re: tiny fonts with wxt term

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

Richard Henwood wrote:

> Anyway... here you go:
> 
> http://www2.warwick.ac.uk/cll/skills/eportfolio/students/eportfoliodirectory/current/phrfaj/gnuplotproblems/gnuplotfontproblem2.png

Thanks.  Well, clearly the font is tiny.  Furthermore, there is something interesting about the polygon compared to what I see in the x11 "test".  In your screenshot the polygon looks nice and symmetric.  In the x11 test on my screen (see below) I'm seeing an asymmetric polygon.  The aspect ration for the two screen shots is about the same.  I can understand that the lines might be a different thickness and that sort of thing.  But why should the aspect ration of the polygon be so different?


>>Richard, we've just had a discussion about wxt/x11.  You chose wxt because
>>why?  It was the default?  Just curious.
>>
> 
> 
> Once I got it compiled in, it was the default so it sorta' chose me!
> I'll follow up to 'default: x11 or wxt' thread.

OK, well that is something for the developers to think about.  If we are going to have wxt as one of the defaults on some systems, we should be reasonably certain it works.  We don't want the community's first impression of wxt to be negative.

Dan

Re: Freeze and gnuplot 4.2 beta 1?

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

Ethan Merritt wrote:
> On Friday 01 September 2006 06:17 am, Petr Mikulik wrote:
> 
>>There was a discussion about NaN values, but it seems the works to be
>>shifted to after-4.2. Thus, isn't it time to freeze the code and
>>release gnuplot 4.2 beta 1?
> 
> 
> Yes.  But I think it should right to 4.2 patchlevel 0

Ethan put together a patch to clean up gplt_x11.c.  I propose that go in before the beta version.  It looked to me to cause no potential problems.

Dan

Re: Freeze and gnuplot 4.2 beta 1?

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

On Friday 01 September 2006 06:17 am, Petr Mikulik wrote:
> There was a discussion about NaN values, but it seems the works to be
> shifted to after-4.2. Thus, isn't it time to freeze the code and
> release gnuplot 4.2 beta 1?

Yes.  But I think it should right to 4.2 patchlevel 0

We've had a stable working version for quite a while now.
Yes, we're still getting occasional bug reports. But that
will always be true.

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

Freeze and gnuplot 4.2 beta 1?

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

There was a discussion about NaN values, but it seems the works to be 
shifted to after-4.2. Thus, isn't it time to freeze the code and release 
gnuplot 4.2 beta 1? (With some edits of 2004 => 2006, gnuplot startup text, 
etc.)

---
PM

Re: default: x11 or wxt?

[Richard H. <r.h...@rl...>]

Petr Mikulik wrote:

> What will be the default terminal for 4.2 under X11 -- x11 or wxt?
> Currently it is wxt. However, its performance for drawing images is lower
> than x11. Should not be x11 the default?
> 

I use x11 terminal for quick looks, and epslatex for hardcopy/publication.

I installed wxt out of curiosity.
These are my general, initial impressions and thoughts:
wxt looks good on the screen.
It provides and mechanism to implement richer functionality (save as
'eps/png/svg/etc..' option?) in future.

however,
I didn't work 'out of the box' for me - fonts are tiny.
It is slower than x11, am I going to run into 'out of memory' problems as
well?
WxWidgets + Cairo + Pango, that's more dependency to maintain.

I think on balance I'll be using X11 because of my particular font problem,
and wxt doesn't give anything unique.
I would probably want wxt default if alpha channel existed and unsupported
in x11.

These thoughts have raised a couple of questions I am curious about:

Does gnuplot support alpha channel?

Is wxt driven by the svg term?


r,

Re: tiny fonts with wxt term

[Richard H. <r.h...@rl...>]

Ethan Merritt wrote:

> On Thursday 31 August 2006 01:47 am, Richard Henwood wrote:
>>
>> I have a CVS gnuplot compiled on my 64bit Suse 10.1 with Gnome
>> Desktop
>>
>>         G N U P L O T
>>         Version 4.1 patchlevel 0
>>         last modified August 2006
>>         System: Linux 2.6.16.21-0.13-smp
>>
>> The font size with wxt terminal is tiny by default, ie ~ 1 pixel of
>> the default window size on my disply (1600x1200).
> 
> I was bitten by this problem also.
> The wxt terminal obtains fonts via a shared desktop utility called
> "fontconfig".  I was not using this utility prior to this, so on my
> machines no configuration had been set up and wxt could not find any
> useful fonts.
> 
> Installing/running fontconfig will create an XML file
> /etc/fonts/fonts.conf that tells the support libraries where to
> find fonts on your system.
> 
> It may also be that you do have a working fontconfig, but it
> doesn't know about any TrueType fonts (e.g. arial) you may have
> installed by other mechanisms.
> 

hmmmm... I suspected that gnuplot was having problems finding fonts.

However, fontconfig is set up, the xml is correctly configured, I think it
is working.

I just tried 'set term png font budmo' (i have budmo.ttf) and this exposed
the fact that my GDFONTPATH wasn't set... I've fixed that: PNG works but
problem remains in wxt.

r,

Re: tiny fonts with wxt term

[Richard H. <r.h...@rl...>]

Daniel J Sebald wrote:

> Richard Henwood wrote:
>> Hi folks,
>> 
>> I have a CVS gnuplot compiled on my 64bit Suse 10.1 with Gnome Desktop
>> 
>>         G N U P L O T
>>         Version 4.1 patchlevel 0
>>         last modified August 2006
>>         System: Linux 2.6.16.21-0.13-smp
>> 
>> The font size with wxt terminal is tiny by default, ie ~ 1 pixel of the
>> default window size on my disply (1600x1200).
> 
> 1 pixel?  Not much info that can be conveyed with that, is there?
> 
> Have you confirmed that wxt is working with some other application on your
> system and that this is isolated to gnuplot?
> 
> What does "test" look like on your system?  Could you create a screen
> capture?
> 

Hi Dan,
Indeed: a screen shot is worth a thousand words. I regularly skim posts to
gnuplot usenet, looking for screenshots to see what people are up to... so
I should be been more forthcoming myself! 

Anyway... here you go:

http://www2.warwick.ac.uk/cll/skills/eportfolio/students/eportfoliodirectory/current/phrfaj/gnuplotproblems/gnuplotfontproblem2.png

> Richard, we've just had a discussion about wxt/x11.  You chose wxt because
> why?  It was the default?  Just curious.
> 

Once I got it compiled in, it was the default so it sorta' chose me!
I'll follow up to 'default: x11 or wxt' thread.

r,

Re: default: x11 or wxt?

[<br...@ph...>]

Petr Mikulik wrote:

> What about printing the following message on gnuplot startup:
> 
>     Send bug reports and suggestions to <gnu...@li...>

That would be the wrong message for a release binary.  Discussion of
released versions is supposed to happen in the USENET newsgroup and on 
the gnuplot-info list.  gnuplot-beta is for developers (and those users 
who want to help us).

Re: tiny fonts with wxt term

[<tim...@en...>]

Richard Henwood a =E9crit :
> Hi folks,
>
> I have a CVS gnuplot compiled on my 64bit Suse 10.1 with Gnome Desktop
>
>         G N U P L O T
>         Version 4.1 patchlevel 0
>         last modified August 2006
>         System: Linux 2.6.16.21-0.13-smp
>
> The font size with wxt terminal is tiny by default, ie ~ 1 pixel of the
> default window size on my disply (1600x1200).
>
> I've tried:
> set term wxt font "Arial,12"
>
> and other values but this has no effect.
>
> Trawling through pango messages sends me off to gtk etc, all without
> anything that I can make sense of.
>
> All the other apps (like Inkscape, which I think use pango) look fine.
>  =20
Hi Richard,

Thank you for trying gnuplot with the wxt terminal. By default, the wxt=20
terminal chooses the font "Sans" (which may be considered as a generic=20
font name, pango may choose whatever "sans" font it has) for the size 10.

I will need a couple more information to debug that: can you tell me if=20
the "oversampling" is enabled (look at the configuration dialog in the=20
plot window), and what version of pango you have ?

A screenshot may be useful too.

Best regards,

Timoth=E9e

Re: tiny fonts with wxt term

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

On Thursday 31 August 2006 01:47 am, Richard Henwood wrote:
>
> I have a CVS gnuplot compiled on my 64bit Suse 10.1 with Gnome
> Desktop
>
>         G N U P L O T
>         Version 4.1 patchlevel 0
>         last modified August 2006
>         System: Linux 2.6.16.21-0.13-smp
>
> The font size with wxt terminal is tiny by default, ie ~ 1 pixel of
> the default window size on my disply (1600x1200).

I was bitten by this problem also.  
The wxt terminal obtains fonts via a shared desktop utility called
"fontconfig".  I was not using this utility prior to this, so on my
machines no configuration had been set up and wxt could not find any
useful fonts.

Installing/running fontconfig will create an XML file
/etc/fonts/fonts.conf that tells the support libraries where to
find fonts on your system.

It may also be that you do have a working fontconfig, but it
doesn't know about any TrueType fonts (e.g. arial) you may have
installed by other mechanisms.

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

Re: tiny fonts with wxt term

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

Richard Henwood wrote:
> Hi folks,
> 
> I have a CVS gnuplot compiled on my 64bit Suse 10.1 with Gnome Desktop
> 
>         G N U P L O T
>         Version 4.1 patchlevel 0
>         last modified August 2006
>         System: Linux 2.6.16.21-0.13-smp
> 
> The font size with wxt terminal is tiny by default, ie ~ 1 pixel of the
> default window size on my disply (1600x1200).

1 pixel?  Not much info that can be conveyed with that, is there?

Have you confirmed that wxt is working with some other application on your system and that this is isolated to gnuplot?

What does "test" look like on your system?  Could you create a screen capture?

Richard, we've just had a discussion about wxt/x11.  You chose wxt because why?  It was the default?  Just curious.

Ethan, is there some other terminal in which the font heights would behave similar to wxt and might be illustrated on Richard's system?

Dan

Re: command line

[Dave D. <dde...@es...>]

Dhiman Barman <dh...@ca...> writes:

> hi,
>   mean, it will be useful to have support for loops, variable 
>   assignment in gnuplot files. 
>   
>   if I have to plot 100 files where only the output filename 
>   and input file name change, it will be useful to have loop
>   support...but that also means having compiler/interpreter
>   support. 
>

>> On Wednesday 30 August 2006 05:19 pm, Dhiman Barman wrote:
>> >   Is there any option of taking input from command
>> > line options while running gnuplot file.gnu?
>> 


There is a trick I once came up with, but for which I've never really
found a good use for. Maybe this is it...

Assuming unix :

$ gnuplot 3< /tmp/somefile

runs gnuplot with file 3 reading from /tmp/somefile

Then inside your script, you can shell-out to read lines from that file
descriptor.

$ cat /tmp/somefile
hello
world

$ gnuplot 3< /tmp/somefile
        G N U P L O T
        Version 4.0 patchlevel 0
        last modified Thu Apr 15 14:44:22 CEST 2004
        System: Linux 2.6.8-2-686-smp
...

gnuplot> print "`head -1 <&3`"
hello
gnuplot> print "`read x <&3 ; echo X $x Y`"            
X world Y

You just need to be careful that a shell-ed out process doesn't read
more from the file than you wanted it to.


dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com

Re: command line

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

On Thursday 31 August 2006 11:09 am, Dhiman Barman wrote:
> hi,
>   mean, it will be useful to have support for loops, variable
>   assignment in gnuplot files.
>
>   if I have to plot 100 files where only the output filename
>   and input file name change, it will be useful to have loop
>   support...but that also means having compiler/interpreter
>   support.

So embed the call to gnuplot in a perl/awk/shell script.
Loop 100 times, changing the file names via an environmental
variable or symlink or in the actual command that is sent
to gnuplot.

Actually you _can_ do this in gnuplot already, using 
string variables and a reread loop.  But it is awkward 
compared to a real scripting language.

	EAM



>
> dhiman
>
> On Wed, Aug 30, 2006 at 05:26:55PM -0700, Ethan Merritt wrote:
> > On Wednesday 30 August 2006 05:19 pm, Dhiman Barman wrote:
> > >   Is there any option of taking input from command
> > > line options while running gnuplot file.gnu?
> >
> > No.
> >
> > > Or can we embed scripts in gnuplot files.
> >
> > I don't understand what you mean.
> > Usually it is the other way around - you embed the
> > gnuplot calls in your script.
> >
> >
> > --
> > Ethan A Merritt
> > Biomolecular Structure Center
> > University of Washington, Seattle WA

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

Re: command line

[Dhiman B. <dh...@ca...>]

hi,
  mean, it will be useful to have support for loops, variable 
  assignment in gnuplot files. 
  
  if I have to plot 100 files where only the output filename 
  and input file name change, it will be useful to have loop
  support...but that also means having compiler/interpreter
  support. 

dhiman 

On Wed, Aug 30, 2006 at 05:26:55PM -0700, Ethan Merritt wrote:
> On Wednesday 30 August 2006 05:19 pm, Dhiman Barman wrote:
> >   Is there any option of taking input from command
> > line options while running gnuplot file.gnu?
> 
> No.
> 
> > Or can we embed scripts in gnuplot files.
> 
> I don't understand what you mean.
> Usually it is the other way around - you embed the
> gnuplot calls in your script.
> 
> 
> -- 
> Ethan A Merritt
> Biomolecular Structure Center
> University of Washington, Seattle WA

Re: default: x11 or wxt?

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

>> What will be the default terminal for 4.2 under X11 -- x11 or wxt?
>> Currently it is wxt.
>
> It is only the default if all the supporting libraries are found.
> People who have all the pango + cairo + wxgtl libraries may reasonably
> be assumed to want to take advantage of them.

Yes, it will be compiled automatically.

So, for modern linux distributions, gnuplot will depend on more packages 
then until now. Or some "optimized" distributions could even distribute 
both gnuplot/X11 and gnuplot/X11+WX.

> If not, then they can set GNUTERM to x11.

it is easier to modify $HOME/.gnuplot

>> However, its performance for drawing images is lower than x11.
>> Should not be x11 the default?
>
> I personally find wxt to be preferable to x11.
> The anti-aliasing makes the plots easier to read,

Yes, wxt has nicer drawings.

> But I admit that I do not use gnuplot for drawing images,
> so if the performance at that specific task is not good
> then I can understand why your preference might depend on
> your typical usage.

I just try to measure it (averaged over 10 times of
plot 'out.gpbin' binary with image):

# Results:  512^2 image: x11 takes 0.25 second, wxt 0.5 seconds
# Results: 1024^2 image: x11 takes 0.8  second, wxt 1.4 seconds
# Results: 2048^2 image: x11 takes 3.2  second, wxt 5.0 seconds

(I use it for images mainly under Octave.)

> If it is only a matter of speed, then maybe it can be
> further optimized.

I think Timothee said that's the speed of pango which will be optimized 
later on.

>> What about printing the following message on gnuplot startup:
>>
>>     Send bug reports and suggestions to <gnu...@li...>
>>     Interactive terminals: x11, wxt
>>     Interactive terminals: pm, x11
>>     Interactive terminals: windows
>
> I assume you mean to print only one of those lines on any given setup.

yes

> But why would anyone want to see that every time?

Because he can choose?

---
PM

Re: raise and <space> on KDE

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

On Thursday 31 August 2006 12:46 am, Petr Mikulik wrote:
> 
> Below are proposed modifications. Plese edit if required.
> 
> help bind:
> 
>   Note: if <space> does not raise the gnuplot window under X11, see
>   discussion in `help raise`.
> 
> help raise:
> 
>   If the window is not raised under X11, then (1) they don't run in the same
>   X11 session (telnet or ssh session, for example), or (2) raising is blocked
>   by your window manager. On KDE, you may like to go to the KDE Control Panel
>   => Desktop => Window Behaviour => Advanced and set the "Focus stealing
>   prevention level" to None (default is Low).

(3) the terminal was invoked with -ctrlq, or the X Resource gnuplot*ctrlq is set.

 
> help x11:
>   ... driver can be modified. If the window does not get raised, see
>   discussion in `help raise`.
> 
> ---
> PM
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> 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

Re: default: x11 or wxt?

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

On Thursday 31 August 2006 12:53 am, Petr Mikulik wrote:
> What will be the default terminal for 4.2 under X11 -- x11 or wxt? 
> Currently it is wxt. 

It is only the default if all the supporting libraries are found.
People who have all the pango + cairo + wxgtl libraries may reasonably
be assumed to want to take advantage of them.

If not, then they can set GNUTERM to x11.

> However, its performance for drawing images is lower than x11.  
> Should not be x11 the default?

I personally find wxt to be preferable to x11.
The anti-aliasing makes the plots easier to read,
the font support is far more usable (UTF-8 works
with no special hacks, unlike x11),
and the user interface will I hope become extensible.

The only thing I don't like about it is the strange
behavior when you resize the plot window.

But I admit that I do not use gnuplot for drawing images,
so if the performance at that specific task is not good 
then I can understand why your preference might depend on
your typical usage.

Is the problem rendering speed, or something else?
If it is only a matter of speed, then maybe it can be
further optimized.

> What about printing the following message on gnuplot startup:
> 
>     Send bug reports and suggestions to <gnu...@li...>
>     Interactive terminals: x11, wxt
>     Interactive terminals: pm, x11
>     Interactive terminals: windows

I assume you mean to print only one of those lines on any given setup.
But why would anyone want to see that every time?

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

tiny fonts with wxt term

[Richard H. <r.h...@rl...>]

Hi folks,

I have a CVS gnuplot compiled on my 64bit Suse 10.1 with Gnome Desktop

        G N U P L O T
        Version 4.1 patchlevel 0
        last modified August 2006
        System: Linux 2.6.16.21-0.13-smp

The font size with wxt terminal is tiny by default, ie ~ 1 pixel of the
default window size on my disply (1600x1200).

I've tried:
set term wxt font "Arial,12"

and other values but this has no effect.

Trawling through pango messages sends me off to gtk etc, all without
anything that I can make sense of.

All the other apps (like Inkscape, which I think use pango) look fine.

Any suggestions? 

richard

default: x11 or wxt?

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

What will be the default terminal for 4.2 under X11 -- x11 or wxt? Currently 
it is wxt. However, its performance for drawing images is lower than x11. 
Should not be x11 the default?

What about printing the following message on gnuplot startup:

    Send bug reports and suggestions to <gnu...@li...>
    Interactive terminals: x11, wxt
    Interactive terminals: pm, x11
    Interactive terminals: windows



---
PM

Re: raise and <space> on KDE

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

> I've got a report that neither of "set term x11 raise", "raise" and the
> <space> hotkey is raising the respective window on KDE unless user switches
> KDE Control Panel => Desktop => Window Behaviour => Advanced => Focus
> stealing prevention level: None (default is Low).
>
> I tried to define an "exception" for gnuplot in the Desktop =>
> Window-Specific Settings, but without success. Is somebody successful?
>
> (Note: this problem is mentioned in gnuplot.doc: 'help bind'; I think it
> should probably be also mentioned in 'help raise').

Below are proposed modifications. Plese edit if required.

help bind:

  Note: if <space> does not raise the gnuplot window under X11, see
  discussion in `help raise`.

help raise:

  If the window is not raised under X11, then (1) they don't run in the same
  X11 session (telnet or ssh session, for example), or (2) raising is blocked
  by your window manager. On KDE, you may like to go to the KDE Control Panel
  => Desktop => Window Behaviour => Advanced and set the "Focus stealing
  prevention level" to None (default is Low).

help x11:
  ... driver can be modified. If the window does not get raised, see
  discussion in `help raise`.

---
PM

Re: command line

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

On Wednesday 30 August 2006 05:19 pm, Dhiman Barman wrote:
>   Is there any option of taking input from command
> line options while running gnuplot file.gnu?

No.

> Or can we embed scripts in gnuplot files.

I don't understand what you mean.
Usually it is the other way around - you embed the
gnuplot calls in your script.


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

command line

[Dhiman B. <dh...@ca...>]

Hi,
  Is there any option of taking input from command 
line options while running gnuplot file.gnu ? Or can we 
embed scripts in gnuplot files. 

Thanks,
Dhiman

Re: Missing/invalid data points

[<br...@ph...>]

Petr Mikulik wrote:
> It seems that Inf is handled, so why not NaN?

Because NaN is worse than Inf.  Infinity doesn't have all the properties 
of a number, but still some of them.  In particular +Inf is larger than 
any other number, -Inf is smaller than any other.

So Inf is generally just out-of-range.   A NaN value, OTOH, is 
completely undefined.  It's not even equal to itself!

> #x y type
>   0.1  10  i
>   0.2  20  i
>   0.3  0.3  u
>   0.4  40  i

Arguably, there's a bug in this result.  The Inf could have
have been stored and marked as "out of range" ('o' instead of 'u').

Re: Missing/invalid data points

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

Ethan Merritt wrote:
> NB:   This discussion is with regard to possible changes
>       or extensions _after_ 4.2
>=20
> On Tuesday 29 August 2006 10:25 am, Hans-Bernhard Br=F6ker wrote:
>=20
>>Ethan Merritt wrote:
>>
>>>The second case keeps the point, marking it as undefined.
>>>That is better, but it would be better yet if the information
>>>stored was
>>>   0.3 NaN 3.33 u
>>>If nothing else, that would allow the tabular output line
>>>to match the original input line.  Beyond that, the extra
>>>info may be of use in auto-scaling the axes,
>>
>>Hardly --- autoscaling should never react to points that aren't
>>actually on the plot.
>=20
>=20
> I am not so sure.  Consider the "using 1:2:3 with pm3d" plots that
> are being discussed.  Because of the oddities in missing/NaN
> handling, the limits of the grid are not determined correctly.=20
> The coordinate information may be necessary for gridding, even
> if some of the points were unmeasured ('missing') or mis-measured
> (NaN or Inf).
>=20
>=20
>>But that's not the actual point.  The core issue is that there's
>>only *one* "undefined" flag per data point.  To use the non-NaN
>>data values safely, datafile.c would have to record which of them are
>>usable, i.e. which caused the DF_UNDEFINED, and which didn't.  And it
>>would have to continue reading / filling after a NaN or missing
>>column.
>>
>>That's a rewrite from scratch of datafile.c and a good portion of all
>>the code using it you've just outlined.
>=20
>=20
> Nevertheless, that is what I am proposing.
> I already said up-thread that this requires changes throughout
> datafile.c
>=20
> However, it is not quite as bad as you make it sound.
> The change can be incremental.=20

I think so too.  The code may look a bit messy, but we've already narrowe=
d down the means for getting data from a file to df_readline() in plot2d.=
c and plot3d.c--in the case of the new binary data file code.  If we beco=
me comfortable enough to accept the binary data file code, which haas bee=
n running for quite a while now, that eliminates "df_3dmatrix()" and make=
s things a little cleaner.

I don't think what Ethan proposed should be too bad.  (Reaching agreement=
 on behavior is a different matter.)

Dan