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

Re: test palette rgb

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

> On Tuesday 25 November 2003 05:58, Petr Mikulik wrote:
> > > <stdio.h>: FILE *tmpfile(void)
> >
> > Unfortunately this does not provide name of the file which I could use
> > in plot 'tmp_file1'
>
> You wouldn't need a file name if you wrote the data as an in-line command:
>   plot '-'
>   xx xx xx
>   xx xx xx
>   E
> and then passed the FILE pointer directly to load_file().
>
> So the code would look like:
> 	pre1 = tmpfile();  data = tmpfile(); post1 = tmpfile();
> 	fprintf(pre1, buf1);	/* write preliminary commands */
> 	fprintf(data, buf2);	/* write inline data for plot */
> 	fprintf(post1, buf3);	/* write any trailing commands */
> 	rewind(pre1); rewind(data); rewind(post1);
> 	load_file(pre1, ...);
> 	load_file(data, ...);
> 	load_file(post1, ...);
>
>
> > 	save set 'tmp_file2'
>
> A similar trick should work here:
> 	save_set(savefp=tmpfile());
> 	...
> 	load_file(savefp, ...);

In the final rework, it turned out that it is sufficient to use only one
temporary file once submitted to load_file().

---
Petr Mikulik

Re: test palette rgb

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

On Tuesday 25 November 2003 05:58, Petr Mikulik wrote:
> > <stdio.h>: FILE *tmpfile(void)
>
> Unfortunately this does not provide name of the file which I could use
> in plot 'tmp_file1'

You wouldn't need a file name if you wrote the data as an in-line command=
:
  plot '-'
  xx xx xx
  xx xx xx
  E
and then passed the FILE pointer directly to load_file().

So the code would look like:
=09pre1 =3D tmpfile();  data =3D tmpfile(); post1 =3D tmpfile();
=09fprintf(pre1, buf1);=09/* write preliminary commands */
=09fprintf(data, buf2);=09/* write inline data for plot */
=09fprintf(post1, buf3);=09/* write any trailing commands */
=09rewind(pre1); rewind(data); rewind(post1);
=09load_file(pre1, ...);
=09load_file(data, ...);
=09load_file(post1, ...);


> =09save set 'tmp_file2'

A similar trick should work here:
=09save_set(savefp=3Dtmpfile());
=09...
=09load_file(savefp, ...);


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

Re: test palette rgb

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

> >Unfortunately this does not provide name of the file which I could use in
> >	plot 'tmp_file1'
>
> An alternative if these temp files are not too big might be
> to slightly alter the "datafile.c" so that it doesn't necessarily
> need to read from a file stream but can instead read from
> some internal memory stream.  That way you could
> temporarily put memory on the heap and not have to deal
> with files...

It could e.g. read from internal memory, and also from shared memory.

Re: test palette rgb

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

> > Unfortunately this does not provide name of the file which I could use in
> > 	plot 'tmp_file1'
> > 	save set 'tmp_file2'
>
> Hmm... looks like the right answer would be "don't do that, then", in this
> case.  I.e. we may have to find a way to generate that test page without
> writing any files.  E.g. set up gnuplot a function per palette channel
> that the core can plot, instead of storing its values to a file.

That would need:

1. gnuplot can draw data from memory

2. gnuplot can save its current status of 'set' to recover from the current
temporary plot setting


Nb 2, alias "push and pop current set status" would be nice, but
unfortunately it is not so structured. For now, using temporary save help is
quite easy.

---
Petr Mikulik

Re: test palette rgb

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

Petr Mikulik wrote:

>>>Man page of tmpnam() and of tempnam() says:
>>>   Never use this function. Use mkstemp(3) instead.
>>>
>>>Is there any safe and portable way to create a file in a temporary
>>>directory, like /tmp or C:\TMP?
>>>      
>>>
>><stdio.h>: FILE *tmpfile(void)
>>    
>>
>
>Unfortunately this does not provide name of the file which I could use in
>	plot 'tmp_file1'
>	save set 'tmp_file2'
>

