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

Re: x11 prints garbage to stdout on OS/2

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

> When you say "everything works OK", does that mean that awk scripts now
> work al

X11 under OS/2 is working fine again.

awk is not working.

---
Petr Mikulik

Re: x11 prints garbage to stdout on OS/2

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

On Wednesday 17 December 2003 03:45, Petr Mikulik wrote:
> should be:
>
> #ifdef PIPE_IPC
>         if (ipc_back_fd >=3D 0)
>              X11_waitforinput();
> #endif
>
> and everything works OK in gnuplot versions up to yesterday.
>
> The patch commited by Ethan works fine as well.

My patch makes this whole section of code conditional
on ipc_back_fd - so yes, they would have the same effect.

When you say "everything works OK", does that mean
that awk scripts now work also?

--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

Re: x11 prints garbage to stdout on OS/2

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

> Petr: you already added a good deal of #ifdef PIPE_IPCs around this
> in end of October 2003 (x11 reversions 1.82, 1.83), so it now looks like
> this:
>
> #ifdef USE_MOUSE
>     /* EAM June 2003 - Flush the set font command through the pipe */
>     /* to gnuplot_x11, then wait for it to return the resulting    */
>     /* font size information (v_char and h_char).                  */
>     if (!default_font_size_known) {
> #ifdef PIPE_IPC
>         IPC_LOCK = TRUE;
> #endif
>         X11_set_default_font();
>         FFLUSH();
> #ifdef PIPE_IPC
>         if (ipc_back_fd >= 0)
> #endif
>             X11_waitforinput();
>         default_font_size_known = TRUE;
> #ifdef PIPE_IPC
>         IPC_LOCK = FALSE;
> #endif
>     }
> #else
>     X11_set_default_font();
> #endif
>
> Petr: I guess you or Franz will have to single-step through this part
> and find out at exactly which part of it the garbage turns up.

Franz did it and there is his answer:

***

Delete

 X11_waitforinput();

in x11.trm  (line 1053 in 15/12/2003 sources)

and try again.
This works for me, but I don't know if it's the right fix.

***

Consequently, this piece of code:

#ifdef PIPE_IPC
         if (ipc_back_fd >= 0)
#endif
             X11_waitforinput();

should be:

#ifdef PIPE_IPC
        if (ipc_back_fd >= 0)
             X11_waitforinput();
#endif


and everything works OK in gnuplot versions up to yesterday.

The patch commited by Ethan works fine as well.

Thus, what should be the best version there?

---
Petr Mikulik

Re: x11 prints garbage to stdout on OS/2

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

On Tuesday 16 December 2003 10:34, Ethan Merritt wrote:
> My proposed non-fix remains to add a command line
> option disabling this feedback mechanism.

I have added a command line option
=09gnuplot -nofeedback
that disables the feedback path which is causing problems.
This is not an ideal fix, just a work-around.
There is a corresponding XResource:
=09gnuplot*feedback:=09off                 (or false)

Please let me know if this successfully bypasses the=20
symptoms you saw under os2.  As a bonus it should=20
also allow the earlier "lost characters" problem we saw
for awk scripts.

If this works, I will add suitable documentation for it.
We can chip away at  fixing the underlying problem later.

--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

Re: x11 prints garbage to stdout on OS/2 - Re: problems compiling gnuplot (fwd)

[Hans-Bernhard B. <br...@ph...>]

On Tue, 16 Dec 2003, Ethan Merritt wrote:

> On Tuesday 16 December 2003 08:24, Petr Mikulik wrote:
> > Franz has found the patch which started to cause this problem.

So the change in question was the one that let gnuplot_x11 report back the
font size of the default font to gnuplot (grep for "EAM June 2003" in
x11.trm).

Petr: you already added a good deal of #ifdef PIPE_IPCs around this
in end of October 2003 (x11 reversions 1.82, 1.83), so it now looks like 
this:

