Re: Zoom peculiarities

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

On Thu, 13 May 2004, Daniel J Sebald wrote:

> I see what is happening now.  Impulses should behave so that negative 
> numbers have a line appearing below y=0.  However, it appears that the 
> current behavior does the same thing for *any* border that appears at 
> the bottom of the plot.  

More to the point, it'll try to draw them towards the border y=0 would
lie beyond, if y=0 isn't inside the yrange of the plot.  But something
went wrong in that area, so the actual baseline may not always be the 
border itself, but will end up slightly outside the actual y range.

You can reproduce the problem without involving the mouse:

	set yrange [35.5:*]
	load 'using.dem'
	# break after the first plot.

You'll find the impulses end at 35 instead of 35.5, which is below the
bottom border.  Looks like they were auto-extended to the nearest tick
position, like autoscaled ranges.  This has to be investigated at 
source level.

>  For some reason, gnuplot thinks it can plot outside the bottom border. 

Not quite.  It doesn't really "think" about drawing outside borders
at all.  In technical terms: it doesn't clip all graphical primitives
to the graph window.

> >Workaround: don't zoom in demos; or if you do, remember to unzoom _before_
> >you proceed to the next plot. Using 'unzoom' on a different graph than the
> >one you zoomed on is IMHO begging for trouble.
> >
> 
> So, when unzoomed in the second plot, the ranges go back to [*:*] or 
> something like that.  

No.  They go back to what they were before you started to zoom.  Do it
in '6' mode and you'll see it happening.

> But why should the explicit
> 
> set xrange [1:8]
> 
> be discarded?  

It's not discarded --- it's overruled by "set xrange [-1:24]"
from the first plot which got pulled off the zoom stack by your typing 
'u'.


> Anyway, I don't see how the "each plot has its own 
> settings" would change matters.  

It wouldn't, all on its own.  But it's a nacessary piece of infrastructure
for allowing the next step.  In particular, the mouse interaction could
avoid garbling the global settings, and each new 'plot' command entered
from the command line could reset the mouse code's copy of the settings.

Conceptually, we have two independent streams of commands.  For that to
work without strange surprises like the one you observed, those two
streams of commands have to work on independant sets of status variables,
synchronized only on explicit request.

> If one plot is zoomed and then a second 
> is generated, what will you use for the ranges of the second plot? 

The 'command line' settings.  The idea would be that the mouse interaction
would have its *own* set of settings to play with.  One per simultaneously
open plot window, actually.

> which would mean that the range settings in this command only apply to 
> replot and when a new plot command comes along, the original ranges are 
> used, not the "temp" or "replot" ones.  Also, with the new plot command, 
> these "temp" or "replot" settings are changed to those ranges 
> corresponding to "plot".

You're just reinventing the same scheme I've been talking about ;-)
Except that I wouldn't limit that to the ranges, but have a complete
collections of all gnuplot settings.  

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