Praxxian / lava-flow

A Foundry VTT module that allows you to import your notes from Obsidian MD into Foundry journal entries.
MIT License
67 stars 10 forks source link

Images uploaded, but <img> tag not set #13

Closed MisterIXI closed 1 year ago

MisterIXI commented 2 years ago

Hi, I am currently dipping my toes in Obsidian.md for the first time so I might use it wrong. The importing of non-md files also seemingly works as intended - landing in the specified folder.

But when I link an image in Obsidian it just uses the "short" version of a link without parent folders:
(Image is under one folder "pnp" from the obsidian vault) image Obsidian:

![[Vodus Whole.jpg]]  
![[Vodus_Whole_Copy.png]]
- [[Kalugan]]
- [[Rabbugia]]
- [[Kragul]]
- [[Sabanun]]
- [[Ougalan]]
- [[Xiles]]

Imported in Foundry:

<p>![[Vodus Whole.jpg]]</p>
<p>![[Vodus<em>Whole</em>Copy.png]]</p>
<ul>
<li>@JournalEntry[eG4SIGrFe71clx0g]{Kalugan}</li>
<li>@JournalEntry[27T4r7tpzcABcRAi]{Rabbugia}</li>
<li>[[Kragul]]</li>
<li>@JournalEntry[zPg9hnAAqb9PnrAO]{Sabanun}</li>
<li>[[Ougalan]]</li>
<li>[[Xiles]]</li>
</ul>

The missing links at the bottom are expected since they are placeholders. But the images are not updated. After some digging in the code I saw that importOtherFile() includes the folder path: https://github.com/Praxxian/lava-flow/blob/b62c371d0a31b308a6136610d50e30e1108a37ac/scripts/js/lava-flow.js#L203 And it seems to try and regex match the path in the link as well (e.g. replaceLink:<img src="imports/lavaflow/Vodus_Whole_Copy.png">; fileInfo.originalFilePath: pnp/Vodus_Whole_Copy.png). Changing that line to let fileInfo = new OtherFileInfo(file.name, path); Seems to partly fix the issue, cutting out the extra folder and the picture is shown in foundry:

<p><img src="imports/lavaflow/Vodus Whole.jpg" /></p>
<p>![[Vodus<em>Whole</em>Copy.png]]</p>
<ul>
<li>@JournalEntry[eG4SIGrFe71clx0g]{Kalugan}</li>
<li>@JournalEntry[27T4r7tpzcABcRAi]{Rabbugia}</li>
<li>[[Kragul]]</li>
<li>@JournalEntry[zPg9hnAAqb9PnrAO]{Sabanun}</li>
<li>[[Ougalan]]</li>
<li>[[Xiles]]</li>
</ul>

While testing around I thought that maybe the space in the name would cause an issue, but as it turns out underscores have a separate problem and get converted to italics. That probably needs adressing as well, but I think that's another topic.

Is there something I am missing that the relativePath is used instead of the name only when obsidian seemingly only uses filenames in the links? P.S. Love the module and documentation so far :)

Praxxian commented 2 years ago

Ah, I see. I ran into something similar with link substitutions because some Obsidian users use full/relative/no paths. So in some instances it will be appropriate to match file name only, and for some users I will need to match the full path. I will take a look at how to make this more flexible.

The second issue is that the MD to HTML library I am using is editing the image name itself, which seems like a bug. It could also be that Obsidian uses its own special markdown for images, but I am surprised it would alter anything inside square brackets to begin with. I will see if this is addressed in a newer version, or if I need to do some pre-processing of the file contents to make sure image sources are not edited.

MisterIXI commented 2 years ago

Ah yeah that makes sense. After changing the obsidian link generation to the absolut path it worked as intended. A seemingly simple solution for shortpath vs absolut path could be to change the regex to just accept both. !\\[\\[(${this.originalFilePath}|${this.shortpath})\\]\\] That at least mapped both version for me just now. This might cause issues with some edge cases and with multiple pictures with the same name at different positions, but it should help in the short run. A bigger problem would probably be relative paths since it uses designators like [[../pic.jpg]]. I feel like those are quite a bit more difficult to map. Using either the absolut path in obsidian or changing the code a bit is an easy workaround luckily.

And regarding the italics thing: Either way it sounds like it requires quite a bit of effort and should probably its separate issue I'm guessing. But I agree with your diagnosis.

MisterIXI commented 2 years ago

While working with the module I noticed another, kind of related problem. When two files have the same name in different folders, the import works but the link translation breaks since it only compares filenames. So from

[[Kalugan/Granhan/Bibliothek]]
[[Kalugan/Harrode/Bibliothek]]

it generates

@JournalEntry[NzJUqwfw2a3u7PwT]{Bibliothek}
@JournalEntry[NzJUqwfw2a3u7PwT]{Bibliothek}

Internally always matching full paths should resolve these issues. The shortlinks also only get used by Obsidian if the filename is unique in the whole vault, so translating those should be doable.

And while not the same issue, #15 should probably be kept in mind when rewriting of the filematching is required.

Praxxian commented 2 years ago

Apologies for the long wait. I have had some family stuff going on and have not been able to work on the project for a little while. I very much would like to get back to maintaining it, so thank you for your patience.

Praxxian commented 2 years ago

Working on v10 compatibility in #19, and that has been a great opportunity to clean up the codebase as well. I think I will have this addressed in that update since v10 supports markdown, which will simplify some things. There's already some improvements in matching all sorts of links (relative, absolute, aliases, etc). Thanks for your patience!

Praxxian commented 1 year ago

Hi and sorry for the massive delay. I just updated for v10, and I believe it fixes this issue. Assuming your Foundry is also on v10, can you update your version of Lava Flow and try it out? Thanks!

Praxxian commented 1 year ago

I know I am one to talk about waiting a long time, but since I have not received a response back in a while. I am going to close this issue. If you experience any problems on the latest version while using Foundry V10, let me know in a new ticket. Thanks!