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

Re[2]: arrowheads too long in PostScript terminal

[Alan G I. <ai...@am...>]

On Wed, 22 Oct 2003, Daniel J Sebald apparently wrote:
>  user expectations
> are something to consider.  But also you should weigh
> in any preceding standards.  My guess is that there
> have been long discussions amongst graphics people
> about the topic and some standard may have emerged
> over the years.  I would consider using that as a guide.


I have not been able to find an answer at this 
level, so I took a different approach: I looked
in a number of nicely done math books to see
how arrows are drawn.

I found two widespread conventions:
i. The arrowhead ink ends right at the point the arrow is
drawn to.  This is the convention that I have been pushing
for.
ii. The arrowhead ink ends right at the edge of a filled
circle, the center of which is the point that the arrow
is drawn "to".  I find this odd conceptually, but I confess
it does produce some nice looking graphics.

I did *not* find cases where the arrowhead ink extends
beyond the point the arrow is drawn to, which is the current
gnuplot convention.  So I not only remain convinced that
current gnuplot practice is wrong at the conceptual level,
it also does not appear to be a common practice (based on my
limited "survey").

So I still think that the right thing for gnuplot to do is
ensure that the very tip of the arrowhead ink is at the
point that the arrow is drawn to.  As I have argued, it is
what the user expects, and based on a little looking around,
it seems this user expectation is in line with established
practice.

However due to case (ii) above---a case that Ethan first
drew my attention to---it seems it would also be useful to
introduce a new option for set arrow: "point", which would
work like similarly to how it does for label.  Specifically,
it would place a point and then allow for a single number
"offset" (interpreted as a shortening of the arrowlength)
which would be specified in pointsize units.  (I guess one
might be wanted at each end, in which case there could also
be an option "points" that accepts two numbers an offset,
one for each end.)

fwiw,
Alan

Re: unlimited windows patch

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

> > BTW, I've noticed that there is a bug visible on some enhanced terminals
> > (PM and gd enhanced patch by Ethan): all text is flushed left instead of right.
>
> What is PM?

OS/2 Presentation Manager terminal (set term pm)

> Text justification in gd+enhanced would be difficult, although I think it

The bug is somewhere else -- it looks like *all* text is wrongly justified,
even when using no enhanced features in any text.

> is possible with some work.   It is much harder than in PostScript because
> libgd does not provide equivalent operators such as gsave/grestore.
> A lot more would have to be done in software.

It would need a routine like strlen_enhanced_text(char*) which would
estimate the width of the label. Additionally, it would be of great use for
gnuplot's auto sizing of margins et al, where it counts all characters of
"/Symbol ...".

---
Petr Mikulik

Re: unlimited windows patch

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

On Friday 31 October 2003 02:50, Petr Mikulik wrote:
> > So, in summary, the structure of 16 plots has been replaced by a
> > linked list.
>
> I propose to add this patch into current cvs. (That limit of 16 windows
> is considered as a bug by some people, mainly when using it with
> Octave's figure(n) function.)

So far it works here also, but I have not tested it very thoroughly.


> BTW, I've noticed that there is a bug visible on some enhanced terminal=
s
> (PM and gd enhanced patch by Ethan): all text is flushed left instead o=
f right.

What is PM?

Text justification in gd+enhanced would be difficult, although I think it
is possible with some work.   It is much harder than in PostScript becaus=
e
libgd does not provide equivalent operators such as gsave/grestore.
A lot more would have to be done in software.   But I did block out the
code in principle.   A bigger problem is that libgd is still not handling
symbol fonts correctly.  I have mailed patches toTom Boutell, but they ha=
ve
not yet made it into a released version.


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

Re: show palette palette <n> savergb

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

> > And if you really suspect confusion, you could still use a different
> > name than 'palette' to distinguish it from 'show palette'.  Say 'save
> > rgbpalette'.

Then docs would have to be like

       save {<option>} '<filename>'
       save rgbpalette '<filename>' <n> {scale <scale> {int}}

> However, logically if you can
>     'save rgbpalette <filename>'
> you would expect to be able to restore it later using
>     'load <filename>'
> This suggests to me that the output of the save command
> should be formatted such that it is acceptable to 'load'.

No, it is to be loaded as
	set palette file 'blabla.dat'

Thus, it is not very coherent with other save/load commands.

Therefore, now I would propose the syntax

	show palette palette <n> {float | int}

Without the float|int option, it would print the complete table as it prints
now. With the option, it would print table of <n> rgb triplets either in
range 0..1 or 0..255. The output would be sent to the file given by 'set
print'.

What do you think about this?


Considering the option 'palette' of 'show palette', it's there for years.
But that's just showing command, thus obviously not used in scripts. It
could be renamed to 'show palette rgbpalette' or 'show palette rgbtable' if
there are some votes for this change, or for any other better name.


> Also, would it not be equally (or even more) useful to have a
>     'test rgbpalette'
> that displays in the plot window an indexed array of the
> palette colors?

That would be really nice. It could be done most easily like that:
  - save rgb table with 256 samples into a temporary file
  - plot it by a call to "do_string"

---
Petr Mikulik

Re: unlimited windows patch

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

> So, in summary, the structure of 16 plots has been replaced by a linked
> list.

I propose to add this patch into current cvs. (That limit of 16 windows is
considered as a bug by some people, mainly when using it with Octave's
figure(n) function.)

The patch works for me fine on OS/2-X11, Linux and Windows/Cygwin-X11.

> set term x11 145 title "Hello World"

This "title" option is cool as well (OS/2 terminal had this for years).


BTW, I've noticed that there is a bug visible on some enhanced terminals (PM
and gd enhanced patch by Ethan): all text is flushed left instead of right.

