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

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

On Wed, 9 Nov 2005, Ethan Merritt wrote:

> > > > 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.
> > >
> > > I do not recall seeing such a patch.
> > > Could you remind me which one that is?
> > > I don't see anything on SourceForge that seems to match your description.
> >
> > #1104264, Fix buggy clipping of arrows in large splots
> > #1105611, Introduce 'set pagesize' command
> >
> > > > 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.
>
> Err, that feature is not found in either of the patches you mentioned.
>
> The "Fix buggy clipping" patch does not touch any terminal drivers.

And what do the patches

        /* EAM FIXME - Is this a sufficient test for out-of-bounds? */
-       if (x < 0 || x > term->xmax || y < 0 || y > term->ymax) {
+       if ((x < 0) ||
+           (multiplot && (x > term->xmax * global_xsize)) ||
+           (!multiplot && (x > term->xmax * xsize)) ||
+           (y < 0) ||
+           (multiplot && (y > term->ymax * global_ysize)) ||
+           (!multiplot && (y > term->ymax * ysize))) {

and

-    if ((0 < x && x < term->xmax) && (0 < y && y < term->ymax))
+    FPRINTF((stderr,"on_page(): %d,%g   %d,%g\n",
+            term->xmax,global_xsize,term->ymax,global_ysize));
+    if ((0 < x && x < term->xmax * global_xsize)
+       && (0 < y && y < term->ymax * global_ysize))

do? They affect clipping due to a 'set size' before 'set terminal'.
Or what does

-    xleft += t->xmax * xoffset;
-    xright += t->xmax * xoffset;
-    ytop += t->ymax * yoffset;
-    ybot += t->ymax * yoffset;
+    xleft += xpagemax * xoffset;
+    xright += xpagemax * xoffset;
+    ytop += ypagemax * yoffset;
+    ybot += ypagemax * yoffset;

and

-    if (*sx < 0 || *sx > term->xmax || *sy < 0 || *sy > term->ymax)
+    if (*sx < 0 || *sx > xpagemax ||
+       *sy < 0 || *sy > ypagemax) {
+       FPRINTF((stderr,"place_arrow3d: skipping out-of-bounds arrow\n"));

do? Yes, clipping. They do not cover all problems we have now because at
the time I started with the patch only arrows in splots were clipped at
screen 1,1. But the maximal coordinate of set size before set terminal
already was stored independently on the term->xmax and term->ymax. They
worked. I did not say that they were elegant (which they for sure
weren't). But they could have served as a start into the right direction.

> The "set pagesize" patch introduces a pair of global scaled values
> xpagesize and ypagesize, but does not add anything like
> term->canvas_xmin,
> term->canvas_xmax,
> term->canvas_ymin,
> term->canvas_ymax
> which is what you would need in order to do clipping.

Yes, it would be more elegant to do it in the term struct. But, I say it
once again, the old approach exactly did what it was supposed do, but
outside of the struct term. This approach did not have the need to touch
the terminals.

I will be glad if sometimes a working clipping will be available.

Best regards
Harald

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