No bro, at least with the default backend (GR) of Plots.jl, there’s no SVG output
That’s not true:
julia> using Plots
julia> plot(rand(10))
julia> savefig("random_plot.svg")
julia> Plots.backend()
Plots.GRBackend()
(@v1.5) pkg> st -m Plots GR
Status `C:\Users\ngudat\.julia\environments\v1.5\Manifest.toml`
[28b8d3ca] GR v0.51.0
[91a5bcdd] Plots v1.6.0
I haven’t said anything about Makie. I just put up Gadfly as a possible alternative that fits the requirement. Feel free to contribute more alternatives…?
GMT certainly looks like a very extensive and powerful library. On the other hand, to me it also looks quite hard to use with a complex net of sub programs. The power to “configure everything” is not what I was talking about, almost every plotting tool has that. You can configure everything in matplotlib as well, but to get to good results you often just have to configure way too many things manually, especially with layouts.
I really don’t want to get into a comparison of layouting syntax or capabilities here, I was merely motivating why I work on a Julia-based plotting package if there are others out there
The issue is not that anyone is likely to hold you accountable in academia/research if you work a bit on plotting libraries. That’s how they most of them are actually written.
It’s just that you pay the opportunity cost of using that time for something for which you are actually rewarded, either directly or indirectly. Plotting software per se is financed in very rare cases, eg ggplot2 by RStudio.
I just renamed this topic from “Julia equivalent of Matplotlib?” to “Julia alternatives to Matplotlib?” which I think better expresses what I’m looking for, but invalidates some of the comments.
I also took your post to be about saving files, so perhaps you were not as clear as you intended. Regardless, even if you were perfectly clear, this kind of antagonism is completely unwarranted.
I was just negating what I took as a mistake, no rudeness intended. I’m sorry if you felt it like that. That being said, I still think you are wrong. In Atom:
julia> using GR
julia> inline()
"svg"
And when I look at the aspect of the plots in the plot pane, definitely they are like the SVG output, not like PNG, e.g:
x = randn(1000); y = randn(1000);
plot(x, y, ".")
Screenshot of the plot pane (identical to the result of savefig("scatter.svg"), although svg images cannot be attached in Discourse):
Result of `savefig(“scatter.png”) - points are made nearly invisible in the process of rastering:
This post in only about the (im)possibility of Pure Julia plotting, so feel free to ignore. As I said previously it’s not important, as also an impossible goal (also in e.g. Python).
None of the its three backends are Julia only, i.e. in the end e.g GLMakie.jl will use GLFW → GLFW_jll a wrapper for C code.
Here you’re closer (I only see Julia code used), and plotting to the terminal is going to be the only “Pure Julia” in a practical sense (for GUI not possible, unless Julia abstracts over GUI libraries, I believe not done, nor wanted, web GUIs may be an exception), except you rely in Julia itself, and e.g. utf8proc written in C. E.g. utf8proc could conceivably have been written in pure Julia, and maybe even libuv, but at some point you’ll have to do I/O to the screen and it’s just not possible in pure Julia (unless we get “boot2Julia”, running baremetal, no OS, not what you want).
Gadfly seems to be pure Julia, but it in some sense doesn’t plot to “the screen”, only to a file (or for the example in docs I tried). Yes, this file gets to the screen, as it fires off your web browser (most likely written in C++, in a sense a huge library) displaying the “temporary” file it made (or not? I do not see them going away after closing the web tab, and /tmp may only get cleared on restart, or not).
File I/O is abstracted by Julia, unlike GUI stuff, with the “exception” of display() on that file.