---
Petr Mikulik

image and binary data file

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

The second patch is a major redo of the image and binary data file
support code:

694789 New plotstyle "with pixels"
[Now called "with image"]

with_image_103003.diff.gz
datafiles.tar:
     blutux.rgb
     scatter2.bin
     sine.bin
     using.bin
     demo.edf

The gzip file is the actual patch.  The datafiles.tar file is several
binary data files required for the "image.dem" demo program
within the patch.

Petr and I really winnowed the features, syntax, etc. on this one.
I think we have a nice set of commands and capabilities.
Discussion is always welcome, of course.

Some significant changes are that it is now 'with image' and
'with rgbimage' as opposed 'with pixels".  Also, the variable
'pixelplanes' is defunct.  No longer is there the ability to control
the individual size of pixels.  I thought that would find very little
use, and there are other ways of doing this.  Instead the image
plotting routine has been generalized for any orientation and
skew of image grid.  It will use the efficient term->image function
if appropriate.  Images can be used in both `plot` and `splot`.  But
RGB images cannot be used in `splot`.  [Perhaps a future
discussion item.]

 From Petr's original discussion list submission about binary
data file syntax, I've done some major changes that make the
use of such files much easier.  A concept of "inherent sampling
array" has emerged to make things easy to remember and no
longer is there the arcane use of 0, -1 and -2 in the `using` string.
Instead, associated with `binary` is `array=1024x1024`.  There
are similar options for controlling data position, spacing, translation,
etc. which include `origin, center,  dx, dy, dz, flipx, flipy, flipz,
transpose, flip, scan, rotation, perpendicular, endian, filetype`.  It
may all seem like a lot to digest, but if you try the patch and
look through the demo commands, I think you will find it makes
a great deal of sense.

Petr has written some code for reading EDF files which
we've incorporated into the code and demo script.  The general
strategy is that the binary feature has a structure describing
details about the binary file in question.  (Of course,
that is what is filled in by options like 'origin, center`, etc.)  The
EDF file function looks at a file's header and fills in the necessary
variables of the structure and lets Gnuplot continue onward.

The binary data seems to work fine through a pipe, i.e., `-`.
(One of the original reasons for the patch.)  Actually, I just tried
it one day and it worked without alteration.

I guess it doesn't pay to go into more on this until people have
had a chance to look at the patch.  I suggest some of the developers
give the demo `image.dem` a try.  (I think you will like some of the
capabilities.)  Then generate some discussion about integration
into CVS.  I'm sure many people will have comments and suggestions
about syntax, etc.  But I think that is better tackled through all
developers having the ability to modify code.  It has become a bit
unwieldy for me to make modifications.  My supporting utilities
are becoming out of date and I think most things that need fine tuning
aren't worth addressing until there is some discussion and agreement
on details.  I'm certainly willing to help with changes down the road,
of course.  I've tried not touching the current behavior of Gnuplot, e.g.
`binary` without a <binary list> still behaves like Gnuplot's current
binary mode.

Dan


-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/

unlimited windows patch

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

Folks,

I've updated some patches on SourceForge (with much of Petr's help)
that I'd like people to test and consider for integration into Gnuplot.  One
is a moderate length patch for unlimited X11 windows.  The other is the
longer patch for image and binary data file support.  I will briefly discuss
the two in separate emails...

Patch 774822 Unlimited plot windows for X11 terminals.

linked_list_103003.diff

