a few matplotlylib imperfections

[etpinard]

Here is a list of matplotlylib imperfections I noticed while helping Randal Olson convert one of his matplotlib figure to plotly.

For more, refer to this notebook.

So, running

import plotly.plotly as py
py.plot_mpl(mpl_fig)

erroneously generates

1. a plotly plot with axis lines (i.e. 'showline':True ), even if the original does not
2. a plotly plot with axis ticks (i.e. ticks: 'inside'), even if the original does not
3. dashed mpl grid lines are converted to dashed scatter traces (note that dashed grid lines are currently not supported in plotly)
4. Annotations are not properly aligned (even their x-y positions match the original). For Randal's figure, this could be corrected by adding 'xanchor': 'left' to each annotation object.
5. \n escape sequences in strings are not converted to <br> HTML tags
6. mpl annotations outside the range of the axes should be converted to annotations containing 'xref: 'paper' and/or 'yref: 'paper' to make them visible
7. Suffixes in axis tick labels vanish (is 'ticksuffix' a valid for x and y axes, like for radial axes?)

[theengineear]

@etpinard, this is perfect. Thanks for the list, I'll crank these out tonight. I hadn't ever thought to convert the '\n' to
, that's a really good call.

[etpinard]

no problem.

[theengineear]

also, number (7), with the 'ticksuffix' is only allowed in polar, i believe. Even if you throw it in with validate=False, it doesn't show up in the JSON when you check it in plotly. not anything we can do about that for now.

[theengineear]

for number (5), i like this idea, but i don't like being sneaky and changing things behind the user's back. For instance this could potentially be a nuisance if you're using mathjax and want to write something like $\nu$! And, yes, a simple rule would be to only change actually escaped things... i'll create a branch for it and see if we like it or not :)

EDIT: duh, '\n' != r'\n' == '\\n', this is no problem.

[theengineear]

@etpinard in (3), are you referring to the NB link? Those dashes are put in as traces, I don't think we should try to build in any heuristics there that basically try to infer the following: 'is the user using this trace as a gridline?'

this likely won't get changed.

[theengineear]

for (4), somewhere down the road I made the choice to center data-referenced annotations. this is because the actual boxes around the annotations are a bit different for mpl and plotly, therefore things look a little weird.

at any rate, here's that change: #48

[etpinard]

Merging both newlines and mpl-annotations into another (local) branch and running

import plotly.plotly as py
dataviz1 = plt.figure(...)
# ...
py.plot_mpl(dataviz1, resize=False)

yields https://plot.ly/~etpinard/343 which is not bad at all.

By zooming out, you can see both the title and the source and info annotations.
These beyond-axis-range annotations should have (in my opinion) 'xref: 'paper' and/or 'yref: 'paper' to make them visible as in mentioned in (6) even if they are set with data coordinates (see renderer.py).

I'll add matplotlylib impefection (8) here:

• Multi-line mpl annotations (e.g. Randal's source and info annotation) should be converted with 'align': 'left' so that the text is left-aligned, which appears (from my NB) to be mpl's default behavior.

[etpinard]

About imperfection (3):

Randal's "grid lines" are actually traces themselves. They were made with:

for y in range(10, 91, 10):  
    plot(range(1968, 2012), [y] * len(range(1968, 2012)), "--", 
         lw=0.5, color="black", alpha=0.3)  

so matplotlylib has no reason to considered them grid lines. My mistake.

[etpinard]

And, by the way, @theengineear I can take a shot at these if you prefer.

[theengineear]

nah, it's no problem. since you've been working with graphs more on the mpl side of things, it's probably most productive if we keep this workflow up! i'll just be honest about whether or not certain issues are fixable. perhaps we should start opening these issues in separate github issues though? That way we can close them as they're completed instead of letting this single issue thread get enormous.

thanks for the help!

[etpinard]

Closed, as now these matplotlylib imperfections are packaged into separate Github issues.