Design and future of the SVG Graphics Driver with dynamic tips

The design of this driver is that it can be used with ordinary R plotting commands. The extra information needed for tooltips and hyperlinks is supplied by a call to a separate function call before the call to the plotting function that generates the shape. Extra information for only one shape can be supplied this way, so shapes that have tooltips or hyperlinks must be drawn one at a time.

SVG coding style

It appears that preferred SVG coding styles have changed over time. The defaults in this driver are those suggested at In particular:

  • The driver output by default does NOT include a DOCTYPE DTD (it is recommended at to NOT include a DOCTYPE declaration.)
  • Use shape properties directly rather than specifying them via style property, e.g., prefer this: over this: .
  • Use "Namespace" aware functions, e.g., getElementsByTagNameNS instead of getElementsByTagName (see also "SVG: Namespace Crash Course" in the references).


  • This driver currently does not have any font metric information, so the use of plotmath is not supported.
  • This device will not record tool tips and hyperlinks if it is called by dev.copy - the functions to add tool tips and hyperlinks are ignored by other devices.

Future development possibilities

  • Clean up the SVG code that defines the layout of a tool tip (SVG_footer() in src/devSVG.c) - currently the vertical spacing (the 'height' and 'y' attributes) is somewhat ad-hoc (coded by trial and error, and may not work for all font sizes).
  • Add font metric information to support the use of plotmath.
  • Clean up the two-line tooltip SVG code: The two-line tooltip mode displays OK in the default SVG renderers in Firefox (under Windows 2000/XP and Linux) but does not display in the Batik standalone SVG viewer. It probably needs declarations to extend XML elements: 23.5 Adding private elements and attributes to the DTD.
  • Provide post-processing to use CSS (cascading style sheets) to make SVG files with lots of elements more compact.
  • The design of how tooltip and URL information is passed to the device is somewhat ugly -- it would be nicer if the basic graphics commands allowed additional optional arguments. However, they don't, and the scheme implemented here at least works. It has the advantage that the graphics commands that specify tooltips and URLs will be ignored when other devices are used. One disadvantage is graphics recording will not record tooltips and URLs.


www Consortum W3C Scalable Vector Graphics (SVG)

SVG authoring guidelines

SVG: Namespaces Crash Course

"SVG Essentials", J. David Eisenberg, O'Reilly and Associates, 2002.

See Also

Overview of the RSVGTips device.

pictex, postscript, Devices.

Cairo is another device for R that can produce SVG graphics; see However, it doesn't appear to support tooltips.

Documentation reproduced from package RSVGTipsDevice, version 1.0-7, License: GPL (>= 2)

Community examples

Looks like there are no examples yet.