SVG files saved with vector-effect:non-scaling-stroke XML option

[eshort0401]

When SVG figure files are saved using plotly.offline, the SVG image's XML code uses the style option vector-effect:non-scaling-stroke for lines associated with scatter traces, but not for graph axes or other lines. When importing these SVG files into vector graphic software packages like Inkscape, this option results in trace lines remaining the same width regardless of the level of zoom, making it difficult to ensure lines are of the desired width. Below is a command line MWE, and some images showing how the generated SVG behaves in Inkscape.

import numpy as np
import plotly
from plotly.offline import iplot
plotly.offline.init_notebook_mode()

trace = {
                'x' : np.arange(0,10),
                'y' : np.arange(0,10),
                'type' : 'scatter',
                'mode' : 'lines+markers',
                'marker' : {'size': 4,  'symbol' : 0},
                'name' : 'Minimal Working Example',
                'line' : {'width' : 1.5,},
         }

fig = {'data': [trace]}

plotly.offline.plot(
        fig,  filename = 'mwe.html', image='svg', output_type='file',
        image_filename = 'mwe', auto_open = False
    )

In Inkscape, the vector-effect:non-scaling-stroke option also prevents you from editing the widths of lines. One solution is to manually change the XML code to vector-effect:none to stop this behaviour, although this is extremely tedious for figures with many traces.

I suspect the overwhelming majority of users would prefer vector-effect:none for their SVG images. If not, perhaps an option could be created so that the user could choose. I've had a brief look at the plotly source and suspect this needs to be implemented in Orca. If this sounds like a good idea, I would love to attempt the change myself, but will probably need some guidance as to where to look in the Orca code.

[jonmmease]

Thanks for the report and for sharing your experience here @eshort0401.

@plotly/plotly_js Do you all have any thoughts on whether the current difference in behavior between axis lines and scatter lines in SVG output is intentional? Would removing vector-effect:non-scaling-stroke result in any change in appearance for figures when displayed live?

[etpinard]

Would removing vector-effect:non-scaling-stroke result in any change in appearance for figures when displayed live?

It wouldn't result in any visual changes on first draw, but it would on scroll zoom (see https://github.com/plotly/plotly.js/issues/1899).

It sounds to me like we could remove that vector-effect:non-scaling-stroke on static exports.

[eshort0401]

It wouldn't result in any visual changes on first draw, but it would on scroll zoom (see plotly/plotly.js#1899).

It sounds to me like we could remove that vector-effect:non-scaling-stroke on static exports.

That would be my preference as a user. I think the non-scaling zoom behaviour makes sense for live figures, but not for static ones.

[jonmmease]

Thanks @etpinard, would you like this as a new plotly.js issue or as something to tack on to https://github.com/plotly/plotly.js/issues/1899?

[gatoniel]

Hi, I just stumbled upon this issue. Therefore, I wanted to ask if there is any progress on this, or a better workaround than rewriting manually the generated svg file. I am using this workaround:

import io


def plotly_to_svg(file, fig, **kwargs):
    buffer = io.BytesIO()
    fig.write_image(buffer, format="svg", **kwargs)
    with open(file, "bw") as f:
        f.write(
            buffer.getvalue().replace(
                b"vector-effect: non-scaling-stroke", b"vector-effect: none"
            )
        )


plotly_to_svg("test.svg", test_fig)

[alexcjohnson]

No progress as yet. If anyone is motivated to make a PR to plotly.js we would happily help get it to completion. The suggestion above from @etpinard is definitely the way to go:

It sounds to me like we could remove that vector-effect:non-scaling-stroke on static exports.

Ideally not as a post-processing step, but avoid adding that attribute in the first place when we see gd._context.staticPlot