[Rd] A patch for extending pdf device to embed popup text and web links

Tony Plate tplate at acm.org
Mon May 5 18:31:54 CEST 2008


Paul Murrell wrote:
> Hi
>
>
> Tobias Verbeke wrote:
>   
>> Dear Tadashi,
>>
>> Thank you very much for sharing your work.
>>
>>     
>>> I am sending a patch for R-2.7.0 for extending pdf device to embed pop
>>> up text and
>>> web links. The patch is available at
>>> http://www.okada.jp.org/RWiki/?plugin=attach&pcmd=open&file=R-2.7.0.patch&refer=pdf%20device%20patch
>>> You can see what the patch can do through a sample output, which is available at
>>> http://www.okada.jp.org/RWiki/?plugin=attach&pcmd=open&file=sample2.pdf&refer=pdf%20device%20patch
>>> An script is at
>>> http://www.okada.jp.org/RWiki/?plugin=attach&pcmd=open&file=sample2.r&refer=pdf%20device%20patch
>>>
>>> Ei-ji Nakama kindly build Windows binary, which can be obtained from
>>> http://prs.ism.ac.jp/~nakama/tadakadosan/cran/
>>> An installer, R-2.7.0pat-win32.exe, will install programs in
>>> C:\Program Files\R\R-2.7.0pat
>>> so that you can use both of original and patched version simultaneously.
>>>       
>> I think it would be most useful if you could bundle your patched version
>> of the pdf device in a separate device package, similar to the
>> RSVGTipsDevice.
>>     
>
>
> I would second that approach, at least in the meantime.  This sort of
> functionality is interesting and useful, but needs careful thought to
> make it compatible with the existing graphics facilities in R.
>
> One major consideration is that the graphics system tries to be mostly
> device-independent, so that R graphics code can be run on any device.
> This would need adjustments to the common graphics engine/device C code
> rather than just to the C code underlying the PDF device.
>   
Yes, more thought about how to integrate standard R graphics with extras 
like popups could be very useful.
I wrote RSVGTipsDevice to be compatible with R graphics, in the sense 
that code that generated a plot on RSVGTipsDevice could generate a plot 
on any device (the information specific to RSVGTipsDevice would just be 
discarded when plotting on other devices.)

I'd love to see more discussion of this, especially if it could lead to 
a more general solution that could be used across multiple formats like 
SVG, PDF, etc, so here's a recap of the issues and approach in 
RSVGTipsDevice.

The features I wanted in RSVGTipsDevice were:
 -- a popup "tooltip" on a graphics shape (a title + one or two lines of 
text)
 -- a clickable hyperlink on a graphics shape
A difference to the PDF device enhancements being discussed here is that 
RSVGTipsDevice did not support adding any annotations to text.

The challenge in implementing this was that the R graphics commands for 
shapes, like points(), rect(), polygon() etc did not provide any way of 
accepting additional arguments (like tooltiptext= or url=) and passing 
them down to the device-specific graphics functions (written in C).

The approach I took was to provide extra R functions that could be used 
like this:
      setSVGShapeToolTip(title="A triangle", desc1="green", desc2="big")
      setSVGShapeURL("http://www.r-project.org")
These would set up info for the next graphics shape drawn, saving the 
info in the C level graphics structure for the next call to a shape 
drawing function.  If the next call to points() (or rect(), etc) drew 
multiple shapes, only the first shape would get a tooltip or a 
hyperlink.  This is a definite limitation -- but I couldn't see a good 
way to provide info for multiple shapes (other than by allowing 
vectorized arguments to setSVGShapeToolTip, which seemed sort of 
clunky).  I was hoping for some more discussion about a better way to 
implement this sort of thing in general.  These function calls were made 
"compatible" with any R graphics device by having them check if the 
current device was RSVGTipsDevice -- if it wasn't they would simply 
discard the info.  This means that for code using these function calls 
to run successfully when drawing on other devices, the RSVGTipsDevice 
package must be loaded.

All this was done in a standard R package, so that as Paul says, people 
could try it out without having to recompile R.

These attempts with RSVGTipsDevice (which were features added to the 
RSvgDevice package written by T Jake Luciani) were just a first attempt 
and I'd welcome any discussion or suggestions on how they could be 
better implemented and integrated with R graphics, or integrated with 
similar functionality for other devices.

-- Tony Plate
> There is also the issue of following standard R coding style and
> semantics.  Rather than your approach of ...
>
> text(5, 2, "text test")
> pdf.link.on.text("http://www.google.com")
>
> ... where the second call relies on a global setting to relate to the
> appropriate text, it would be better to have something like ...
>
> linkedText(5, 2, "text test", href="http://www.google.com")
>
> ... so that the association is explicit.
>
> By developing your ideas as an add-on package, people can try out your
> ideas without having to recompile R.  As Tobias has pointed out, the
> RSVGTipsDevice package might be a good place to start.
>
> Paul
>
>
>
>   
>> What do you think ?
>>
>> Kind regards,
>> Tobias
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>     
>
>



More information about the R-devel mailing list