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

Dots - consistency across terminals

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

The postscript and pdf terminals plots dots as a zero length vector
using the current linewidth. This means that 
	plot <foo> with dots lw 1, <baz> with dots lw 10
produces two different dot sizes.

Other terminals do not do this. Should they?

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

Version 4.2 release plans

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

Unless someone chimes in with a set of new problems, 
I propose to put out a third and hopefully final release candidate
next week.  If all goes well, the plan is that the final 4.2 release
would be identical to -rc3 except for the various versioning tags

Changes since 4.2-rc2
=====================
- Document deprecation of "set size" to change image file size in pixels.
  (But version 4.0 behaviour is still maintained for default 'set term')
- Explicit size in terminal commands (e.g. "set term png size 500,300")
  guarantees output image size in pixels.
- 2D back/front settings are also honored in 3D plots with "set view map"
- Allow for quoted strings in csv data files.
- orientation of images drawn by "with image" is corrected for axis direction.
- Multi-dimensional parameters to "binary" and "with image" plot commands are
  now separated by colons rather than commas, and may be variables.
- In anticipation of libgd 2.0.34, gd.trm now checks for error from gdImageCreate
- Update Japanese documentation patch for terminals


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

Re: Vertical centering inconsistency

[m s. <mw...@us...>]

> ----- Original Message -----
> From: "Ethan A Merritt" <merritt@u.washington.edu>
> To: "m sutton" <mw...@us...>
> Subject: Vertical centering inconsistency [was: Splot map and gd.trm bugs=
 (long)]
> Date: Fri, 22 Dec 2006 16:12:08 -0800
>=20
>=20
> On Thursday 21 December 2006 14:49, m sutton wrote:
>=20
> I am going to have to think about this for a while. I am not sure
> that your expectations for vertical centering are matched by core code.
>=20

I did some investigating.  I found that the X11, CGM and Postscript enhance=
d will do vertical centering.  PNG (gd), Postscript, and EMF do not do vert=
ical centering.

This appears to be a terminal dependent issue.  I noticed this because I mo=
stly use X11 and PNG (gd).  Perhaps wrongly, I was expecting to get the sam=
e basic behavior for placing labels.

I'm leaning towards having terminals use the "current" font height when pla=
cing labels instead of the font height associated with the "set term" comma=
nd.  I also think the offset parameter for labels should use the "current" =
font metrics.

Mike Sutton


--=20
Low Prices, Wide Selection of Gas Masks
Everyday low price guarantee. We offer special police discounts and an extr=
emely wide selection of gas masks, filters and huge selection of preparedne=
ss gear.
http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=3D24e08df2353d2e6cb9bae=
3a0e3c8c61e

Re: with filledcurve

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

On Friday 05 January 2007 14:55, Ken Hicks wrote:
> Is there some way to adjust the color palette for the "with filledcurve"
> option?
> 
> Of course, adding "lt #" at the end will change the color to one of the
> curve colors, but on my X11 system, there are only 8 colors (even though
> there are 32 linetypes).  If I could adjust the color palette for the
> linetypes, then this would solve the problem.  But right now, I can only use
> a very limited number of colors for X11 and postscript terminals.

Version 4.2 and cvs code base both support full 24-but rgb color specs.
For convenience you can also give one of the pre-defined color names
listed by
    "show palette colornames"

Examples:
	plot "foo" using 1:2:3 with filledcurve lt rgb "dark-goldenrod"
	plot "baz" using 1:2 with filledcurve lt rgb "#ffaabb"

See also on-line demos of color choice options
	http://gnuplot.sourceforge.net/demo_4.2/rainbow.html
	http://gnuplot.sourceforge.net/demo_4.2/rgb_variable.html

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

with filledcurve

[Ken H. <hi...@oh...>]

Is there some way to adjust the color palette for the "with filledcurve"
option?

Of course, adding "lt #" at the end will change the color to one of the
curve colors, but on my X11 system, there are only 8 colors (even though
there are 32 linetypes).  If I could adjust the color palette for the
linetypes, then this would solve the problem.  But right now, I can only use
a very limited number of colors for X11 and postscript terminals.

Thanks,
Ken Hicks

Re: Gnuplot qua Web-Service

[Jonathan T. <jt...@ae...>]

I wrote
| Even if you completely shut off gnuplot's ability to fork shells
| and run other commands, gnuplot is very likely not secure against
| malicious inputs.  That is, it is very likely that there exist malicious
| gnuplot command sequences that could trigger a buffer overflow, allowing
| the attacker to execute arbitrary code of her choosing in place of gnuplot.

On Sat, 30 Dec 2006, Daniel J Sebald wrote:
> I'm not following what you are saying.  Are you saying that gnuplot can plot
> some big files and hence overwhelm a system?  (Say, just the way my web
> browser with plug-ins will allow unlimited bloated, animated adverts and will
> slow the system to a crawl.)

Hmm.  That's true, but it's not what I was thinking of.  It's basically
a denial-of-service attack.


> Or are you saying gnuplot will lose track of
> some buffer that will overflow and a hacker could stuff a nasty program in
> there without the system knowing?

This is what I meant to imply.