#ifdef USE_MOUSE
    /* EAM June 2003 - Flush the set font command through the pipe */
    /* to gnuplot_x11, then wait for it to return the resulting    */
    /* font size information (v_char and h_char).                  */
    if (!default_font_size_known) {
#ifdef PIPE_IPC
        IPC_LOCK = TRUE;
#endif
        X11_set_default_font();
        FFLUSH();
#ifdef PIPE_IPC
        if (ipc_back_fd >= 0)
#endif
            X11_waitforinput();
        default_font_size_known = TRUE;
#ifdef PIPE_IPC
        IPC_LOCK = FALSE;
#endif
    }
#else
    X11_set_default_font();
#endif

Petr: I guess you or Franz will have to single-step through this part 
and find out at exactly which part of it the garbage turns up.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: x11 prints garbage to stdout on OS/2

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

[ resending the message with hopefully correct character encoding ]

On Tuesday 16 December 2003 06:52, Petr Mikulik wrote:
> There is a report, which I can confirm, that X11 terminal under OS/2
>
> - prints a lot of garbage onto the gnuplot xterm, or

I have no idea about this one, and no way of debugging it.
Could you at least establish whether it is gnuplot or gnuplot_x11
that produces this garbage?

> I *guess* there is some code using PIPE_IPC without #ifdef PIPE_IPC
> around it, and thus all the communication goes into the screen.

I don't think so, at least not in the x11.trm code.  This would cause a
severe error when the program tried to write to an invalid file descripto=
r.


--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

Re: x11 prints garbage to stdout on OS/2

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

[ resending this message with (I hope) correct character encoding ]

On Tuesday 16 December 2003 08:24, Petr Mikulik wrote:
> Franz has found the patch which started to cause this problem.
> Ethan, can you please look at it?

I have no way of debugging anything under os2.
So unless you can find a similar failure that I can reproduce here,
I can't do much other than maybe disable the feedback altogether
with a command line option (see other message).

>
> 20. June 2003 works  and  21. June 2003 doesn't.
> So one of these patches are the culprit:
> From Changelog:
>
> 2003-06-20  Ethan Merritt  <merritt@u.washington.edu>
> 2003-06-19  Ethan Merritt  <merritt@u.washington.edu>

The details of this code were changed by later patches,
so this only point a finger at the entire feedback mechanism
for requesting font and sizing information.=20
My proposed non-fix remains to add a command line
option disabling this feedback mechanism.

--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

Re: x11 prints garbage to stdout on OS/2 - Re: problems compiling gnuplot (fwd)

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

On Tuesday 16 December 2003 08:24, Petr Mikulik wrote:
> Franz has found the patch which started to cause this problem.
> Ethan, can you please look at it?

I have no way of debugging anything under os2.
So unless you can find a similar failure that I can reproduce here,
I can't do much other than maybe disable the feedback altogether
with a command line option (see other message).

>
> 20. June 2003 works  and  21. June 2003 doesn't.
> So one of these patches are the culprit:
> From Changelog:
>
> 2003-06-20  Ethan Merritt  <merritt@u.washington.edu>
> 2003-06-19  Ethan Merritt  <merritt@u.washington.edu>

The details of this code were changed by later patches,
so this only point a finger at the entire feedback mechanism
for requesting font and sizing information.=20
My proposed non-fix remains to add a command line
option disabling this feedback mechanism.

--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

Re: color box positioning for splot

[Hans-Bernhard B. <br...@ph...>]

On Tue, 16 Dec 2003, Daniel J Sebald wrote:

[...]
> I was skeptical about finding a quick fix, but this is a worthy 
> improvement.  The graph brushes up against the colorbox in some views 
> (which is the same issue as with the key, I guess), but it will do.

Those views are mainly those where the z rotation is an odd multiple of
45 degrees, i.e. those where the 3D box has maximum width.  

If you don't like the current placement, you or Petr feel free to modify
the constants I put in there.  There's quite some space left between the
current position if the cbox and the right border of a default plot. May
the gods save us from users who 'set size 0.7,1', though...

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: x11 prints garbage to stdout on OS/2

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

On Tuesday 16 December 2003 06:52, Petr Mikulik wrote:
> There is a report, which I can confirm, that X11 terminal under OS/2
>
> - prints a lot of garbage onto the gnuplot xterm, or

I have no idea about this one, and no way of debugging it.
Could you at least establish whether it is gnuplot or gnuplot_x11
that produces this garbage?