An alternative if these temp files are not too big might be
to slightly alter the "datafile.c" so that it doesn't necessarily
need to read from a file stream but can instead read from
some internal memory stream.  That way you could
temporarily put memory on the heap and not have to deal
with files...  or the equivalent, some type of mechanism to
generate an arbitrary function mapping points from one
set to another set that you can plot without having to use
a datafile but rather a function... or, could datafile.c be
rewritten so that the name of the file is not needed, just
the FILE *.  That is, there is already a special case '-'.
Maybe there is something simple to do there.

Dan

Re: test palette rgb

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

On Tue, 25 Nov 2003, Petr Mikulik wrote:

> > > Man page of tmpnam() and of tempnam() says:
> > >    Never use this function. Use mkstemp(3) instead.
> > >
> > > Is there any safe and portable way to create a file in a temporary
> > > directory, like /tmp or C:\TMP?
> >
> > <stdio.h>: FILE *tmpfile(void)
> 
> Unfortunately this does not provide name of the file which I could use in
> 	plot 'tmp_file1'
> 	save set 'tmp_file2'

Hmm... looks like the right answer would be "don't do that, then", in this
case.  I.e. we may have to find a way to generate that test page without
writing any files.  E.g. set up gnuplot a function per palette channel
that the core can plot, instead of storing its values to a file.

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

Re: test palette rgb

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

> > Man page of tmpnam() and of tempnam() says:
> >    Never use this function. Use mkstemp(3) instead.
> >
> > Is there any safe and portable way to create a file in a temporary
> > directory, like /tmp or C:\TMP?
>
> <stdio.h>: FILE *tmpfile(void)

Unfortunately this does not provide name of the file which I could use in
	plot 'tmp_file1'
	save set 'tmp_file2'

---
Petr Mikulik

Re: test palette rgb

[Lars H. <lhe...@us...>]

Hans-Bernhard Broeker writes:
> On Tue, 25 Nov 2003, Petr Mikulik wrote:
> 
> > Man page of tmpnam() and of tempnam() says:
> >    Never use this function. Use mkstemp(3) instead.
> > 
> > Is there any safe and portable way to create a file in a temporary
> > directory, like /tmp or C:\TMP?
> 
> <stdio.h>: FILE *tmpfile(void)
> 
> It may not be particularly safe, but it's as portable as they come, being
> an ANSI/ISO C Standard Library function.  You get no control whatsoever
> about the directory it places the file in, though.
 
 It is quite difficult to do this portably and securly (avoiding races).
 It's probably best to create a temporary directory (mkdtemp() if available),
 chmod 700 it, and create all temp files in that directory. I've written
 some not terribly intelligent code like this for amavis.

Re: test palette rgb

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

On Tue, 25 Nov 2003, Petr Mikulik wrote:

> Man page of tmpnam() and of tempnam() says:
>    Never use this function. Use mkstemp(3) instead.
> 
> Is there any safe and portable way to create a file in a temporary
> directory, like /tmp or C:\TMP?

<stdio.h>: FILE *tmpfile(void)

It may not be particularly safe, but it's as portable as they come, being
an ANSI/ISO C Standard Library function.  You get no control whatsoever
about the directory it places the file in, though.

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

Re: bug in variable.c: fontpath_handler(ACTION_GET)

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

On Mon, 24 Nov 2003, Petr Mikulik wrote:

> ==30824== Invalid read of size 1
> ==30824==    at 0x4016371B: strlen (in /usr/lib/valgrind/valgrind.so)
> ==30824==    by 0x80E88BC: fontpath_handler (variable.c:519)

A similar bug seems to be in loadpath_handler, too, where it's easier
to trigger: just give the commands

	test pal
	test pal

in a fresh gnuplot session that does have a loadpath from the environment
($GNUPLOT_LIB is set), and the second one will cause a SIGSEGV in
loadpath_handler, in a line that's in exactly the same context as line
variable.c:519 which valgrind complained about:

(gdb) cont
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x080dae74 in loadpath_handler (action=16, path=0x0)
    at ../../src/variable.c:175