That is, I am saying that unless someone has done a careful security
audit on the entire gnuplot source code (which I don't think is the case),
	[And maybe even if someone *has* done an audit
	-- audits can and do miss things!]
I think it very likely that there exists one or more bugs in gnuplot
which could be exploited (by malicious command and/or data-file input)
to cause the execution of arbitrary attacker-supplied code.

I emphasize that I am *not* suggesting that gnuplot is a particularly
flawed piece of software in this regard.  Rather, I'm simply saying that
Murphy's law suggests that just about *any* piece of software that's
big, complicated, written in C, and uses lots of dynamic data structures,
probably has a few exploitable buffer-overflow bugs lurking somewhere.


> We have been better at not allowing and
> ridding gnuplot of memory leaks.

Yes, this is clearly a good thing to do.  But I don't believe we're
going to fix 100% of these bugs any time soon.  We might well fix N%
for some large N which is still < 100, and that is a very good thing,
but I don't expect to get to 100%.

ciao,

-- 
-- "Jonathan Thornburg -- remove -animal to reply" <jt...@ae...>
   Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
   Golm, Germany, "Old Europe"     http://www.aei.mpg.de/~jthorn/home.html      
   "Washing one's hands of the conflict between the powerful and the
    powerless means to side with the powerful, not to be neutral."
                                      -- quote by Freire / poster by Oxfam

Re: Gnuplot qua Web-Service

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

Jonathan Thornburg wrote:

> Even if you completely shut off gnuplot's ability to fork shells
> and run other commands, gnuplot is very likely not secure against
> malicious inputs.  That is, it is very likely that there exist malicious
> gnuplot command sequences that could trigger a buffer overflow, allowing
> the attacker to execute arbitrary code of her choosing in place of gnuplot.

I'm not following what you are saying.  Are you saying that gnuplot can plot some big files and hence overwhelm a system?  (Say, just the way my web browser with plug-ins will allow unlimited bloated, animated adverts and will slow the system to a crawl.)  Or are you saying gnuplot will lose track of some buffer that will overflow and a hacker could stuff a nasty program in there without the system knowing?  We have been better at not allowing and ridding gnuplot of memory leaks.

Dan

Re: Gnuplot qua Web-Service

[Peter D. <pc...@wi...>]

> You should rather look into chroot and other mechanisms of isolating
> the web server environment itself from the rest of the system.


     Thanks,  Ethan; Gnuplot was pretty easily chrooted, but
as long as there's no harm in excising system() and shell(),
it seems like a prudent micro-component to a macro-security-
model.

--
Peter Danenberg                                           .
wikisophia.org                                           ..:

Re: Gnuplot qua Web-Service

[Peter D. <pc...@wi...>]

> That is, it is very likely that there exist malicious gnuplot
> command sequences that could trigger a buffer overflow....


     Thanks,  Jonathan; I take it Gnuplot isn't a "hardened"
application, then.

     With Schadenfreude, nevertheless, I may take the  usual
precautions (unprivileged user, chroot, resource limits) and
set loose the patched Gnuplot.

--
Peter Danenberg                                           .
wikisophia.org                                           ..:

Re: Gnuplot qua Web-Service

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

On Thursday 28 December 2006 09:08, Peter Danenberg wrote:
>      I'm running Gnuplot as a web-service, and would like to
> castrate its feral shell- and system-facilities; would  any-
> one  mind  inspecting  the  attached  patch to command.c for
> unintended consequences?

The particular code chunk you are eviscerating is only the
tip of the iceberg [to mix metaphors hideously]. 

Shell substitution and file/pipe creation are built into gnuplot
in multiple places.  Consider statements like
   set print "/var/www/html/index.html";  print pi
Would this trash the main page of your web site?
What about
  plot "/etc/passwd" using 0:(0):1 with labels
or
  plot "< /usr/bin/reboot"

I really don't think that gutting gnuplot's internal code is the
way to approach this.  You should rather look into chroot and
other mechanisms of isolating the web server environment
itself from the rest of the system.

Re: Gnuplot qua Web-Service

[Jonathan T. <jt...@ae...>]

On Thu, 28 Dec 2006, Peter Danenberg wrote:
>      I'm running Gnuplot as a web-service, and would like to
> castrate its feral shell- and system-facilities; would  any-
> one  mind  inspecting  the  attached  patch to command.c for
> unintended consequences?

Even if you completely shut off gnuplot's ability to fork shells
and run other commands, gnuplot is very likely not secure against
malicious inputs.  That is, it is very likely that there exist malicious
gnuplot command sequences that could trigger a buffer overflow, allowing
the attacker to execute arbitrary code of her choosing in place of gnuplot.

Thus, you sould look very carefully at the security risks of allowing
untrusted web users to talk directly to gnuplot -- they might well be
able to take over control of the gnuplot process and use it for malicious
purposes.

ciao,

-- 
-- "Jonathan Thornburg -- remove -animal to reply" <jt...@ae...>
   Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
   Golm, Germany, "Old Europe"     http://www.aei.mpg.de/~jthorn/home.html      
   "Washing one's hands of the conflict between the powerful and the
    powerless means to side with the powerful, not to be neutral."
                                      -- quote by Freire / poster by Oxfam

Gnuplot qua Web-Service

[Peter D. <pc...@wi...>]

(Sorry for the cross-post.)

Salvete,

     I'm running Gnuplot as a web-service, and would like to
castrate its feral shell- and system-facilities; would  any-
one  mind  inspecting  the  attached  patch to command.c for
unintended consequences?

     In particular, I kept:

     screen_ok = false;
     c_token++';

though I'm not sure what they do.

--
Peter Danenberg                                           .
wikisophia.org                                           ..:

Re: writing plot coordinates to a file

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

On Wednesday 27 December 2006 08:46, S.Newhouse wrote:
> 
> Clicking with the middle mouse button on the canvas makes the coordinates of the
> clicked points visible.  Is there a way to get these coordinates to be written
> to a file?  

In version 4.2 the most recent mouse-click coordinates are stored in user
variables MOUSE_X and MOUSE_Y.  So yes, you can print to a file by doing
	set print "coord.out"
	print MOUSE_X, MOUSE_Y

See:  "help mouse variables"
demo: mousevariables.dem

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

writing plot coordinates to a file

[S. N. <se...@ma...>]

I would like to know if it is possible to write "mouse-clicked coordinates" to a
file.

For instance, the command 
 plot sin(x)

produces a plot of the sine function.

Clicking with the middle mouse button on the canvas makes the coordinates of the
clicked points visible.  Is there a way to get these coordinates to be written
to a file?  

If not, I am willing to add a small patch doing this (for my own use until it is
well-tested), but I need to know where in the source code the "mouse-cliced
coordinates" are to be found.  

Thanks for any hints.

-sen

Vertical centering inconsistency [was: Splot map and gd.trm bugs (long)]

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

On Thursday 21 December 2006 14:49, m sutton wrote:
> > 
> > Do you have an actual demo bug that this patch fixes?
> 
> The change is needed because PNG_put_text uses png_state.charh to 
> compute the position of text.  The effect of this is most noticeable 
> when using a font different from the font used with 'set term png'.  
> The label should be centered vertically at 0.  
> Without the fix the bottom of the label is just a hair below zero.

I am going to have to think about this for a while. I am not sure
that your expectations for vertical centering are matched by core code.

If nothing else, I can  easily demonstrate that the postscript
driver exhibits the same effect, and always has.

Consider this script, run through either 4.0 or the current cvs code.
In the t1 case the terminal is opened with a small default font,
while in the t2 case it is opened with a large default font.
Then a single large-font "f+g" is printed at the origin.
Only the t2 case comes out vertically centered.

################################################
set label 1 "f+g" at 0,0 font "Times,30" center
set grid back
set format xy ""
plot sin(x)
#
set term post solid color eps font "Times,3"
set output 't1.eps'
replot
#
set term post solid color eps font "Times,30"
set output 't2.eps'
replot
#
set term post solid color eps font "Times,3" enhanced
set output 't3.eps'
replot
#
set term post solid color eps font "Times,30" enhanced
set output 't4.eps'
replot
################################################

On the other hand, putting the terminal into enhanced text mode
(t3,t4) changes the behaviour to be more like your patched png terminal.
That may be what we want, but if so there is more to it than patching
gd.trm 

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

Re: Splot map and gd.trm bugs (long)

[m s. <mw...@us...>]

> ----- Original Message -----
> From: "Ethan A Merritt" <merritt@u.washington.edu>
> To: "m sutton" <mw...@us...>
> Subject: Re: Splot map and gd.trm bugs (long)
> Date: Sun, 17 Dec 2006 20:44:59 -0800
>=20
>=20
> On Sunday 17 December 2006 20:12, m sutton wrote:
> > > > Did you find a specific place where this is not already being done?
> > > Here is a little patch for gd.trm to help keep the character=20
> > info syncronized.
>=20
> Do you have an actual demo bug that this patch fixes?
> I don't follow why these changes necessary or desirable.
> No text has been printed by either of the code segments you are
> modifying, so I don't see why it is correct to update the variables
> holding the last font used.  After all, the font could easily
> change again before the next text is printed.  Setting the font
> is different from writing a string.
>=20

The change is needed because PNG_put_text uses png_state.charh to compute t=
he position of text.  The effect of this is most noticeable when using a fo=
nt different from the font used with 'set term png'.  The example below use=
s TTF fonts.  I have used sized to exaggerate the problem.  The label shoul=
d be centered vertically at 0.  Without the fix the bottom of the label is =
just a hair below zero.  Below is my test script.

------
set term x11 persist
set style line 98 lt 1 lw 1 lc rgb 'magenta'
set style line 99 lt -1 lw 3 lc rgb 'cyan'
set grid back ls 98
unset key
set xr [-60:60]
set yr [-60:60]
set border front ls 99
png =3D 1
if (png > 0) set term png tiny truecolor butt nocrop size 500,500

if (png >0) set out 'plot-gd-font.png'

if (png < 1) set term x11 2

set title "2D PLOT" font "luxirr,8"
set lab 1 "MY LABELXXXXXXXXX" at 0,0 center font "luxirr,24" offset 0,0 fro=
nt=20
plot '-' w p pt 5 ps 1
0 -20
e




--=20
___________________________________________________
Search for products and services at:
http://search.mail.com

Please include pie chart option in gnuplot

[Andreas K. <And...@di...>]

Hi,

To my surprise I have found that gnuplot cannot construct pie charts.

Yes, I know that some consider pie charts as bad for presenting data, 
but they are nevertheless used by many people, and some find them useful.

Could you please include a possibility to construct pie charts in gnuplot?

Best regards,
Andreas Karlsson

Re: Splot map and gd.trm bugs (long)

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

On Sunday 17 December 2006 20:12, m sutton wrote:
> > 
> > Did you find a specific place where this is not already being done?
> > 
> 
> Here is a little patch for gd.trm to help keep the character info syncronized.

Do you have an actual demo bug that this patch fixes?
I don't follow why these changes necessary or desirable.
No text has been printed by either of the code segments you are
modifying, so I don't see why it is correct to update the variables
holding the last font used.  After all, the font could easily
change again before the next text is printed.  Setting the font
is different from writing a string.




> 
> Index: gd.trm
> ===================================================================
> RCS file: /cvsroot/gnuplot/gnuplot/term/gd.trm,v
> retrieving revision 1.100
> diff -u -r1.100 gd.trm
> --- gd.trm      9 Dec 2006 19:32:44 -0000       1.100
> +++ gd.trm      18 Dec 2006 04:09:42 -0000
> @@ -941,6 +941,8 @@
>         if (!err) {
>             term->h_char = .11 * (float)(brect[2] - brect[0]) + 0.5;
>             term->v_char = 1.1 * (float)(brect[1] - brect[7]) + 0.5;
> +           png_state.charw=term->h_char;
> +           png_state.charh=term->v_char;
>         }
>      }
>  #endif
> @@ -1741,6 +1743,8 @@
>         if (!err) {
>             term->h_char = .11 * (float)(brect[2] - brect[0]) + 0.5;
>             term->v_char = 1.1 * (float)(brect[1] - brect[7]) + 0.5;
> +           png_state.charw=term->h_char;
> +           png_state.charh=term->v_char;
>         }
>      }
>  #endif
> 
> 

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

