Menu
▾
▴
gnuplot-beta
|
From: Joe K. <jko...@co...> - 2006-09-20 20:01:32
Attachments:
nobox_demo.tar.gz
|
I asked about this problem on the gnuplot help list and didn't get a response after a day or two, so I am assuming that it is a bug, not a new feature. Attached in .tar.gz format is a script and a short data file that reproduce the bug on my machine. I am using the Sept. 17 CVS of gnuplot-4.1, compiled on a Mac G5 with OS X 10.4.7 and Xcode-2.4 developer tools. I upgraded automake-1.6.3 to 1.9.6 in order to get ./prepare to work. This has been reported via the gnuplot help list. I am using AquaTerm-1.0.1 for output. The build completed and installed without problems. When I run the script via gnuplot < gnutest.inp, the colorbox to the right of the plot frame does not appear. This script has worked with an earlier version of gnuplot-4.1 built back in March of this year. Is this a bug? Thanks. Joe Koski |
|
From: <br...@ph...> - 2006-09-21 21:10:42
|
Joe Koski wrote:
> I asked about this problem on the gnuplot help list and didn't get a
> response after a day or two, so I am assuming that it is a bug, not a new
> feature. Attached in .tar.gz format is a script and a short data file that
> reproduce the bug on my machine.
The example is a bit too complicated. It can be boiled down to just one
command:
splot x+y with points palette
The outermost reason why this plot doesn't get a colorbox is that the
comparison against TC_DEFAULT made by set_plot_with_palette is
triggered. The plot in question has a pm3d_color.type value of 6, as if
the user had specified 'palette z'. This might be an inadvertant side
effect of the changes that allowed 'with points palette cb -45' etc.
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-09-23 04:40:20
|
On Thursday 21 September 2006 02:12 pm, Hans-Bernhard Br=F6ker wrote:
> Joe Koski wrote:
> > I asked about this problem on the gnuplot help list and didn't get a
> > response after a day or two, so I am assuming that it is a bug, not a n=
ew
> > feature. Attached in .tar.gz format is a script and a short data file t=
hat
> > reproduce the bug on my machine.
>=20
> The example is a bit too complicated. It can be boiled down to just one=
=20
> command:
>=20
> splot x+y with points palette
>=20
> The outermost reason why this plot doesn't get a colorbox is that the=20
> comparison against TC_DEFAULT made by set_plot_with_palette is=20
> triggered. The plot in question has a pm3d_color.type value of 6, as if=
=20
> the user had specified 'palette z'. This might be an inadvertant side=20
> effect of the changes that allowed 'with points palette cb -45' etc.
I think that is correct.
As best as I can make out, the error arises from a false assumption that was
waiting to bite us for a long time. I don't know exactly which change
caused it to emerge. The offending lines are these, from pm3d.c
1001 if (this_3dplot->lp_properties.use_palette) {
1002 if (this_3dplot->lp_properties.pm3d_color.type !=3D TC_DEFAU=
LT)
1003 /* can this really happen? for which syntax? */
1004 want_palette_but_not_colorbox =3D TRUE;
1005 /* don't return yet -- decide later whether showing colo=
r box is desirable */
The implicit assumption is that no color spec other than TC_DEFAULT uses
the palette. This has been incorrect for a very long time, but was not a
problem until you could explicitly override the default color-by-z style
of splot surfaces using another palette option. =20
The fix is
=2D-- gnuplot/src/pm3d.c 2006-06-15 08:42:33.000000000 -0700
+++ gnuplot-cvs/src/pm3d.c 2006-09-22 21:25:10.000000000 -0700
@@ -999,8 +999,8 @@
return;
#endif
if (this_3dplot->lp_properties.use_palette) {
=2D if (this_3dplot->lp_properties.pm3d_color.type !=3D TC_DEFAULT)
=2D /* can this really happen? for which syntax? */
+ int type =3D this_3dplot->lp_properties.pm3d_color.type;
+ if (type =3D=3D TC_LT || type =3D=3D TC_LINESTYLE || type =3D=3D TC_RGB)
want_palette_but_not_colorbox =3D TRUE;
/* don't return yet -- decide later whether showing color box is des=
irable */
else
=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: Joe K. <jko...@co...> - 2006-09-23 18:03:11
|
on 9/22/06 10:40 PM, Ethan A Merritt at merritt@u.washington.edu wrote:
> On Thursday 21 September 2006 02:12 pm, Hans-Bernhard Br=F6ker wrote:
>> Joe Koski wrote:
>>> I asked about this problem on the gnuplot help list and didn't get a
>>> response after a day or two, so I am assuming that it is a bug, not a n=
ew
>>> feature. Attached in .tar.gz format is a script and a short data file t=
hat
>>> reproduce the bug on my machine.
>>=20
>> The example is a bit too complicated. It can be boiled down to just one
>> command:
>>=20
>> splot x+y with points palette
>>=20
>> The outermost reason why this plot doesn't get a colorbox is that the
>> comparison against TC_DEFAULT made by set_plot_with_palette is
>> triggered. The plot in question has a pm3d_color.type value of 6, as if
>> the user had specified 'palette z'. This might be an inadvertant side
>> effect of the changes that allowed 'with points palette cb -45' etc.
>=20
> I think that is correct.
> As best as I can make out, the error arises from a false assumption that =
was
> waiting to bite us for a long time. I don't know exactly which change
> caused it to emerge. The offending lines are these, from pm3d.c
>=20
> 1001 if (this_3dplot->lp_properties.use_palette) {
> 1002 if (this_3dplot->lp_properties.pm3d_color.type !=3D TC_DEFAU=
LT)
> 1003 /* can this really happen? for which syntax? */
> 1004 want_palette_but_not_colorbox =3D TRUE;
> 1005 /* don't return yet -- decide later whether showing co=
lor
> box is desirable */
>=20
> The implicit assumption is that no color spec other than TC_DEFAULT uses
> the palette. This has been incorrect for a very long time, but was not a
> problem until you could explicitly override the default color-by-z style
> of splot surfaces using another palette option.
>=20
> The fix is
>=20
> --- gnuplot/src/pm3d.c 2006-06-15 08:42:33.000000000 -0700
> +++ gnuplot-cvs/src/pm3d.c 2006-09-22 21:25:10.000000000 -0700
> @@ -999,8 +999,8 @@
> return;
> #endif
> if (this_3dplot->lp_properties.use_palette) {
> - if (this_3dplot->lp_properties.pm3d_color.type !=3D TC_DEFAULT)
> - /* can this really happen? for which syntax? */
> + int type =3D this_3dplot->lp_properties.pm3d_color.type;
> + if (type =3D=3D TC_LT || type =3D=3D TC_LINESTYLE || type =3D=3D TC_RGB)
> want_palette_but_not_colorbox =3D TRUE;
> /* don't return yet -- decide later whether showing color box is desir=
able
> */
> else
>=20
Ethan,
I applied the patch to pm3d.c and did make, make install, and it does solve
the problem for me. Thanks.
Joe
|
