The only instance when I got the Missing PDF error was when it had two file paths within the parenthesis. Try changing the position and indentation of the block. It looks like yours is a child block from citationFull.
I took a couple screenshots to show what is going on. @Aryan’s plugin correctly inserts a relative path. The item has 3 attachments and they all end up in one link, instead as 3 links, but that is no big deal, I can just delete the two extra ones manually.
I deleted the two extra attachments, icon is now shown properly, but when I click on the link, the pdf doesn’t open in Logseq, and instead I get an error message with the wrong path under assets.
As far as I understand this, the citation plugin is working fine, the problem is Logseq interpreting the relative path as an absolute path inside of assets.
when I remove file:// from the item note itself (path starting with .., I get exactly the same error message. I didn’t try “Template for file URLs in your” in your settings, just edited the file directly.
Pdf opens correctly in Logseq when I manually prepend the absolute path, i.e. file://C:\\Users\\....
You mentioned you didn’t add support for relative links, but on my system (Win 10), the plugin adds relative links (which is what it should do).
When I put in an absolute path without the file://, the Pdf opens in Acroread externally.
I don’t think so, the total absolute path length is about 100 characters, including the file://. I’ve already spent a couple of hours trying out all combinations of different paths.
Logseq does not seem to process the relative paths correctly and always assumes they are under assets. Here is someone who has a similar issue:
Does Aryan’s plugin insert full or relative paths on your system?
I guess I could automatically resolve the file paths into an absolute path. WOn’t work cross platform though. Else, you should post this bug onto githhub, seems pretty serious.
Hi Aryan, I don’t think there is anything wrong with your plugin. A relative path is clearly the better solution, otherwise the whole library will break if one uses a different path.
It looks like a bug in Logseq to me.
Actually. I think relative path is wrong. If your zotero folder was stored in the same location as the assets folder or the pages folder then it would be correct. But in this case it’s wrong as …/ in logseq will check for files in your db folder.
it’s
I just checked the paths in my .bib file. It has file paths relative to the folder of the bib file. This might be as I set a custom storage location in Zotero, maybe that is why andupaz has absolute paths.
That folder was at the same level as the top level logseq folder, so the paths would be correct as seen from this folder.
As an experiment, I exported into the assets folder, which gives relative paths starting with ../../. Logseq ignores these relative path and puts everything under assets, so it looks for logseq/assets/zotero/storage. This looks like a bug. Once this works, I think it would make sense to accept relative paths in the .bib file, but as this file might not reside in the assets folder, the paths need to be replaced by a relative path with respect to the Logseq folders.
Wow! Nice to hear that, I could definitely use these features. When I want to insert a page from zotero, the search bar is soooo slow.
maybe this is a little beyond the scope of this proposal of extension, but I want to say the pdf reading experience is not so good in current logseq.
It lacks multi tab feature, this makes reading supplementary materials and the main article at the same time an awful job to do.
And the pdf reader lacks the ability to jump back to last position. For example, I get interested about a reference mentioned in the main text, I clicked the reference linked to the end of the article, and then I get lost where I have been reading just now. Zotero, as well as many (if not all) other pdf reader have this important feature, you just press alt + left/right arrow and you can navigate through jumped positions.
The most urgent need is that use the relative path in file-path and file fields in the pdf annotation file (e.g., hls .md file) to implement pdf annotation across multiple devices, such as Mac and Windows.