Re: Splot map and gd.trm bugs (long)

[m s. <mw...@us...>]

> ----- Original Message -----
> From: "Ethan A Merritt" <merritt@u.washington.edu>
> To: gnu...@li..., mw...@us...
> Subject: Re: Splot map and gd.trm bugs (long)
> Date: Sat, 16 Dec 2006 15:48:07 -0800
>=20
>=20
> > I have done some digging through the code and found a couple of
> > issues.  First, gd.trm has two differing variables for storing
> > character size information: term->[vh]_char and png_state.char[wh].
> > These are often set to each other.  However, when finding approximate
> > TTF font info the png_state.char[wh] variables were not being set.  A
> > quick fix is to always set png_state.char[wh] when the TTF font info
> > is determined.
>=20
> Did you find a specific place where this is not already being done?
>=20

Here is a little patch for gd.trm to help keep the character info syncroniz=
ed.

Index: gd.trm
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/gnuplot/gnuplot/term/gd.trm,v
retrieving revision 1.100
diff -u -r1.100 gd.trm
--- gd.trm      9 Dec 2006 19:32:44 -0000       1.100
+++ gd.trm      18 Dec 2006 04:09:42 -0000
@@ -941,6 +941,8 @@
        if (!err) {
            term->h_char =3D .11 * (float)(brect[2] - brect[0]) + 0.5;
            term->v_char =3D 1.1 * (float)(brect[1] - brect[7]) + 0.5;
+           png_state.charw=3Dterm->h_char;
+           png_state.charh=3Dterm->v_char;
        }
     }
 #endif