The unlimited X11 windows patch consists of the one file listed above.
The strategy here was to take the large table containing information
about the window and add a few pointers for a doubly-linked list and
an identifier (the window #).  Then there is a large chunk of code to
support the linked list.  It actually is fairly straightforward with a few
short routines like "Add_To_List", "Remove_From_List", etc.  The only
tricky part was robustly cleaning up plots that are deleted via the OS,
e.g., pressing the close button of the window.  That requires a queue
for deleting plots because otherwise the OS error handler could delete
a plot that gnuplot_x11 is currently accessing.  In any case, it has been
very robust and I can't recall ever seeing gnuplot_x11 go defunct with
this strategy.  I've also run this through Octave to generate a couple
hundred plots on the screen and it works fine.

So, in summary, the structure of 16 plots has been replaced by a linked
list.  Petr has tested the patch and also gave some good suggestions
for additions.  Also, the issue of closing a window has come up on the
list, so I added a "close", although there may be an issue with the
different pipes.  (Try it, see if it suitable.)  The X11_options() routine
has been cleaned up to do reasonable sanity checks and to not change
anything unless a valid "set term" command is entered.  This is more
in line with the manner in which "plot" and "splot" behave.

There is documentation in Gnuplot, but some examples are

set term x11 145 title "Hello World"
plot sin(x)
set term x11 close

Dan


-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/

Re: show palette palette <n> savergb

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

On Thursday 30 October 2003 01:07, Hans-Bernhard Broeker wrote:
> On Thu, 30 Oct 2003, Petr Mikulik wrote:
>
> And if you really suspect confusion, you could still use a different
> name than 'palette' to distinguish it from 'show palette'.  Say 'save
> rgbpalette'.

I like that option best of the ones mentioned so far.
However, logically if you can
    'save rgbpalette <filename>'
you would expect to be able to restore it later using
    'load <filename>'
This suggests to me that the output of the save command
should be formatted such that it is acceptable to 'load'.

Also, would it not be equally (or even more) useful to have a
    'test rgbpalette'
that displays in the plot window an indexed array of the
palette colors?

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

Re: show palette palette <n> savergb

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

On Thu, 30 Oct 2003, Petr Mikulik wrote:

> > If you're going to 'save' it to a file, wouldn't the most sensible place
> > be a sub-option of the 'save' command?  So IMHO it should be something
> > like
> >
> > 	save palette '<filename>' ncolors <n>
>
> That could confuse user whether it is saving "set palette" or the discrete
> r,g,b values of the current palette.

I strongly doubt it'll be less confusing than breaking the existing
tradition that 'show' shows, and 'save' writes to file.

And if you really suspect confusion, you could still use a different name
than 'palette' to distinguish it from 'show palette'.  Say 'save
rgbpalette'.

> I find it more logic to be able to save
> the rgb table to a file at the same place it can write it to screen.

But the problem is you're planning to write to screen something different
than what you would save to file, anyway.  If you want the actual
'show' output in a file, there's always 'set print' for that, right?

> > > show palette palette <n> {savergb {<scale> {int}} 'filename'}
> >
> > The doubling of 'palette' in there feels wrong, to me.
>
> It's OK -- there are more "show palette" print options, see "help palette".

Sure --- but that still doesn't make 'palette' a good sub-option name. If
you worry about confusing the user, this should have you pretty worried,
IMHO.

> > I seriously doubt that all that scaling is worth the hassle.  Either write
> > out floats, or ints scaled up to the usual 8-bit range.
>
> I think it is worth it: some apps loading rgb palettes require integer range
> 0..255, others float range 0..1.

Exactly --- and those are the *only* ones I've ever seen anybody use.
Which means there's hardly any point offering a selection much more
general than that.  A simple option {int | float} would be sufficient.
For plotting the colour profiles from gnuplot, you wouldn't need it all,
of course...

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

Re: show palette palette <n> savergb

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

> > Currently gnuplot can print colour palette table on screen by 'show
> > palette palette <n>'. I made a patch which can save it to a file, just 3
> > columns of r,g,b, to be easily plotted by gnuplot as colour profiles.
> > The syntax proposed is below. Does somebody propose any other addition?
> > (E.g. how to save lut files?)
>
> If you're going to 'save' it to a file, wouldn't the most sensible place
> be a sub-option of the 'save' command?  So IMHO it should be something
> like
>
> 	save palette '<filename>' ncolors <n>

That could confuse user whether it is saving "set palette" or the discrete
r,g,b values of the current palette. I find it more logic to be able to save
the rgb table to a file at the same place it can write it to screen.

> > show palette palette <n> {savergb {<scale> {int}} 'filename'}
>
> The doubling of 'palette' in there feels wrong, to me.

It's OK -- there are more "show palette" print options, see "help palette".

> I seriously doubt that all that scaling is worth the hassle.  Either write
> out floats, or ints scaled up to the usual 8-bit range.

I think it is worth it: some apps loading rgb palettes require integer range
0..255, others float range 0..1.

---
Petr Mikulik

Re: show palette palette <n> savergb

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

On Wed, 29 Oct 2003, Petr Mikulik wrote:

> Currently gnuplot can print colour palette table on screen by 'show
> palette palette <n>'. I made a patch which can save it to a file, just 3
> columns of r,g,b, to be easily plotted by gnuplot as colour profiles.
> The syntax proposed is below. Does somebody propose any other addition?
> (E.g. how to save lut files?)

If you're going to 'save' it to a file, wouldn't the most sensible place
be a sub-option of the 'save' command?  So IMHO it should be something
like

	save palette '<filename>' ncolors <n>

> show palette palette <n> {savergb {<scale> {int}} 'filename'}
[...]

The doubling of 'palette' in there feels wrong, to me.

I seriously doubt that all that scaling is worth the hassle.  Either write
out floats, or ints scaled up to the usual 8-bit range.

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

show palette palette <n> savergb

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

Currently gnuplot can print colour palette table on screen by 'show palette
palette <n>'. I made a patch which can save it to a file, just 3 columns of
r,g,b, to be easily plotted by gnuplot as colour profiles. The syntax
proposed is below. Does somebody propose any other addition? (E.g. how to
save lut files?)


show palette palette <n> {savergb {<scale> {int}} 'filename'}

`show palette palette <n>` shows RGB triplets for the current settings and a
palette having <n> discrete colors. This table can be saved into a
`filename` (accepting also '-' and '|pipe_command'), optionally scaled by
'<scale>' and rounded to integer values.


---
Petr Mikulik

Re: again: x11 is eating one character from stdin pipe

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

> So now we have a problem:  octave scripts only work with the call
> to setvbuf(), while awk scripts only work without it.  Octave is likely the
> more important application, and anyway people have been using the
> setvbuf() version for almost 2 years now.  So we should leave the
> default the way it is.

I.e., there are some applications which call setvbuf(gp,NULL,_IOLBF,0); or
do fflush(gp) after each command, and those which don't. Fortunately,
interactive programs should not be affected unless they "set mouse"
explicitly. However, this applies only to X11 terminal.


I think it would be worth to add some text about the necessity of using
	setvbuf(f,NULL,_IOLBF,0); /* set unbuffered output */
into "help x11_mouse".


> However, in case someone does want to use an awk script,
> perhaps there could be an option
> 	set mouse [no]buffered
> The default would be nobuffered, implemented by the existing call
> to setvbuf(). Specifying 'set mouse buffered' instead would bypass
> the call to setvbuf() and allow awk to work.
>
> Would that be an acceptable work-around?

Isn't this just X11 specific? Does it set both stdin/stdout to application
and to terminal to non-buffer, or only for one end?


Maybe, in the next fool-proof reincarnation of X11 terminal, it would be
worth to do it like in gnuplot for OS/2 -- named pipe terminal->gnuplot,
with gnuplot having a thread waiting for pipe events (or semaphores +
shared memory).

---
Petr Mikulik

Re: demos

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

On Tuesday 21 October 2003 03:21, Petr Mikulik wrote:
>
> There are still many *.dem which use "set no" instead of "unset", and
> "set data/func style" instead of "set style data/func". Could somebody
> have a look, update and test *.dem for the new 3.8 syntax?

Done.
I used:
sed -e 's/unset key/set key off/' \
       -e 's/set no/unset /' \
       -e 's/^set key *$/set key on/' \
       -e 's/set data style/set style data/' \
       -e 's/set function style/set style function/'
--=20
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center Box 357742
University of Washington, Seattle, WA 98195

Re: again: x11 is eating one character from stdin pipe

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

Ethan Merritt wrote:

>Daniel J Sebald <dan...@ie...> wrote>
>  
>
>>That is some strange code, however.  
>>    
>>
>
>I will choose to take that as a compliment :-)
>

Why, of course I meant it that way.  :-)

>>Maybe a handshaking scheme is needed.  Perhaps x11.trm
>>    
>>
>
>Handshaking didn't help.
>

Yes, sometimes it just pushes the problem to some other
obscure location.

Dan

-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/

Re: again: x11 is eating one character from stdin pipe

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

On Monday 27 October 2003 07:04, Petr Mikulik wrote:
> I'd a look to the patch of June 21 which made the break; even though I
> don't understand it, I've found that commenting out the
> "X11_waitforinput();" call does not produce the forgetting-pipe error:
>
>    /* Force default font at start of plot */
> #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) {
>         X11_set_default_font();
>         FFLUSH();
>         X11_waitforinput();
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>         default_font_size_known =3D TRUE;
>     }
> #else
>     X11_set_default_font();
> #endif
>     X11_set_font("");
> }
>
>
> Does that command have to be there?

Well yes.  That is the whole point of the excercise.
The idea is to give X11 a chance to initialize the window data
structure and send back sizing and font information before
proceeding.  That way the plot can be laid out correctly.

Daniel J Sebald <dan...@ie...> wrote>
>That is some strange code, however. =20

I will choose to take that as a compliment :-)

>Does anyone know what the basic concept is here?

See above.=20

> Maybe a handshaking scheme is needed.  Perhaps x11.trm

Handshaking didn't help.  What was needed was an interlock.
I added that to CVS on 23 Oct.  You should not (I hope!!) be
seeing problems with Octave any more.   If you are then=20
please send me another sample script that generates the
error.

As I previously noted, there is a separate problem with
buffered/unbuffered input streams.   Awk is not happy=20
with the unbuffered stream.  I don't know why, and I don't
know what other scripting environments might suffer from
the same problem.

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

Re: again: x11 is eating one character from stdin pipe

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

Petr Mikulik wrote:

