Re: General bug - No out of bounds checking on 3D coordinates

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

On Mon, 5 Jul 2004, Daniel J Sebald wrote:

> I don't understand why negative coordinates is an error.  Conceptually, 
> it's as though our view port is from (0, 0) to (x_max, y_max). 
>  Certainly there are some situations where the graphical element may 
> make no sense to be outside that range.  But the decision if that is a 
> problem or not lies at the very last use, inside the driver.

Not really.  The terminal driver can only do what I would refer to as
"emergency clipping".  I.e. if a point passed to the driver is outside the
viewport, but the output format can't handle that, the gnuplot terminal
driver will have to deal with that, probably by discarding the entire
primitive being drawn.  That appears to be the case for our PDF driver.

But the globally missing clipping is one that has to be done by the core
of gnuplot.  It has to be done at a layer of the program where information
about what the user intended is still available.

Summing it up, map3d_xy would be exactly the wrong place to try and do
clipping in: it knows neither the terminal, nor the user's intention.
About the only thing this function can do is detect the problem, but
it can't administer the cure.

[On a side note:]
> There is one thing about the terminal scheme that 
> doesn't have a solid concept, or at least I don't recognize it.  It is 
> how to have "default" routines of a driver.  

That's what the do_whatever() routines in term.c are for.  For functions
that are required, a driver can register those directly.  It can even
just supply a zero (i.e. a NULL function pointer) and change_term() will
fill in the right default handler.

Unfortunately the NULL pointer replacement aspect of this scheme is only
good for one level of inheritance, i.e. there's a single, somewhat virtual
"base" terminal driver, using only the fallback routines, and a given
driver can either use those, or implement its own overrides.   For doing
real inheritance, we have to refer to what in C++ parlance would be
caused "mangled" method names, e.g. in epslatex.trm, which registers
the postscript driver's PM3D functions to itself, turning itself into
something of a derived class of post.trm.  

Hmmm... now that I'm thinking about it, it could be a neat idea to move
these "base class" functions into a *.trm driver of their own, if only to
get them out of term.c.

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