HTML image media paths

[ghost]

Hi,

using pandoc 2.13 to convert epub to html with this simple command: "pandoc -s --extract-media=dnslos_files dns.epub -o dnslos.html" on Win10x64.

On previous versions pandoc produced html image locations: "img src="dnslos_files**/**" but now it is "img src="dnslos_files**\**"

Could I please ask that option to select which slash used to path be implemented in future version.

[jgm]

Sorry, I'm not sure I understand. Can you be more explicit about the difference between the paths created before and now?

[ghost]

Sorry, I'm not sure I understand. Can you be more explicit about the difference between the paths created before and now?

Yes, of course. So with pandoc 2.10 when converting epub to html image:

<p><img src="poi_files/graphics/9780133415100.jpg" /></p>

With latest pandoc:

<p><img src="poi_files\graphics\9780133415100.jpg" /></p>

HTML image tag has path differently displayed (with back slash on latest version but previously was forward slash). If we could have an option which slash to use that would be more than great.

[jgm]

I think in this context we're always going to want a forward slash. I'll have to look into it more to see what change is responsible for this.

[ghost]

I think in this context we're always going to want a forward slash. I'll have to look into it more to see what change is responsible for this.

Thanks.

[nixsee]

This has caused me a major problem as well - I do a global search/replace for \ to remove the escape character throughout my markdown files. Now that image paths use \ rather than /, this search/replace destroys all image paths. It is going to be a major problem for me (I'm not particularly good at coding) to figure out a way to exclude image paths from this search/replace, or to swap the slashes in the path before replacing the rest

edit: I've been able to figure out a workaround for this, so i suppose my comment can be ignored.

[tarleb]

Am I correct to believe that this was fixed in ddbd984a0d8ea7e75f78ad6632fe3568e2390deb?

[jgm]

I don't think that should have affected this behavior -- before we used [FilePath] and did a Posix.joinPath on extracting, which would have used / separators. Now we just use a Text, but the behavior should be the sae.

[jgm]

But someone on Windows could test?