Re: Argh: Why are arrows clipped to the graph?

[Harald H. <h.h...@tu...>]

On Wed, 9 Nov 2005, Ethan Merritt wrote:

> On Wednesday 09 November 2005 12:49 pm, Harald Harders wrote:
> > Ethan,
> >
> > please tell me the cause why this plot file only plots two arrows in
> > total and one partly?
>
> Damn.  Well, I added a work-around for the clipping problem
> reported by Juergen Wieferink.  The problem, and the work-around
> patch, were circulated. Juergen reported that the work-around
> was successful, so I put it in cvs, but it appears to have broken
> your intended use.
>
> I will revert the (1-line) patch that fixed Juergen's problem,
> leaving us where we were before.

I have changed term_start_plot() locally to set far too big canvas
coordinates and also reverted the patch. This works for me because I am
only using Postscript-Based terminals.

> > Of course, arrows produced by a plot command are supposed to be bounded by
> > the graph boundaries. But 'set arrow' has to enable the user to put them
> > everywhere within the canvas.
>
> Yes....   But how to do this when the postscript driver does not
> tell us how big its canvas is?

I once have provided a patch that worked, storing both the term boundaries
as they are now and the canvas size. It wasn't applied to cvs. I remember
that you were one of the people that complained that this was not the
right way to do it. But it worked.

> For that matter, you yourself have been complaining about buggy
> clipping and contributing patches to fix it.  So how do you come
> around now to saying it all "worked fine"?

It used to work fine with postscript ages ago. Then, some clipping
routines were added that broke large plots. I have added a working patch.
CVS was changed again and broke even more and made my patch not working
anymore. I am not willing to do further work on this topic. I just want to
get a working gnuplot that provides the usage of the hole canvas even if
it has strange screen coordinate. And I want to preserve these strange
screen coordinates (at least as an option) since a change would break
hundreds of old scripts. (We do not have to discuss that a better size
mechanism should be added, but added, not replaced).

> I welcome your help in fixing this mess.  As we discussed,
> there needs to be a size option to the "set term post ..."
> command that lets you specify how big the bounding box is.

Yes, in addition to the current behaviour. First, the current behaviour
has to be fixed. The only way to do this is to change the meaning of some
variables and add more, unfortunately:

term->xmax means the position, where the screen coordinate is 1
term->ymax means the position, where the screen coordinate is 1
term->xcanvas is the maximal screen coordinate in the canvas
term->ycanvas is the second maximal screen coordinate in the canvas

This has been provided by my rejected patch, to remind you once again.

> Secondly, the postscript terminal calculates its own plotting
> limits internally but never tells the core code what they are.
> That needs to be fixed also.

Has been available.

> Finally, we need to agree on what is or is not enforced with
> regards to plotting outside the canvas limits.  I continue
> to maintain that this should be categorically prevented, by
> clipping to the current canvas in the core routines.

I agree.

> I.e. no more setting size greater than 1.0.

I definitely do not agree. I agree that the default way should be to have
upper right canvas corner has screen coordinates 1,1. And it is definitely
nonsense to allow reduction of size below 1.0 but to disallow an increase.
Either the upper right corner is 1,1 in all cases or everything is
allowed. Since the old and current behaviour allows sizes different from
one, this has to be preserved: To preserve the compatibility to old
scripts, the old behaviour definitely has to be preserved. For me, this
would mean that hundreds of old scripts would not work anymore.
And I am sure that many many others would have the same problem. Beware
that in Postscript this was the only possibility to produce plots in a
different size than 1,1. Thus, every postscript plot in a non-default size
would be affected.

I propose to rename the command to change the canvas size to
'set size canvas' instead of 'set size' before 'set terminal' and to
maintain the rest of the current behaviour. It would be okay to change one
single line in all my scripts.

> But even if you all over-rule me on that one, we still need
> to get the different drivers to behave the same way with regard
> to size > 1.

With 'set size canvas' this would be no problem.

> But even if you all over-rule me on that one, we still need
> to get the different drivers to behave the same way with regard
> to size > 1.

Try asdf.gpl:
In the first three examples, the canvas is changed to 1,2 and the plot
scaled accordingly, without the recent one-line-change in gnuplot (and
with ignored canvas clipping), the arrows are printed correctly. In xfig
and png, the text above screen 1 is ignored.
x11 scales the plot and and scales the screen coordinate system, but does
not change the canvas, i.e., window size.

It sounds strange that png produces a 320x480 picture after requesting a
320x240 picture. But it is consistent.

Which other terminals do not work similarly? If it is not wanted to be
able to change window sizes of interactive terminals from within gnuplot
(why not?), they have to be exceptions.

Best regards
Harald

PS: I still think that introducing absolute measures as mm, inch, etc.
would be a good idea. But before starting work on that, the old behaviour
has to be fixed.

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de