0. Introduction

This project is focused on using STL containers in order to graph data on a two dimensional (and if time allows, three dimensional!) plot. The graph would be written in an svg image, compliant with the W3C standard. The goals of the project are as follows:

• To provide an easy syntax for building graphs
• To let users produce a simple graph with minimal intervention by using sane defaults
• To demonstrate how to incorporate SVG images into Boost documentation
• To allow users to easily customize graphs to their heart's content
• To allow the user to talk with the svg_graph class using coordinate units instead of pixels or other arbitrary measures

I have only a student's grasp of C++, so if you have a suggestion to help me with design or implementation, either leave them here or email me at jakevoytko [at] gmail [dot] com

1. User Interface

Example

vector<double> experiment_data;

// fill experiment_data here

svg_graph my_graph("./image.svg");

my_graph<< image_size(500, 500) << x_scale(0, 10) << y_scale(0, 10)
        << line_color(BLACK) << draw_axis();

my_graph<< plot_range(experiment_data.begin(), experiment_data.end()) << write();

Output

---

2. Design Decisions

2.1 svg_graph class

Currently supported operations of the form my_graph << function():

• x_scale(double, double) and y_scale(double, double)
  • Allows the user to set the bottom, top, left, and right edge of the graph

• image_size(int, int)
  • This sizes the border of the image. The default right now is up in the air. 100x100 is perhaps unreasonably small for someone with a 1280x1024 monitor, but maybe 300x300 is unreasonably large for someone with 800x600 screen resolution

• set_start(int)
  • Allows the user to set the x-axis location of the first data point. This is important currently because the interface does not yet support coordinate pair<,>s, and so the user is stuck defining the interval with which the data is input. Obviously not all data has a uniform distribution, and they'll be able to pass an STL container of pair<,>s in the future to alleviate this problem.

• set_interval(double)
  • This allows the user to set the interval between data points that are being graphed. Again, this is necessary until we allow the user to put in coordinate pair<,>s, and will remain necessary after that for users who do not have data in coordinates

• plot_range(std::vector<double>::iterator, std::vector<double>::iterator)
  • Will be the made generic
  • Allows the user to input a begin and an end, and have the user plot the data in between

• draw_axis()
  • The user specifies that s/he would like the axis drawn in the image.

Inherited from svg. I am only including the ones it makes sense to include. In the current prototype code, it inherits handling for a few functions that are not only illogical, but produce unexpected results! This will be taken care of.

• write()
  • Since it would be too much work (and sometimes impossible) to maintain the file without intervention, this function acts as a 'commit'.
  • The user can be sure that whenever they have executed this command, the full output is written to the stream they have specified.

• line_color(svg_color c)
  • Allows users to define a color
  • line_point() will soon be supported
  • Users will be able to define custom colors soon

2.2 svg Class

All of the design decisions for the svg class are motivated by the fact that the svg class is the parent for the svg_graph class. As such, I tend to treat it as a second-class citizen. My personal tendency is to make it purely a computation and drawing class, and leave all interface work to the svg_graph class

When I designed the prototype, I made the svg class have a user interface much in the way that the svg_graph class does with the stream operator. However, as I look at the list of features that I'd like the user to be able to access, I will consider the ramifications of removing a user interface for the svg portion, and instead focus it on being the functional backbone of the svg_graph class. I will post to the Boost discussion board and see if people are more interested in eventually having a fully-functioning SVG suite, or more interested in having a fully-functioning graphing utility in the near future.

---

3. To Do List

3.1 Near Future

• Set up codebase in SVN
• Clean up demo code. Comment better, cement next draft of architecture
• Explore size-saving of the output file (I currently don't take advantage of things like paths that the svg model has to offer)
• Allow any STL-compliant container to be input
• Fully support chaining of the overloaded input operator

3.2 Medium Future

• Explore hover features in the SVG format as a potential way to label data

3.3 Not So Near Future

• Support 3-D graphs