@@ -1741,6 +1743,8 @@
        if (!err) {
            term->h_char =3D .11 * (float)(brect[2] - brect[0]) + 0.5;
            term->v_char =3D 1.1 * (float)(brect[1] - brect[7]) + 0.5;
+           png_state.charw=3Dterm->h_char;
+           png_state.charh=3Dterm->v_char;
        }
     }
 #endif


--=20

Search for products and services at:=20
http://search.mail.com

Re: Splot map and gd.trm bugs (long)

[m s. <mw...@us...>]

> ----- Original Message -----
> From: "Ethan A Merritt" <merritt@u.washington.edu>
> To: "Mike Sutton" <mw...@us...>, gnu...@li...
> Subject: Re: Splot map and gd.trm bugs (long)
> Date: Sun, 17 Dec 2006 10:09:42 -0800

> But here's another one, with a proposed fix for the axis/grid/border bug
> in 3D plots with "set view map".  It explicitly passes the current layer
> (LAYER_FRONT or LAYER_BACK) to draw_3d_graphbox() so that in the case of
> "set view map" the individual plot elements can be checked against their
> 2D settings for front/back.
>=20

I was getting BACKGRID/ALLGRID/FRONTGRID settings confused with the layers =
settings.  Your patch seems to do the trick.

Mike Sutton