> I *guess* there is some code using PIPE_IPC without #ifdef PIPE_IPC
> around it, and thus all the communication goes into the screen.

I don't think so, at least not in the x11 code.  This would cause a
severe error when the program tried to write to an invalid file descripto=
r.

--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

Re: News in gnuplot.doc

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

On Tuesday 16 December 2003 06:07, Petr Mikulik wrote:
> > > x11.trm: It may be worth to write into docs that piping with "set
> > > mouse" can be used only if pipe must be (un??)buffered, the externa=
l
> > > caller program must issue a command like setmode(????, O_????).
>
> That's it, I don't know exactly how is it now -- I think Ethan is the
> most informed in this matter. Can you please write a bit about that?

If I understood it well enough to document properly, I would have
fixed it :-)

All I know is that some callers have problems, but most do not.
Blaming the buffered/unbuffered state of the pipe is just a guess
based on Johannes' earlier comments in x11.trm, but I cannot
confirm this is the crucial difference.
=20
The same for your just-reported problem under OS2.  I have no
idea exactly what is different in the environment, but something
obviously is making the communication channel lose synchronization.

The best thing may be to add a -noXfeedback option to the
command line, and document that it should be used in case
of problems such as the ones seen with awk scripts or OS2.=20

--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

Re: color box positioning for splot

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

Hans-Bernhard Broeker wrote:

>On Sun, 14 Dec 2003, Daniel J Sebald wrote:
>
>  
>
>>I don't have time to modify and test a quick fix for the colorbox. 
>>    
>>
>
>I did one and put it into CVS.  
>
>It works as announced in my original reply: it places the color box in
>exactly the position it has in default 'set view' settings, regardless of
>what the current view settings are.  This could have been done by
>resetting the view matrix to default, but I chose a more blunt way: ran
>the existing code in a debugger to step through map3d_xy when called from
>the colorbox generator, and wrote down the position of the color box in
>"view coordinates".  It's really a quick and dirty fix, but like all such,
>it works ;-)
>

I was skeptical about finding a quick fix, but this is a worthy 
improvement.  The graph brushes up against the colorbox in some views 
(which is the same issue as with the key, I guess), but it will do.

Doubting Daniel

Re: x11 prints garbage to stdout on OS/2 - Re: problems compiling gnuplot (fwd)

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

Franz has found the patch which started to cause this problem.
Ethan, can you please look at it?

Thanks, Petr

---------- Forwarded message ----------
Date: Tue, 16 Dec 2003 17:19:05 +0100 (CET)
From: Franz Bakan <fb...@gm...>
To: "os2...@wa..." <os2...@wa...>,
     Petr Mikulik <mi...@ph...>
Subject: Re: problems compiling gnuplot

Hi Petr, Hi list,

On Mon, 15 Dec 2003 16:23:44 +0100 (CET), Petr Mikulik wrote:

>> I tried a little bit now and x11 works very limited:
>>
>> Within HOBX11 it works like this:
>>
>>  gnuplot>set term x11
>>  gnuplot> plot sin(x)
>>
>> X11-window opens and the x11-clock-cursor appears but no plot.
>> When I now press 'return' in the gnuplot-VIO window the plot appears in
>> the X11-Winwow.
>
>Ok, I see them same problems too (with XFree86 as well as with PMX).
>If I recompile gnuplot without MOUSE, then it works OK.
>
>One guess: there is somewhere code using PIPE_IPC (and thus stdin/stdout of
>gnuplot_x11) which is not encapsulated by #ifdef PIPE_IPC ... #endif.
>
>Note that PIPE_IPC is unixish communication gnuplot_x11 => gnuplot, while
>OS/2 is using OS2_IPC for this.
>
>
>> Because your binaries from May 2003 work without such problems with HOBX11
>
>Maybe you could try to download some later version of gnuplot, by a command
>like
>	cvs -z3 -D "June 1, 2003" checkout -P gnuplot

cvs -z3 -d:pserver:ano...@cv...:/cvsroot/gnuplot checkout -D "June 21, 2003" -P -d gnuplot-2003-06-21

is the working syntax.

>and see where it was still working => thus figure out which patch made
>the problem ... if my guess is OK.

