mpld3/mplexporter — pull request #13 by theengineear (2014-03-14 02:28:22+00:00)
Title: Merged the drawing of lines and markers, no more draw_markers.

Functions modified:
- draw_line (exporter)
- get_line_style (utils)

Functions deleted:
- get_marker_style (utils)

Functions requiring modification/deletion in renderers:
- self.draw_line
- self.draw_markers (may or may not need modification or deletion)

Since both markers and lines are really just `Line2D` objects in mpl, they
can just be treated together. Rather than have the exporter decide that
they should be treated differently (i.e., call to `draw_line` or
`draw_markers`), the exporter now just gives the line, the style, and a
`types` indicator.

The `types` indicator is a list of the objects within the line that a
renderer needs to deal with. It can have one, none, or both of the
following entries: `'line'`, `'marker'`.

This is very helpful to high-level renderers. For instance, Plotly links
data with lines/markers, therefore, if a call is made to draw markers
and then another call is made to draw lines, an extra trace is created
unnecessarily. Of course, this can be handled by storing the lines and
messing with the line objects on the renderer side, but I think this
saves the hassle and don't see how it would hinder other renderers that
want to draw the SVG paths for markers and such.

Finally, though the exporter passes all of the text objects through,
`Line2D` labels are not passed. Therefore, I included it as a property
(not contained within the style dict). Another example from plotly: all
pieces of data have a name attached to them in plotly. When you hover
over data, this name appears. If mpl users care to enter a 'label' for
their `Line2D` objects, this should be preserved and could, for instance,
show up in the hover or in the data spreadsheet in plotly.

Where there any reasons the Line2D objects were getting split into markers and lines that make this a bad idea?