--=20

Search for products and services at:=20
http://search.mail.com

Re: Splot map and gd.trm bugs (long)

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

On Sunday 17 December 2006 10:09, Ethan A Merritt wrote:
> 
> I have not yet looked into the colorbox problem.

The colorbox is shown in both your plots because you have
explicitly said "set pm3d".   This behaviour seems reasonable to me,
since it is now possible to use pm3d colors in 2D as well.


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

Re: Splot map and gd.trm bugs (long)

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

On Saturday 16 December 2006 19:25, Mike Sutton wrote:
> 
> Attached is a PNG that shows how the double draw of tics and labels creates 
> fuzziness.  I couldn't think of a better word than that.

OK. So by 'fuzziness' you mean that the label was printed twice, and the
two copies do not superimpose perfectly.  That is the same bug as the
grid being printed twice.

> p.s. what is the general consensus about sending attachments to the mailing 
> list?

Dunno.
But here's another one, with a proposed fix for the axis/grid/border bug
in 3D plots with "set view map".  It explicitly passes the current layer
(LAYER_FRONT or LAYER_BACK) to draw_3d_graphbox() so that in the case of
"set view map" the individual plot elements can be checked against their
2D settings for front/back.

I have not yet looked into the colorbox problem.


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

Re: Splot map and gd.trm bugs (long)

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

mw...@us... wrote:
> I'm using the CVS head.
> 
> I noticed a very weird problem when using 'set view map' in conjunction

[snip]

Mike,

It is alright with me if you'd like to put some effort into cleaning up tic placement in 3D.  However, let me say a couple things.

As Ethan pointed out, there are a few issues.  One is to unify code when possible, such as the example of "map" and 2D drawing should basically be the same routine.  Another issue for which I think there should be some discussion is consistent and intuitive plot layout in terms of white space at the margins and color box placement.  When I look at 3D plots, sometimes things aren't quite in balance the way I think they should be.  There is an element of not knowing the extent in 2D of a 3D image (project).  But perhaps we can come up with something to make better use of the space by default.

Also, if we are going the route of cleaning up tic placement in one or two modes, I'd like to have the group review the patch I created for tic placement (I think it was time axis or something, I can't remember exactly what) before things get changed too much that the patch needs a lot of redoing.  I'm pretty sure I can convince people of why it is a worthwhile patch... It solved a bug of dropping a tic mark at the end of an axis.

Dan

Re: Splot map and gd.trm bugs (long)

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