>I'd a look to the patch of June 21 which made the break; even though I don't
>understand it, I've found that commenting out the "X11_waitforinput();" call
>does not produce the forgetting-pipe error:
>
>
>   /* Force default font at start of plot */
>#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) {
>        X11_set_default_font();
>        FFLUSH();
>        X11_waitforinput();
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>        default_font_size_known = TRUE;
>    }
>#else
>    X11_set_default_font();
>#endif
>    X11_set_font("");
>}
>
>
>Does that command have to be there?
>

My guess would be "yes" if the size of the font is to be correct
when used in Gnuplot formatting.

That is some strange code, however.  Does anyone know what
the basic concept is here?  Is this using a single pipe to have
traffic in both directions?  If so, I might speculate that x11.trm
is sending information through the pipe then looking to get
something back perhaps grabbing characters that it just sent
into the pipe because gplt_x11 hasn't yet pulled them out.(????)

Maybe a handshaking scheme is needed.  Perhaps x11.trm
should send a command through the pipe.  The gplt_x11
font command doesn't send stuff immediately but waits for
another special character to be sent.  On the other end,
x11.trm first sits waiting for the pipe to be completely empty.
Then it knows that gplt_x11 has received the font command
and is waiting to send something back.  x11.trm then sends
the special character.  But still that doesn't seem fool proof,
unless there is some way for x11.trm to know the pipe has
grown bigger than the one character it sent, say.  That might
be a way of knowing that what is in the pipe came from
gplt_x11 and not its own self.

Dan

-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/

Re: again: x11 is eating one character from stdin pipe

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

> > > With the setvbuf() in place, running the awk script causes the
> > > first 120+ plot commands to be lost in transit!!!!!!
> > >
> > > Without the setvbuf() command, only a single character is
> > > dropped - the first one following the first plot command.
> >
> > I've tried it with Octave, but there is no change with or without
> > setvbuf. Gnuplot mostly looses the first character.
>
> Last night I built Octave 2.1.50 so that I could test this
> myself. What I found is that the Octave problem and the awk
> problem are not the same.
>
> The Octave problem can, I believe, be solved with the first
> patch attached below (ipc_lock.patch).  This one causes
> X11_waitforinput() to refuse to read any more characters
> using getc(stdin) while it is waiting for a response from the
> mousing pipe.
>
> This still leaves awk losing many lines of input, which is
> fixed only if I also remove the call to setvbuf() as in the
> second patch below (setvbuf.patch).
>
> Applying these two patches makes both the awk and octave
> test scripts run on my usual desktop machine under linux.
>
> I've tested both with gnu libreadline and with the builtin
> readline. But I have not yet tested on other machines, and
> I would not like to commit either patch to CVS without more
> extensive testing.
>
> In particular I am concerned that if the response from the
> mouse pipe is lost altogether, then the first patch will cause
> gnuplot will hang.  I need to add some sort of timeout or
> upper limit of attempts to read from the mouse pipe.


I'd a look to the patch of June 21 which made the break; even though I don't
understand it, I've found that commenting out the "X11_waitforinput();" call
does not produce the forgetting-pipe error:


   /* Force default font at start of plot */
#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) {
        X11_set_default_font();
        FFLUSH();
        X11_waitforinput();
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        default_font_size_known = TRUE;
    }
#else
    X11_set_default_font();
#endif
    X11_set_font("");
}


Does that command have to be there?

Petr

Re: x11.trm terminal options

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

Ethan A Merritt wrote:

>On Thursday 23 October 2003 11:46 pm, Daniel J Sebald wrote:
>  
>
>>Point 1 is simply a matter of breaking
>>out of a loop when a number change code 'N' is seen
>>by Gnuplot.  It is then possible to resize all windows
>>after a "set term x11".
>>    
>>
>
>OK. That sounds like a pure bug-fix.  Did you check the
>rest of that loop to see if all the other options have proper
>exit code also?
>

There are one or two others, but they are ones for which
following commands (always sent by gnuplo)t kick it out of
the loop.  For example, the 'G' always has other commands
immediately following it.  The 'N' was the only one where
a single command would be issued.

But if I remember correctly, just changing the 'N' case so
that it kicks out of the loop for the current CVS raises a
different problem, one address with the mods I made.

