also fails. However, the PlutoUI method Show(MIME"image/png"(), read("/path/to/my/local/image.png")) saves my day. But I still want to figure out why the markdown and html methods don’t work.
When embedding a pdf into Pluto notebook, the embedding method
let
# Load the local PDF file
pdf_path = "/path/to/my/local/image.pdf"
pdf_data = read(pdf_path) # Read the file as raw binary
pdf_base64 = base64encode(pdf_data) # Convert to base64
# Embed the PDF using a data URL
HTML("""
<iframe src="data:application/pdf;base64,$pdf_base64" width="80%" height="600px" style="border:none;"></iframe>
""")
end
Also, if you have better practice to show a local image, tell me straitly.
Any suggestion is warmly welcomed!
It’s not Pluto’s fault. Browsers don’t allow this kind of linking anymore. If you look at your browser’s dev console, you’ll probably see some security errors.
Thanks for your reply! It does make sense to prevent broswer from accessing local files directly. Can I conclude that the two working methods work because they provide the broswer the data, which they obtain from other programs, to the broswer, thus the broswer don’t need to access the local data directly?
Generally, any file can be read into a Base64 format, and be feed into the broswer to be shown. This should be a generally solution in the pluto notebook right?
What makes it work is when the data is coming from the “same origin” as the Pluto web server that’s serving requests at localhost:1234. Since the web page for the notebook is being served from localhost:1234, the browser will trust anything else from localhost:1234.
The requests that didn’t work WERE NOT same origin.
Also, let’s take a step back here. Putting local assets in your notebook will limit its portability. If someone else tried to open your notebook on their own computer, there’s a very high chance that the notebook won’t be able to find those local assets you embedded into the notebook.
If you’re OK with that, keep going, but I think it’s important to understand the implications of what you’re doing.
I think notebooks are best when they make no assumptions about their local environment, and thus work portably across many different environments.
Well, I am confused again. The machine that provides the http server is the machine where the retrieved files locate. Well, the situation is bit complicated:
the http server is remote but can be connected via local network. The http server is etablished on a working node, which is connected from main node by ssh with port forwarding. I do this because I can only access the main node using http.
Nevertheless, the file are still located locally to the http server. I can’t see why they can not be retrieved in the above example…
The machine might be the same but the “origin” as far as the browser is concerned is different. The browser sees “localhost:1234” vs “file://” and says nope.
…actually, I’m reading your original post a little more carefully, and you didn’t even use “file://”. When you use “/path/to/my/local/image.png” that’s asking the Pluto HTTP server to serve that up to you. I don’t know where it serves static content from, but it’s certainly not / on your local filesystem.
I apologize for giving out a misleading and incorrect answer. (The info I gave is still good to know in general, but it didn’t answer your question correctly.)
I tried add the file:// ahead of the file path, but unfortunately it didn’t work. So I will stick using the Base64 stream until I find the reason.
Thanks for your time, and your kind reply is informative and helpful. I have learned some security mechanism of browsers. It is always joyful to learn new things, right? So, thanks all the same!