Drawing SVG

Alternative title: "Drawing API"

Introduction

Drupal is synonymous with compliance and accessibility, but at the other end of the spectrum is the desire to push boundaries. The Drupal community has always been an early adopter of new technology - especially the "open" variety. You hear about something new, like Open-ID, and you bet that Drupal is almost there.

One open standard that Drupal has not touched is SVG. This great specification, well supported by most graphics programs, could use a leg-up in the browser market.

Paraphrased from Wikipedia:

Scalable Vector Graphics (SVG) is an XML markup language for describing 2D vector graphics. It is an open standard created by the World Wide Web Consortium.

Current situation

At the moment, a developer who would like represent information in a visual format only has a few options:

• Create functions to interface with GD or Imagemagick. This is viewed as too much effort.
• Integrate with a third-party tool. This is sometimes not a bad option, but other times it is appropriate to create dependencies for minor features.

Just to shed some more light. There are a few simple examples where a developer would like to generate graphics.

• A statistics module like Graphstat wants a line which generates a simple line chart of x over y.
• Another module is creating a bar chart by creatively using
  tags. However a new situation requires these charts to be generated in a non-browser environment and the style div tags are a poor option.

  Why SVG?

  SVG is a defined and reasonably well supported open standard. Adobe Illustrator supports import and export of SVG format graphics. A simple SVG graphic opens on Opera 8.5, Firefox 2 and IE7. If you want to read further, I've initiated such discussion in the Graphing & SVG group. While embedded SVG is definitely troublesome, and while any SVG API is unlikely to get into Drupal core for a few hundred years, I feel that this is outweighed by a tradition of supporting open specifications.

  svg.inc may end up being a simple XML generator that is passed data (fapi) arrays of an appropriate structure.

  Scope

  There is a risk with this project of pushing too far into the SVG specification. It is very important to focus on the structural integrity of the module. By implementing hook_shapes and theme functions, designers/developers are not be limited. Here are some specificn guidelines.

  1. Geometry is limited to: rectangle, ellipse, line, path (multi-segment line).
  2. Basic text, not specifically formatted. (Rationale.) Text extensible by hook_shape and theming of course.
  3. Visual properties limited to: line width, line color, fill color.
  4. Management of a "canvas" to which elements are added as they are called. That is, all functions should be passed some sort of $canvas object which identifies important co-ordinates on the current image.
  5. SVG-compliance checking using JavaScript. User settings to turn svg on and off.

  Code structure

  While this project is limited to SVG, we will give some thought to future drawing APIs. We could easily place all code in one file, but instead we'll split the code into a generic API called drawing.module and a toolkit/plugin called svg.inc.

  drawing.module should define shapes using Drupal's establish "hook" system. For example, the hook :

  hook_svg_shapes() {
      $shapes[] = array(
      //...data
         );
  } 
  

  drawing.module itself would define it's own shapes, and these can be kept relatively simple. For example:

  <?php
  drawing_svg_shapes() {
    $shapes[] = array(
      '#name' => 'rectangle',
      '#callback' => 'drawing_callb_rectangle'
      '#callback_args' => array('x'=>'int','y'=>'int') etc.
    );
  } 
  ?>
  

  This will allow other modules to extend the visual object collection, without necessarily extending the scope of the SoC project. For example:

  <?php
  graphstat_svg_shapes() {
    $shapes[] = array(
      '#name' => 'curved_rectangle',
      '#implements' => array('svg', 'gd'),
      '#degrade_path' => array('rectangle'), // conjecture
      '#callback' => 'drawing_callb_rectangle'
      '#callback_args' => array('x'=>'int','y'=>'int') etc.
    );
  } 
  ?>
  

  In the above, I've add a few attributes like "implements" and "degrade_path". These are not necessarily in the scope of the project, but they sketch out some future design directions that should not be conflicted by the first design.

  Last but not least, a flexible theme callback component, which automatically generates theme calls for every defined shape. Plus a shape_alter callback to allow other modules to modify the shape data definitions.

  Thanks to...

  ... you for reading this far and Bèr Kessels for valuable feedback.

  Please submit your opinions and criticisms in a comment below.
  Simon Hobbs (sime)

  Comments on this proposal

  PEAR XML_SVG
  rconstantine - March 22, 2007 - 18:26

  I haven't looked into SVG and Drupal, so maybe you know the answer to this:

  Is there a reason we can't just use PHP PEAR's XML_SVG functions?
  ======================================================
  ======================================================

  There's no killer
  sime - March 22, 2007 - 19:37

  There's no killer reason.

  Many Drupal developer's prefer to use code that is in Drupal CVS, which has a history here, that could eventually be made to play especially well with Drupal core. Or if a decision is made to include some simple functions in Drupal core, a Drupal SVG library would already be fapified and so on.

  Other's would say "if there is a problem with pear xml_svg we have no control"

  Other's would say "because it's not Drupal"

  yada yada
  ======================================================
  ======================================================

  Can't Always Guarentee PEAR
  eljefe - March 24, 2007 - 16:45

  You can't always be guaranteed that PEAR will be installed on a user's server, and often said users may not have the permission to get PEAR installed.
  ======================================================
  ======================================================

  If I have to
  NancyDru - May 9, 2007 - 21:44

  If I have to learn any API, I'd rather it be a Drupal one. I am definitely interested in being able to display graphs. {Now if I can just figure out how to get that data from that other web site...}

  Nancy W.
  Drupal Cookbook (for New Drupallers)
  Adding Hidden Design or How To notes in your database
  ======================================================
  ======================================================