>>2c below I've ruled out as an alternative.  It is confusing
>>when the windows behave that way.  This is accomplished
>>by doing an X11_init() in the X11_options() of x11.trm.
>>    
>>
>
>Are you saying this is only needed for (c)?  Or are you
>proposing to do this for (a) also?
>
>  
>
>>[But really, the proper thing to do would be to check the
>>sanity of the "plot->window" variable before using it.
>>    
>>
>
>Or maybe to set this to point at a dummy structure when
>a window is destroyed, instead of setting it to NULL.
>
>  
>
>>The alternatives 2a and 2b are achieved by a simple
>>mod of:
>>    
>>
>
>(b) is to pop up a blank window as soon as the terminal
>type is set, right?   I do not like that idea at all.
>

Based upon the feedback from you and Hans, the 2a/b/c cases
now boil down to "no window appear until when something is
plotted."

>I'd like to have a look at the proposed code changes
>before offering a final opinion.
>

No problem.  I'll make the patch available in a couple days after
Petr and I agree it behaves as designed.  I think you'll like it.

Dan

Re: x11.trm terminal options

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

Ethan Merritt wrote:

>On Friday 24 October 2003 15:22, Daniel J Sebald wrote:
>  
>
>>As for the issue with different processes, I'm wondering
>>how this situation comes about.
>>    
>>
>
>Minimal example from command line:
>
>set term x11 1 persist
>plot something()
>set term x11 reset
>set term x11 2 persist
>plot somthingelse()
>set term x11 1 close
>^^^^^^^^^^^ will fail
>
>window 1 is still on the screen and still responding to
>mouse events, but is being controlled by a different
>gnuplot_x11 process than window 2.
>

Oh yeah, persist.  I forgot about that.  Well, that is sort of above
and beyond a normal driver anyway...

>In practice I would expect this to be more of an 
>issue with scripts and automated drivers.
>

but yes, I guess for scripts the persist finds a use, e.g., a script
that launches gnuplot, plots, then exits gnuplot but wants to
retain the windows.

>I don't know exactly what goes on inside Octave,
>but if it ever sends a 'set term reset' at all, I should
>think this could happen fairly easily.
>

I don't think the issue is with 'set term reset' unless Octave puts
Gnuplot into persist mode.

>From looking at the code, I also think it can happen
>if a non-tty process switches from nomouse to mouse
>within a session.  Opening a new X11 term with nomouse
>and non-tty causes it to shut down the back_ipc,
>and then the next open _with_ a mouse starts a
>whole new gnuplot_x11 so it can get a mousing
>channel.  But I don't have a real-world example of
>that.
>

Hmm... that seems like something that would be fixable.

>>So if there are multiple pipes each
>>one running a version of gplt_x11, what would be the
>>sense of having built a multiwindow gplt_x11 in the first
>>place?
>>    
>>
>
>Good question.  I wouldn't have done it this way.
>
>  
>
>> x11.trm could have handled the various windows
>>on its own.  
>>    
>>
>
>Yup.  And I think that would be better. 
>But it would be a lot of work to change over.
>

Of course, gplt_x11.c would serve as a good basis.  The storing
of "commands" sent across the pipe as code words could be
replaced by the storing of gnuplot internal commands.  In the long
run, my guess is that the two manners of storing a plot boil down
to roughly the same amount of memory usage per plot.

But I'm not totally put off by the gplt_x11 scheme of things.  There
are only a couple of complaints for me:  One, the use of ASCII to store
all the information bloats memory.  Two, there is no way to send what
is appearing in an X11 window to a printer or file.  That is, say someone
generates ten plots on the screen and wants to print any one of them.
[I tend to avoid this sort of development approach, opting to do almost
everything from script files so I can repeat what I did.]  The person
would need to retrace all his or her commands to get back to the
plot they want and then use the PostScript driver.

So, in some sense it would be nice have a system where instead of
storing the code letter commands, the terminal function calls are
saved and can be directed to PostScript.  But, as you pointed out
this might be a lot of work because Gnuplot does different things
in a few spots based upon the type of terminal.  An alternative might
be for gplt_x11 to have some mode where it can generate PostScript
from its code letter commands.

>I'm hoping that someone will write a multi-window
>Qt driver and we can just switch over to using that instead
>of x11.trm
>

I'm not familiar with Qt.  What part of the system commands
for describing the plot would be stored?  Internal Gnuplot?
Gnuplot terminal commands?  

Dan

Re: x11.trm terminal options

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

On Thursday 23 October 2003 11:46 pm, Daniel J Sebald wrote:
> Point 1 is simply a matter of breaking
> out of a loop when a number change code 'N' is seen
> by Gnuplot.  It is then possible to resize all windows
> after a "set term x11".

OK. That sounds like a pure bug-fix.  Did you check the
rest of that loop to see if all the other options have proper
exit code also?

> 2c below I've ruled out as an alternative.  It is confusing
> when the windows behave that way.  This is accomplished
> by doing an X11_init() in the X11_options() of x11.trm.

Are you saying this is only needed for (c)?  Or are you
proposing to do this for (a) also?

> [But really, the proper thing to do would be to check the
> sanity of the "plot->window" variable before using it.

Or maybe to set this to point at a dummy structure when
a window is destroyed, instead of setting it to NULL.

> The alternatives 2a and 2b are achieved by a simple
> mod of:

(b) is to pop up a blank window as soon as the terminal
type is set, right?   I do not like that idea at all.

I'd like to have a look at the proposed code changes
before offering a final opinion.

-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Re: x11.trm terminal options

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

I believe I have a few simple mods to address points
1 and 2 below.  Point 1 is simply a matter of breaking
out of a loop when a number change code 'N' is seen
by Gnuplot.  It is then possible to resize all windows
after a "set term x11".

2c below I've ruled out as an alternative.  It is confusing
when the windows behave that way.  This is accomplished
by doing an X11_init() in the X11_options() of x11.trm.
The ramification of doing this is that the X11 window
must be created even if just a "set term x11" is called.
Why?  Looking through the gplt_x11.c code there are
many many places where a pointer in the plot table
called "plot->window" of type Window is used without
testing first if it is valid.  Rather than touch up all these
occurrences, I've just made sure the windows are
initialized whenever a new window number is used in some way.
[But really, the proper thing to do would be to check the
sanity of the "plot->window" variable before using it.
The reason is that if the plot being drawn to is destroyed
in some way and "plot->window" gets set back to
zero, gplt_x11 will not crash.  E.g., if a slow graph is
drawing and the "destroy" button is pressed.]

The alternatives 2a and 2b are achieved by a simple
mod of:

#define DISPLAY_WINDOW_UPON_CREATION 0
#if DISPLAY_WINDOW_UPON_CREATION
    XMapWindow(dpy, plot->window);
#endif

inside the pr_window() routine of gplt_x11.c.  If the defined
value is 0 the window is not made visible until something
is actually plotted to it.  If the defined value is 1, the empty
window is displayed upon creation, i.e., a "set term x11"

As for issue 3, I may go through and make sure some
reasonable tests for duplicated options is done.

Dan



Daniel J Sebald wrote:

> My original message must have been lost by SF, but I
> don't think it needs resending to clarify the issue.  The
> points up to this point are
>
> 1)  I think the problem of x11 windows getting stuck
> when only a "set term x11 #" should be fixed at some
> point.  Nobody needs to change this, I can do so with
> Petr's help.  But, feel free to comment.
>
> 2)  If you think the above problem should be modified,
> do you feel that
>
> a) graphics windows should not appear until something
> is actually plotted to them
>
> b) graphics windows should _always_ appear when
> "set term x11 ..." is entered
>
> c) the first x11 window should not appear until something
> is actually plotted, but after that "set term x11 ..." will
> cause a new blank window to appear.
>
> With regard to 2, note that if one types "set output 'name'"
> followed by no plot commands, but then "set output", the
> file 'name' will be created.  Is there an analogy here between
> a file and a window?
>
> The next point is
>
> 3)  Looking at the X11_options() in x11.trm it is very similar
> to other parsing/interpretting schemes, however it doesn't have
> the many checks for repeated entry, valid entry, etc.  Some
> commands are sent to gplt_x11 even before the end of parsing.
> So even if there is something bogus in the "set term x11"
> command, a portion of the command could have been processed.
> Should it do that?  Or should it wait until it is known that the whole
> command is valid?  For example,
>
> "set term x11 3 "TimesFont""
>
> will show an error message because "font" is missing before
> the font name, but it will in fact change the x11 window to 3.
>
> If you feel point 2b above should be the case, then
>
> "set term x11 1 2 noraise"
>
> where someone mistypes the 12 will cause window 1 and window
> 2 to show on the desktop.  In fact, as it currently is
>
> "set term x11 1 2 noraise reset 3 4 raise"
>
> is fine by Gnuplot.  Should there be some checks to prevent
> this kind of thing?
>
> Dan
>
>
> Daniel J Sebald wrote:
>
>>
>>
>> Daniel J Sebald wrote:
>>
>>> In other words, from a fresh invocation
>>>
>>> set term x11 3
>>>
>>> creates no window. But
>>>
>>> plot sin(x)
>>> set term x11 3
>>>
>>> creates _two_ windows. 
>>
>>
>>
>>
>> You are probably wondering what I mean because the
>> current version doesn't do this, as I just realized. What
>> I am speaking of the system's behavior after an alteration
>> to the 'N' option for changing the X11 window via
>>
>> "set term x11 5"
>>
>> [If you type the following, you'll notice you are unable
>> to resize the first plot... that should be fixed at some
>> point.
>>
>> plot sin(x)
>> set term x11 4
>> {try resizing first plot}]
>>
>> I guess the question boils down to should the command
>>
>> set term x11 7
>>
>> cause an empty X11 window to appear on the desktop
>> if it didn't already exist? Or should it be until after something
>> is actually plotted to the window that it appears on the
>> desktop?
>>
>> Dan
>>
>