On Saturday 16 December 2006 14:29, Mike Sutton wrote:
> 
> I noticed a very weird problem when using 'set view map' in conjunction
> with 'splot' (aka. splot map).  The symptom was noticed when I created
> some PNG files using TTF fonts.  The x & y tics and labels looked
> fuzzy.  I initially thought the problem was is gd.trm.  However, I
> realized that the tics and labels were actually being drawn twice.
> Then I realized that the grid was not being drawn in the back as
> specified.  This was all very confusing.

You have identified 2 or maybe 3 separate bugs here.

1) The axis/grid/border lines in "set view map" should be handled as
   they are for 2D plots, not 3D plots

2) For some sequence of commands (illustrated by your script) the
   selection of the colorbox is not reset

3? (gd.trm only) If the font for the plot title is not found, then
   initialization of the default font for the rest of the plot may
   be corrupted. I thought this bug had been fixed, but perhaps it
   has resurfaced.

> I have done some digging through the code and found a couple of
> issues.  First, gd.trm has two differing variables for storing
> character size information: term->[vh]_char and png_state.char[wh].
> These are often set to each other.  However, when finding approximate
> TTF font info the png_state.char[wh] variables were not being set.  A
> quick fix is to always set png_state.char[wh] when the TTF font info
> is determined.

Did you find a specific place where this is not already being done?

Although the situation is not ideal, the two sets of variables are not
quite the same.  The term->[vh]_char values are exported by each terminal
to the core routines so that they can estimate the space that will be
required for various labels, titles and plot elements.
The true values of the ttf font properties used for any particular 
element are not known at that point, only those of the default font.

The png_state.* variables are used only internally, and should correspond
to the _current_ values (i.e. those of the most recent font used). But
these will change every time an explicit font or font size is encountered.
You wouldn't in general want to export these via term->[vh]_char because
there is no particular expectation that they will be used in the future
for subsequent plot elements.

> So when the title font is different or invalid, the 
> character size data is wrong when the axis text is drawn.  This will
> removed the fuzziness from the PNG plot.

I'm not following you here.  What does any of this have to do
with "fuzziness"?

> I found that the drawing order for 2D and 3D were different.  It
> appears that the layer settings are not working properly in the 3D
> code.  I discovered that draw_3d_graphbox is called repeatedly and
> that is why the tics and axis labels are drawn twice.  The x & y tics
> and labels are drawn every time draw_3d_graphbox is called.

There may be bug, but at least let me explain the logic as I understand
it.  The 3D code unfortunately does not do true depth-ordering for all
plot elements.  Instead it provides various partial solutions. For
lines and grid surfaces (and more recently points and labels) there is 
"set hidden3d".  For pm3d surfaces there is "set pm3d depthorder".
The axes, grid, and border lines are not handled by either of these.
Instead the code tries to draw them in three passes, back/middle/front,
in the hope that this coarse depth-ordering is good enough for most
plots. 

> I suggest that draw_3d_graphbox be broken up into three routines:
> place_grid3d, plot_border3d, and place_axis_labels3d.  This would
> allow finer control over drawing each part on the proper layer.  I'm
> willing to tackle the break up of the routine if its agreed upon.

I don't see how that would help at all.  I think the true fix is to
fold the axes, border, and grid into the general depth-sorting that
is done by hidden3d.

However, that whole logic and procedure was intended for true 3D plots.
It's relevance to "set view map" is dubious.  Large chunks of the
"set view map" code are shared with 2D, and probably more should be.
It is conceivable that a bug exists currently such that some element
is actually drawn twice, once by the 2D code and again by the 3D code.
If you have found such an example, we should definitely quash that bug.

> The other thing I noticed is that the pre-processor token
> USE_GRID_LAYERS is set in graph3d.c and is not used as a configuration
> option anywhere.  Can it be eliminated?

If you mean eliminate the conditional test and just use the new code
always, then I think yes.  I'm figuring that once 4.2 is officially
released we can have a grand round of removing dead code and conditional
tests for features that are no longer marked EXPERIMENTAL.
 
