Try remove file:// from the pdf template maybe?
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.
Strange. Might it be possible that your filepath is too long or that you have duplicate items in Zotero?
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 have absolute paths automatically inserted into mine.
interesting! I get relative paths, and those seem not to work (bug in Logseq), as discussed in another thread: Link to external pdfs in local Zotero folder and Better BibTex support
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.
The relative path issue is indeed a known bug, here is an older feature request: Relative path for Zotero data directory
I made some notes about what I think an ideal workflow should look like and also added some comments about where it breaks down currently.
2 Likes
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.
1 Like
I should better have posted this Zotero: tag imported items as imported in Zotero database here perhaps.
It would be great if LogSeq could add tags to an imported Zotero item within Zotero upon import of the item in LogSeq.
My use case was to tag items in Zotero has having been imported to LogSeq. Perhaps others would have other use of such tags.
1 Like
Thanks for that !
With new version of Zotero… il would be great to import highlights and notes into Logseq 
1 Like
Thanks for the initiative! Zotero enhancement as suggested here would also be very useful: Zotero enhancement by including citations, references and related papers
While I see your point from an engineering perspective, I beg to differ.
There’s two main reasons: workflow and attracting users.
As awesome as it is that logseq has a builtin PDF annotator, I prefer to annotate in Zotero.
To me, the layout of Zotero works better when working through a PDF.
Also, Zotero has been around for a long time now, and will likely persist.
In contrast, the note-taking/PKM scene is constantly shifting.
I myself have tried a bunch: Tiddly, Roam, Anytype, Athens, …
If the PDF annotations are locked into logseq, it’s harder to convince people to try it, as they have to fear losing them in the future. (I’m looking at you Polar …)
If, instead, one could annotate in Zotero and then just pull annotations into logseq, one has nothing to lose and everything to gain by trying logseq.
To me, that’s the ideal workflow: pull PDF into Zotero, annotate there, then pull the notes into logseq where I can use the annotations in writing by referencing the blocks, but still being able to look up where the blocks come from in the PDF via the imported highlights.
1 Like
Valid points. You’re thinking however from a consumer perspective. My thoughts are based from a logseq perspective. If fear of losing annotations is what keeps people at bay, logseq should work towards guaranteeing that this will not happen and being the PKM that masters PDF annotation.
Zotero’s annotator is perfectly fine, but you must keep in mind that it’s a different software with a team behind that is not thinking about other PKMs. The engineering perspective is the one that matters when two independent softwares must be linked to each other. It is here where you should fear losing your annotations.
Finally, outsourcing PDF annotation basically ruins the purpose of a built-in annotator in your PKM. Having a built-in annotator is there to simultaneously integrate your annotation with your existing notes, not add an additional step in your workflow.