-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/





-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/

Re: x11.trm terminal options

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

Hans-Bernhard Broeker wrote:

>On Thu, 23 Oct 2003, Daniel J Sebald wrote:
>
>[...]
>  
>
>>2)  If you think the above problem should be modified,
>>do you feel that
>>
>>a) graphics windows should not appear until something
>> is actually plotted to them
>>    
>>
>
>Yes.  A gnuplot X11 graph window serves no purpose whatsoever until a
>graph is plotted into it, so there's no point displaying it until that
>point in time.
>

OK.  Seems agreement is emerging on that.  So, gplt_x11 will
create the window in memory (because of all the plot->window
references) but not display it until something is plotted.  An
alternative can be investigated later, e.g.,  waiting until 'G'
(prepare plot) is sent to do the actual individual plot update.

>>With regard to 2, note that if one types "set output 'name'"
>>followed by no plot commands, but then "set output", the
>>file 'name' will be created.  Is there an analogy here between
>>a file and a window?
>>    
>>
>
>Not really.  Arguably, that behaviour of 'set output' is wrong itself.
>

I will check if that can be modified easily.  It may not
be as entwined as gplt_x11.c.

>>3)  Looking at the X11_options() in x11.trm it is very similar
>>to other parsing/interpretting schemes, however it doesn't have
>>the many checks for repeated entry, valid entry, etc.  Some
>>commands are sent to gplt_x11 even before the end of parsing.
>>    
>>
>
>That's a bug, then.  But AFAICS, the only command sent to gplt_x11.c
>before parsing of the options is finished is an update of the window
>number.
>  
>

