Did anyone get {file++} links to work on windows? I added {file++} to my template, but something goes wrong with the translation from a relative to an absolute path. Logseq expands..\\zotero\\storage as /assets/zotero/storage and ignores the ...
The {file++} link contains a relative path (relative to the Logseq directory, looks ok): file://..\\zotero\\storage
when I click on the link, I get an error message Missing PDF "file:///C:/Users/path/to/logseq/assets/zotero/storage\\PIU7QTAR\\Xu_Song_2010_Some Test Document.pdf". Is this the correct path?
I am so glad about the burst of activity here, thanks @Aryan for another great plugin and everyone else here for a great ongoing discussion!
@andupaz I agree with gax points about the many further use cases a zotero API would enable
For @Aryan and @gax I would add one that is important for usability when citing from zotero in logseq:
the plugin does not enable the selection from specific zotero libraries and collections - but these are key organising principles both for individual work (eg a separate collection for paper y, project x, PhD z) as well as Group work (shared libraries with group A and B, each of which can again contain collections). Implementing this would go a long way to reedy the usability issues with citation selection mentioned above.
I am sure this is because the data is missing in the bibtex file - if it is, I am happy to bring this up with the bibtex plugin dev. Having this implemented would make the zotero plugin a solution for many zotero and logseq users
Thanks for clearing my doubts! I sure hope to see anything soon. With Aryans citation plugin now adding the PDF, Iāll be switching to it. But depending on when the comprehensive plugin will be released, Iāll have to rethink it. Lot of going back and forth.
@gax Yeah, I was able to link it in Windows. Put the {file++} in a new normal block by itself (not in properties).
Iāve just pushed a major performance improvement and fixed an issue with the reindex on startup feature. Iāll be adding support for a JSON format soon so that you wonāt have to deal with this indexing process for larger graphs.
@andupaz I tried putting the {file++} into a block by itself, but still the same problem.
The link inserted by {file++} is relative file://..\\zotero\\storage, but the error message shows an absolute path that ignores the .., it tries to find the pdf in logseq/assets/zotero/storage
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.
