use standard plotting implementation

[scottdraves]

replace our plotting API with a more standard one such as: 1) vega 2) chartjs 3) bokeh 4) bqplot

we would need an API adaptor to maintain code compatibility (but new code could access the new API directly of course).

[jpallas]

5. plotly.js?

How important are existing language bindings? For Scala, vega has vegas, and bokeh has bokeh-scala. It looks like the existing plotly Scala support is only for the server-based product and not for plotly.js. chartjs and bqplot don't seem to have anything for Scala.

Do any of these have native Java or Groovy support?

[benmccann]

@jpallas I know Chart.js has https://github.com/mdewilde/chart for Java support. You should be able to use it from the other JVM languages like Scala and Groovy as well.

[benmccann]

I've worked on projects in the past where having several charts on the page or having one chart with a large number of data points has had a performance impact and switching from svg to canvas made a big improvement. I'd like to suggest we look at the backend rendering used as one consideration. I've listed what I can find below

• vega - canvas or svg
• Chart.js - canvas
• bokeh - canvas
• bqplot - says canvas is on the roadmap, but it's a pretty big change, so it probably won't happen anytime in the foreseeable future
• plotly - svg. It looks like only scatter charts support webgl. Documentation for webgl support is quite sparse

[benmccann]

@scottdraves Some of the libraries suggested have Python APIs (bokeh & bqplot) while others have JavaScript APIs (vega & chart.js). Is one preferable over the other?

[scottdraves]

i think having some kind of JavaScript API is a requirement since our current plotting widget would have to call it to draw the plot, when the plot was created with a current kernel API (groovy, python, scala, etc).

[jameskoch2]

(Beaker newb here, apologies if this is off-base)

On the subject of language bindings, I've found the plotting approach in spark-notebook to be useful. They expose basically the full plotly API in its native JSON format, unencumbered by the Scala typesystem. Contrast this w/ existing BeakerX Scala plotting APIs, which attempt to model all the fine-grained details in Scala types.

(Most interesting examples start about half way down this page)

https://github.com/spark-notebook/spark-notebook/blob/ae3b20cbdb89a18c5a210746e640d0ae7238f1db/notebooks/viz/Custom%20Plotly%20Charts.snb.ipynb

vs

http://nbviewer.jupyter.org/github/twosigma/beakerx/blob/master/doc/scala/Plot.ipynb

[altavir]

It is specifics of Plotly. Since it is initially a JS library, Plotly API in any language is just a wrapper for its JSON. I don't think it will work this way for any other library, since most of them create language API first and JSON later.

[benmccann]

I think there are a lot of JS libraries that take options as JSON input such Plotly, Chart.js, AmCharts, etc. If it makes implementation easier in beakerx we could choose a library that is initially a JS library

[altavir]

I like the idea of using JSON-based API. Current beakerx API is better than matplotlib, but it is imperative in its core and hard to extend. On the other hand, all modern languages have some kind of tree-building APIs. Groovy has a huge part dedicated to DSL and Kotlin type-safe builders a just brilliant (I can contribute that one if there is a clear JSON API definition). I think it will also reduce amount of manpower to support it since you do not need to change backend if you add something new to frontend, just add new lines to the documentation.

[altavir]

I've made it work just by using DefMacro('\svg{}{}','\includegraphics[width=#1]{#2.svg}');. Now the problem is with paths since it uses path which was passed to it not even adding graphicspath. Is it possible to adjust it?

UPDATE: The xml generates correct path for candidates relative to the tex file, but in my case tex and xml are in different directories.

[benmccann]

Perhaps we could add support for multiple JS chart libraries. E.g. PlotlyBar, AmchartsBar, HighchartsBar, etc. There are so many variations on how each chart displays and I'm guessing each user will have their own requirements. I personally would really like to find a way to support react-stockcharts as it's the best library I've found for drawing stock charts

[altavir]

I've recently started to work on kplot library, which is intended to be a universal plot api for kotlin with multiple implementation. The idea is not to adapt to multiple JSON API but to create my own JSON representation and then to convert it to specific library requirements on client side. Meaning that we just send a JSON and depending on the client configuration, different plot library will be used. The idea is the same as with matplotlib api, but using declarative approach instead of imperative one.