SVG "export"?

[stephen.friedrich]

I am currently evaluating JS charting products/frameworks.
Highcharts demos really look impressive.

A common problem with all products I have looked at so far, is the inability to (re)create charts on the server side, for example to include them in a PDF file or to send them by e-mail.

One partial solution would be to post svg to the server and render/convert it in the backend.

Is it possible to access the SVG representation of a chart (even if it is not rendered as SVG in the current browser)?

[torstein.honsi]

This is the big issue for the next major version, 1.3.

The main idea is to create an SVG representation of the chart on the client side, post it to the server, use ImageMagick or its likes to convert it to any image format and return it or do something else with it. We will offer a cloud service to do this on our servers, as well as server components for clients to install on their servers.

Now the big question is how to generate the SVG. Highcharts started out as SVG/VML experiments three years ago, but the SVG renderer was abandoned mainly due to Safari's lacking support. That has changed now. I can't see any reasons why to use canvas over SVG.

Should we refactor Highcharts to use SVG in compatible browsers? SVG is object oriented, which opens for animation and reuse of elements instead of the double buffering techniques currently used in Highcharts. Memory usage will go down as all the canvas layers disappear. The charts will appear razor sharp when zoomed, which is a common operation on mobile user agents. We can skip the excanvas abstraction as VML is more kin to SVG than Canvas. Native animation is coming to SVG enabled browsers. And finally, Microsoft have joined the SVG workgroup, a signal that SVG will probably be supported by IE in the future.

To generate the SVG in IE, all we have to do is to switch from the default VML renderer to SVG, render the chart in a hidden container and send it off to the server for conversion.

I have started rebuilding Highcharts to SVG as an experiment. See http://highcharts.com/demo/?prerelease=1.3. This URL sets a cookie to your browser to use the 1.3 prerelease. To unset it, click http://highcharts.com/demo/?prerelease= . Currently it works in Firefox and Opera. Safari has a problem with alpha transparency. Many features are not yet refactored, so you will experience JavaScript errors and missing features.

Is this the way to go forward with Highcharts? Any comments are welcome.

[stephen.friedrich]

Wow, that's very great and exciting news.
If you follow through with this Highcharts will definitely set itself apart from the competition even more.

Overall this does indeed sound like the way to go.
Of course VML support would need to stay around for a couple of years.
(Currently the 1.3 prerelease simply does not work at all in IE.)

A cloud service might be nice, but for our intranet I would need a pure Java implementation that can be run as part of my app on a Java app server.
I could probably implement this myself, provided I get the API to hook into to query the SVG. In the past I had used Batik with good success - http://xmlgraphics.apache.org/batik

[torstein.honsi]

If you follow through with this Highcharts will definitely set itself apart from the competition even more.

Yes I think so too. Export options is the single most requested feature at the moment.

A cloud service might be nice, but for our intranet I would need a pure Java implementation that can be run as part of my app on a Java app server.

Most corporate customers would require that the images be generated on their own server. The cloud service is intended only as a quick and easy option, and will be supplied with downloadable server components for Java, Ruby, PHP, python etc. I haven't actually experimented with the backends yet, but as I see it these will be quite simple implementations on top of either Batik or ImageMagick.

[Les]

Yes I think so too. Export options is the single most requested feature at the moment.

Interesting. As a Web developer I'm getting a lot of requests for a robust set of financial style features/charts.

Why is the ability to save a chart as image important? What would be the possible applications of this feature?

I can always print screen and then cut and paste the image, so why this new addition?

[torstein.honsi]

It surprised me too that this request appeared so frequently. I'm used to working on the web with no paperwork at all and using URL's to live resources instead of images. I think most of the users requesting this develop web solutions that are part of a greater system. Export possiblilies will allow them for example to attach a PDF of a chart with an internal report or to convert the chart for use within any other system.

[brettkiefer]

As a developer of a commercial web app, I will say that whenever we have said 'oh, that's easy, just take a screenshot, paste it into an image viewer, crop to the part you want, then save that image', the answer has been 'I might understand that, but not all of my users will'. It's actually kind of a hassle to do all of that, and if your application tries to be usable for those less tech-savvy, you want to make it easy for them to export any images they might need without knowing that PrtScn takes a screenshot. So that's why we're looking for that functionality.

[stephen.friedrich]

Yes, usability is a big issue. (Recently a user send me a "real" screenshot: Photographed with his digicam, printed, with handwritten notes, then scanned and and send by e-mail via the office copy machine.)

The most important use case for me is generation of a PDF report with several additional data sources and including tabular data, all that separated into chapters, with lots of styled text.
That is (and should be IMHO) simply outside the scope of Highcharts.

[lokw]

Something that may be even nicer is if, in supporting browsers, you render the SVG, then use a canvas tag's drawImage to draw the (hidden) svg <img> onto the canvas, then we can use canvas.toDataURL() to get a nice binary/base64/etc image right in the browser that we can POST to a server for whatever.

[torstein.honsi]

Yes that's an option too. But you'll loose the scalability of the vector graphics and obviously the cross browser support.

[telesma]

SVG instead of Canvas sounds really great. Perhaps the rendering in IE is also faster than with the excanvas translation?

[torstein.honsi]

Yes I would think so. By getting rid of the abstraction layer that excanvas is, we can address the VML objects more directly. SVG and VML are quite similar in the sense that they have a DOM, events can be added directly to the element and properties can be changed after generation time unlike canvas. Designing the application for use with two so closely related languages means less abstraction and better implementations of both.

[lokw]

I only meant for an 'export' option, not the direct rendering. For example, a method on the chart library would copy a chart to a data URL by copying the SVG to a temporary canvas to return the 2D image data.

That said, some basic experiments in Firefox 3.6 fail for me -- it may be a temporary thing, but the 1.3 prerelease generates SVG that works inline, but once it's linked via an <img> tag it no longer works -- the shading is missing. When I save the DOM contents of the SVG node to a separate file, it won't render properly in Inkscape either -- most of the shaded regions are black.

[torstein.honsi]

As an extra export option it could come in handy, you could for example pop up the canvas image and instruct the user to right click and copy it to the clipboard.

By the missing shading, do you mean the semitransparent fill colors? In that case, it is probably the same issue that you can see if you open the test page in Safari. It doesn't understand rgba colors, so those colors have to be split into "fill" and "fill-opacity" attributes. Perhaps this will fix the canvas issue too.

[lokw]

Yes, it appears to be the rgba issue. It's odd that Firefox seems to support it for an inline SVG but not the same SVG saved as a .svg and loaded via <object>...