done and now I can tell you that

20. June 2003 works  and  21. June 2003 doesn't.

So one of these patches are the culprit:

>From Changelog:

2003-06-20  Ethan Merritt  <merritt@u.washington.edu>

        * src/gplt_x11.c:
        It turns out that yesterday's patch breaks the "pause -1" command
        (it always returns immediately).  I have temporarily disabled the
        new code while I track down the problem.  The offending line is now
        protected by #ifdef X11_FONT_UPDATE.

        * term/x11.trm:
        Add an interlock so that the gnuplot_x11<->x11.trm font info exchange
        is only performed once per splot, rather than every time the view is
        changed using the mouse.

2003-06-19  Ethan Merritt  <merritt@u.washington.edu>

        * src/gplt_x11.c src/graphics.c src/mouse.c src/mousecmn.h term/x11.trm
        Use existing mouse communication pipe to send X11 font characteristics
        back from gnuplot_x11 to x11.trm. This allows gnuplot to lay out the
        plot with v_char and h_char sizes that are correct for the current
        default X11 font. This patch slightly changes the timing of initial
        operations over the pipe, and adds a FFLUSH(), so there is a remote
        possibility that it also fixes a reported problem in which gnuplot_x11
        eats CPU cycles while supposedly idle. This patch should have no effect
        if gnuplot is configured with --disable-mouse.

        * term/pslatex.trm: Escape % to %% inside printf() statement.

Re: x11 prints garbage to stdout on OS/2

[Hans-Bernhard B. <br...@ph...>]

On Tue, 16 Dec 2003, Petr Mikulik wrote:

> There is a report, which I can confirm, that X11 terminal under OS/2
> 
> - prints a lot of garbage onto the gnuplot xterm, or
> - blocks until you hit <Enter>
> 
> In the latter case, gnuplot continues to plot OK.
> 
> I *guess* there is some code using PIPE_IPC without #ifdef PIPE_IPC around
> it, and thus all the communication goes into the screen. Or reading stdin
> where it should not, or like that. Can somebody have a look to this issue?
> Thanks. I haven't found a problem in gplt_x11.c, maybe somewhere else?

By far the most likely place for this to happen is not gplt_x11.c, but
x11.trm.  Looking at that "garbage" should help a lot to clear that up.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

x11 prints garbage to stdout on OS/2

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

There is a report, which I can confirm, that X11 terminal under OS/2

- prints a lot of garbage onto the gnuplot xterm, or
- blocks until you hit <Enter>

In the latter case, gnuplot continues to plot OK.

I *guess* there is some code using PIPE_IPC without #ifdef PIPE_IPC around
it, and thus all the communication goes into the screen. Or reading stdin
where it should not, or like that. Can somebody have a look to this issue?
Thanks. I haven't found a problem in gplt_x11.c, maybe somewhere else?

(Note: OS/2 communication is surrounded by OS2_IPC)

---
Petr Mikulik

Re: News in gnuplot.doc

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

> > Ethan has added new section "What is New in Version 4.0". I've just added
> > some items in it. Please, have a look and extend it as necessary as you
> > think.
>
> Having this section feels like a maintenance problem --- we now have to
> maintain the same information in two places, NEWS and gnuplot.doc.

No, they are different. NEWS is more or less (un)organized, with lines added
during the time development -- well, it shows progress of gnuplot.

"New" section in gnuplot.doc is a nicely written polished version of changes
from 3.7 to 4.0 with hypertext facility to the corresponding places in the
file. It is grouped by functionality, not by time.

> > I have searched some docs about using "history file", i.e.  automatic saving
> > and restoring of the command history.  Is it there or not?  I though it is,
> > but I could not find it.
>
> It's not in 'help history', which means that if it either doesn't exist,
> or it's in the wrong place.  Either way, this would have to be fixed.

I don't know whether it exists -- maybe with GNU readline? I remember it was
discussed, but don't remember the result.

> > x11.trm: It may be worth to write into docs that piping with "set mouse" can
> > be used only if pipe must be (un??)buffered, the external caller program
> > must issue a command like setmode(????, O_????).
>
> You seem to know best about it ---> you write it.

