[some_guy_nobel]

I agree with the author when they write:

""" In my idealistic vision of how scientific publishing should work, each paper would be accompanied by a fully interactive environment where the reader could explore the data, rerun the experiments, tweak the parameters, and see how the results changed. """

I do like seeing larger labs/companies releasing research full of SVGs. In recent memory, I quite liked this from NVIDIA:

https://research.nvidia.com/labs/dbr/blog/illustrated-evo2/

[gaha]

This really reminds me of a new paper [1] from my colleagues. All figures in the paper link to a website, where the figures can be reproduced and dynamically changed in the browser from the source data. It's really cool, it is a static website that runs DuckDB, WebR, and ggplot. Here [2] is an example for the first figure.

[1] Paper: https://www.cs.cit.tum.de/fileadmin/w00cfj/dis/papers/clouds...

[2] Figure 1: https://tum-dis.github.io/cloudspecs/?state=N4IgzgjgNgigrgUw...

[_heimdall]

The idea of rerunning experiments only seems feasible when the entire experiment was based on modelling, presumably modelling that can easily/quickly be rerun in a browser environment.

The idea of being able to view and parse the dataset in different ways is interesting though, effectively allowing readers to interpret the experiment's resulting dataset from different angles than the author published.

[mmooss]

Without the OP's proposed use of SVG, what format would someone use? PDFs won't handle it well - unless PDF's interactivity capabilities are much better than I think. We never developed a client-side multimedia file format; all we have are text formats like Word and PDF, which embed images decently, and embed multimedia and interactivity (beyond form filling) in awkwardly and in a limited manner.

[steezeburger]

What's wrong with SVG? Notebooks have their issues but are kinda this conceptually. I guess FLAs and Flash too. But you say we never developed a "client-side multimedia file format". Is that not exactly what html + js are for?

[mmooss]

I mean the equivalent of a Word document: a file I can reasonably edit, including editing the multimedia and interactive/dynamic content, save, email, put on a thumb drive or Dropbox, etc.

[Agraillo]

I'd say that html+js suggestion of GP still holds, but with caveats. After all these years, HTML has everything needed for this, including images that can be embedded via the data URI scheme [1].

For example, I once adjusted an Object Pascal interactive program (target: Windows/Win32) for the browser target (FreePascal compiler has the JS target). An intermediate result was a bunch of files that worked locally on desktop but struggled on mobile. With a little help from the SingleFile extension [2], I ended up with a single HTML file containing all functionality and content. It worked great, for example, in MiXplorer's internal HTML viewer. I can't recall the exact details, but the file:/// protocol still had issues in Chrome, Firefox, or both. Anyway, preparing a local address correctly with a keyboard is a challenge so let's just assume that having capable file managers running local html files is enough

Sure, to make this manageable, you need good tools that handle all sides of the task. But at least in theory, the format is fully capable. My only global issue was that the state for locally run HTML files is a kind of ephemeral entity, but for interactive multimedia files, you may consider this obstacle small.

[1] https://en.wikipedia.org/wiki/Data_URI_scheme

[2] https://github.com/gildas-lormeau/SingleFile

[mmooss]

In essence you're describing epub, which is HTML, and I agree. It has great potential but nobody seems to see it as more than a cheap ebook format, and even that is underdeveloped in terms of capabilities: presentation quality and annotation are nowhere near PDF, for example.

Most of all it needs usable editors, and editors which integrate multimedia and dynamic content editing. End users can't turn to a different editor for each media and then integrate the output into the epub document, like a web developer does (e.g., for an image use Photoshop, save the jpg, copy to the proper directory, reference appropriately in the html).

[cl3misch]

I think HTML is exactly the "client-side multimedia file format" you want. I guess what we don't have is an established editor UI. You have to create it yourself.

It's if we had the .docx format but MS Word was read-only. You would have to create the XML and zip it yourself, to be then rendered by Word. That's effectively how I see HTML+js in browsers.

[mmooss]

Yes, that's epub. See my other comment in this thread.

[zipy124]

Even just allowing GIFs or videos to be embedded would be a value add.

[fooker]

Interactive and SVGs don't really mix, although intuitively it would seem that they do. Rendering remotely complex SVGs tale multiple seconds, while any kind of interactivity demands ~30+ frames per seconds.

Without interactivity, postscript is vector graphics too.

[dekhn]

How complex are you talking about? I've done animations with hundreds of elements and it's fine.

[fooker]

A typical scene graph for a visually interesting 2D game has more than 5000 elements and works on a 15 year old computer without issues.

[Grimblewald]

I'd be curious to know what classes as complex for you, since ive done some frankly crazy stuff with svg's, which outperformed any raster implementation. Ultimately, poor performance was always my fault, especially initially when i was still treating it with paradigms better suited to the world of raster graphics.