[Rd] followup to graphics bug #414

[Paul Murrell]

hi

i have committed a fix for this bug into the development version.

The idea is that, for devices which canClip, R still does some preclipping
to the device
extent.  This stops stupidly large numbers being sent to the device, but
there is a penalty in that two sets of clipping occurs.  Note that this
preclipping occurs in the graphics engine to  avoid the need for per-device
checks.  For more information, see the latex file included below.

paul


---snip---


\documentclass{article}
\title{Changes to Clipping in R}
\author{Paul Murrell}
\begin{document}
\maketitle

All devices have a {\tt canClip} field which indicates whether they
have clipping facilities.  Previously,
if this field was {\tt true} then R used to
delegate all clipping to the device.  R has its own clipping code (in
{\tt graphics.c}) for devices which cannot do the clipping themselves.

Note that R's clipping is inferior to a device's clipping (which is why we
let the device do the clipping if it can).  For example, R's text
clipping completely clips text if the text intersects the boundary of
the clipping region at all (i.e., text is only drawn if it lies wholly
within the clipping region).

\section*{The Problem}

Devices which can clip still have problems with (for example) very large
numbers.  For example, if you try to draw a line which is several feet
off the edge of an X11 window or a Postscript page, the device will fall
over.

\section*{The Solution}

For devices which {\tt canClip}, R does some ``preclipping'' to the device
extent.  This removes the possibility of ridiculously large numbers being
sent to a device.  The device is still responsible for any further clipping.
For devices which cannot clip, R does all of the clipping (as before).

This preclipping occurs at the level of graphical primitives (i.e.,
{\tt GLine}, {\tt GPolyline}, {\tt GPolygon}, {\tt GRect}, {\tt GCircle},
and {\tt GText}).
Only text is a special case.  In general, any part of the graphical
primitive which lies outside of the device extent gets clipped.  This means
that the device only gets sent graphical primitives which lie entirely
within the device extent.  Because R's text clipping is pretty crude,
this policy is a bit of overkill, so
if the device {\tt canClip} and the text intersects the device boundary,
the text is sent unaltered to the device.  It is assumed that, if a
piece of text intersects the boundary of the device then it cannot extend
a ridiculous distance outside of the device (unless it is a VERY long
piece of text, or a VERY large font is being used).

There will be a speed penalty for devices which {\tt canClip} because there
will now be two sets of clipping occurring (R clips to the device, then
the device clips to the current setting of {\tt par("xpd")}).  This may
affect X11 and Windows devices - don't know by how much.

\section*{Addendum}

The Postscript device was not doing any clipping, despite the fact that
Postscript has full clipping capabilities.  This has been changed so that
Postscript devices now {\tt canClip}.  This should improve the text
clipping on Postscript output (which used to use R's crude text clipping).

\end{document}



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