That's it, I don't know exactly how is it now -- I think Ethan is the most
informed in this matter. Can you please write a bit about that?

Maybe there can be a link from "help batch/interactive" .. and maybe also to
"pgnuplot" for windows?

---
Petr Mikulik

Re: News in gnuplot.doc

[Hans-Bernhard B. <br...@ph...>]

On Tue, 16 Dec 2003, Petr Mikulik wrote:

> Ethan has added new section "What is New in Version 4.0". I've just added
> some items in it. Please, have a look and extend it as necessary as you
> think.

Having this section feels like a maintenance problem --- we now have to
maintain the same information in two places, NEWS and gnuplot.doc.

Can we perhaps have a mechanism that generates one from the other (only
active in autoconf "maintainer mode")?

> I have searched some docs about using "history file", i.e.  automatic saving
> and restoring of the command history.  Is it there or not?  I though it is,
> but I could not find it.

It's not in 'help history', which means that if it either doesn't exist,
or it's in the wrong place.  Either way, this would have to be fixed.

> Should "test time" command be documented? Who knows/uses it?

I don't think it should be documented.  It's useful almost only to us
developers.  It may be best to remove its implementation rather than add
documentation of it, as far as I'm concerned.

> x11.trm: It may be worth to write into docs that piping with "set mouse" can
> be used only if pipe must be (un??)buffered, the external caller program
> must issue a command like setmode(????, O_????).

You seem to know best about it ---> you write it.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

News in gnuplot.doc

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

Ethan has added new section "What is New in Version 4.0". I've just added
some items in it. Please, have a look and extend it as necessary as you
think.

Maybe some (more) words about fontpath, gdfontpath and truetype fonts?


And some additional notes to the docs:
--------------------------------------

I have searched some docs about using "history file", i.e.  automatic saving
and restoring of the command history.  Is it there or not?  I though it is,
but I could not find it.


Should "test time" command be documented? Who knows/uses it?


x11.trm: It may be worth to write into docs that piping with "set mouse" can
be used only if pipe must be (un??)buffered, the external caller program
must issue a command like setmode(????, O_????).


---
Petr Mikulik

Re: webify.pl and HTML demos

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

> > 	save "|gpsavediff >electron-1.gp"
> >
> > Is this possible?
>
> It is possible, but the output from the gnuplot "save" command is
> not the best thing to provide people as a sample script because
> it is so wordy.

That's why I've proposed to pass it through the "gnuplot save diff" script
to write out only those commands changed wrt the "reset" status. (I'm
enclosing my favourite gpsavediff.)

It is convenient to have a look to a demo image and say "I want such an
image!" and just to download a simple script for this.

> More ideas for this demo page are welcome.  I only made a very
> quick script because I thought we really needed something more
> recent than the old 3.7 demo output.

Add a PDF file with these plots so that people can download it?

---
Petr Mikulik

Re: Subject: Re: Bug in PostScript arrows

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

On Sunday 14 December 2003 23:41, Petr Mikulik wrote:
>
> As a test, try "set pm3d map; splot x" (or "splot y") (maybe adjust
> sampling) with output to a color postscript file, pass it through
> pm3dConvert....awk script and see whether it is OK in ghostview.

It is true that the awk scripts do not like having the "stroke"
present.  However, the stroke command is nevertheless correct
in cases where it is needed in order to complete the previous
line-drawing sequence.

I did not find any tests in which the *.ps output was incorrectly
rendered by gv with the PS_FLUSH_PATH present; only cases
where the awk scripts failed to parse it.

However, it is true that the original code called PS_FLUSH_PATH
in more cases than is strictly necessary.  I changed the call in=20
PS_filled_polygon to be conditional:

    /* Stroke the previous graphic element if required. */
    if (PS_relative_ok)
        PS_FLUSH_PATH;

This works for all the test cases I have tried, but I don't=20
guarantee there isn't some sequence of calls that will insert
a "stroke" somewhere that the awk scripts do not expect it.
If there is such a case, I think the fix will have to be in the awk scrip=
ts.

--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

Re: webify.pl and HTML demos

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

