Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rendering of inline images with relative paths is not working #23

Closed
tciecka opened this issue Mar 12, 2017 · 13 comments
Closed

Rendering of inline images with relative paths is not working #23

tciecka opened this issue Mar 12, 2017 · 13 comments
Assignees
Labels

Comments

@tciecka
Copy link

tciecka commented Mar 12, 2017

The viewer panel does not render images that are in a path relative to the file being edited. It does render remote images just fine, however. Examples have been included that demonstrate a failed render and a successful render. In both cases, the Export/HTML command will produce a document that is able to render in a browser since the links are properly formatted in both example cases.

Example1 - render failure:

  • Image exists in a relative directory: ./images
  • File target for the markdown link: ./images/someImage.png
  • Goal - render the image inline in the viewer panel
  • Markdown - ![Test](./images/someImage.png)
  • Result - Image is not rendered; an [X] placeholder is there instead

Example2 - render success:

@nea
Copy link
Owner

nea commented Mar 13, 2017

Hey tciecka

Thanks for the examples.

I will have a look to handle this and release a bugfix.

Thanks

@nea nea added the bug label Mar 13, 2017
@nea nea self-assigned this Mar 13, 2017
@nea
Copy link
Owner

nea commented Mar 16, 2017

Hi @tciecka

I just released a new version 0.7.1. It should fix your issue by adding the ability to reference local files, relatively and absolutely.

You have to add the protocol file:/// in front of every reference, otherwise it is not detected. This is to stay consistent with the http and https protocol/scheme checks internally.

My test included:

![Test](file:///C:/test/icon48.png)
![Test](file:///./icon48.png)
![Test](file:///icon48.png)
![Test](file:///C:/Users/Name%20Surname/Downloads/icon48.png)
![alt text](https://github.com/adam-p/markdown-here/raw/master/src/common/images/icon48.png)

Everything was loaded correctly. If the path is relative, the path of the current file is used. If the file has not been saved it does not work, obviously ^^'
Spaces in the path have to be escaped with %20 and you may only use forward slashes.

I hope this helps your documentation and my test cases were enough to filter everything out.

If not, just let me know.

Sorry for the long time to fix but Cheers :)

@nea nea closed this as completed Mar 16, 2017
@andrewanswer
Copy link

Hello nea,
I use your greatest plugin, but I suppose what local images in same folder should be rendered just with

![Title](1.png)

It's easier to understand and shorter to write. Markdown doesn't have common standard for this, but here and here you find the proposal:

![Alt text](/path/to/img.jpg)

I also use ReText and it works with images same way.

@nea
Copy link
Owner

nea commented Apr 18, 2017

Hey @andrewanswer

Thanks a lot ^^
Yeah, when I worked on the fix for this I thought about that. But the parsing made it way easier with the file:/// prefix.
But I'll keep this on my desk to fine-tune the parser and renderer accordingly.

Cheers

@kovarex
Copy link

kovarex commented Dec 14, 2017

I just wanted to note, that on github for example ,using the file:/// prefix for local doesn't work when viewed on line.

@btbroot
Copy link

btbroot commented May 22, 2018

Neither GitHub's Markdown renderer, nor Pandoc support "file:///" URI (security concerns?) Thus, requiring local files to be referred with "file" scheme makes Markdown files not really portable.

Please allow bare file paths (or ",/path") in the image statements

@patricktokeeffe
Copy link

Hi, I think this should be re-opened because (1) the file:/// prefix is not compatible with online renders (ex: Github) and (2) it's not part of the commonmark spec to which this project claims adherence.

I'm not demanding a fix (though we'd love one 😉), just suggesting it be left open to reflect the current status of things.

@nirtak
Copy link

nirtak commented Dec 30, 2018

I'm not sure if this is the right place for this. Images were working fine for me, but after a computer reboot, they are no longer working.
Genetic Seal
Ideas? Suggestions?

I also have a request/question. I am using MarkdownViewer++ to work on books published through LeanPub. They require a pre-named default location for images and other resources (I've asked if they could help as well). The only way I have right now of making images show in the viewer without having is to keep a copy of all images in the same directory as the text as well as a copy in the directory required by LeanPub. It's a pain. Is there any way to specify a default directory so I don't need 2 copies of every image?

@Aranoh
Copy link

Aranoh commented Mar 2, 2020

Spaces do not seem to be picked up correctly using images.

@Aranoh
Copy link

Aranoh commented Mar 2, 2020

also this issue post is from 2017 🤷‍♀ u can claim this is 'for personal use only' but your plugin shows up in the notpad++ plugin browser..

@Aranoh
Copy link

Aranoh commented Mar 2, 2020

i would suggest anyone looking for a markdown editor to use the "Markdown Panel" plugin that can be found through the plugin browser in notepad ++ instead.

@furuse-kazufumi
Copy link

Adding "file:///", Exactly "View" works. but "Export as" doesn't work.

@bhu1st
Copy link

bhu1st commented Jun 8, 2024

@nea here's a fix: #134

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

10 participants