Re: Bug in image code ?

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

Daniel J Sebald wrote:
> Then again, should it be the core's responsibility to deal with boundary 
> checks if ultimately these terminal parameters come from the terminal 
> driver?  

The parameters come from the driver, but the data being plotted don't.
By the time they arrive in the driver, they should be usable by it, i.e. 
within the terminal coordinate range.

 > If yes, then where should the boundary checks be placed?  As
> part of map_x() and map_y()?  

No.  Clipping depends on the primitive being drawn, so it can't be done 
by just clipping individual coordinates.  We already have quite a 
collection of special clipping functions, for that reason:

	cliptorange
	clip_point
	clip_line
	clip_move / clip_vector
	clip_put_text
	clip_put_text_just
	edge_intersect
	edge_intersect_steps
	edge_intersect_fsteps
	two_edge_intersect
	two_edge_intersect_steps
	two_edge_intersect_fsteps
	bound_intersect
	edge3d_intersect
	two_edge3d_intersect

Some of those are misnomers, but they all handle clipping either to the
graph box interior, or to the page, for various primitives or plotting 
styles.

But clipping should indeed typically happen closely before map_x() is 
called, because that's where data get transformed from doubles to 
terminal coordinates.  I.e. searching for calls of map_x() can help 
locate the positions that need to be checked if clipping is being 
handled correctly.  The traditional plot style handlers (plot_lines() & 
friends) handle clipping by checking input data a couple of processing 
steps before they ever reach map_x() --- that's what INRANGE/OUTRANGE 
are about.  plot_image_...() doesn't.

The problem is that different graphical primitives need different 
clipping techniques.