On Monday 15 December 2003 02:04, Petr Mikulik wrote:
>
>   I have one idea: clicking on the image, or to a "download full script=
"
> link, or like, would retrieve commands just needed to reproduce the
> script, i.e.  something like
> =09plot ....
> =09save "|gpsavediff >electron-1.gp"
>
> Is this possible?

It is possible, but the output from the gnuplot "save" command is
not the best thing to provide people as a sample script because
it is so wordy.   I think maybe it is better to give a short explanation
on the top web page that the commands required to generate the
plots within each demo are cumulative.

More ideas for this demo page are welcome.  I only made a very
quick script because I thought we really needed something more
recent than the old 3.7 demo output.

If I find some time I will add thumbnails to the top level page and
try to make it more of a visual FAQ -
"How do I make a plot like this? <click on plot to see demo script>"=20

--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

Re: color box positioning for splot

[Hans-Bernhard B. <br...@ph...>]

On Sun, 14 Dec 2003, Daniel J Sebald wrote:

> I don't have time to modify and test a quick fix for the colorbox. 

I did one and put it into CVS.  

It works as announced in my original reply: it places the color box in
exactly the position it has in default 'set view' settings, regardless of
what the current view settings are.  This could have been done by
resetting the view matrix to default, but I chose a more blunt way: ran
the existing code in a debugger to step through map3d_xy when called from
the colorbox generator, and wrote down the position of the color box in
"view coordinates".  It's really a quick and dirty fix, but like all such,
it works ;-)

Daniel: your thoughts about xleft and friends are only partly right.
The actual mapping for 3D plots does *not* actually use those.  It
uses the variables xscaler, xmiddle, yscaler and ymiddle, instead, so
the actual code snippet I inserted looks like this:

        cb_x_from = xmiddle + 0.709 * xscaler;
        cb_x_to   = xmiddle + 0.778 * xscaler;
        cb_y_from = ymiddle - 0.147 * yscaler;
        cb_y_to   = ymiddle + 0.497 * yscaler;

The constants are what I ripped out of that debugger session, the rest is
the expected mapping from view coordinates to terminal coordinates, as
used by map3d_xy() and the TERMCOORD() macro in util3d.

Some other parts of the 3D plotting engine (outputting the title and key,
e.g.) do use xleft and friends, but that's because they work directly in
2D, neglecting the whole 3D stuff.


-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

webify.pl and HTML demos

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

	Hi Ethan,

the script & demos are nice.

  I have one idea: clicking on the image, or to a "download full script"
link, or like, would retrieve commands just needed to reproduce the script,
i.e.  something like
	plot ....
	save "|gpsavediff >electron-1.gp"

Currently, the text shown, is with respect to the previous plot, not with
respect to the "reset" status.

Is this possible?

---
Petr Mikulik

Re: Subject: Re: Bug in PostScript arrows [ was Re: Updated HTML version of demo scripts now on SourceForge

[Harald H. <h.h...@tu...>]

> As I remember, my patch fixed broken filled objects -- pm3d and
> filledcurves. This gnuplot-automatic "stroke" made the stroke before
> "closepath" or "fillpath" operators thus coloring only parts of (some?
> large?) filled objects. "stroke" can be used after "{close|fill}path"
> (but it is not necessary I think).

It is not necessary after fillpath but it _is_ necessary after closepath.

Yours
Harald

--=20
Harald Harders                           Langer Kamp 8
Institut f=FCr Werkstoffe                  D-38106 Braunschweig
Technische Universit=E4t Braunschweig      Germany
E-Mail: h.h...@tu...               Tel: +49 (5 31) 3 91-3062
WWW   : http://www.ifw.tu-bs.de          Fax: +49 (5 31) 3 91-3058

Re: Konsola and KDE list

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

> > What I would really love now is that "space-bar" hotkey working in x11
> > terminal in gnuplot running under KDE's Konsole. It works in xterm, gnome
> > terminal, but not in Konsole. I've tried to ask at several places, but
> > nobody answered.
> >
> > Does somebody an idea what to do now? Whom/where to ask for help?
>
>  KDE developer list?

This helped.
Feature implemented and commited. <space> hotkey works nice in KDE!

Somebody wants to support multitabs in gnome-terminal?

---
Petr Mikulik