On Dec 5, 2009, at 4:11 PM, Romain Francois wrote: > I agree too, I was just trying to put on the balance the amount of work that > would require graphics supporting connections. > > Who's willing to do it ? >
The issue is not the will nor complexity on the GD side, but connections are not exposed outside of R (or at the C level), so there is currently no way to do it (AFAIR). Jeff Horner has proposed a patch long ago and Cairo works with connections if you patch R, but connections are to date still not part of the API. So I suspect the real issue is to create a connection API so packages (and devices) can use it. Cheers, Simon > On 12/05/2009 07:06 PM, Tobias Verbeke wrote: >> >> Hi, >> >> Gabor Grothendieck wrote: >> >>> Its not just the time. Its also the nuisance of having to manage files >>> that >>> I never needed in the first place. >> >> I agree with Gabor that it is more than a 'nice to have'. >> >> There are situations (when integrating R with other >> applications) you don't want to touch a disk and >> manage files afterwards (e.g. when one wants to pass >> a byte string). >> >> A recent question on the topic can be found here: >> >> http://tolstoy.newcastle.edu.au/R/e8/help/09/11/5902.html >> >> Best, >> Tobias >> >>> On Fri, Dec 4, 2009 at 11:01 AM, Romain Francois >>> <romain.franc...@dbmail.com >>>> wrote: >>> >>>> On 12/04/2009 03:19 PM, Gabor Grothendieck wrote: >>>> >>>>> Thanks. >>>>> >>>>> I am looking for the data to be just as if I had read in the png >>>>> file (or >>>>> wmf file or whatever). >>>>> >>>> Hi, >>>> >>>> You are after the binary payload of the rendered graph as a png file. So >>>> you are going to have to go through a png file. >>>> >>>> It would be nice to be able to render to a binary connection, like a >>>> rawConnection, but it seems like an expensive "nice to have" >>>> >>>> >>>> grid.cap seems to give a bitmap and then would >>>>> require some sort of processing to get the png or wmf, etc. form. Also >>>>> note >>>>> that I need it for classic graphics and not just grid graphics. >>>>> >>>> grid.cap does not seem to care, baptiste code uses traditional graphics >>>> >>>> >>>> What I have right now works just as I want it _except_ I have to >>>> create a >>>>> file and then read it back in which seems a waste. >>>>> >>>> Can you measure the time it takes to do dev.off() and readBin ? >>>> >>>> >>>> On Fri, Dec 4, 2009 at 9:06 AM, baptiste auguie< >>>>> baptiste.aug...@googlemail.com> wrote: >>>>> >>>>> Hi, >>>>>> You can use grid.cap, >>>>>> >>>>>> x11() >>>>>> plot(1:10) >>>>>> g = grid.cap() >>>>>> dev.off() >>>>>> str(g) >>>>>> # chr [1:672, 1:671] "white" "white" "white" "white" "white" ... >>>>>> >>>>>> but as far as I understand in ?grid.cap and the underlying code there >>>>>> is no "capGrob" equivalent that wouldn't require opening a new device >>>>>> before capturing the output. >>>>>> >>>>>> I hope I'm mistaken. >>>>>> >>>>>> Best, >>>>>> >>>>>> baptiste >>>>>> >>>>>> 2009/12/4 Gabor Grothendieck<ggrothendi...@gmail.com>: >>>>>> >>>>>>> Currently I have an application that saves the current graphics image >>>>>>> >>>>>> (that >>>>>> >>>>>>> was created with classic graphics or grid graphics) to a file and >>>>>>> then >>>>>>> >>>>>> reads >>>>>> >>>>>>> the file back in using readBin: >>>>>>> >>>>>>> png("my.png") >>>>>>> plot(1:10) >>>>>>> dev.off() >>>>>>> raw.img<- readBin("my.png", "raw", size = 1, n = 100000000) >>>>>>> >>>>>>> (I am doing this on Windows but would like to be able to do it on any >>>>>>> platform.) >>>>>>> >>>>>>> Does the new raster functionality give me any way to get the object >>>>>>> >>>>>> raw.img >>>>>> >>>>>>> without creating the intermediate file, my.png? If so what is the >>>>>>> corresponding code? >>>>>>> >>>>>>> >>>>>>> On Mon, Nov 30, 2009 at 8:17 PM, Paul >>>>>>> Murrell<p.murr...@auckland.ac.nz >>>>>>> wrote: >>>>>>> >>>>>>> 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 marker of this change. >>>>>>>> This means that, at a minimum, all graphics devices should be >>>>>>>> updated >>>>>>>> to >>>>>>>> provide dummy implementations of these new functions that just >>>>>>>> say the >>>>>>>> feature is not yet implemented (see for example the PicTeX and XFig >>>>>>>> >>>>>>> devices >>>>>>> in the 'grDevices' package). >>>>>>>> A full implementation of dev_Raster() should be able to draw a >>>>>>>> raster >>>>>>>> >>>>>>> image >>>>>>> (provided as an array of 32-bit R colors) at any size, possibly >>>>>>> (bilinear) >>>>>>> interpolated (otherwise nearest-neighbour), at any orientation, >>>>>>> and with >>>>>>> a >>>>>>> per-pixel alpha channel. Where these are not natively supported by a >>>>>>>> device, the graphics engine provides some routines for scaling and >>>>>>>> >>>>>>> rotating >>>>>>> raster images (see for example the X11 device). The dev_Cap() >>>>>>> function >>>>>>>> should return a representation of a raster image captured from the >>>>>>>> >>>>>>> current >>>>>>> device. This will only make sense for some devices (see for >>>>>>> example the >>>>>>>> Cairo device in the 'grDevices' package). >>>>>>>> >>>>>>>> A little more information and a couple of small examples are >>>>>>>> provided >>>>>>>> at >>>>>>>> http://developer.r-project.org/Raster/raster-RFC.html >>>>>>>> >>>>>>>> Paul >>>>>>>> -- >>>>>>>> Dr Paul Murrell >>>>>>>> Department of Statistics >>>>>>>> The University of Auckland >>>>>>>> Private Bag 92019 >>>>>>>> Auckland >>>>>>>> New Zealand >>>>>>>> 64 9 3737599 x85392 >>>>>>>> p...@stat.auckland.ac.nz >>>>>>>> http://www.stat.auckland.ac.nz/~paul/<http://www.stat.auckland.ac.nz/%7Epaul/> >>>>>>>> >>>>>>>> <http://www.stat.auckland.ac.nz/%7Epaul/> >>>>>>>> >>>>>>> <http://www.stat.auckland.ac.nz/%7Epaul/> >>>> -- > > > -- > Romain Francois > Professional R Enthusiast > +33(0) 6 28 91 30 30 > http://romainfrancois.blog.free.fr > |- http://tr.im/Gq7i : ohloh > |- http://tr.im/FtUu : new package : highlight > `- http://tr.im/EAD5 : LondonR slides > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel