> The priority for me is to be able to fiddle with the details of the plot: change the font, define a new colour, remove the tick marks, have two y-axes, change the aspect ratio, insert formulas in LaTeX, etc. So the plot itself is usually very simple, but I need to be able to make any change requested by my supervisor, or the journal editor, or the referee.
Personally, I long gave up on trying to use a single program to achieve both on-screen, interactive, exploratory plotting and figure preparation for publication. This is reflected in Gaston.jl, which is focused on fast, simple on-screen plotting. Once the data looks good, I prepare a for-publication figure using something like pgfplots, which is (IMHO) unsurpassed at doing that. -- mb On Mon, Sep 14, 2015 at 9:03 AM, Daniel Carrera <[email protected]> wrote: > On Friday, 11 September 2015 03:48:44 UTC+2, Tom Breloff wrote: >> >> Hi Miguel... Looking forward to your comments. The short answer is that >> it depends on the situation. For functionality that just isn't possible for >> a backend, I'll probably just throw an error (ideally with a message >> describing other backends that can do what you're looking for). For some >> cases, I might automatically replace the call with something similar. For >> an example, I couldn't figure out how to make a "sticks" plot in Gadfly, so >> I made a bar plot instead. I hope that the package authors can help me with >> this process though... Sometimes there's undocumented functionality that >> does what I need, and it would be a big help to have package authors >> contribute. >> >> I also want to hear from people on visualizations that aren't possible >> with this API, as this all falls apart if you only cover some of your needs >> through Plots.jl. Look at the TODO at the bottom of the readme for an idea >> of my roadmap, and let me know if you want me to add to or prioritize >> something. >> > > > Overwhelmingly, I do relatively simple scatter plots and line plots; with > the occasional "heat map" plot. The priority for me is to be able to fiddle > with the details of the plot: change the font, define a new colour, remove > the tick marks, have two y-axes, change the aspect ratio, insert formulas > in LaTeX, etc. So the plot itself is usually very simple, but I need to be > able to make any change requested by my supervisor, or the journal editor, > or the referee. > > Cheers, > Daniel. > > > > >> >> >> On Thursday, September 10, 2015, Miguel Bazdresch <[email protected]> >> wrote: >> >>> Hi Tom, >>> >>> I'm the author of Gaston.jl. This looks interesting, and I'll take a >>> closer look. I'm wondering, how do you plan to handle the different >>> capabilities of each backend? Say, for example, that the user specifies a >>> plot that Gaston can't handle -- maybe the marker type is not supported by >>> Gnuplot, or something like that. >>> >>> -- mb >>> >>> On Thu, Sep 10, 2015 at 4:26 PM, Tom Breloff <[email protected]> wrote: >>> >>>> This may be a slightly premature announcement, but I wanted to put it >>>> out there so that people that have strong opinions have a chance to give >>>> their thoughts. Here's the link: >>>> >>>> https://github.com/tbreloff/Plots.jl >>>> >>>> Plots.jl is intended to be an API/interface that sits above other >>>> plotting packages (backends) and gives the user simple, consistent, and >>>> flexible plotting commands. It's a problem when someone is used to a >>>> package which is great for interactive plots, but then has to re-learn and >>>> re-code new plots in another package when producing publication-quality >>>> plots (or vice versa). The same goes for switching between desktop GUIs >>>> and javascript technologies... sometimes one package is better than another >>>> for a specific task, and it's a shame to be forced to choose. >>>> >>>> I've implemented a bunch of functionality for both Gadfly.jl and Qwt.jl >>>> backends. See the examples to get a sense of how they differ. I think >>>> Vega.jl and UnicodePlots.jl might be next on my priority list, but please >>>> let me know if I should prioritize differently. Note: This is still a work >>>> in progress, and I will probably change parts of the API, and not every >>>> plot type is implemented yet. >>>> >>>> Please let me know comments, wish lists, etc. Issues are great for >>>> actionable items, comments can go here. This effort was partially inspired >>>> by various discussions here and on github, which prompted the forming of >>>> https://github.com/JuliaPlot, and an effort to improve the plotting >>>> landscape with tutorials and documentation. If you're interested: >>>> https://github.com/JuliaPlot/juliaplot_docs/issues >>>> >>>> Tom >>>> >>> >>>