175                 p += strlen(p);
(gdb) l
170                 if (p < limit)
171                     return p;
172                 else
173                     return NULL;
174             } else {
175                 p += strlen(p);
176                 /* skip over '\0' */
177                 p++;
178                 if (p < limit)
179                     return p;

So the real problem obviously is that 'beenhere' wasn't reset to zero,
even though the state of 'p' suggests it has.

And the reason for that is pretty clear, too: fontpath_handler() and
loadpath_handler() both expect the caller to *always* do ACTION_GET until
it gets a NULL return.  The code in 'test palette' doesn't do that, and
thus it crashes.  The right fix would thus be to set 'beenhere' to zero
whenever p is NULLed, i.e. on each re-initialization of fontpath_handler()
or loadpath_handler, respectively.

Actually 'beenhere' serves no useful purpose anyway, as far as I can see.
Tests for it can be replaced by the condition (p != NULL), I think.

I'm checking in a fix along these lines.

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

Re: test palette rgb

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

Further, it was crashing in read-only directory. I've fixed that.

The problem is that it needs to write two temporary files ('save set', and
palette data). For that, I use mkstemp(). But this functions makes the file
in the current directory.

Man page of tmpnam() and of tempnam() says:
   Never use this function. Use mkstemp(3) instead.

Is there any safe and portable way to create a file in a temporary
directory, like /tmp or C:\TMP?

---
Petr Mikulik

Re: bug in variable.c: fontpath_handler(ACTION_GET)

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

On Monday 24 November 2003 07:22, Petr Mikulik wrote:
> There seems to be a bug in file
> =09variable.c
>
> Below is an ad-hoc fix -- and actually two possibilities of the fix.
> Does someone (Harald?) know what that code is doing and propose a
> correct fix?

This is a parallel case to the crash I was getting.
Mine was in loadpath_handler(), yours in fontpath_handler().
I make the correct fix to be the one given below, but I don't
know why this problem is only showing up now:

--- gnuplot/src/variable.c=092002-10-11 09:26:49.000000000 -0700
+++ gnuplot-eam/src/variable.c=092003-11-24 16:32:16.000000000 -0800
@@ -161,7 +161,7 @@
 =09FPRINTF((stderr, "Get loadpath\n"));
 =09if (!loadpath)
 =09    return NULL;
-=09if (!beenhere) {
+=09if (!beenhere || !p) {
 =09    /* init section */
 =09    beenhere =3D 1;
 =09    p =3D loadpath;
@@ -505,7 +505,7 @@
 =09FPRINTF((stderr, "Get fontpath\n"));
 =09if (!fontpath)
 =09    return NULL;
-=09if (!beenhere) {
+=09if (!beenhere || !p) {
 =09    /* init section */
 =09    beenhere =3D 1;
 =09    p =3D fontpath;


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

Re: test palette rgb

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

> So it is in cvs.

Works nicely the first time. =20
Crashes on the second.
Same behaviour seen for x11, png, and post terminal types

gnuplot> set term png font arial
Terminal type set to 'png'
Options are 'nocrop font arial 12 size 640,480 '
gnuplot> set output 'rgb.png'
gnuplot> test palette
smooth palette in png: available 157 color positions; using 157 of them
gnuplot> test palette

Program received signal SIGSEGV, Segmentation fault.
0x401ebbc3 in strlen () from /lib/i686/libc.so.6
(gdb) where
#0  0x401ebbc3 in strlen () from /lib/i686/libc.so.6
#1  0x080e8c67 in loadpath_handler (action=3D0, path=3D0x1 <Address 0x1 o=
ut of bounds>) at variable.c:175
#2  0x08092612 in save_set_all (fp=3D0x8212240) at save.c:837
#3  0x08090e08 in save_set (fp=3D0x80f6c3c) at save.c:100
#4  0x080536f8 in test_palette_subcommand () at command.c:1371
#5  0x08051e4a in command () at command.c:507
#6  0x080519b5 in do_line () at command.c:364
#7  0x080518d3 in com_line () at command.c:323
#8  0x08084e69 in main (argc=3D1, argv=3D0xbfffec74) at plot.c:609
#9  0x4018f082 in __libc_start_main () from /lib/i686/libc.so.6



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

Re: update for www.gnuplot.info

[Lars H. <lhe...@us...>]

Petr Mikulik writes:
> According to SourceForge Patch:
> 
> [ 790847 ] Updated link to Gnuplot.py for gnuplot homepage
> 
> The gnuplot homepage contains a link to Gnuplot.py, the
> Python interface to gnuplot. But the link is obsolete.
> Please change it to
> 
> http://gnuplot-py.sourceforge.net/
> 
> 
> Can someone fix it on gnuplot.info?
 
 gnuplot.info should pick it up with the next resync.

update for www.gnuplot.info

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

According to SourceForge Patch:

[ 790847 ] Updated link to Gnuplot.py for gnuplot homepage

The gnuplot homepage contains a link to Gnuplot.py, the
Python interface to gnuplot. But the link is obsolete.
Please change it to

http://gnuplot-py.sourceforge.net/


Can someone fix it on gnuplot.info?

---
Petr Mikulik

Re: unlimited windows patch

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

On Monday 24 November 2003 07:53, Petr Mikulik wrote:
> 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?

I've no idea, but I don't think this has anything in particular to do wit=
h gnuplot.
Konsole is broken in so many ways that I gave up on it long ago.
There are so many good alternatives (xterm, rxvt, eterm,...) that it does=
 not
seem worth worrying about.

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

Re: bug in variable.c: fontpath_handler(ACTION_GET)

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

> > There seems to be a bug in file
> > 	variable.c
> > which sometimes causes 'test palette' to segfault. It shows up in some
> > combinations of save_set(), load_file(), and do_string("reset;");
> >
> > "valgrind" helped to discover the problematic place. It is in routine
> > fontpath_handler(action, path) in case ACTION_GET:
>
> It's hard to discuss the fix without an explanation what the actual bug
> was.  How did it segfault?

Try this:

$ valgrind gnuplot
....
Terminal type set to 'x11'
gnuplot> test pal
==30824==
==30824== Conditional jump or move depends on uninitialised value(s)
==30824==    at 0x40162EB7: malloc (in /usr/lib/valgrind/valgrind.so)
==30824==    by 0x804B0F4: gp_alloc (alloc.c:280)
==30824==    by 0x8053A80: test_palette_subcommand (command.c:1363)
==30824==    by 0x805216B: command (command.c:507)
gnuplot> test pal
==30824==
==30824== Invalid read of size 1
==30824==    at 0x4016371B: strlen (in /usr/lib/valgrind/valgrind.so)
==30824==    by 0x80E88BC: fontpath_handler (variable.c:519)
==30824==    by 0x809225B: save_set_all (save.c:826)
==30824==    by 0x8090807: save_set (save.c:100)
==30824==    Address 0x0 is not stack'd, malloc'd or free'd
Segmentation fault


(The 1st report is not an issue for the 2nd.)

---
Petr Mikulik

Re: bug in variable.c: fontpath_handler(ACTION_GET)

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

On Mon, 24 Nov 2003, Petr Mikulik wrote:

> There seems to be a bug in file
> 	variable.c
> which sometimes causes 'test palette' to segfault. It shows up in some
> combinations of save_set(), load_file(), and do_string("reset;");
> 
> "valgrind" helped to discover the problematic place. It is in routine
> fontpath_handler(action, path) in case ACTION_GET:

It's hard to discuss the fix without an explanation what the actual bug
was.  How did it segfault?

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

Re: unlimited windows patch

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

> > 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
>
> I think the patch has been carefully tested by several people and it works
> fine. What about if I move it to cvs?

It is there. Thanks for the patch.

===

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?

---
Petr Mikulik

Re: bug in variable.c: fontpath_handler(ACTION_GET)

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

On Mon, 24 Nov 2003, Petr Mikulik wrote:

> There seems to be a bug in file
> =09variable.c
> which sometimes causes 'test palette' to segfault. It shows up in some
> combinations of save_set(), load_file(), and do_string("reset;");
>
> "valgrind" helped to discover the problematic place. It is in routine
> fontpath_handler(action, path) in case ACTION_GET:
>
> Below is an ad-hoc fix -- and actually two possibilities of the fix. Does
> someone (Harald?) know what that code is doing and propose a correct fix?

It's ages ago that I have programmed the fontpath handling. But I will
have a look at it at home. Please give me two days to find it out again.

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

bug in variable.c: fontpath_handler(ACTION_GET)

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

There seems to be a bug in file
	variable.c
which sometimes causes 'test palette' to segfault. It shows up in some
combinations of save_set(), load_file(), and do_string("reset;");

"valgrind" helped to discover the problematic place. It is in routine
fontpath_handler(action, path) in case ACTION_GET:

Below is an ad-hoc fix -- and actually two possibilities of the fix. Does
someone (Harald?) know what that code is doing and propose a correct fix?


diff -uwr src/variable.c src-TestPal/variable.c
--- src/variable.c	2002-10-11 18:26:00.000000000 +0200
+++ src-TestPal/variable.c	2003-11-23 17:46:33.000000000 +0100
@@ -302,6 +302,7 @@
 	init_fontpath();
     }

+
     switch (action) {
     case ACTION_CLEAR:
 	/* Clear fontpath, fall through to init */
@@ -516,6 +517,15 @@
 	    else
 		return NULL;
 	} else {
+//@@@@@@@@@@@@@@@@@@@ bug in variable.c:
+//@@@@@@@@@@@@@@@@@@@ fontpath_handler(action, path) for ACTION_GET:
+//@@@@@@@@@@@@@@@@@@@ PETR: WHAT IS CORRECT HERE ??? WHICH FIX?
+#if 1
+if (p == NULL) { beenhere = 0; return NULL; }
+#else
+if (p == NULL) { return NULL; }
+#endif
+//@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ END OF A BUG FIX
 	    p += strlen(p);
 	    /* skip over '\0' */
 	    p++;

Re: test palette rgb

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

> > A snapshot is here:
> >   http://www.sci.muni.cz/~mikulik/gnuplot/gp_rgb.png
>
> I see.
> I like that!

So it is in cvs.

Associated changes:

- 'test' is synonym for 'test terminal'

- Undocumented command 'testtime' changed to undocumented command
'test time'.

BTW, is there any particular reason this to be undocumented, now, when it is
a suboption of 'test'? Cannot it be changed to become useful for users of
"time" plots?

---
Petr Mikulik

Re: arrowheads too long in PostScript terminal

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

Alan, Ethan,

I've drawn up a diagram illustrating the tip of an arrow
and how to compensate for the line ending so that the
tip lands right at the desired end point.  It is in PDF format
at:

http://acer-access.com/~ds...@ac.../

under "gnuplot stuff".

The formula is actually quite simple given the angle of
the tip "wings" as specified in Gnuplot.  Basically a small
vector opposite the direction of the vector from start (S) to
end (E) is added to the end point (E).

Here is a small chunk of code that implements the formula
intended for the "place_arrows" routine in graphics.c.  But
THIS DOESN'T WORK currently (read below) so just
illustrates the simplicity of the formula.

    apply_head_properties(&(this_arrow->arrow_properties));
    /* A correction factor for the line so that the arrow head does
     * not extend past the ending point of the line.
     *
     * THIS IS CURRENTLY JUST A DEMONSTRATION AND DOESN'T ACCOUNT
     * FOR ALL THE SPECIAL CONDITIONS LIKE headlength < 0, alpha = 0,
     * ETC.
     */
    if (this_arrow->arrow_properties.head_length > DBL_EPSILON) {
        double dx = (double) sx - (double) ex;
        double dy = (double) sy - (double) ey;
        double len_arrow = sqrt(dx * dx + dy * dy);
        double alpha = this_arrow->arrow_properties.head_angle * DEG2RAD;
        double w = this_arrow->arrow_properties.lp_properties.l_width;
        double factor = w/(2*len_arrow*sin(alpha));
        ex += dx*factor;
        ey += dy*factor;
    }
    (*t->arrow) (sx, sy, ex, ey, this_arrow->arrow_properties.head);

OK.  This doesn't work because THE LINE WIDTH IS NOT KNOWN
IN TERMS OF PLOT UNITS.  That is, in the formula above, "w" should
be the line width in terms of plot units not in terms of "unity" units.  You
see, the line width properties are sent all the way down to the driver level
and I think it is there that the value of "lp_properties.l_width" takes on a
meaning.

So there are a couple significant problems here in compensating for the
tip of the arrow.

1)  Where should the compensation for the arrow tip be done?  The
options are inside the Gnuplot "place_arrow" routine, inside the
default terminal "do_arrow" function, or inside each individual driver's
"arrow" function.  There are pluses and minuses for all.

2)  Somewhere the width of a line must be known in terms of plot
units in order to compensate for the arrow tip.  I don't see where this
information can be gotten easily and this could be some major
driver level coding to send back such information.  (Ethan, is this
similar to the problems you've come across with getting font height
information back from the driver?)

Dan



Alan G Isaac wrote:

>>On Monday 20 October 2003 23:14, Alan G Isaac wrote:
>>    
>>
>>>Basic user interface issue:
>>>set arrow from ptA to ptB
>>>will be expected to do precisely that:
>>>start at ptA and end at ptB.
>>>      
>>>
>
>On Tue, 21 Oct 2003 11:20:41 -0700 Ethan Merritt <merritt@u.washington.edu> wrote:
>  
>
>>Gnuplot does that now.  What we are disagreeing about is the
>>meaning of the word "precisely".
>>    
>>
>
>Actually I think we are disagreeing on the more basic words
>'start' and 'end'.  I have not been able to understand your
>apparent suggestion (?) that the user will expect ink past
>ptB (in the direction of the arrow).
>
>On Tue, 21 Oct 2003 11:20:41 -0700 Ethan Merritt <merritt@u.washington.edu> wrote:
>  
>
>>You may not like the behavior, but that doesn't mean it
>>is ambiguous.
>>    
>>
>
>I think you are giving a programmer's perspective rather 
>than a user's perspective on ambiguity here.  Of course,
>the code says what it says.  But a user has no simple
>way to tell where an arrow will end. (I.e., where the
>ink will end.)
>
>On Tue, 21 Oct 2003 11:20:41 -0700 Ethan Merritt <merritt@u.washington.edu> wrote:
>  
>
>>think of line segments in gnuplot as a
>>connect-the-dots process:  place a dot at the "from"
>>position, place another at the "to" position, then connect
>>them.
>>    
>>
>
>I accept that if I draw several independent (i.e., unjoined)
>line segments end to end that round caps will produce a
>better looking line.  But this is not how people use arrows.
>Or rather, I don't know anyone using arrows this way.
>And those who do have a round caps option available to them.
>
>  
>
>>I personally think that rounded ends are best.
>>But it should be left up to the user, as it is now.
>>    
>>
>
>No, it isn't.  Not for arrows with heads.  Selecting butt
>caps does not cause arrowhead ink to terminate at the
>specified end point.
>
>
>  
>
>>But they don't.   They extend exactly to the specified
>>endpoint *** to the resolution of the pen used ***.
>>    
>>
>
>  
>
>>>What is more, with
>>>this behavior it is essentially impossible for me to make an
>>>arrow terminate precisely where I wish it to.
>>>      
>>>
>
>  
>
>>I don't see why.  Can't you just specifiy a very thin
>>pen width and a filled arrowhead?  Stroke the tail of
>>the arrow separately if you want that part thicker.
>>    
>>
>
>Stroke the tail to where, exactly?  (That is the 
>user interface issue!)
>
>A picture is worth a thousand words.  How can the sript
>below be considered to produce desirable output for these
>script commands?  I still say the key issue is: what will
>users expect, and what makes it easiest for them to achieve
>precisely what they desire in a predictable fashion?  When
>the user wants an arrow from ptA to ptB, that really ends at
>ptB (i.e., no ink past ptB), s/he should not have to make
>length adjustments everytime s/he changes the linewidth or
>arrowhead angle.  Yet that is the current situation.  I
>cannot see that this behavior (in the sample script) can
>meet the goal of being predictable for the user.  And I add
>to that a personal query: thinking back over your own use of
>arrows in gnuplot, can you really claim that your *intent*
>when you first think of drawing an arrow from ptA to ptB
>is for the ink to extend past ptB?
>
>Alan Isaac
>
>##############################################################
>set term post eps color solid butt
>set output 'c:\temp3.eps'
>set xrange [0:4]
>set yrange [0:5]
>set style arrow 1 front head size 0.2,15 nofilled lt -1
>set style arrow 2 front nohead lt -1
>set style arrow 3 front nohead lw 5 lt -1
>set style arrow 4 front head size 0.2,15 nofilled lw 5 lt -1
>set arrow from  1,1 to 3,1 as 1
>set arrow from  1,2 to 3,2 as 2
>set arrow from  1,3 to 3,3 as 3
>set arrow from  1,4 to 3,4 as 4
>plot '-' with points ps 1 pt 7 lt 1
>3 1
>3 2
>3 3
>e
>##############################################################
>
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by OSDN developer relations
>Here's your chance to show off your extensive product knowledge
>We want to know what you know. Tell us and you have a chance to win $100
>http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54
>_______________________________________________
>gnuplot-beta mailing list
>gnu...@li...
>https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>
>
>  
>

-- 

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

Re: Universal enhanced text mode!

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

On Wednesday 19 November 2003 00:55, you wrote:
> Well, this shift can also be seen on the "dumb enha" terminal -- but it=
s
> character size should not be scalable so that {/*4 } should alway be se=
t
> to 1, I think? The same for other terminals with non-scalable fonts.

But is this a bug?  The program is doing what you tell it to do - scale
the font size by some large factor.  The optimal choice of font and scali=
ng
is always going to depend on the specific output device, so I think the
user is ultimately responsible for requesting reasonable values.

This behavior is also present in the original PostScript code.
The placement of the sub- and superscripts is calculated separately
by the layout code, and if you tell it there is a large font it will plac=
e them
far above or below the baseline.   gnuplot does not really know if the
font size information is correct or not, it just assumes that if you sele=
ct
a font size you know what you are doing.

And even for PostScript output this assumption can go wrong.
Gnuplot calculates text  placement based on the font information
present at the time you create the plot.  But if you print the output fil=
e on
a printer that  does not have that font, the printer will substitute some
other font and the sub/superscript placement may well be incorrect.

This is exactly parallel to the X11 case.  You tell gnuplot that
such-and-such a font is to be used, and what size it is=20
supposed to be.  Gnuplot positions text accordingly, then
sends the output to a separate program (gnuplot_x11)=20
which in turn sends it to an X-server.  And that X-server
may not have that font, or may not be able to provide the
size requested.  But this failure is too late, and in the wrong
program, for gnuplot to do anything about it.

OK, yes, I agree that the dumb terminal driver is never going
to be able to scale fonts.  So maybe it is a special case.
But I was not really worried about producing optimal output
on the dumb terminal. Do you think this is important?

And if I change it so that the scale factor is ignored in some
cases,  then you will lose the ability to tweak the scale factor if you
*do* in fact want to adjust the sub- and super- scripts placement.
For instance if you have multiple levels of sub/superscripts
=09label =3D "{x^{k_1}}"
You need to request a larger font scaling in the dumb terminal
in order to spread the k-sub-1 over two lines.

There are more complex options, I suppose.
We could create a new style option
=09set font [no[scaleable]] [charset <val>] [... others?]
But I think this can all come afterwards, if people find that
the current mechanism is inadequate in practice.


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

Re: test palette rgb -- Re: show palette palette <n> savergb

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

> > I propose
> > 	test palette {{rgb | grb | bgr | rbg | ...}}
> >
> > to get the user chance to distinguish which R,G,B profiles overlap in
> > e.g. gray palette.
>
> I'm afraid I don't understand what you are saying here.
> Probably a picture is worth a thousand words of explaination.
> What is the difference between
> 	test palette rgb
> and
> 	test palette grb
> in the resulting output?


Being the rgb profiles in 'tmpfile', the option rgb | bgr | ... would choose
this order:

plot 'tmpfile' \
  u 1:2 title 'red'w l 1, ''u 1:3 tit 'green'w l 2, ''u 1:4 tit 'blue' w l 3

or this one

 using 1:4 'blue', u 1:3 'green', u 1:2 'red'

or ....

In principle, it select which color curve will be on top if (at least) two
overlap like e.g. in 'palette gray' (all 3 r,g,b profiles overlap).

A snapshot is here:
  http://www.sci.muni.cz/~mikulik/gnuplot/gp_rgb.png

---
Petr Mikulik