Re: crash bug in pdf terminal

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

On Tuesday 26 October 2004 12:30 pm, Daniel J Sebald wrote:
> 
> I think I see the issue now... what you all were probably talking about 
> but I paid no attention.  In the terminal directory, the .trm files all 
> have "unsigned" for coordinates, e.g.,

It isn't just the *.trm files.
In fact I think it is reasonable for the terminal drivers to receive
unsigned coordinates.  The problem comes before that.

Didn't we have this discussion already?

All the internal routines convert coordinates to (unsigned int).
Unfortunately sometimes they convert too soon, i.e. before clipping.
Harald Harders and I have been slowly switching the lower-level
routines over to use integer or double coordinates, and adding
proper clipping code on top of them.  It should now be working
for the newer plot styles (with labels, with filledcurves between,
with vectors) but not yet for all of the older plot styles.

> OK.  I'm getting the feeling this is case of someone having to go 
> through the pain of changing all those "unsigned" coordinate values 
> inside the terminal drivers to "signed".  At least I don't think it 
> should wreck any working behavior.  It can only make bad behavior better.
> 

It is messier than it ought to be because of the way that inverted
axis ranges are implemented.  Every test for out-of-bounds has
to allow for the possibility that the axes limits are stored in 
reverse order.  I'm inclined to say it would be better to change that
first, and only afterwards worry about adding clipping code
everywhere.  But I am not familiar with the history of the axis code,
so I don't know all the places that would be affected. 

> If people are happy with that as a fix, I'm fine with it too.  [Or it 
> could be just
> 
>     double h = (signed) x, v = (signed) y;

Doesn't work.  It only catches the cases that are out of bounds
by virtue of having gone negative.  It doesn't catch all the other
cases of improper clipping.  The proper fix lies in the clipping
code, not the individual drivers.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195