But why even update that?  How about the precedence idea
of waiting until the line is verified as valid, then if "reset", reset;
if "number", number; the rest?  That way
"set term x11 reset 19 noraise" is the same as
"set term x11 noraise 19 reset".  Also, "reset" should set the
number back to 0, unless a number is also given.  This is a
cleaner and easier way of doing things I think.  Should take
ten minutes.

Dan


-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/

Re: x11.trm terminal options

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

Ethan Merritt wrote:

>On Friday 24 October 2003 14:01, Daniel J Sebald wrote:
>  
>
>>Ethan Merritt wrote>
>>    
>>
>>>I did try to add that feature a while ago, but it turned out to
>>>be harder than it sounded at first blush.  So it remains on the
>>>list of things that would be nice but are non-trivial.
>>>      
>>>
>>It did take a while to figure out exactly where to
>>put the code, but after that not bad.  From gplt_x11's
>>perspective it would be one line of code to close
>>the window in question.
>>    
>>
>
>You are missing the hard part.  The gplt_x11
>process you currently have a pipe to may or may not
>be the same process that opened the window you
>want to close.  How do you communicate with the
>original gnuplot_x11 process to tell it to close the
>window?
>
>Of course it's possible. You could keep a list of old
>pipe descriptors, being careful of course never to
>close any of them.  But it's non-trivial.
>
>Or you could just give up and not handle this case,
>but it seems a pity to do a half-baked job.
>

Well, I've programmed a simple close statement and it works
fine over a single pipe, i.e., single instance of gplt_x11.  On the
x11.trm side of things it is

    if (set_number && !set_close && X11_ipc) {
        fprintf(X11_ipc, "N%d\n", X11_plot_number);
        fflush(X11_ipc);
    } else if (set_close && X11_ipc) {
        fprintf(X11_ipc, (set_number ? "C%d\n" : "C\n"), X11_plot_number);
        fflush(X11_ipc);
    }

[Any objection to using the conditional inside the fprintf
in that way?  I think the argument is just ignored if
set_number is not true.]

As for the issue with different processes, I'm wondering
how this situation comes about.  That would mean the
user is opening different pipes intentionally.  (Let's
rule out the accidental destroying of the pipe and a
new one being created...)  So if there are multiple pipes each
one running a version of gplt_x11, what would be the
sense of having built a multiwindow gplt_x11 in the first
place?  x11.trm could have handled the various windows
on its own.  Also, if this is an issue with "close", it is also
an issue with the current "set term x11 #" because that
could be other pipes as well.

 From gplt_x11's side of things, everything is fine, I believe.
I'd say it is worth having because in most situations it will
work as expected.  So instead of half-baked, it's
nine-tenths-baked.  :)

Dan

-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/

Re: x11.trm terminal options

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

Ethan Merritt wrote:

>>#if NOT_PROCESS_IF_DUPLICATION
>>
>Let's not proliferate conditional code.  Go for one or the
>other (error or warning).
>

I'd vote for error then simply because that is
the way "plot" and "splot" behave.  Nothing
is done if you don't have valid syntax.

>>So it works fine.  But I recall something now.  I believe there
>>was a discussion a while back about the ability to close a
>>single X11 graph from the command line.  So perhaps if both
>>a "reset" and a number appear in the options, only the plot
>>associated with that number could be closed.  Right now it
>>will reset the whole thing (i.e., close all windows) and then
>>switch to plot number.  How does that sound?
>>    
>>
>
>I think that should be a separate command.  "reset" and
>"close" do not mean the same thing to me.
>

So you would want a syntax

set term x11 close 5

(or set term x11 5 close is the equivalent)

?  That seems just fine to me and it makes
sense too.  It is just adding one more case
in the case statement.  Easy.

>I did try to add that feature a while ago, but it turned out to
>be harder than it sounded at first blush.  So it remains on the
>list of things that would be nice but are non-trivial.
>

It did take a while to figure out exactly where to
put the code, but after that not bad.  From gplt_x11's
perspective it would be one line of code to close
the window in question.  That would effectively
wipe out any attributes to that window.  The next
time the user plots to that window, the window's
attributes will have been reset.  I could add a code
word 'C' or 'c' (not used, surprisingly) inside
gplt_x11.c.

Dan

-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/