Re: Ethans patch of 2005-10-15

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

On Sunday 16 October 2005 12:02 pm, Harald Harders wrote:
>
> But I still do not understand what it does. Because the variable canvas
> is a pure copy of  { 0, term->xmax, 0, term->ymax }. Why do we now have
> the term->xmax and term->ymax and a copy of them?

Because it abstracts the notion of a clipping area to the generic case.
The 15 Oct patch by itself does nothing. Previously the routines 
clip_line() and clip_point() were hard-coded to clip against the plot
boundaries.  Now they have been generalized to clip against whatever
the current clipping area is.

> What does it really do?

"Patience, grasshopper". It paves the way.

It is much cleaner to change the infrastructure first,
with *no* intentional change in program behaviour, and then
introduce actual changes in separate incremental steps.
It makes it a whole lot easier to pinpoint the source of
a bug later on.

> Still, the clipping of
> labels and arrow does not work at all.

Indeed.  But today's patchset adds generic clipping of arrows,
fixing bug  #1187336  and a bunch of others.  Give me another
hour or so of running test scripts though it.

And following that I will re-visit the clipping of labels.
That's a more difficult problem, however, because gnuplot itself
is not very good at predicting whether a text string will
exceed the clipping limits.

> Try this:
>
> set size 2,2

I am not interested in fixing bugs that arise from
setting size > 1.    I thought we had agreed to work
toward making such kludges unnecessary.



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742