similar to: support for polygons with holes

Hi This is for developers of extension packages that provide extra *graphics devices* for R. In the *development* version of R, support has been added to the graphics engine for sending raster images (bitmaps) to a graphics device. This consists mainly of two new device functions: dev_Raster() and dev_Cap(). The R_GE_version constant (in GraphicsEngine.h) has been bumped up to 6 as a

On Thu, 4 Aug 2016 at 11:17 Paul Murrell <paul at stat.auckland.ac.nz> wrote: > Hi > > Just to clarify, I think this IS a problem with grid.path() as well as > polypath(). > > Hi, oh dear - sorry about that I appreciate the deeper explanation, I knew about the id aspect in grid, but just forgot in my haste. I'll be more careful with examples if I find any more clues.

Hello, The current xfig device lacks the functionality to set the textspecial flag and use the defaultfont in xfig. This is necessary when you want to export to xfig and use interpreted text (e.g., $ \frac{1}{e}$ gets interpreted by latex). The attached patch adds this functionality. Why would you like to do this? - Use math in labels (e.g., name your variables $r_{xy}$, do a

Hi r72261 in r-devel has modified the graphics device API and bumped R_GE_version in GraphicsEngine.h (to satisfy PR 16951). This means that ... (i) third-party graphics device packages need to be reinstalled. (ii) third-party graphics device packages will ideally need a new version for r-devel. (iii) any packages that make use of getGraphicsEvent() should test against r-devel (and let me

On Thu, 4 Aug 2016 at 17:53 Michael Sumner <mdsumner at gmail.com> wrote: > On Thu, 4 Aug 2016 at 11:17 Paul Murrell <paul at stat.auckland.ac.nz> wrote: > >> Hi >> >> Just to clarify, I think this IS a problem with grid.path() as well as >> polypath(). >> >> > Hi, oh dear - sorry about that > > I appreciate the deeper explanation, I

Hi Just to clarify, I think this IS a problem with grid.path() as well as polypath(). For the example you give, grid.path() diverts to drawing a polygon (because there is no 'id' specified), and the NAs in 'x' generate two separate polygons, which get drawn one on top of the other. The correct analogy to the polypath() example is ... x2 <- matrix(x[!is.na(x)], ncol=2)

Hi All, I've started work on a MetaPost device driver (please don't hold your breath). I've copied the XFig driver and renamed everything and this works, I can open the new metapost() and it works exactly like the xfig driver. Now all I have to do is the actual work! Just one question. There is a magic number in ExtEntries as follows: static const R_ExternalMethodDef ExtEntries[] =

Hi All, I've started work on a MetaPost device driver (please don't hold your breath). I've copied the XFig driver and renamed everything and this works, I can open the new metapost() and it works exactly like the xfig driver. Now all I have to do is the actual work! Just one question. There is a magic number in ExtEntries as follows: static const R_ExternalMethodDef ExtEntries[] =

Hello, it's probably worth adding that this is not a problem with pathGrob, only polypath. This code is sufficient to demonstrate the problem in Windows. ## overlapping, both clock-wise x <- cbind(c(.1, .1, .6, .6, NA, .4, .4, .9, .9), c(.1, .6, .6, .1, NA, .4, .9, .9, .4)) ## only a problem on Windows windows() and png() plot(x);polypath(x, rule = "winding", col =

Hi, I see different results in png() and pdf() for polypath() on Windows when using the "winding" rule ## overlapping, both clock-wise x <- cbind(c(.1, .1, .6, .6, NA, .4, .4, .9, .9), c(.1, .6, .6, .1, NA, .4, .9, .9, .4)) pfun <- function() { plot(x) polypath(x * 0.8 + 0.2, rule = "winding", col = "#BEBEBE80") polypath(x, rule =

The header file still contains the old places for some code that is now in the 'module' section: * currently existing device drivers: * FILE driver name prefix * ---------------------- ------------------ * ../main/devPS.c PS _and_ XFig * ../main/devPicTeX.c PicTeX * ../unix/X11/devX11.c X11 * ../gnuwin32/devga.c GA * ../unix/gnome/devGTK.c GTK * ../unix/gnome/devGNOME.c

Hi there, I want to create plots with some kind of 'complex' axis labelling of the form $\dot{V}$ and integrate those plots into a LaTeX document. What is the best way to go? I've figured out, that the 'plotmath' commands are somewhat limited (at least I wasn't able to get the $\dot{V}$ generated) and that plots with 'plotmath'-axes wouldn't export

Hy (I hope this is the right list). 1. Mac porting I'm finishing the porting of R for Mac. I hope to finish it for the end of september. Thanks to the porting of R 0.64 by Ross (that he gave me) I succeded in this porting. This is the current state: Both R 1.1.1. and 1.2.0 works with minor modification to the original code. The Macintosh device has been updated to the new version of

Just got trapped by inconsistency of name of first argument for file-based graphics devices. Both 'file' and 'filename' are currently in use depending on the device. I ran on a machine without PNG support which my code used postscript as the backup device and choked here. > do.call(device, list(filename = pathname, height = height,

Greetings- I'm aware that there's no documentation for pictex available easily (that is, without purchasing it). I'm wondering if someone can help me with a simple task. When generating a plot using pictex() from R, one of the commands I use is mtext("Dimension 2: L=xxxx", side=2, line=3) when using X11(), this appears vertically along the Y axis; when using pictex(), it

There appears to be a bug in the R xfig() driver. When I run a simple example, eg > data(InsectSprays) > boxplot(count ~ spray, data = InsectSprays, col = "lightgray") the boxplot is fine. Doing the same thing after > xfig(file='test.fig') and then opening in Xfig (ver3.2 patchlevel 2) on my Linux box produces boxplots where the boxes, although correctly shaded in,

There appears to be a bug in the R xfig() driver. When I run a simple example, eg > data(InsectSprays) > boxplot(count ~ spray, data = InsectSprays, col = "lightgray") the boxplot is fine. Doing the same thing after > xfig(file='test.fig') and then opening in Xfig (ver3.2 patchlevel 2) on my Linux box produces boxplots where the boxes, although correctly shaded in,

Dear all, I am sending a patch for extending pdf device to embed popup text and web links. I implemented this feature by using annotation object, a interactive feature of pdf. You can see a sample code for using this feature in the following, and sample pdf is in

GCC 7.0.1 can determine if there is likely to be sufficient space in the output buffer when using sprintf/snprintf, based on the format string. The errors were all either of this form: bindtests.c:717:29: error: '%zu' directive output may be truncated writing between 1 and 19 bytes into a region of size 16 [-Werror=format-truncation=] snprintf (strs[i], 16, "%zu", i);

GCC 7 complains that the fixed size buffers are not large enough (at least in theory) when using ‘-O3 -mtune=broadwell’. --- daemon/devsparts.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/daemon/devsparts.c b/daemon/devsparts.c index 584e7d8b8..eac79197e 100644 --- a/daemon/devsparts.c +++ b/daemon/devsparts.c @@ -125,13 +125,16 @@ foreach_block_device