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

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

Hans-Bernhard Broeker wrote:

>>- Have map3d_xy() call int_error() if the coordinates go negative?
>>    
>>
>
>No.  map3d_xy is far too deep in the basement of gnuplot to output a
>meaningful int_error() message. 
>

Right.

>>- Have map3d_xy() siliently truncate to zero?
>>    
>>
>
>  
>
>>- Have map3d_xy() truncate, but not so silently?
>>    
>>
>
>No to both.  For the same reason: map3d_xy() has no way of knowing how to
>properly clip positions.  E.g. if the actual thing being drawn is a line
>segment, clipping the out-of-range endpoint to the nearest point on the
>viewport border will rotate the entire edge.  I'm quite sure that's not
>sensible behaviour.
>

I agree with that.

>>The cleanest is probably to return an error from map3d_xy, 
>>    
>>
>
>Agreed.
>

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.

>IMHO clipping has to be the duty of the callers of map3d_xy, because only
>they can possibly know what the right reaction should be, or at least
>output an intelligible errors message if they can't seem to find a
>reasonable reaction.
>

I agree with that.  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.  The analogy would be like 
the base routine of an object oriented language; a base routine that can 
be overridden.  A couple examples:  Take clipping a line segment at the 
border.  There are probably some terminal drivers which handle this 
cleanly, and perhaps some that don't.  Well, it's a simple routine, and 
all the terminals that can't handle clipping should instead access a 
single gnuplot routine that does the clipping (and of course that 
routine would in turn call the terminal driver for plotting line 
segments that are within bounds).  The second example might be the image 
routines.  I've recently noticed in PostScript and PDF that "skews" can 
be put in images.  That is, rather than use the PM3D routines to plot an 
image with a skew, all that simply need be done for PostScript and PDF 
is give the appropriate parameters, resulting in a more efficient PS or 
PDF file.  My guess is that not all terminals can do this, so gnuplot or 
terminal drivers should default to using PM3D elements for this option. 
 So here would be the alternatives:

1)  Forget about fairly advanced features as this in PostScript where 
images can be given skew.

2)  At the driver level have some type of default routine containing the 
PM3D method (i.e., little paralellograms for pixels).

3)  At the gnuplot level (graphics.c) deal with this, but have the 
terminal indicate if it can handle skewed images, e.g.

if (term->parameters(HAVE_SKEWED_IMAGES)) {
} else {
}

Another one in this category might be the arrow head/line thickness 
problem.  I'm in the camp who think lines with arrows should have the 
head of the arrow stop exactly at the point given to gnuplot.  The code 
to do this isn't too bad provided one knew the thickness of the line in 
question.  One would want to reuse that code.  Should it be at the 
driver level in an object oriented model (2) or should it be at the 
gnuplot level (3) and get the line thickness from the terminal, e.g., 
term->parameters(LINE_THICKNESS)?  I mean, provided it was pressing 
enough to address the issue?

Dan