0. Introduction

This is the central repository for design and implementation considerations for this project. If you have any suggestions or comments, 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();

---

2. Design Decisions

2.1 svg class

Document enum

The very first thing the user sees in svg.hpp is the following line:

enum {SVG_XML_HEADER, SVG_XML_DOCTYPE, SVG_OPEN, SVG_G_OPEN, SVG_G_STROKE,
          SVG_G_FILL, SVG_G_CLOSE};

This is done in order to standardize locations in the svg document that is being output. document[SVG_XML_HEADER], for example, will always refer to the line that has the SVG file's XML header. I'm currently debating the necessity of this feature; in my demo program that I wrote, there were lines in document that I never had to refer to again, but there were some lines that I did have to use a few times. At the moment, I'm going to keep the enum, though I will probably move it to a more suitable location so that it's not in the boost::svg namespace.

Private default constructor

I'm making the default constructor private simply because I can not think of a reasonable default for the class to have. I'd bet good money that having the data output to the console was not what the user wanted! Guessing a default file could potentially be disasterous: if we don't overwrite an already existing file, all of the user's efforts would be for naught. If we overwrite an existing file, we could overwrite something the user would have preferred to keep. As a result, I find it reasonable to expect the user to specify a stream when they create the svg object, in keeping with Scott Meyer's suggestion that incorrect use of the interface should not compile.

To be continued…

---

3. To Do List

• Finish organizing this wiki
• Set up codebase in SVN
• Clean up demo code. Perhaps I could comment a little better
• Explore compression of the output file
• Allow any STL-compliant container to be input
• Fully support chaining of the overloaded input operator