> Below is the a script that illustrates the problem using some
> exaggerated settings.  You will notice that the grid is supposed to be
> in the back and the border in the front.  However, the result has the
> grid in front over the border and the data points in the 3D splot map
> but not the 2D plot.  

The front/back option for grid and border is only check for 2D plots.
3D plots follow the more complicated scheme I outlined above.  The bug
is that "set view map" should cause the 2D procedure to be used rather
than the 3D procedure.

> Another odd thing is that the colorbox shows up  on the 2D plot when
> its not needed. 

That's a separate bug. It looks like something is not reset properly
at the end of the previous plot. I wonder what?


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

Splot map and gd.trm bugs (long)

[<mw...@us...>]

I'm using the CVS head.

I noticed a very weird problem when using 'set view map' in conjunction
with 'splot' (aka. splot map).  The symptom was noticed when I created
some PNG files using TTF fonts.  The x & y tics and labels looked
fuzzy.  I initially thought the problem was is gd.trm.  However, I
realized that the tics and labels were actually being drawn twice.
Then I realized that the grid was not being drawn in the back as
specified.  This was all very confusing.

I have done some digging through the code and found a couple of
issues.  First, gd.trm has two differing variables for storing
character size information: term->[vh]_char and png_state.char[wh].
These are often set to each other.  However, when finding approximate
TTF font info the png_state.char[wh] variables were not being set.  A
quick fix is to always set png_state.char[wh] when the TTF font info
is determined.  So when the title font is different or invalid, the
character size data is wrong when the axis text is drawn.  This will
removed the fuzziness from the PNG plot.

I'm thinking that gd.trm should only have one variable that holds the
character size info and that should probably be term->[vh]_char.

It does nothing to address why the tics and labels are being drawn
twice.  So, I began comparing the 2D plotting stuff to the 3D stuff.

I found that the drawing order for 2D and 3D were different.  It
appears that the layer settings are not working properly in the 3D
code.  I discovered that draw_3d_graphbox is called repeatedly and
that is why the tics and axis labels are drawn twice.  The x & y tics
and labels are drawn every time draw_3d_graphbox is called.

I suggest that draw_3d_graphbox be broken up into three routines:
place_grid3d, plot_border3d, and place_axis_labels3d.  This would
allow finer control over drawing each part on the proper layer.  I'm
willing to tackle the break up of the routine if its agreed upon.

The other thing I noticed is that the pre-processor token
USE_GRID_LAYERS is set in graph3d.c and is not used as a configuration
option anywhere.  Can it be eliminated?

Below is the a script that illustrates the problem using some
exaggerated settings.  You will notice that the grid is supposed to be
in the back and the border in the front.  However, the result has the
grid in front over the border and the data points in the 3D splot map
but not the 2D plot.  Another odd thing is that the colorbox shows up
on the 2D plot when its not needed.

Mike Sutton

set term x11 persist
set style line 98 lt 1 lw 1 lc rgb 'magenta'
set style line 99 lt -1 lw 3 lc rgb 'cyan'
set grid back ls 98
unset key
set xr [-60:60]
set yr [-60:60]
set xlabel "MY Xlabel"
set ylabel "MY Ylabel"
set cblabel "MY CB"
set border front ls 99
set pm3d
set view map
png = 0
if (png > 0) set term png  giant truecolor butt nocrop size 1280,1024;\
  set term png font "luxirr,8"; \
  set out 'splot-gd.png'
set title "3D SPLOT MAP" font "luxirr,40"
#set title font "luxirrdd,40"
if (png >0) set term png font "luxirr,16"

splot "mike2.dat" w p pt 5 ps 4 lc pal

if (png < 1) set term x11 2
if (png >0) set out 'plot-gd.png'
set title "2D PLOT"

plot 'mike2.dat' w p pt 5 ps 4


-- data 
0  0   44
0  10  -2 
-30. 20 8
50 30 -5
-33 -44 10