Re: crash bug in pdf terminal

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

Ethan Merritt wrote:

>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?
>

Probably did and it went right past me, sorry.

>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. 
>

Reminds me of the image stuff.  First I translated the orientation of 
the image (without moving data around) to just one orientation. 
 Sometimes one can write routines with absolute values and such to get 
proper behavior without "getting ones footing", but often it comes out 
so obfuscated that it's tedious to work with at a later time.  So yeah, 
picking an order early on is fine.  (But choose notation to reflect 
that, for example if order doesn't matter it might be x1, x2.  If it 
does, then perhaps xlow, xhigh.)

>>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.
>

Oh yeah, those situations where the lines go randomly off into space, 
often seen when zooming, right?

OK, I'm content to just kludge the above on my system and fix my 
immediate problem.  If later you want me to pick a few terminal drivers 
to fix up the unsigned/signed inconsistencies, let me know.

Dan