Local files in HTML output

[TheCedarPrince]

Breaking out a reported issue from #162.

Hey @fonsp, I was wondering if you could explain why local images are not able to be rendered in Pluto notebooks. I feel like this is actually a pretty big concern. Especially in terms of accessibility.

I know that sometimes I have poor internet where I live and I could only imagine that being the same for other Pluto users. This feels like a huge limitation for Pluto that may impact its adoption. For my use case in creating example notebooks, I am worried that my users would not be able to work with the notebooks due to this limitation.

Is there anything we can do to improve offline accessibility? Do you see my point of concern here? If you have any questions or if I was not clear, please let me know. Thanks! :smile:

[fonsp]

The notebook is rendered using a web browser, and web browsers are not allowed to access local files given their path (for obvious security reasons).

The Julia code md"![texty](linky)" becomes the HTML string <img alt="texty "src="linky" /> - this is built in to Julia, not Pluto.

Pluto could add a backdoor (this would not introduce a new security issue - you can already access files using Julia code 🙃), but it will only lead to people writing notebooks with images that only show on their own machine (this is why videos never work in Powerpoint, for example), which is even worse! My long term goal is for Pluto notebooks to contain their own reproduction data, so adding this in will make things difficult later.

Your point about accessibility is somewhat true, but to me, the more important thing is that other people's code is accessible - URLs and the web are the way to do that!

[TheCedarPrince]

Hey Fons,

I definitely see your point, but I respectfully disagree that creating a backdoor for local files will create more issues. I understand that users could unwittingly reference local files on their machine that are only accessible to them on their machine. Thus, when someone tries to reproduce the notebook, it would lead to unreferenced files. But that is their problem, not Pluto's.

What I am working on has a repository with Pluto notebooks in one folder and all the corresponding assets in another folder. Together, they are in the same repository and are relative to one another. I believe the references to images ought to resolve relative to the notebook.

I am very much for the idea of a backdoor. If the backdoor is implemented and causes issues, we can revert to the prior method.

Actually, I think we are talking about two separate concepts: global reproducibility and local reproducibility. When I refer to local reproducibility, I imagine someone finding my repository, cloning it to their computer, and using it locally for themselves. This is common practice.

What I think you are talking about is global reproducibility. The idea that anyone can access the files from anywhere in the world regardless of whether or not they have the proper images or files. This is a great and laudable idea.

However, this can be very problematic if we only focus on global reproducibility. For example, in healthcare, if you share images or data to the web, this could get you fired or even a lawsuit against you. Therefore, local reproducibility is a huge need.

Do you see my point that I am trying to make here? I think this is a very fixable issue that could be handled by explaining to a Pluto user how to make something globally reproducible and locally reproducible. Of course, if we open that backdoor you referred to.

Perhaps one could also implement LiveServer.jl to assist with local reproduction? (thanks @wikunia for the thoughts)

[fonsp]

I think your comment is too aggressive towards implementing one particular solution (for one particular problem). Global reproducibility implies local reproducibility, which is why I am so interested in the former. To add to my earlier suggestions: you could link to the image files in your gh repository directly. (Right click -> copy image address.)

I do see the need for local images with relative paths - I have been thinking for a while about the more general possibility of widgets accessing asset files from their own packages. As for the suggestion, Pluto already has a auto-updating static file server built in, but please note that such a back door is far from trivial to add in - and again - will make things difficult for me later.

Another approach is to use something like Images.jl: you can load images from a local (relative) path, and interpolate them into markdown. You could even write a helper function for that:

Dog: $(img("./dog.jpg"))

instead of

Dog: ![](./dog.jpg)

(This works already)

[fonsp]

You can also base64 encode your image, that could be built in to Pluto. 🌈

I'm sorry for being frustrating - I will always be overly critical of feature requests that "break open" a part of the system to make things happen, but I think that this critical approach helps to keep the project maintainable and keeps doors open for future ideas.

[Wikunia]

I find interesting that

Dog: $(img("./dog.jpg"))

instead of

Dog: ![](./dog.jpg)

works. Then I think a first step would be add it as a "FAQ" to the wiki such that people know the reasons why ![]() is not supported but that there are ways around it like using an url or using julia.

[TheCedarPrince]

Will comment more later but this workaround should definitely go into #162!

[fonsp]

It should not go in 162 because 1) using URLs is the recommended method, 2) the markdown notebook has to have no dependencies and 3) I think the base64 idea is much better for local files - this also works for assets that are not images

[fonsp]

This isn't going anywhere useful - #183