From paul@stat.auckland.ac.nz  Tue Mar 21 04:11:00 2000
From: paul@stat.auckland.ac.nz (Paul Murrell)
Date: Tue, 21 Mar 2000 16:11:00 +1200
Subject: [Rd] followup to graphics bug #414
References: <Pine.LNX.4.10.10003201645220.8643-100000@bolker.zoo.ufl.edu> <x2k8ixp662.fsf@blueberry.kubism.ku.dk> <012101bf92c8$89c92ac0$175dd882@stat.auckland.ac.nz> <x266uhupx3.fsf@blueberry.kubism.ku.dk>
Message-ID: <015f01bf92eb$7c17af00$175dd882@stat.auckland.ac.nz>

hi


> > > I suspect it will. The clipping functions are broken with logged axes
> > > on all devices which cannot do their own clipping, and since Paul made
> > > devPS capable of clipping...
> >
> >
> > or it may have just made it a little more sinister.  devices which can
do
> > their own clipping still use the R clipping to preclip to the device
extent.
> > so if you specify a line which extends outside of the device extent (and
you
> > have log axes) it will be (incorrectly) clipped by R before sending on
to
> > the device.
>
> Hmmno.. (well maybe now in the development version.) In R-release, we have
>
>     if (dd->dp.canClip) {
>         GClip(dd);
>         dd->dp.polyline(n, x, y, coords, dd);
>     }
>     else
>         CScliplines(n, x, y, coords, dd);
>
> and CScliplines has the problem. GClip just sets the clip boundary for
> the device.


yes, but in R-release postscript can't clip right ?  if, in r-release we
just changed devPS so that it would clip, then r-release would be ok.
r-devel is broken though because the above code segment has changed.

paul


-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._


[Rd] followup to graphics bug #414
Paul Murrell